Am 05.03.2010 23:12, schrieb Ihad:
> Hi,
>
> Maybe this is more suitable for arch-dev, but I hope that the devs also read
> here. Let me know if I should redirect this to arch-dev-public.
arch-dev-public is read-only for non-developers.
> The rebuilding device has devices connected to the PCI controller. All other
> devices are handled by sis5513, btw. also from /lib/modules/*/ide
>
> The autodetect hook from mkinitcpio thinks that pata_hpt366 is the module of
> choice. But it doesn't work. It crashes the kernel after some time,
> unfortunately not reproducible and without a log message. The box just stops
> responding to anything, including a ping. So I guess this something like a
> kernel panic.
>
> The IDE driver (hpt366) works like a charm, but it doesn't seem to generate
> udev events, so the device nodes don't get created in the initrd, and I'm
> stuck with a busybox prompt. So I created my own hook in /lib/initcpio/hooks:
> # cat ide
> run_hook ()
> {
> msg -n ":: Creating IDE device nodes"
> /bin/mknod "/dev/hda" b 3 0
> /bin/mknod "/dev/hda1" b 3 1
> /bin/mknod "/dev/hda2" b 3 2
> /bin/mknod "/dev/hdb" b 3 64
> /bin/mknod "/dev/hdb1" b 3 65
> /bin/mknod "/dev/hdb2" b 3 66
> /bin/mknod "/dev/hdc" b 22 0
> [snip]
> /bin/mknod "/dev/hdg2" b 34 2
> msg "done."
> }
> and included it into my hooks. Works like a charm.
>
> Now my question: is this expected behavior or is it a bug? If it's a bug,
> where should I file it? LKML or against arch/mkinitcpio? LKML is a problem,
> since I don't have any a trace. BTW, pata_hpt366 is marked as experimental in
> 2.6.30. at least.
Some rules with respect to IDE devices were in fact removed in a
previous udev version. In fact, almost nobody still uses the IDE
subsystem, most(!) drivers work better with the ATA subsystem these days.
However, these "standard" nodes should still be created, there should be
no special udev rules required for them. I am a bit unsure how to debug
this. Are the device nodes created when root is mounted and Arch is
booted? Are they created when you boot with the break=y option and wait
for a while?
I am wondering if we can somehow monitor the uevents at this early stage
of the boot process to see what goes wrong.
Attachment:
signature.asc
Description: OpenPGP digital signature
