LinuxQuestions.org
Go Job Hunting at the LQ Job Marketplace
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
LinkBack Search this Thread
Old 05-04-2013, 06:28 PM   #16
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 553

Rep: Reputation: 103Reputation: 103

Quote:
Originally Posted by Skaperen View Post
Please explain to me what you mean by "just use an right INITRD and an GENERIC kernel". It's more trouble to build an initrd image than to just hack a quick script. or is there an initrd image ready made for this?
Umm... Well, I believe that you known that Slackware have an tool to easy make INITRDs... It's called mkinitrd.

So, if we assume that your kernel is 3.8.8-smp, your root partition is an ext4 on /dev/sda2 and your swap partition is on /dev/sda3, then, like I said, an example of generation of an correct initrd is executing:

Code:
mkinitrd -c -k 3.8.8-smp -f ext4 -r /dev/sda2 -h /dev/sda3 -m usb-storage:xhci-hcd:ehci-pci:ohci-hcd:usbhid:mbcache:jbd2:ext4 -u -M -o /boot/initrd-3.8.8-smp.gz
Voila!

Then, you have just to add it to your /etc/lilo.conf.
 
Old 05-04-2013, 06:46 PM   #17
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Just remember when you have two ways to do a task, A and B, it is not always the case that everyone agrees on which is the easier. For example, if the task involved some programming, and A used the C language and B used the Python language, C programmers might find A to be easier and Python programmers might find B to be easier. For me, init scripts are easier because ... I've gone through the process of writing working (and still working on two of my machines) the entire suite of init scripts from scratch (and it's neither BSD nor SYSV style).

But I'll try mkinitrd.
 
Old 05-04-2013, 06:56 PM   #18
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 553

Rep: Reputation: 103Reputation: 103
Quote:
Originally Posted by Skaperen View Post
Just remember when you have two ways to do a task, A and B, it is not always the case that everyone agrees on which is the easier. For example, if the task involved some programming, and A used the C language and B used the Python language, C programmers might find A to be easier and Python programmers might find B to be easier.
Sure, we'll agree there. BUT, we talk about the (orthodox) Slackware-current, there, right? And I suggested to use just the official method to create INITRDs on Slackware.

Quote:
Originally Posted by Skaperen View Post
For me, init scripts are easier because ... I've gone through the process of writing working (and still working on two of my machines) the entire suite of init scripts from scratch (and it's neither BSD nor SYSV style).

But I'll try mkinitrd.
There you make me curious... And I have to ask something: we talk about a machine which use the Slackware standard init scripts and not running something written in Python, Perl or Make files, right?
 
Old 05-04-2013, 07:38 PM   #19
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by Darth Vader View Post
There you make me curious... And I have to ask something: we talk about a machine which use the Slackware standard init scripts and not running something written in Python, Perl or Make files, right?
I wrote my own init script system from scratch ten years ago. I literally started from scratch as in started emacs with empty files and started coding. By the end of the day I had something that would boot up and run. It did have a lot of noisy error messages. But it RAN! It took a few more days to get the bugs and bad messages cleaned up. Eventually I had ALL of my machines using it. Today, 2 machines remain using it. I lost interest in keeping it up to date. But I do plan to re-do something to put together a system that is udev-free.

The design of my init scripts used a scheme where the directory /etc/sys contained a list of script files named with a hybrid sequence number and run level scheme:
Code:
tesla/root /root 1# cd /etc/sys
tesla/root /etc/sys 2# ls -l
total 284
-rwxr-xr-x 1 root root  923 Apr  5  2003 000.12345.net_lo
-rwxr-xr-x 1 root root 1722 Jan  5  2008 020.--345.video_128x54
-rwxr-xr-x 1 root root  951 Apr  5  2003 040.--345.keymap
-rwxr-xr-x 1 root root 1798 Nov 14  2006 060.-2345.mouse
-rwxr-xr-x 1 root root 8620 Apr  5  2003 100.-2345.net_eth0
-rwxr-xr-x 1 root root 8620 Apr  5  2003 101.-2345.net_eth1
-rwxr-xr-x 1 root root 8620 Apr  5  2003 102.-----.net_eth2
-rwxr-xr-x 1 root root 8620 Apr  5  2003 103.-----.net_eth3
-rwxr-xr-x 1 root root 1487 Apr  5  2003 190.-2345.gw
-rwxr-xr-x 1 root root 1175 Apr  5  2003 200.--345.random
-rwxr-xr-x 1 root root 1525 Apr  5  2003 220.-2345.syslog
-rwxr-xr-x 1 root root  956 Apr  5  2003 240.--345.at
-rwxr-xr-x 1 root root  959 Apr  5  2003 260.--345.cron
-rwxr-xr-x 1 root root 1459 Jan 10  2009 300.-2345.dns
-rwxr-xr-x 1 root root 9826 Aug 20  2004 320.-----.nsd
-rwxr-xr-x 1 root root 1399 Nov 23  2003 340.-----.sdns
-rwxr-xr-x 1 root root 1219 Dec 18  2005 360.-2345.ntp
-rwxr-xr-x 1 root root 4256 Dec 31  2006 412.-2345.ssh_12
-rwxr-xr-x 1 root root 4256 Dec 31  2006 422.-----.ssh_22
-rwxr-xr-x 1 root root 4256 Dec 31  2006 432.--345.ssh_32
-rwxr-xr-x 1 root root  855 Apr  5  2003 520.-----.inet
-rwxr-xr-x 1 root root 1973 Sep 11  2003 600.-----.mail
-rwxr-xr-x 1 root root 1302 Apr  5  2003 620.-----.http
-rwxr-xr-x 1 root root 1132 Apr  5  2003 640.-----.rsync
-rwxr-xr-x 1 root root 1125 Apr  5  2003 660.-----.pop3
-rwxr-xr-x 1 root root 1294 Sep 26  2004 690.-----.stunnel
-rwxr-xr-x 1 root root 1022 Apr  5  2003 700.----5.xfs
-rwxr-xr-x 1 root root 1154 May  3  2003 780.-----.ftp
-rwxr-xr-x 1 root root 1621 Dec 14  2003 800.-----.cache
-rwxr-xr-x 1 root root 1483 Apr 21  2004 810.-----.relay_nntp
-rwxr-xr-x 1 root root 1072 Jul 15  2006 840.-----.cups
-rwxr-xr-x 1 root root 4426 Jan  5  2005 850.-----.mysql
-rwxr-xr-x 1 root root 1102 Apr  5  2003 950.----5.xdm
tesla/root /etc/sys 3#
There are no symlinks like SYSV has. The run levels for the scripts are handled by renaming them to have the desired run levels in the middle part of the name. If the run level digit is there anywhere between the first and second dot, it will be active for that run level (but will not be run at all if the run level change does not involve a change of what is being run ... so going from 2 to 3 will run the cron script in start mode, but not run the dns script at all).

I find this scheme easier because it's all in one place, and you can see how it is configured with "ls -l". Scripts being started are run in forward order. Scripts being stopped are run in reverse order.

So ... there you have the gist of it. There are some core scripts as well. They were all written from scratch. Soon, these machines will be decomissioned (one will get Slackware 14.1). It's unlikely I will run this scheme again, unless it proves valuable in making a udev-free system. But I do always end up hacking init scripts. And this is one reason I like Slackware is it plays well with people changing stuff.

edit:

Note that host "tesla" and the one next to it "faraday" running this init system have been solid and stable for years ... and have no trouble accepting hot-plugged hard drives on USB or SATA despite there being no udev on either of them. I could understand some people might want what udev does as their tool for exacting control over everything that happens. But that comes at the price of people like me just wanting it to default to the old behavior until explicitly configured otherwise.

Last edited by Skaperen; 05-04-2013 at 07:43 PM.
 
Old 05-04-2013, 08:16 PM   #20
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
It will be a little while before I test mkinitrd. I put 14.0 on in place of -current to test that (it hangs in udev). I need to put -current back on. But I have decided to do a full erase of everything except the /dev/sda9 -> /home partition, then re-install -current. Maybe get to that later tonight.
 
Old 05-04-2013, 09:23 PM   #21
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Are you sure -smp is right?
Code:
root@planck:~# mkinitrd -c -k 3.8.8-smp -f ext4 -r /dev/sda2 -h /dev/sda3 -m usb-storage:xhci-hcd:ehci-pci:ohci-hcd:usbhid:mbcache:jbd2:ext4 -u -M -o /boot/initrd-3.8.8-smp.gz
ERROR: No /lib/modules/3.8.8-smp kernel modules tree found for kernel "3.8.8-smp"
root@planck:~# ls -Al /lib/modules
total 4
drwxr-xr-x 3 root root 4096 May  3 22:06 3.8.8/
root@planck:~# uname -a
Linux planck 3.8.8 #2 SMP Thu Apr 18 22:48:10 CDT 2013 x86_64 Intel(R) Xeon(R) CPU E5-1620 0 @ 3.60GHz GenuineIntel GNU/Linux
root@planck:~#
edit:

I think 64-bit only has SMP (ever heard of a one core 64 bit CPU?), and does not have "-smp" designation.

Last edited by Skaperen; 05-04-2013 at 10:38 PM.
 
Old 05-04-2013, 09:52 PM   #22
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
So I tried it without the "-smp" ...
Code:
bash-4.2# mkinitrd -c -k 3.8.8 -f ext4 -r /dev/sda2 -h /dev/sda3 -m usb-storage:xhci-hcd:ehci-pci:ohci-hcd:usbhid:mbcache:jbd2:ext4 -u -M -o /boot/initrd-3.8.8.gz
OK: /lib/modules/3.8.8/kernel/drivers/usb/storage/usb-storage.ko added.
OK: /lib/modules/3.8.8/kernel/drivers/usb/host/xhci-hcd.ko added.
OK: /lib/modules/3.8.8/kernel/drivers/usb/host/ehci-hcd.ko added.
OK: /lib/modules/3.8.8/kernel/drivers/usb/host/ehci-pci.ko added.
OK: /lib/modules/3.8.8/kernel/drivers/usb/host/ohci-hcd.ko added.
OK: /lib/modules/3.8.8/kernel/drivers/hid/hid.ko added.
OK: /lib/modules/3.8.8/kernel/drivers/hid/usbhid/usbhid.ko added.
OK: /lib/modules/3.8.8/kernel/fs/mbcache.ko added.
OK: /lib/modules/3.8.8/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/3.8.8/kernel/fs/mbcache.ko added.
OK: /lib/modules/3.8.8/kernel/fs/jbd2/jbd2.ko added.
OK: /lib/modules/3.8.8/kernel/fs/ext4/ext4.ko added.
24276 blocks
/boot/initrd-3.8.8.gz created.
Be sure to run lilo again if you use it.
bash-4.2# lilo
Warning: LBA32 addressing assumed
Added gen-w-initrd  +  *
Added gen-n-initrd
Added huge-w-initrd  +
Added huge-n-initrd
One warning was issued.
bash-4.2#
Turns out the default install was running the huge kernel. I had believed it was not doing so previously but I'm not sure. Anyway, when I run the generic kernel with the initrd, it panics and gives a traceback. With the huge kernel it is fine. It the initrd that specific?

It seems to have no effect. The mouse still does not work. The xhci* modules are not loaded. The following from dmesg suggests something wrong:
Code:
[    0.349093] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
[    0.350480] Freeing initrd memory: 5008k freed
FYI, I reconfigured /etc/lilo.conf to have 4 different boot choices.

Last edited by Skaperen; 05-04-2013 at 10:52 PM.
 
Old 05-04-2013, 11:29 PM   #23
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
I went ahead and did the module loading in a script. It seems the "huge" kernel already has SOME of the modules in it. So ordered loading is screwed. And the "generic" kernel is bad in some way and panics before it ever gets to userland/init. I don't know why. Of course this is working with -current which has its ups and downs as the next version is coming together.

So maybe I have to fall way back to kernel building?

edit:

Here's what the two kernels have configured:

Code:
bash-4.2# egrep -i 'usb.storage|xhci.hcd|ehci.pci|ohci.hcd|usbhid' /boot/config-{generic,huge}-3.8.8
/boot/config-generic-3.8.8:CONFIG_USB_XHCI_HCD=m
/boot/config-generic-3.8.8:# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
/boot/config-generic-3.8.8:CONFIG_USB_EHCI_PCI=m
/boot/config-generic-3.8.8:CONFIG_USB_OHCI_HCD=m
/boot/config-generic-3.8.8:CONFIG_USB_OHCI_HCD_SSB=y
/boot/config-generic-3.8.8:CONFIG_USB_OHCI_HCD_PLATFORM=y
/boot/config-generic-3.8.8:# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
/boot/config-generic-3.8.8:# also be needed; see USB_STORAGE Help for more info
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE=m
/boot/config-generic-3.8.8:# CONFIG_USB_STORAGE_DEBUG is not set
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_REALTEK=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_DATAFAB=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_FREECOM=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_ISD200=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_USBAT=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_SDDR09=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_SDDR55=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_JUMPSHOT=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_ALAUDA=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_ONETOUCH=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_KARMA=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_CYPRESS_ATACB=m
/boot/config-generic-3.8.8:CONFIG_USB_STORAGE_ENE_UB6250=m
/boot/config-huge-3.8.8:CONFIG_USB_XHCI_HCD=y
/boot/config-huge-3.8.8:# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
/boot/config-huge-3.8.8:CONFIG_USB_EHCI_PCI=m
/boot/config-huge-3.8.8:CONFIG_USB_OHCI_HCD=m
/boot/config-huge-3.8.8:CONFIG_USB_OHCI_HCD_SSB=y
/boot/config-huge-3.8.8:CONFIG_USB_OHCI_HCD_PLATFORM=y
/boot/config-huge-3.8.8:# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
/boot/config-huge-3.8.8:# also be needed; see USB_STORAGE Help for more info
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE=m
/boot/config-huge-3.8.8:# CONFIG_USB_STORAGE_DEBUG is not set
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_REALTEK=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_DATAFAB=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_FREECOM=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_ISD200=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_USBAT=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_SDDR09=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_SDDR55=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_JUMPSHOT=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_ALAUDA=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_ONETOUCH=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_KARMA=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_CYPRESS_ATACB=m
/boot/config-huge-3.8.8:CONFIG_USB_STORAGE_ENE_UB6250=m
So that goes along with your urging to use generic. But generic panics.

Last edited by Skaperen; 05-04-2013 at 11:44 PM.
 
Old 05-05-2013, 03:06 AM   #24
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 5,953

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
Having just done it, I'll make suggestions on your kernel below.

Do you want to solve your problem? What's your ~#@$&! chipset? Post the output of lspci, and let people know what you're trying to set up.

For a kernel, boot the huge kernel, remove the config, switch everything you use on and connect it, and run

make localmodconfig

THEN go through that config. I had to find and add modules for webcam, card reader (under some 'staging drivers' heading) and printer as well. some things that are compiled in you won't need, but it speeds thing up mightily. I would label it 3.8.8-1 - there's a spot for a suffix in the general setup. Just make it -1. Next one becomes -2, etc. Also be aware that the slackware kernel has an intel kms driver as part of it, while the stock kernel does not. If you are using the linus kernel, go figure that first.
 
Old 05-05-2013, 09:55 AM   #25
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
See message #10 for motherboard and chipset.

See message #1 for link to lots of info including lspci (it was too much to embed in the initial question).

It looks like I was booting the huge kernel all along. It looks like the huge kernel is causing drivers to be initialized out of order because that kernel has some, but not all, of the drivers you suggested loading in a particular order. So the problem of out of order initialization is inherint in the huge kernel itself.

I tried the generic kernel, but it has another panic issue somewhere.

It looks like my next step is one of these:
1. Get the panic problem of the generic kernel fixed
2. Put all the drivers mentioned in the huge kernel (maybe it will init in the right order that way)
3. Take all the drivers mentioned out of the huge kernel (so that can be loaded as modules in order)
4. Put together a custom kernel in some way.

Which config should I remove? The one in /boot or elsewhere? Where should the "make localmodconfig" be done? Is there a special Slackware place for that, or do I just do it in the kernel source tree?

And it is still unclear if you are wanting me to do things statically in the kernel or as modules.

What all I can do is still rather limited and slow until I get it working right. Other USB things work sometimes, but sometimes not, so I have to use my SATA attached CF card slot to run my rescue device, instead of USB.

At this point I'm looking at Alien's guide to building a kernel and making a new custom one. That or just test cross-fitting the Xubuntu kernel and module set just to see what it does.

Last edited by Skaperen; 05-05-2013 at 09:56 AM.
 
Old 05-06-2013, 03:59 AM   #26
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 5,953

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
Intel C602 Sandy Bridge chipset. I'm not familiar at all with it, but others will be. Intel's hardware is usually straight down the line.

In your option list, I would do 1. or 4., not 2, or 3. 2 or 3 might be a faster route, but they might never sort it.

Your problem with the generic kernel is simply that you haven't made an initrd to suit. You need modules for filesystem(ext4 or whatever), motherboard chipset, usb [x|e|u]hci_hcd, and anything else you need to get onto the root filesystem. The initrd is mounted on / and the kernel grabs modules from there until your root partition is mounted over it on / and the module tree becomes available.

A problem with the huge kernel is that ohci (which you don't want) is compiled in, whereas uhci is just a module. You get a kernel source (FYI, the slackware 3.8.8 kernel source in current has the intel graphics driver added) cd to top source, and work from there. A good start would be
Quote:
make mrproper
make localmodconfig (with everything connected & switched on)
make menuconfig
Then go through it. You won't have 500 webcam modules of which yours is one. You are inclined to have the right module.

As for the lspci, there is a Nvidia card in there as well. the kernel offers some laptop gpu switching option at this stage so maybe we're catching up.
 
Old 05-06-2013, 08:58 PM   #27
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by business_kid View Post
Intel C602 Sandy Bridge chipset. I'm not familiar at all with it, but others will be. Intel's hardware is usually straight down the line.
It's very new. Has more USB via 2 controllers. Has PS/2 but I don't know if it's the chipset that is limiting things to one PS/2 port. It has quad channel memory paths (better than triple channel).

Quote:
Originally Posted by business_kid View Post
In your option list, I would do 1. or 4., not 2, or 3. 2 or 3 might be a faster route, but they might never sort it.
I would have hoped the USB driver author(s) would know what they are doing and have it work right if all of the needed drivers are built in statically.

Quote:
Originally Posted by business_kid View Post
Your problem with the generic kernel is simply that you haven't made an initrd to suit. You need modules for filesystem(ext4 or whatever), motherboard chipset, usb [x|e|u]hci_hcd, and anything else you need to get onto the root filesystem. The initrd is mounted on / and the kernel grabs modules from there until your root partition is mounted over it on / and the module tree becomes available.
The generic kernel panics before userland. The initrd is userland. It never gets there to have any chance to load modules. I've installed SYSLINUX boot loader, now, and can set this to go to 48 line mode and maybe I'll be able to see the cause of the panic.

My previous Slackware systems don't need or have an initrd and their USB works (there's no XHCI involved, though). I did not pay attention to whether they are statically built in or loaded as modules, but USB does work. I do know how initrd fundamentally works, as well as loading modules. But I have not needed initrd on Slackware before because the basics have always been there in generic and huge ... enough to get to the point where modules fill in the rest.

Quote:
Originally Posted by business_kid View Post
A problem with the huge kernel is that ohci (which you don't want) is compiled in, whereas uhci is just a module. You get a kernel source (FYI, the slackware 3.8.8 kernel source in current has the intel graphics driver added) cd to top source, and work from there. A good start would be
So does this mean my USB 1.1 devices won't work?

Wikipedia says XHCI supports ALL device speeds. So I guess 1.1 won't be a problem if we can get it to work. So in theory XHCI is all that I need. But the other drivers like OHCI are interfering?

My graphics is working fine so far. The nouveau driver loaded, switch the text screen to frame buffer mode, and Slackware loaded some fonts that gave a 240x75 text display in 1920x1200 pixels. The installer did a larger font that actually looked nice (I'll figure out which it is later).

Quote:
Originally Posted by business_kid View Post
Then go through it. You won't have 500 webcam modules of which yours is one. You are inclined to have the right module.
I don't have a webcam so I won't need this.

Quote:
Originally Posted by business_kid View Post
As for the lspci, there is a Nvidia card in there as well. the kernel offers some laptop gpu switching option at this stage so maybe we're catching up.
I'm plugged into 1 of 2 ports of that NVIDIA card and all looks well in the display department so far.
 
Old 05-06-2013, 09:27 PM   #28
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 836

Rep: Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620Reputation: 1620
Quote:
Originally Posted by business_kid View Post
A problem with the huge kernel is that ohci (which you don't want) is compiled in, whereas uhci is just a module.
Actually, OHCI is also a module in the -current huge kernel for a couple of kernel versions now.
 
Old 05-07-2013, 12:19 AM   #29
Skaperen
Senior Member
 
Registered: May 2009
Location: WV, USA
Distribution: Slackware, CentOS, Ubuntu, Fedora, Timesys, Linux From Scratch
Posts: 1,777
Blog Entries: 20

Original Poster
Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by volkerdi View Post
Actually, OHCI is also a module in the -current huge kernel for a couple of kernel versions now.
Right now (before I have compiled a kernel) I have this:
Code:
bash-4.2# egrep -i 'ohci|uhci|ehci|xhci' < /boot/config-generic-3.8.8         
CONFIG_FIREWIRE_OHCI=m
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_XHCI_HCD=m
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_SSB=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_EHCI_HCD_PLATFORM=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
bash-4.2# egrep -i 'ohci|uhci|ehci|xhci' < /boot/config-huge-3.8.8         
CONFIG_FIREWIRE_OHCI=m
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB_ARCH_HAS_XHCI=y
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_HCD_DEBUGGING is not set
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=m
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_HCD_SSB=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_EHCI_HCD_PLATFORM=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_FIREWIRE_OHCI_REMOTE_DMA is not set
bash-4.2#
I believe I definitely need to get UHCI and OHCI out of it, and possibly also EHCI. XHCI is supposed to be able to handle all the speeds in one, whereas the others only handled their respective speeds only. The BIOS on this motherboard does have an option to enabled or disable "EHCI handoff" (whatever that really is). I've tried with that enabled and disabled and so far it seems to have no effect either way. It may have an effect when the only drivers are EHCI and XHCI. But my first goal will be to omit all 3 of UHCI, OHCI, EHCI and just go with XHCI alone.

If that works, it could complicate how to set up kernels. On hosts without XHCI, which run from USB storage devices, a kernel without EHCI could not get to the root device. It would have to be there for all those systems older than a few months or so. I still need to see if that causes problems and if it does, if the BIOS setting above can get around it.

So it looks like I'll go build a couple kernels based on the huge kernel config, tweaked to have in one case just XHCI alone, and in the other have XHCI and EHCI combined, and blacklist OHCI and UHCI for testing them.

I spent today switching to the EXTLINUX boot loader and did not work on the USB issues.
 
Old 05-07-2013, 03:46 AM   #30
business_kid
Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware & Android
Posts: 5,953

Rep: Reputation: 496Reputation: 496Reputation: 496Reputation: 496Reputation: 496
To prevent modules loading you can
1. put them in /etc/modprobe.d/blacklist

They still just might load, so you can also have some usb.conf in /etc/modprobe.d with lines like

Code:
install ohci_hcd /sbin/modprobe xhci_hcd
The 'install command offers an alternative action when the command to load that module comes along.

Using those two, you should be able to experiment with all the modules one by one.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Slackware current x64 dbus related issue kkmic Slackware 2 12-15-2010 03:37 AM
FC10 nvidia troubles and other related issues bocochoco Fedora 6 12-15-2008 05:58 PM
Second Life Troubles - libexpat related Ariata Linux - Games 2 10-14-2006 09:01 PM
Xauthority timeout problem and hard drive partition troubles (related) W0bbles Linux - General 1 12-31-2005 08:56 PM
current Slack-Current giving troubles? r_jensen11 Slackware 5 02-02-2004 05:08 PM


All times are GMT -5. The time now is 09:31 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration