On Sat, 2003-05-03 at 19:21, Bartlomiej Zolnierkiewicz wrote:
> >
> > So my patch may actually fix some cases there too.
>
> No, look at ide_match_hwif() in setup-pci.c .
> PCI grabs only ide_unknown interfaces.
No, you missed my point.
1) setup-pci claims a free hwif slot
2) the driver sets some custom IOPs (MMIO PCI interface for example)
and/or does other tweaks to hwif
3) no device is attached to this interface, the IDE probe code leaves
hwif->present to 0, but the hwif fields (IOps etc... are still
set by the PCI driver)
4) later on, ide-cs gets in, and picks that slot since hwif->present
is 0 and ide-cs doesn't care about chipset. However, those IOps
fields (and possibly other, DMA stuff etc...) are still those of
the PCI interface. If the PCI interface set it to MMIO for example,
boom !
Note that I haven't actually tested the above scenario as I don't have
a box with such PCI IDE interfaces, but it seems the problem I have
with ide-pmac in this case is identical.
With my patch, since the PCI interface will not set the "hold" flag,
ide_register_hw() called by ide-cs will call init_hwif_data(), thus
putting back the hwif to a sane state
> btw, I think the only real long-term solution for all ordering issues
> is customizable device mapper... 2.7?
Or not relying on /dev/hdX entries for mounting ? (disk UUID etc..) ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 07 2003 - 22:00:18 EST