Remi Turk wrote:
> > Ok, the problem is that you have an interrupt router table for your Ali
> > 1533, but no interrupt router entry for your IDE device.  That's why
> > pci_enable_device is failing.
> >
> > Would you mind testing two kernel patches for me?  Both of these changes
> > should be attempted separately in 2.4.0-test10-pre6, and -without-
> > Andre's change.
> >
> > The first change attempts to build an interrupt router entry for you, if
> > none is available.  I am most interested if this works.
> >
> > The second change simply ignores any pci_enable_device error returns,
> > and assumes that the IDE subsystem will pick up the pieces.
> >
> > Remember, do not apply both of these changes at the same time...
> >
> > Thanks,
> >
> >         Jeff
> 
> The second patch (the one ignoring errors) doesn't seem to change
> anything (except not giving the warning IIRC)
> Also, dump_pirq and lspci -vv output didn't change.
> 
> The first says the following at boot:
> 
> PCI: PCI BIOS revision 2.10 entry at 0xf0560, last bus=1
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> Unknown bridge resource 0: assuming transparent
> PCI: Using IRQ router ALI [10b9/1533] at 00:07.0
> PCI: Found IRQ 14 for device 00:0f.0
> 
> dump_pirq output remains the same.
> The lspci -vv output does change with the second patch:
> 
>  00:0f.0 IDE interface: Acer Laboratories Inc. M5229 (rev c1) (prog-if
> fa)
>         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 2 min, 4 max, 32 set
> -       Interrupt: pin A routed to IRQ 0
> +       Interrupt: pin A routed to IRQ 14
>         Region 4: I/O ports at d000
> 
> More info on request.
> 

Hm, while running with the first patch (the one trying to build
an interrupt router table for my chipset) my system locked solid
for a few seconds while I was copying the kernel-source to another
place and moved from one virtual screen to another in X.
It happened just once, but I don't remember the last time I had
this kind of latency. At the same time I noticed this in my
kernel logs:

localhost kernel: cdrom: open failed. 
   I haven't done anything with my cdrom since the last reboot.

localhost modprobe: modprobe: Can't locate module block-major-33
localhost modprobe: modprobe: Can't locate module block-major-33
localhost modprobe: modprobe: Can't locate module block-major-34
localhost modprobe: modprobe: Can't locate module block-major-34
localhost modprobe: modprobe: Can't locate module block-major-8
localhost last message repeated 15 times
   I only have hd[a-c]

(timestamps removed to prevent irritating wrapping,
they were all in the same minute)

My dmesg is attached, just in case.

-- 
Linux 2.4.0-test10-pre6-test1 #1 Sat Oct 28 23:04:32 CEST 2000