Tpowa's "Simple Hardware Detection"

lilsirecho · 2005-11-24 20:11:39

tpowa;
Corrected the ushid entry and no change occurred on reboot...still no usb mouse and keyboard.

Suspect that KDE requires rc.conf modules rather than hwdetect-initscripts.

Will restore rc.conf~ in place of rc.conf in arch CD chroot and reboot.

tpowa · 2005-11-24 20:15:52

could you send me your kernel.log? then it is perhaps easier to see where the problem is.
please zip it, thanks
greetings
tpowa

lilsirecho · 2005-11-24 20:35:30

tpowa;

Restored rc.conf modules without ne2k-pci. System booted with USB available but no network.

Restore ne2k-pci in rc.conf and rebooted. Now back on kernel 2.6.13 with USB enabled.

Please advise how to provide the data you request regarding kernel

EDIT: kernel log found in /var/log

Do I e-mail this?

tpowa · 2005-11-24 21:34:48

yes this kernel log and does unplugging and replugging get the keyboard working?

lilsirecho · 2005-11-24 21:39:43

The kernel 2.6.13 with rc.conf reinstalled with the modules it had originally permits the re-boot into arch kde with both mouse and keyboard functional.

I am unable to address the kernel 2.6.14 problem at this time.

I will attempt to e-mail the kernel log as you requested.....

lilsirecho · 2005-11-24 23:54:18

tpowa;

I installed the same rc.conf modules into kernel 2.6.14 system via the arch 0.7.1 CD.

The system is now up and running in both kernels. The USB turned on during the load sequence well before KDE sequences and remained on after KDE loaded.

KMplayer now plays using USB audio. The kmixer has no pci optionas it should. The data below is the present state of rc.conf modules.
============================================================
MODULES=(!usbserial !ide-scsi ne2k-pci snd-usb-audio snd-lib-usb
ehci-hcd usbhid snd-pcm-oss audio uhci-hcd)

Don't know why kmplayer is now performing!!

lilsirecho · 2005-11-25 02:09:15

tpowa;

You requested kernel log in zip format.

I have gzipped the kernel log and it is 1GB in size.

Please advise!

tpowa · 2005-11-25 06:41:11

wow congrats
ok then just move your existing kernel log to somewhere else and boot again, then it should be 20k or somehting like that.
greetings
tpowa

lilsirecho · 2005-11-25 07:05:13

Thanks for the tip. Gzip log is now 5.7kb.

Don't have your e-mail address.

Shall I send it PM?

tpowa · 2005-11-25 10:51:01

just try my name and archlinux.org

tpowa · 2005-11-25 15:55:47

Does it help when you add ehci-hcd uhci-hcd usbhid to modules array?

lilsirecho · 2005-11-25 18:52:28

tpowa;

Entered the change you requested into both kernel systems.

Rebooted the kernel 2.6.13 version and verified it had the change in rc.conf.

Then performed the same change in kernel 2.6.14 system..

Went back to system 2.6.13 to e-mail you of the result(s).

System 2.6.13 now failed on this reboot as before with no USB mouse or keyboard and the arts information message. During boot, error messages occur at rapid rate, one indicating no internet. Arch logo and log-in is possible with the keybd but following kde boot sequence, the mouse/keyboard dies.

During boot of 2.6.14, fatal messages....module audio not found...snd-lib-usb not found.

Kmplayer responds in 2.6.14 using USB audio...mplayer in same system does not perform.

I am in Knoppix with no e-mail setup so had to respond via arch forum.

I will re-install the original rc.conf again to get 2.6.13 re-started.

lilsirecho · 2005-11-25 19:55:09

I include this post to report that the failure to boot in the 2.6.13 system was caused by the loss of MODULES listing in rc.conf.

This may be of interest to other users.

EDIT: an :oops: also...error in entry of MOD_AUTOLOAD=yes in rc.conf :oops:

andyprior · 2005-11-27 13:33:06

'hwdetect --show-net' shows both 3c59x and nvnet modules. 'lsmod' shows that they are loaded. However, nvnet does not activate the nic.

If I remove both modules with 'modprobe -r 3c59x' and' modprobe -r nvnet' then re-install with 'modprobe nvnet' and 'modprobe 3c59x', both nics are activated. If the module installation order is reversed, nvnet fails to activate.

forcedeth behaves in the same way.

It appears that order is important and that hwdetect does it the wrong way round for my mobo with built-in 3com and nforce interfaces.

Any ideas or is it back to hotplug for me.

tpowa · 2005-11-27 14:27:50

well, you could load the modules in modules array in correct order, hwdetect loads modules in alphabetical order.
modules= has priority over hwdetect.
greetings
tpowa

andyprior · 2005-11-28 04:07:47

Tried that before and just tried it again with the same result - system freeze on starting CUPS daemon during reboot. However, on this occasion and by mistake, I rebooted a second time without changing anything. Now everything seems to work.

Can't explain it but the behaviour is repeatable.

Thanks for the reply.

Dusty · 2005-11-28 04:48:39

I think perhaps this script has caused more trouble than its worth.... maybe 'simple' isn't the right word for it?

Dusty

tpowa · 2005-11-28 06:22:45

Dusty, last fixes where needed for people with old or unusual setups, i can't test more then on my systems and on my systems it runs clean.
Hope now all showstoppers are fixed.
And Dusty lislricho's errors come from a wrong rc.conf entry and was not a fault by hwdetect at all.
greetings
tpowa

iphitus · 2005-11-28 08:12:37

From what i've read, most of the problems come from the script causing the system to simply not boot.

A simple workaround would be to setup a timeout, if the script doesnt finish within say... a minute, the system will continue to boot.

this is somewhat hackish.... but its a try.

/sbin/hwdetect &
sleep 90
pid=`pgrep hwdetect`
if [ $? = 0 ]; then
echo "There has been an error in this script. Do something about it"
sleep 10
kill $pid
fi

and at the end of hwdetect, kill `pgrep sleep`

As you can see, it starts the script in background, waits for 90 seconds, checks if its still running, and kills it. Conversely if the hwdetect finishes before the 90 seconds, it kills the sleep process.

Yes it's hacky, yes it's very icky. And yes, you should change the message. But it should work. And it will make sure this thing runs for everyone. The timeout is deliberately long so that people realise that something has gone wrong, and so that hwdetect wont be killed when its honestly still running.

At least in unusual configurations that you cant handle, or for new users to arch with such configurations who wont even know how to disable it, it won't prevent the system from booting.

iphitus

tpowa · 2005-11-28 13:04:11

iphitus, the hangs come from for i in; do ;done when empty files were processed, now 2 checks were added and this hangs should be history
greetings
tpowa

shadowhand · 2005-11-28 21:28:16

hwdetect doesn't work on my system. It simply gives the following error then dies without loading any modules:

cat: /sys/bus/pnp/drivers/ide: Is a directory

Moo-Crumpus · 2005-11-28 21:45:20

hwdetect stucks recognizing modules on my system, tpowa. Which informations do you need or what can I do?

tpowa · 2005-11-28 22:41:41

checkout new hwdetect from cvs, i think now we got all you custom kernel users
http://cvs.archlinux.org/cgi-bin/viewcv … ot=Current
greetings
tpowa

andyprior · 2005-11-29 04:55:27

No you haven't ! Using 0.7.1-15:

I continue to get hangs intermittently during boot-up at different places in the sequence.

This is not a custom kernel, its a plain, out-of-the box 2.6.13. If its of any help, I have noticed that if the MOD_BLACKLIST and MODULES arrays are empty no hanging on boot occurs. But as soon as these arrays contain data the boot process will hang. Simply re-re-booting will often work but not always.

I am not convinced that this script is yet sufficiently robust for mainstream use.

shadowhand · 2005-11-29 05:39:08

Even after upgrading, it still doesn't work on my system. No output at all, even with 'hwdetect -show-modules'.

Arch Linux

#101 2005-11-24 20:11:39

Re: Tpowa's "Simple Hardware Detection"

#102 2005-11-24 20:15:52

Re: Tpowa's "Simple Hardware Detection"

#103 2005-11-24 20:35:30

Re: Tpowa's "Simple Hardware Detection"

#104 2005-11-24 21:34:48

Re: Tpowa's "Simple Hardware Detection"

#105 2005-11-24 21:39:43

Re: Tpowa's "Simple Hardware Detection"

#106 2005-11-24 23:54:18

Re: Tpowa's "Simple Hardware Detection"

#107 2005-11-25 02:09:15

Re: Tpowa's "Simple Hardware Detection"

#108 2005-11-25 06:41:11

Re: Tpowa's "Simple Hardware Detection"

#109 2005-11-25 07:05:13

Re: Tpowa's "Simple Hardware Detection"

#110 2005-11-25 10:51:01

Re: Tpowa's "Simple Hardware Detection"

#111 2005-11-25 15:55:47

Re: Tpowa's "Simple Hardware Detection"

#112 2005-11-25 18:52:28

Re: Tpowa's "Simple Hardware Detection"

#113 2005-11-25 19:55:09

Re: Tpowa's "Simple Hardware Detection"

#114 2005-11-27 13:33:06

Re: Tpowa's "Simple Hardware Detection"

#115 2005-11-27 14:27:50

Re: Tpowa's "Simple Hardware Detection"

#116 2005-11-28 04:07:47

Re: Tpowa's "Simple Hardware Detection"

#117 2005-11-28 04:48:39

Re: Tpowa's "Simple Hardware Detection"

#118 2005-11-28 06:22:45

Re: Tpowa's "Simple Hardware Detection"

#119 2005-11-28 08:12:37

Re: Tpowa's "Simple Hardware Detection"

#120 2005-11-28 13:04:11

Re: Tpowa's "Simple Hardware Detection"

#121 2005-11-28 21:28:16

Re: Tpowa's "Simple Hardware Detection"

#122 2005-11-28 21:45:20

Re: Tpowa's "Simple Hardware Detection"

#123 2005-11-28 22:41:41

Re: Tpowa's "Simple Hardware Detection"

#124 2005-11-29 04:55:27

Re: Tpowa's "Simple Hardware Detection"

#125 2005-11-29 05:39:08

Re: Tpowa's "Simple Hardware Detection"

Board footer