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