ide-disk, ide-cd, ide-floppy, ide-generic are not autoloaded

Created an attachment (id=202)
lspci, lspci-n and dmesg output

What kind of disks does it have? Both IDE and SCSI?

Sounds like https://bugzilla.ubuntu.com/show_bug.cgi?id=1400
which was fixed. Did you use a recent daily?

Yes, this is the same bug. The machine has a scsi boot disk, and additional ide
devices.

It was an upgrade from old-sid or woody, I think.

I needed to manually tell it about udev and hotplug.

At what point should /etc/modules have been modified during the upgrade? New
kernel? New udev? New hotplug? Either way, it wasn't :-)

This is the udev "chicken-and-egg" problem: with static or devfs /dev, the
module would be automatically loaded upon the first access to the block device
node. However, with udev, the device node is not created until the device is
activated in the kernel (exactly the reverse). The way that we work around this
in Warty is to add the necessary modules
to /etc/modules during the installation, but for upgrades, we can't do this.

This is one of the things that the administrator needs to change when switching
to udev, and should be documented as such. If we could solve it in some
automatic fashion, though, then we could also remove the workaround from d-i
used to fix Bug #8156.

Herbert, what is the upstream position on this issue? Is there a proposed
solution to arrange for these modules to be automatically loaded when using udev?

(In reply to comment #4)
> Herbert, what is the upstream position on this issue? Is there a proposed
> solution to arrange for these modules to be automatically loaded when using udev?

The position in general is that the module should be loaded by hotplug.

For IDE in particular, the problem is that IDE modularisation is still fairly
broken at the moment. In particular, the fact that the onboard chip can be
enabled by both ide-core and the chipset specific driver is the issue here.
Otherwise we could simply load ide-generic unconditionally after ide-core.

One workaround would be to get hotplug to always load ide-generic after loading
an IDE chipset driver, e.g., something in kernel/drivers/ide/pci/*.

Correct me if I misunderstand, but I think the change from "sr" to "scd" needs
to be changed in the sysfs interface exported by the driver, while udev can
handle creating the sr -> scd symlinks

We're talking about disks here so I don't understand your commend re sr/scd.

That comment should have gone to bug #8646

(In reply to comment #5)
> For IDE in particular, the problem is that IDE modularisation is still fairly
> broken at the moment. In particular, the fact that the onboard chip can be
> enabled by both ide-core and the chipset specific driver is the issue here.
> Otherwise we could simply load ide-generic unconditionally after ide-core.
>
> One workaround would be to get hotplug to always load ide-generic after loading
> an IDE chipset driver, e.g., something in kernel/drivers/ide/pci/*.

That workaround doesn't sound too bad. If we arrange for ide-generic to be
loaded, does that take care of ide-cd and ide-disk as well, if needed? I am
under the impression that those modules are not automatically loaded either.

Yes once ide-generic starts the probing process drivers like ide-disk/ide-cd
will be loaded automatically.

*** Bug 8939 has been marked as a duplicate of this bug. ***

*** Bug 9517 has been marked as a duplicate of this bug. ***

*** Bug 8325 has been marked as a duplicate of this bug. ***

*** Bug 8427 has been marked as a duplicate of this bug. ***

*** Bug 9824 has been marked as a duplicate of this bug. ***

*** Bug 10791 has been marked as a duplicate of this bug. ***

(In reply to comment #10)
> Yes once ide-generic starts the probing process drivers like ide-disk/ide-cd
> will be loaded automatically.

I finally got around to testing your proposed approach, and this doesn't seem to
be the case. I arranged for ide-generic to be loaded immediately after any
drivers/ide/pci driver, and yet ide-disk and ide-cd were never loaded.

Marco d'Itri proposed a solution here:
http://article.gmane.org/gmane.linux.hotplug.devel/6003 which seems like exactly
what I thought should be done to address the issue of loading ide-cd, ide-disk, etc.

Marco, do you plan to integrate this into the Debian hotplug package? There
seemed to be relatively little feedback on the hotplug devel list, but it seems
like the right thing to me.

Also interesting is this bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=280112

which alleges that it should not be necessary to load ide-generic. Can someone
confirm this?

*** Bug 8882 has been marked as a duplicate of this bug. ***

Created an attachment (id=1015)
hotplug ide.rc

Attaching ide.rc from Marco d'Itri

Created an attachment (id=1016)
New hotplug.init needed to implement ide.rc

Attaching hotplug.init from Marco d'Itri

I see two ways forward with this bug:

1. Extend hotplug to load the modules in the particular manner required by the
current kernel

2. Drop the modular-ide patch, which seems to be the cause (and thus the reason
why no one else seems bothered by this)

(2.) has the advantage of being far simpler. Can anyone speak on behalf of the
modular-ide patch, and what benefits it provides that justify the additional
effort and complexity of (1.) ?

*** Bug 10362 has been marked as a duplicate of this bug. ***

The reason why the (pci) drivers require ide-generic to load is because they
don't actually register w/ the pci subsystem. Most pci drivers will call
pci_register_driver(), which allows the pci subsystem to check the pci bus for
the devices that the driver can handle, and call the driver's probe callback.
Instead, what the ide pci drivers do is call ide_pci_register_driver(); this
allows the ide subsystem to keep a local list of all ide drivers, and then
register the ide drivers w/ the pci subsystem once ide-generic is loaded. This
is done so that ordering of drivers is done; individual ide controller drivers
get priority for devices, and if a driver is not found for a controller, the
generic ide driver is used.

In the code; ide-generic calls ide_scan_pcibus, which first scans for devices in
need of an ide driver (ide_scan_pcidev), and then registers each driver w/ the
pci subsystem. Bartlomiej Zolnierkiewicz has posted some interesting patches to
lkml (http://thread.gmane.org/gmane.linux.ide/2974) which may end up being the
proper way to solve this problem. I will play w/ it a bit and see how it goes.

(In reply to comment #25)
> In the code; ide-generic calls ide_scan_pcibus, which first scans for devices in
> need of an ide driver (ide_scan_pcidev), and then registers each driver w/ the
> pci subsystem. Bartlomiej Zolnierkiewicz has posted some interesting patches to
> lkml (http://thread.gmane.org/gmane.linux.ide/2974) which may end up being the
> proper way to solve this problem. I will play w/ it a bit and see how it goes.

Thanks for the details and status update. Fabio can work with you to build
Ubuntu kernels suitable for testing with any candidate patches for this bug, and
Jeff says that he is close to having the hotplug ide.rc infrastructure ready to
deploy

Created an attachment (id=1302)
Diff to current init that only uses tools available in d-i's busybox

This patch adds two shell functions to deal with the problem. Marco's patch
requires the use of tsort and tac. A couple problems:

1) They're in /usr, so not necessarily available at boot time
2) They're not in busybox, so this wouldn't work for d-i.

Created an attachment (id=1303)
ide.rc done as a file for debian/patches

Created an attachment (id=1306)
Try #2 - Remove debugging echo's.

Work around uploaded as hotplug 0.0.20040329-16ubuntu11. This work around deals
with the coldplugging case primarily. Ordering is applied to make sure that PCI
and USB are loaded before IDE, so specific drivers ought to be loaded always
before ide-generic.

dilinger says that this is really a kernel bug, and that it ought to actually
work. Setting this bug to 'remind' so that I can help hunt that down.

I've made a similar change in rootskel:

rootskel (1.11ubuntu8) hoary; urgency=low

  * When starting up hotplug, make sure that ide.rc is called after pci.rc
    and usb.rc. Mirrors hotplug 0.0.20040329-16ubuntu11.

 -- Colin Watson <email address hidden> Fri, 25 Feb 2005 11:33:01 +0000

I haveamachine with SATA drives that cannot see it's CDROM drive. The system is
fully installed and working. Could this be the same bug or should I file a new one?

During boot I see some messages like:

ide0: I/O resource 0x1F0-0x1F7 not free.
ide0: ports already in use, skipping probe
ide1: I/O resource 0x170-0x177 not free.
ide1: ports already in use, skipping probe

In /etc/modules I have ide-cd, ide-disk and ide-generic.

After boot, there are no /dev/hd* entries at all.

(In reply to comment #32)
> I haveamachine with SATA drives that cannot see it's CDROM drive. The system is
> fully installed and working. Could this be the same bug or should I file a new
one?

That's bug #8196 (CCing you on it)

Matt I'm not certain it's the same bug. 1440 is a bug during the install, this
is happening after install.

(In reply to comment #34)
> Matt I'm not certain it's the same bug. 1440 is a bug during the install, this
> is happening after install.

Thanks to Colin's work for Hoary, they both use the same hardware detection code now

*** Bug 14497 has been marked as a duplicate of this bug. ***

re: bug 14497

removing the ide-* modules from /etc/modules, they don't get loaded
automatically and i'm left without access to my IDE drives because their device
files don't get created.

(In reply to comment #37)
> re: bug 14497
>
> removing the ide-* modules from /etc/modules, they don't get loaded
> automatically and i'm left without access to my IDE drives because their device
> files don't get created.

Are you running a recently upgraded version of hoary? If yes, can you please
provide the output of dpkg -l hotplug, and ls -al /proc/ide

Tks,
Jeff Bailey

Yeah, I update this machine with the latest Hoary packages regularly.

simon@bainbridge:~$ dpkg -l hotplug
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii hotplug 0.0.20040329-1 Linux Hotplug Scripts
simon@bainbridge:~$ ls -al /proc/ide
total 3
dr-xr-xr-x 4 root root 0 2005-03-31 01:55 .
dr-xr-xr-x 129 root root 0 2005-03-28 00:55 ..
-r--r--r-- 1 root root 0 2005-03-31 01:55 amd74xx
-r--r--r-- 1 root root 0 2005-03-31 01:55 drivers
lrwxrwxrwx 1 root root 8 2005-03-31 01:55 hda -> ide0/hda
lrwxrwxrwx 1 root root 8 2005-03-31 01:55 hdb -> ide0/hdb
lrwxrwxrwx 1 root root 8 2005-03-31 01:55 hdc -> ide1/hdc
dr-xr-xr-x 4 root root 0 2005-03-31 01:55 ide0
dr-xr-xr-x 3 root root 0 2005-03-31 01:55 ide1

This is with the ide-* modules uncommented in /etc/modules. If you want the same
output with them commented out just ask.

(In reply to comment #39)

> This is with the ide-* modules uncommented in /etc/modules. If you want the same
> output with them commented out just ask.

Please.

simon@bainbridge:~$ dpkg -l hotplug
ii hotplug 0.0.20040329-1 Linux Hotplug Scripts

simon@bainbridge:~$ ls -al /proc/ide
total 0
dr-xr-xr-x 2 root root 0 2005-04-06 14:22 .
dr-xr-xr-x 93 root root 0 2005-04-06 14:21 ..
-r--r--r-- 1 root root 0 2005-04-06 14:22 drivers

simon@bainbridge:~$ cat /etc/modules
amd74xx
#ide-cd
#ide-disk
#ide-generic
#lp
mousedev
#psmouse
rtc
nvidia

simon@bainbridge:~$ lsmod
Module Size Used by
ipv6 268512 8
video 18760 0
sony_acpi 6864 0
pcc_acpi 13568 0
button 7776 0
battery 11400 0
container 5120 0
ac 5640 0
tsdev 8768 0
usbhid 34176 0
forcedeth 18880 0
snd_intel8x0 35584 1
snd_ac97_codec 80992 1 snd_intel8x0
snd_pcm_oss 56676 0
snd_mixer_oss 20288 2 snd_pcm_oss
snd_pcm 102348 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_timer 26184 1 snd_pcm
snd 58600 6
snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore 11360 2 snd
snd_page_alloc 11400 2 snd_intel8x0,snd_pcm
ehci_hcd 33604 0
ohci_hcd 22408 0
pcspkr 4024 0
evdev 10688 0
reiserfs 253680 0
nls_cp437 7232 1
ntfs 102400 1
capability 5832 0
commoncap 9536 1 capability
nvidia 4569404 0
rtc 13320 0
mousedev 13148 1
amd74xx 15472 0
ide_core 150276 1 amd74xx
ext3 140560 1
jbd 61104 1 ext3
mbcache 9160 1 ext3
sd_mod 18584 4
sata_nv 9860 3
libata 55560 1 sata_nv
scsi_mod 143448 2 sd_mod,libata
unix 30016 626
thermal 15692 0
processor 26432 1 thermal
fan 5256 0
fbcon 38688 0
font 8960 1 fbcon
bitblit 5888 1 fbcon
vesafb 7680 0
cfbcopyarea 4288 1 vesafb
cfbimgblt 3200 1 vesafb
cfbfillrect 4288 1 vesafb

Okee. Looks like sata_nv needs the ide-generic workaround the same way we did
sata_via

Can you please post the output of lspci and lspci -n?

Reopening bug, targetting 5.10.

simon@bainbridge:~$ lspci
0000:00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
0000:00:01.0 ISA bridge: nVidia Corporation: Unknown device 0050 (rev a3)
0000:00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
0000:00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
0000:00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
0000:00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
0000:00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
0000:00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
0000:00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
0000:00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
0000:00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
0000:00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Address Map
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
DRAM Controller
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
0000:01:00.0 VGA compatible controller: nVidia Corporation: Unknown device 0141
(rev a2)

simon@bainbridge:~$ lspci -n
0000:00:00.0 0580: 10de:005e (rev a3)
0000:00:01.0 0601: 10de:0050 (rev a3)
0000:00:01.1 0c05: 10de:0052 (rev a2)
0000:00:02.0 0c03: 10de:005a (rev a2)
0000:00:02.1 0c03: 10de:005b (rev a3)
0000:00:04.0 0401: 10de:0059 (rev a2)
0000:00:06.0 0101: 10de:0053 (rev a2)
0000:00:07.0 0101: 10de:0054 (rev a3)
0000:00:08.0 0101: 10de:0055 (rev a3)
0000:00:09.0 0604: 10de:005c (rev a2)
0000:00:0a.0 0680: 10de:0057 (rev a3)
0000:00:0b.0 0604: 10de:005d (rev a3)
0000:00:0c.0 0604: 10de:005d (rev a3)
0000:00:0d.0 0604: 10de:005d (rev a3)
0000:00:0e.0 0604: 10de:005d (rev a3)
0000:00:18.0 0600: 1022:1100
0000:00:18.1 0600: 1022:1101
0000:00:18.2 0600: 1022:1102
0000:00:18.3 0600: 1022:1103
0000:01:00.0 0300: 10de:0141 (rev a2)

Good and bad(ish) news. I've started tracking Breezy and I was pleased to notice
on my last reboot that my IDE drives were found and mounted. The problem is that
my samba share (which was working before) wasn't. Just like the IDE problem,
mounting it manually works fine.

I'm assuming the seemingly simultaneous fix + breakage are related.

(In reply to comment #44)
> Good and bad(ish) news. I've started tracking Breezy and I was pleased to notice
> on my last reboot that my IDE drives were found and mounted. The problem is that
> my samba share (which was working before) wasn't. Just like the IDE problem,
> mounting it manually works fine.
>
> I'm assuming the seemingly simultaneous fix + breakage are related.

There's no reason they should be related - getting the IDE devices to be auto
detected was a matter of making sure the IDE drivers were actually loaded.

Please file a new bug for this problem. Thanks! (closing this bug)