No IDE drivers loaded for Toshiba Satellite 320 CDS - Kernel

This is a discussion on No IDE drivers loaded for Toshiba Satellite 320 CDS - Kernel ; > > 1) ide-generic is only loaded _after_ any otherwise detected modules That is the correct approach, as with libata and ata_generic/pata_legacy > > 2) it is only loaded if an ISA bus is present All PC class systems have ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 33 of 33

Thread: No IDE drivers loaded for Toshiba Satellite 320 CDS

  1. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    > > 1) ide-generic is only loaded _after_ any otherwise detected modules

    That is the correct approach, as with libata and ata_generic/pata_legacy

    > > 2) it is only loaded if an ISA bus is present


    All PC class systems have an ISA bus, it may be on the main board and
    called LPC but it is there.

    > > 3) it is only included in the initrd for the installed system if loading it
    > > in the installer resulted in additional block devices appearing

    >
    > OK, great for x86 perhaps, what about other systems?


    Should be valid for all sane ISA bus systems. The IDE legacy code as per
    arch probe rules.

    > > I would unload ide-generic in the installer if no additional block devices
    > > appear, but unfortunately that's not possible as it is marked "permanent".


    Yes - old IDE doesn't do hotplugging, libata can so your approach would
    work there.


    Alan
    --
    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/

  2. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    On Monday 14 April 2008, Alan Cox wrote:
    > > > 2) it is only loaded if an ISA bus is present

    >
    > All PC class systems have an ISA bus, it may be on the main board and
    > called LPC but it is there.


    The actual test is if /sys/bus/isa exists, which it does not at least on my
    current PC class desktop (em64t).
    My 4 year old laptop (i386) does have it though.
    --
    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/

  3. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    On Monday 14 April 2008, you wrote:
    > > I also think the way I've implemented in the Debian installer should be
    > > relatively safe:
    > > 1) ide-generic is only loaded _after_ any otherwise detected modules
    > > 2) it is only loaded if an ISA bus is present
    > > 3) it is only included in the initrd for the installed system if
    > > loading it in the installer resulted in additional block devices
    > > appearing

    >
    > OK, great for x86 perhaps, what about other systems?


    As I've said before, that needs testing.

    > In the past debian would load ide-generic last. It worked great. Keep
    > doing that. I am not aware of loading ide-generic after all the other
    > drivers ever causing any harm in the older debian installers.


    Maybe not, but having it loaded in _every_ installed Debian system even when
    it was completely unused is definitely something we want to get rid of.

    Note that the old behavior relied on the fact that initramfs-tools also
    loaded ide-generic by default, which it now no longer does.

    Cheers,
    FJP
    --
    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/

  4. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    Alan Cox wrote:
    >> If a driver supports a device with dual interfaces, then it better
    >> reserve both sets of ports to prevent the generic driver from trying to
    >> use them.

    >
    > That isn't the problem. The generic driver doesn't know if there is
    > another valid driver for the ports - how can it - and the other driver
    > may not be loaded first so cannot reserve the ports. If you load the
    > generic driver last then you should be fine, and the link order for IDE
    > and libata puts acpi, pci generic and legacy at the end for good reason.
    >
    > Libata pata_legacy has some smarts in this area but they are only good
    > for the common cases.


    Always loading generic or ata_generic used to be safe. It's still
    pretty safe but not as much as before. Nowadays, there are good number
    of controllers which have dual interfaces. Usually an ahci interface
    and a legacy one but there are other controllers which also implement
    dual interface.

    Because PCI BARs usually contain IO regions for legacy interface in PCI
    BAR 0-4, the native driver can work it out by claiming all PCI BARs on
    attach, which I learned the hard way after seeing the generic driver
    borking the native one on certain configurations. The thing I'm worried
    about is that there are a lot of vendors making this type of controllers
    nowadays and a lot of BIOS implementations for each of them. And of
    course each BIOS implementation has its own many ways of configuring the
    dual mode (or more thanks to fake RAIDs) controller.

    I wouldn't be too surprised if one of those plethora of configurations
    gets the compatible IO port and BAR configurations mismatched.
    Especially when the controller is put into native mode. It's entirely
    possible to leave the compatible IO ports enabled while not setting the
    PCI BARs accordingly. Some of them might even think that's better to
    prevent IDE drivers from attaching to it.

    So, I don't really want to depend on that. I don't know. Do I sound
    paranoid?

    --
    tejun
    --
    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/

  5. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    > Always loading generic or ata_generic used to be safe. It's still
    > pretty safe but not as much as before. Nowadays, there are good number


    ata_generic is always safe unless you force it to grab every class
    device. By default it grabs only those devices we know obey the class
    interface well enough and for which we have no proper driver (usually
    because there are no documents). Ditto for ide/pci/generic.

    The trickier one is pata_legacy, which tries to be smart and knows about
    the known exception so *should* always be safe. The old IDE legacy driver
    lacks these smarts so in some cases will do the wrong thing even if
    loaded last.

    Alan
    --
    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/

  6. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    On Tue, Apr 15, 2008 at 11:37:26AM +0900, Tejun Heo wrote:
    > Alan Cox wrote:
    > >>If a driver supports a device with dual interfaces, then it better
    > >>reserve both sets of ports to prevent the generic driver from trying to
    > >>use them.

    > >
    > >That isn't the problem. The generic driver doesn't know if there is
    > >another valid driver for the ports - how can it - and the other driver
    > >may not be loaded first so cannot reserve the ports. If you load the
    > >generic driver last then you should be fine, and the link order for IDE
    > >and libata puts acpi, pci generic and legacy at the end for good reason.
    > >
    > >Libata pata_legacy has some smarts in this area but they are only good
    > >for the common cases.

    >
    > Always loading generic or ata_generic used to be safe. It's still
    > pretty safe but not as much as before. Nowadays, there are good number
    > of controllers which have dual interfaces. Usually an ahci interface
    > and a legacy one but there are other controllers which also implement
    > dual interface.
    >
    > Because PCI BARs usually contain IO regions for legacy interface in PCI
    > BAR 0-4, the native driver can work it out by claiming all PCI BARs on
    > attach, which I learned the hard way after seeing the generic driver
    > borking the native one on certain configurations. The thing I'm worried
    > about is that there are a lot of vendors making this type of controllers
    > nowadays and a lot of BIOS implementations for each of them. And of
    > course each BIOS implementation has its own many ways of configuring the
    > dual mode (or more thanks to fake RAIDs) controller.
    >
    > I wouldn't be too surprised if one of those plethora of configurations
    > gets the compatible IO port and BAR configurations mismatched.
    > Especially when the controller is put into native mode. It's entirely
    > possible to leave the compatible IO ports enabled while not setting the
    > PCI BARs accordingly. Some of them might even think that's better to
    > prevent IDE drivers from attaching to it.
    >
    > So, I don't really want to depend on that. I don't know. Do I sound
    > paranoid?


    Yes. After all you would quickly see a problem if you built a kernel
    with all the IDE drivers built in, which some people do. In that case
    ide generic is always activated last and anything bad that would happen
    with loading a module would happen built in too.

    I think it is the wrong place to worry about problems. If a native
    driver takes control of a chip, it is that drivers responsibility to
    reserve any relevant ports on that chip sufficiently to prevent another
    driver from messing with it that doesn't know anything about that chip.
    If the native driver doesn't load at all, then ide-generic ought to try
    and drive the chip if it has legacy ports.

    So my opinion is that making life easy to those machines with legacy ide
    ports is a good thing, while trying to be overly paranoid about one
    driver potentially hitting a bug in another driver is just silly. Why
    couldn't two native ide drivers potentially go looking for the same
    ports too? Are you sure no native driver uses the legacy IDE port
    numbers to control a chip in native mode? Finding bugs is good since
    then they can be fixed. Trying to prevent hitting bugs (which shouldn't
    be there in the first place) doesn't seem useful.

    --
    Len Sorensen
    --
    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/

  7. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    Alan Cox wrote:
    >> Always loading generic or ata_generic used to be safe. It's still
    >> pretty safe but not as much as before. Nowadays, there are good number

    >
    > ata_generic is always safe unless you force it to grab every class
    > device. By default it grabs only those devices we know obey the class
    > interface well enough and for which we have no proper driver (usually
    > because there are no documents). Ditto for ide/pci/generic.
    >
    > The trickier one is pata_legacy, which tries to be smart and knows about
    > the known exception so *should* always be safe. The old IDE legacy driver
    > lacks these smarts so in some cases will do the wrong thing even if
    > loaded last.


    Right, I was thinking about drivers/ide/ide-generic.c which just grabs
    every known legacy IO ports. This actually caused rather serious
    problems on some ATI controllers under certain configurations. :-(

    --
    tejun
    --
    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/

  8. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    Hi,

    Lennart Sorensen wrote:
    > Yes. After all you would quickly see a problem if you built a kernel
    > with all the IDE drivers built in, which some people do. In that case
    > ide generic is always activated last and anything bad that would happen
    > with loading a module would happen built in too.


    Yeah, pick the right configuration. You can make it malfunction.

    > I think it is the wrong place to worry about problems. If a native
    > driver takes control of a chip, it is that drivers responsibility to
    > reserve any relevant ports on that chip sufficiently to prevent another
    > driver from messing with it that doesn't know anything about that chip.
    > If the native driver doesn't load at all, then ide-generic ought to try
    > and drive the chip if it has legacy ports.


    I'm not too sure whether that will be always possible and I'm less sure
    we'll get enough test coverage over this kind of stuff.

    > So my opinion is that making life easy to those machines with legacy ide
    > ports is a good thing, while trying to be overly paranoid about one
    > driver potentially hitting a bug in another driver is just silly. Why
    > couldn't two native ide drivers potentially go looking for the same
    > ports too? Are you sure no native driver uses the legacy IDE port
    > numbers to control a chip in native mode? Finding bugs is good since
    > then they can be fixed. Trying to prevent hitting bugs (which shouldn't
    > be there in the first place) doesn't seem useful.


    Yeah, theoretically, you're right. The problem is that what breaks when
    things go wrong. If you don't probe generic ports by default, harddisks
    won't be detected on some legacy systems but you can always prompt the
    user about loading the generic driver. If you probe generic ports by
    default, when things go wrong, you break modern machines in an
    unrecoverable (w/o reset) way. I'd rather choose bothering the user on
    legacy machines.

    thanks.

    --
    tejun
    --
    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/

  9. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    On Wednesday 16 April 2008, Tejun Heo wrote:
    > Yeah, theoretically, you're right. The problem is that what breaks when
    > things go wrong. If you don't probe generic ports by default, harddisks
    > won't be detected on some legacy systems but you can always prompt the
    > user about loading the generic driver. If you probe generic ports by
    > default, when things go wrong, you break modern machines in an
    > unrecoverable (w/o reset) way. I'd rather choose bothering the user on
    > legacy machines.


    The problem here is determining whether a machine is "legacy" or not.
    So far in this discussion I've seen no suggestions how to do that (except
    maybe for my test whether /sys/bus/isa is present), which would mean asking
    _all_ users, and that's a damned ugly option.
    --
    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/

  10. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    Frans Pop wrote:
    > On Wednesday 16 April 2008, Tejun Heo wrote:
    >> Yeah, theoretically, you're right. The problem is that what breaks when
    >> things go wrong. If you don't probe generic ports by default, harddisks
    >> won't be detected on some legacy systems but you can always prompt the
    >> user about loading the generic driver. If you probe generic ports by
    >> default, when things go wrong, you break modern machines in an
    >> unrecoverable (w/o reset) way. I'd rather choose bothering the user on
    >> legacy machines.

    >
    > The problem here is determining whether a machine is "legacy" or not.
    > So far in this discussion I've seen no suggestions how to do that (except
    > maybe for my test whether /sys/bus/isa is present), which would mean asking
    > _all_ users, and that's a damned ugly option.


    Asking when no harddisk is detected w/ the option to choose it
    explicitly should do for most cases. No?

    --
    tejun
    --
    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/

  11. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS


    > The problem here is determining whether a machine is "legacy" or not.
    > So far in this discussion I've seen no suggestions how to do that (except
    > maybe for my test whether /sys/bus/isa is present), which would mean asking
    > _all_ users, and that's a damned ugly option.


    Libata pata_legacy handles this itself for all known cases using the
    ruleset

    IF any PCI device -> no PATA legacy scans beyond IDE0/IDE1
    IF any PCI IDE in legacy compat mode -> No pata_legacy bind to that port
    IF CS55x0 or MPIIX -> read the chipset magic [these are the obscure 'not
    PCI but not ISA' specials]

    Alan
    --
    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/

  12. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    On Thu, Apr 17, 2008 at 07:12:35AM +0900, Tejun Heo wrote:
    > Asking when no harddisk is detected w/ the option to choose it
    > explicitly should do for most cases. No?


    I suppose it might, although I could still see an older machine have a
    PCI controller as well as an ISA legacy controller on an ISA sound card,
    and might even have a CDROM drive connected to the sound card. Not very
    likely though, but not imposible. In that case you might detect the HD
    connected to the HD, but not the CDROM connected to the sound card.
    That might be confusing to the user. On the other hand anyone running
    such old hardware might just have a pretty good idea what they are doing
    and could run in expert mode and tell the installer to also load the
    generic driver.

    I still think the correct solution is to always try loading it, posibly
    with a boot option to make the installer not do so for any machines that
    have issues with that. Any such machines should then have bug reports
    filed so that the driver that runs their chipset's IDE controller in a
    native mode can ensure they reserve the legacy IDE ports so that nothing
    else (like the generic driver) can go poking at them.

    After all I thought the whole point of all the ports listed in
    /proc/ioports was to indicate which io ports were currently reserved by
    which driver so that no other driver could try to access them. If it
    doesn't in fact work that way then it probably should.

    --
    Len Sorensen
    --
    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/

  13. Re: No IDE drivers loaded for Toshiba Satellite 320 CDS

    Lennart Sorensen wrote:
    > After all I thought the whole point of all the ports listed in
    > /proc/ioports was to indicate which io ports were currently reserved by
    > which driver so that no other driver could try to access them. If it
    > doesn't in fact work that way then it probably should.


    It does work most of the time and it's probably safe to load legacy /
    generic drivers on most configurations. It's just that we're talking
    about 15+ years of gap between ISA and PCI-e and there could be some
    exceptions and we might need to tread a bit more carefully. To me, it
    sounds reasonable.

    Thanks.

    --
    tejun
    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2