Re: x86_64 SATA DVD drive + libata trouble - Kernel

This is a discussion on Re: x86_64 SATA DVD drive + libata trouble - Kernel ; Bernd Strieder wrote: > Hello, > > please CC me, I'm not subscribed. > > If any kernel developer is interested in more specific information > please mail me, I can build kernels, I can apply patches, though > have ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: x86_64 SATA DVD drive + libata trouble

  1. Re: x86_64 SATA DVD drive + libata trouble

    Bernd Strieder wrote:
    > Hello,
    >
    > please CC me, I'm not subscribed.
    >
    > If any kernel developer is interested in more specific information
    > please mail me, I can build kernels, I can apply patches, though
    > have not done it regularly.
    >
    > I'd like to get the DVD drive working somehow. I have googled a lot
    > and did not find any more ideas what to do. Some good keywords to
    > find a solution would suffice at that end.
    >
    > Rough problem description:
    >
    > I have a Tyan mainboard with NVIDIA chipset CK804. The only
    > SATA/IDE device is a SATA DVD combo, the harddisks are on a RAID
    > controller from 3ware. The harddisks are fine.
    >
    > The openSuSE 10.3 boot dvds fail after booting from the BIOS, the
    > installation kernel cannot use the DVD drive. That kernel uses
    > libata and sata_nv pata_amd as drivers. The drive is recognized
    > but it cannot be used. This is the situation probably during
    > install from DVD and now in the running system after a network
    > install it persists.
    >
    > Reading from the dvd device /dev/sr0 with dd stops after at most
    > 119kb of rubbish read. Mounting fails with superblock not found.
    > When trying to remove the pata_amd module I get an Oops. I tried to
    > remove the modules to have a chance to reload them with other
    > options (atapi_enable), but that did not help, even after
    > rebooting.
    >
    > A vanilla 2.6.23.1 kernel behaves even less friendly, the dd
    > on /dev/sr0 causes a hard reset.
    >
    > So there are clearly some problems with libata in this system.
    >
    > I have failed switching away from libata getting the drive to be
    > recognized at all.


    There is a known problem with ATAPI devices on CK804 chipsets which have
    memory above the 4GB mark, being debugged here:

    https://bugzilla.redhat.com/show_bug.cgi?id=351451

    If you are running into that one you can workaround it for now by
    passing the adma=0 parameter to the sata_nv module (not sure how this
    would be done on Suse's setup) or pass sata_nv.adma=0 on the kernel
    command line if sata_nv is built into the kernel. If that does help, I
    could ask you to test patches :-)

    --
    Robert Han**** Saskatoon, SK, Canada
    To email, remove "nospam" from han****r@nospamshaw.ca
    Home Page: http://www.roberthan****.com/

    -
    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: x86_64 SATA DVD drive + libata trouble

    Hello,

    sorry for the large amount of files in my last mail, which will be
    outdated by this mail. Had I only read a little bit further on the
    bugzilla page.

    Robert Han**** wrote:
    > There is a known problem with ATAPI devices on CK804 chipsets
    > which have memory above the 4GB mark, being debugged here:
    >
    > https://bugzilla.redhat.com/show_bug.cgi?id=351451


    There is a second patch on this bugzilla page which I did not see
    in the first place.

    https://bugzilla.redhat.com/attachment.cgi?id=254191

    This patch gives me a working 2.6.24-rc1-git10 kernel WITH adma and
    with the full 8GB of RAM. See the attached dmesg text file below.

    >
    > If you are running into that one you can workaround it for now
    > by passing the adma=0 parameter to the sata_nv module (not sure
    > how this would be done on Suse's setup) or pass sata_nv.adma=0
    > on the kernel command line if sata_nv is built into the kernel.
    > If that does help, I could ask you to test patches :-)


    Obviously there is no need for more patches to get the drive
    working. I will probably just use that working kernel after some
    testing. And if I get to know that the patch gets upstream, then I
    will probably use 2.6.24 when it is finished.

    If there are more patches to test on this problem please let me
    hear. Now I have a setup that makes testing a patch taking a lot
    less time than before.

    Thanks for the help,

    Bernd Strieder



+ Reply to Thread