PING.  How did it go?

Created attachment 145201 [details]
Yast2 installation logs

The installation completed successfully.

Attached the installtion logs above.

Thanks.  Please post result of 'hwinfo --all' and /var/log/boot.msg.

Two files follow.

Created attachment 145362 [details]
hwinfo --all

Created attachment 145363 [details]
/var/log/boot.msg

Thanks.  It seems upstream pata_ali driver is broken.  Can you be persuaded into building and testing vanilla kernel (2.6.22-rc4)?

I can do that, it's been a while, though.

Yeap, please do that.  The same bug should be in 2.6.22-rc4.  We can report this bug to linux-ide@vger.kernel.org and ask someone more familiar with the driver to take a look (Alan or Bart).  Thanks.

I am compiling the kernel now.

I'm not quite sure how to test this, though. I'm guessing you want me load the pata_ali driver before the alim15x3 driver.

My initrd modules line looks like this:

INITRD_MODULES="processor thermal alim15x3 fan jbd ext3 edd"

I will create an initrd file with these modules: processor thermal pata_ali alim15x3 fan jbd ext3 edd.

If you want me to try something different, let me know.

Took forever to compile.

Similar error messages were observed when loading the pata_ali driver. However, it did get past them and booted all the way.

I saved the /var/log/boot.msg file and will attach it shortly.

Damn, downloaded 2.6.21 instead of 2.6.21-rc4.

I'll try again tomorrow morning.

I'll attach the boot log anyways, sorry.

Created attachment 145779 [details]
Boot logs from vanilla kernel 2.6.21

OK, I compiled 2.6.22-rc4. Right version, right release candidate number.

It had trouble with the pata_ali driver, but finished the boot sequence. The DVD drive is not available.

The boot.msg file follows.

Created attachment 145985 [details]
Boot logs of 2.6.22-rc4

Created attachment 146256 [details]
use-dma-only-for-rw

Can you test the attached patch?

The patch made the driver skip whatever was causing the error messages. It booted all the way and seems have found the DVD drive. I'm attaching the boot.msg file.

Created attachment 146392 [details]
Boot messages after applying the patch suggested.

Alright, forwarding the patch upstream.  Thanks a lot.

Hmmm... Let's try one more thing before submitting the patch.  Can you boot with the ide alim15x3 driver and try to burn cd or dvd with wodim and see whether it works?

Created attachment 146692 [details]
pio-inquiry-horkage.patch

Also, can you please try this patch on top of 2.6.22-rc5 and see whether it fixes pata_ali?  Thanks.

In ref to #21, I boot with the alim15x3 driver to use this laptop.

It has a cd burner. I've burned a CD with it under the Alpha 4 Suse kernel. I'm not sure what kernel you really wanted. I'll try burning with the 2.6.22-rc5 next.

Created attachment 147306 [details]
use-irq-driven-IDENTIFY-and-SETXFERMODE.patch

Just testing the alpha kernel is enough (the burning test).  After testing pio-inquiry-horkage, can you also give this patch a shot?  Please remove the inquiry patch before applying this one (patch -R -p1 < pio-inquiry-horkage.patch).

Thanks.

I'm starting to compile the kernel with the pio-inquiry-horkage.patch patch. Sorry, I've been busy.

The pio-inquiry-horkage.patch patch allowed to boot without error messages, but I cannot access the cd drive.

I'm getting several errors. while trying to read a CD.

Created attachment 147483 [details]
Boot logs after applying pio-inquire-horkage patch

Created attachment 147484 [details]
System log after bootting with patch and trying to read CD drive

The use-irq-driven-IDENTIFY-and-SETXFERMODE.patch patch did not work either.

Created attachment 147515 [details]
update-ata_check_atapi_dma.patch

Okay, one more patch to try.  Please test this patch on top of 2.6.22-rc4 or 5 without any patch and report the result.  Thanks.

It failed to recognize the CD drive at boot.

One of the error messages during boot was the "model number mismatch" related to cd drive name "QSI CD-RW/DVD-ROM SBW-241". Similar to the error messages during boot I've posted before.

I modified libata-core.c (on top of your latest patch) and blacklisted this particular drive with ATA_HORKAGE_NODMA. Booted again and was able to use the drive and burn a cd.

I suspect my monkeying around with the code didn't really resolve the problem, since there appears to a problem with the driver. Let me know what you want me to do next.

Can you post the boot log with?  INQUIRY shouldn't have failed.  It's still being done using PIO.  Can you use the device using the alim driver?

Created attachment 150145 [details]
Boot log of 2.6.22-rc5 + update-ata_check_atapi_dma.patch

Here is the boot log of 2.6.22-rc5 with your last patch.

The CD/DVD drive is unavailable after the boot process is finished.

So, INQUERY of the QSI SBW-241 drive still fails under PIO.

Rafael,

Could you please apply the following debug patch to 2.6.22-rcX kernel
(http://bugzilla.kernel.org/attachment.cgi?id=11883).

It will flood /var/log/messages with a lot of debug traces. Please reproduce
the INQUIRY timeout and submit the full debug trace (better with bzip2
compressed). Hopefully we can see if any clue from the debug trace, thanks.

> So, INQUERY of the QSI SBW-241 drive still fails under PIO.

Ah, I'm wrong. The INQUIRY here is 96-bytes so it's not PIO. Given previous "limit DMA to R/W only" works, maybe this drive requires the DMA_RW_ONLY horkage?

This reminds of the TORiSAN drive problem, I will ask that bug submitter to test if TORiSAN works under "ATAPI DMA for multiple of 16-bytes" again.

Do you still want me to try the patch?

Created attachment 150327 [details]
system logs after booting verbose patch

Created attachment 150401 [details]
Debug patch for port 2 only

Rafael,

Thanks for the trace. However, the log was overrun by the hard drive traces. (I should limit the trace to port 2 only...)

Could you please try the attached debug patch on 2.6.22 kernel and collect the debug traces again. Thanks.

Created attachment 150596 [details]
boot log

The only debug messages were output during boot.

Hi Rafael,
From the boot log, the first INQUIRY was executed in PIO mode and successful. However, the second 96-bytes INQUIRY was executed in ATAPI DMA mode and failed. Looks like yet another piece of "designed for microsoft windows (tm) but not standard" hardware. Also, it seems Tejun's limit ATAPI DMA to multiple of 16-bytes doesn't catch them all. :(

I'm wondering whether the problem is in the ALi M5229 controller or the QSI SBW-241 drive? There is a previous report about M5229 ATAPI DMA problem by Andrey Borzenkov (http://marc.info/?l=linux-kernel&m=116500554505311&w=2).

Maybe we can test the ALi M5229 controller with another known-to-be-good CD-ROM drive to see if this is the problem of M5229 or not. However, both your and Andrey are notebook computer and the CD-ROM drive is difficult to replace...

Why is this one still in NEEDINFO?

Hmmm... The weird thing is that the IDE driver can detect and use the device without problem.  With ata_check_atapi_dma() updated, libata should behave the same way as the ide counterpart.  Or did we something else?  Rafael, are you up for more debugging patches?

Hi Tejun,

We have yet another one report of ATAPI device times out on INQUERY of 96-bytes when connected to ALi controllers: 

http://bugzilla.kernel.org/show_bug.cgi?id=7500

I guess maybe the ALi driver needs to have adapter specific check_atapi_dma(), something like pata_pdc2027x has...

I see.  What I'm curious about is why the IDE driver works.  Can it be because the IDE cdrom driver doesn't issue the 96 byte INQUIRY?  It would be nice to issue 96byte INQUIRY (could sg_inq do this?) to the IDE driver and see what happens.

Also, if we're gonna implement check_atapi_dma() for ali, what condition should we check against?

Thanks.

> ... why the IDE driver works

Don't know. Maybe the ATAPI devices are configured to PIO? 

> if we're gonna implement check_atapi_dma() for ali,
> what condition should we check against?

I guess maybe we can use the same logic of pata_pdc2027x for pata_ali.
The logic seems to be what the Windows atapi driver uses. And some hardware vendors design their hardware specifically for that logic...

Created attachment 156739 [details]
Limit ATAPI DMA of pata_ali to specific scsi commands only

(In reply to comment #45 from Albert Lee)
> > ... why the IDE driver works
> 
> Don't know. Maybe the ATAPI devices are configured to PIO? 

It's actually configured to UDMA33.

  https://bugzilla.novell.com/attachment.cgi?id=145363

> > if we're gonna implement check_atapi_dma() for ali,
> > what condition should we check against?
> 
> I guess maybe we can use the same logic of pata_pdc2027x for pata_ali.
> The logic seems to be what the Windows atapi driver uses. And some hardware
> vendors design their hardware specifically for that logic...

Hmmm... My memory of MMC is fading.  When ripping a CD or writing one, does MMC use READ/WRITE commands?  Or are there different dedicated commands?  If we don't pay a lot of penalty for common cases, I think we better default to what windows defaults to.

(In reply to comment #42 from Tejun Heo)
> Rafael, are you up for more debugging patches?

Sure, I'll be installing beta1 later today.

I'll apply the patch above and test.

I'm booting the DVD with the usual "brokenmodules=pata_ali."

When it gets time to start the installation, it cannot mount the DVD.

I had the same problem with the Alpha 7 version.

I'm attaching the Yast logs.

I will mount image and do a network install.

Created attachment 156868 [details]
Logs of failed installation

Yast logs, dmesg and boot.msg of failed Beta 1 installation. Installer could not mount the DVD.

Notice the warning messages about the serial interface in the dmesg file.

There may be more than one thing going on here, and may or may not be related to this bug. Please let me know if they are, and if I should file separate reports.

This is being debugged in upstream.  It seems to be the controller/driver's problem but isn't clear yet whether mwdma mode programming is wrong or the controller chokes on DMA transfer request for INQUIRY which is pretty short.  Please be patient.

any update on this bug?

Rafael, please give a shot at beta1.  It contains ATAPI DMA filter update which should fix the QSI case.  Thanks.

I have tried Beta2 and still have the same problem.

If I use "brokenmodules=pata_ali" it recognizes the dvd drive, but cannot mount the DVD. I reported that here and in bug #307400.

On the next beta, there will be a sledgehammer option to turn off ATAPI DMA and I'll suppress ATAPI DMA for data transfers < 2048, which should hopefully fix the problem.  So, please test -rc1 when it comes out (even if the < 2048 trick doesn't work, the sledgehammer should be able to get you going).  Thanks.

The sledgehammer is in but the < 2048 trick isn't.  Please specify "libata.pata_dma=1" at the kernel prompt and try installation.

Thanks.

Hi Tejun,

Is this " < 2048 " trick being pushing to the mainline?
If yes, I am worried it will impact the performance of devices such as GoVault ATAPI hard drive, which has a sector size of 512. Maybe we need a better logic on the usage of ATAPI DMA...

I'm not sure yet but one way or the other we definitely need some improvements in ATAPI dma filtering.  Too many ATAPI devices are falling out.

Booted RC1 with the "libata.pata_dma=1" option and got error messages and the DVD drive was not detected.

Can you post /var/log/boot.msg?  Thanks.

Created attachment 173973 [details]
Boot messages.

Humm, the boot message indicates:

<3>Unknown boot option `libata.pata_dma=1': ignoring

The kernel in RC1 does not seem to have the patch you are talking about.
Which kernel do you want me to try?

I have installed RC1 using a network install.

I've downloaded and installed the kernel available in the online update, 2.6.22.5-25, recreated the initrd file to load the pata_ali driver, edited the boot options to add the libata.pata_dma=1 option and rebooted the system.

I get a message about waiting for /dev/hda7 (my root partition) to appear. The boot sequence fails. I do not get the error messages associated to the DVD drive.

Okay, here's what I've found out.

* During installation you need to specify the following to pass libata.pata_dma=1 to libata.

  options="libata.pata_dma=1"

* When booting from the harddisk after installation is complete, you can simply add the following.  Kernel will generate a warning message but the parameter will be passed to the module by initrd.

  libata.pata_dma=1

* You can verify the parameter was passed by running the following.

  cat /sys/modules/libata/parameters/pata_dma

Regarding the last comment, how come /dev/hda7 is root not /dev/sda7?  After failing to mount root, you'll be dropped into emergency shell, can you access your harddrive from there?

Rafael,
A correction Tejun gave me in Bug 229260.  For install, you should use:
    options="libata=pata_dma=1"

(back from a series of family events and moving)

Sorry about the confusion.  Please report how it went.

(In reply to comment #65 from Benjamin McCann)
> A correction Tejun gave me in Bug 229260.  For install, you should use:
>     options="libata=pata_dma=1"

I'm using the corrected option above with the gold master dvd.

The boot sequence proceeded without error messages. The DVD drive was detected. It is installing the os at this time. I will report more after it finishes.

Installation went smooth until after online update (while still installing.) The computer was rebooted and it appears the special boot option was not added to the boot loader configuration. The installed menu.lst does not mention the libata option. The system starts having problems with the DVD drive again.

I did go into the boot loader configuration panels, but I don't remember seeing the libata option in there.

I have added
    options="libata=pata_dma=1"

to the Grub when booting from the hard drive, but it does not seem to be recognized.

Is there a different format for this option when booting from the installed kernel?

How is the libata option added to the boot options after the system is installed?

Yeah, the installer was using its own format.  After installation, you should use.

  libata.pata_dma=1

Now you see where my confusion came from. :-)

Can you please apply a patch and see whether it fixes your problem (ie. works w/o libata.pata_dma=1)?

Created attachment 179366 [details]
atapi-dma-for-rw-only.patch

Here's the patch.  Please test all common cd/dvd operations - reading, recording, ripping cd, etc - and report any anomaly including too high cpu usage and slow transfer speed.  Thanks.

Ping.

The boot option "libata.pata_dma=1" did allow me to boot the laptop.

I have not had time to compile a new kernel with the patch. Give me a little more time.

ping2

Compiled and installed the kernel kernel-source-2.6.22.12-0.1 and applied the patch above.

The boot process went well. I removed the "libata.pata_dma=1" option before booting.

Created attachment 184967 [details]
Boot log of kernel-source-2.6.22.12-0.1

OK.

After installing the patched kernel, I re-booted it with the "libata.pata_dma=1" option and verified no obvious error messages showed up. Launched k3b and burned an ISO image successfully.

After that I re-booted the laptop without "libata.pata_dma=1" and again no abvious error message. Then I launched k3b and it could not read the DVD drive.

I am attaching the error messages collected in /var/log/messages.

Created attachment 186964 [details]
System log showing errors reading DVD drive.

What happens if you put a data cd in and mount and read files from it?

Created attachment 187272 [details]
System log after trying to mount a data CD.

(In reply to comment #79 from Rafael Herrera)
> Created an attachment (id=187272) [details]
> System log after trying to mount a data CD.

Needless to say, I cannot read the CD.

With the "libata.pata_dma=1", I can access the CD and read its files.

*** Bug 359213 has been marked as a duplicate of this bug. ***

The laptop that had this problem is broken at this time.

I do not think we will repair it, so you may want close this report.

This has been worked around on SL103 w/ the use of kISO and SL110 should work out of the box (I have a test machine here).  Hmmm... I thought I wrote it here.

The workaround is, well, workaround, it just turns of ATAPI DMA on pata_ali.  I spent quite some time trying to determine the different between IDE alim and pata_ali and asked other ATA developers but we haven't succeeded yet.  I'm keeping the problem on mind and will try more proper solutions as they come up.

Resolving as FIXED for now.  Thanks.

For, SL103, kISO is...

 http://htj.dyndns.org/export/kiso/SL103-x86_64-KISOTD-20080221152521.iso

For information on how to use kISO.

 http://htj.dyndns.org/export/kiso/SL103-kISO-doc.txt