Bug 11742

Can you send me your .config and dmesg pls?

Thanks.

Reply-To: valerio.passini@unicam.it

Alle lunedì 13 ottobre 2008, hai scritto:
> http://bugzilla.kernel.org/show_bug.cgi?id=11742
>
>
>
>
>
> ------- Comment #1 from bbpetkov@yahoo.de  2008-10-12 23:44 -------
> Can you send me your .config and dmesg pls?
>
> Thanks.

Of course I can. Here they are.
Cheers

Valerio

Here some information about the attached config files.

config-2.6.27 it's my custom config with some drivers compiled statically 
(i.e: SATA and ext3), many unnecessary modules removed to speed up 
compilation and other options to fit better my architecture (core duo 2 
64bit).

config-2.6.27b it's more similar to the Debian configuration of stock kernel 
(2.6.26), I just made some changes to fit architecture and removed drivers 
obviously (IMO :) ) not related to my problem (bug 11742) like ALSA modules, 
V4L modules and so on. I have just tried to check if it worked better but it 
didn't.

dmesg.txt is related to the kernel made with the first config in attachment 
(config-2.6.27)

Hi,

I don't see your attachments probably because you have to add the attachments over the bugzilla interface "Create a New Attachment" usually found at the lower end of the bugpage. Simply attaching them to the mail won't work, imho.

Thanks,
Boris.

I have send this stuff to your personal account too, just to be sure(bbpetkov_At_yahoo...). Anyhow, i will attach here the same files, so that everybody else can give a look to them :)

Created attachment 18299 [details]
my custom config quite different from the debian one

config-2.6.27 it's my custom config with some drivers compiled statically 
(i.e: SATA and ext3), many unnecessary modules removed to speed up 
compilation and other options to fit better my architecture (core duo 2 
64bit).

Created attachment 18300 [details]
A config more similar than the previous to Debian stock kernel's config

config-2.6.27b it's more similar to the Debian configuration of stock kernel 
(2.6.26), I just made some changes to fit architecture and removed drivers 
obviously (IMO :) ) not related to my problem (bug 11742) like ALSA modules, 
V4L modules and so on. I have just tried to check if it worked better but it 
didn't.

Created attachment 18301 [details]
dmesg output

dmesg.txt is related to the kernel made with the first config in attachment 
(config-2.6.27

Can you give a shot at ata_piix and see whether it behaves any differently?

I assume the dmesg is your failing kernel? Can you also boot with your working kernel (2.6.26.5, as you say above) and send me that dmesg too?

Thanks.

Created attachment 18321 [details]
dmesg output from 2.6.26.5 Kernel

In this kernel everything is working as expected.

Created attachment 18322 [details]
lsmod output from the non working 2.6.27 kernel

This file shows that the kernel is already using ata_piix as module

the previous dmesg that I've posted yesterday is referred to the non working kernel 2.6.27.

> Can you give a shot at ata_piix and see whether it behaves any differently?

Do you mean to try with or without? As you can see from the above attached lsmod belonging from 2.6.27 kernel, ata_piix is loaded as module automatically. If you wanted me to disable it, please send me a kernel option I can give at boot time to GRUB to override this default behaviour of the kernel.

See you

ata_piix can drive the same controllers piix can but in your case piix is being loaded before ata_piix thus grabbing the common controller.  So, to rephrase, can you please retry without piix and with ata_piix?  How to inhibit or exclude a module from initrd is distro specific, so you'll need to dig a bit there.  Thanks.

I have blacklisted piix in Debian and so scsi emulation has been activated instead of "native" ide-cd (a couple of errors at boot time, but nothing serious). Thus the drive is listed as /dev/scd0 instead of /dev/hda
The result is that burning a CD in simulation and real mode produces no buffer under runs. :)
Now that we have found who is guilty, what are we going to do next?

Hang the developer :)

You could bisect search for the commit which is causing that regression - this'll be of great help. Here's a good tutorial on that:

http://www.kernel.org/doc/local/git-quick.html

Thanks.

Valerio,

I'm afraid you've stumbled on an ongoing dispute among developers regarding which drivers to use and improve. The "piix" driver is part of the old "ide" framework that is being replaced. The ata_piix driver is part of the new "libata" framework that is close to doing everything that "ide" does, plus a lot more.

Some developers like Borislav are sadly willing to spend their time on the old "ide" framework, which will be removed from the kernel soon. That would be fine, if it weren't for the fact that they are also wasting the users' (read: your) time debugging and git-bisecting a dead horse. You can read some background on the problem at http://marc.info/?l=linux-ide&m=122392751706811&w=2 .

If ata_piix works for you, just use that. Please attach the boot time errors you mentioned in Comment #14 so that they can be fixed in libata/ata_piix.

Thanks.

Sure, you can do that too, nobody is forced to do anything here.

> Some developers like Borislav are sadly willing to spend their time on the
> old
> "ide" framework, which will be removed from the kernel soon. That would be

I hear this since 2005...

Nobody is going to remove "old" framework anytime soon.  It is still a preferred solution on the embedded front (we've just support for another controller recently) and many non-x86 platforms.

There is a lot of non-ISA/VLB & non-x86 hardware that is not supported by libata.  Please check up your facts.

> fine, if it weren't for the fact that they are also wasting the users' (read:
> your) time debugging and git-bisecting a dead horse. You can read some

Nobody is forcing anybody here to do anything.  People are free to use or develop whatever driver or framework they want.

Please keep the discussion technical == free of unfounded speculations and your personal preferences.  If you want to show your support for libata the best way to do it is to go work on it instead of forcing other people to do it.

PS this is not piix/ata_piix issue but a ide-cd one

This is wild guess but does reverting commit e5318b531b008c79d2a0c0df06a7b8628da38e2f help?

[ it should be possible to just revert patch

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=e5318b531b008c79d2a0c0df06a7b8628da38e2f

  from 2.6.27 if you are not using git ]

Thank Boris and Stan for you replies.

Stan said:
>If ata_piix works for you, just use that. Please attach the boot time errors
>you mentioned in Comment #14 so that they can be fixed in libata/ata_piix.

Don't worry, it was "my" mistake. In the procedure I've found to blacklist piix it was not mentioned to "depmod -ae" before creating an initrd image. Anyhow, now that I have fixed it, there is no more any warning at boot time :).
It's time to be happy, relax and take a coffee ;)


>You could bisect search for the commit which is causing that regression -
>this'll be of great help. Here's a good tutorial on that:
Ok, it seems not easy, but sadly now I've a lot of free time and I think that spending it on helping in fixing this bug is not that bad... at least until you have both frameworks in the kernel. I don't want to mess in the discussion, I'm not a developer, just an user. But I have a practical approach to almost everything and IMO until we have both, we should have them working and avoid problems to other users. I consider this as a service to the community. That's all

(In reply to comment #19)
> PS this is not piix/ata_piix issue but a ide-cd one
> 

Ok, I can help you on testing if you can't reproduce this bug on your computer and/or don't have time to do it, but please tell me exactly what to do. Are you sure it's a ide-cd problem? 
You mentioned to work with patches instead of GIT. It would be great, because I'm more familiar with patching the kernel than in GIT, that I must learn before.

Ok, you can do the following if !GIT:

patch -p1 -R --dry-run < [patch]

(in case there are no rejects, remove the --dry-run option)

ontop of 2.6.27. It should revert cleanly, though. Then recompile the kernel, boot. The [patch] above is following in an attachment.

Thanks,
Boris.

Created attachment 18339 [details]
ATA_PC dma alignment

Good news, the patch fix this bug!
Here I write the steps I've done, just to check everything.
tar xf linux-2.6.27.tar.bz2 (vanilla kernel)
cp /home/valerio/Desktop/ide-cd-use-the-dma-safe-check-for-req_type_ata_pc.patch /usr/src/linux-2.6.27
cd /usr/src/linux-2.6.27
patch -p1 -R --dry-run < ide-cd-use-the-dma-safe-check-for-req_type_ata_pc.patch
no error message was given then
patch -p1 -R < ide-cd-use-the-dma-safe-check-for-req_type_ata_pc.patch
make oldconfig
fakeroot make-kpkg binary-arch -rev=vale.5
etc...
Booted and checked that piix was loaded and /dev/hda in place. I've burned a CD in simulation and real mode without issues. Things have worked. Time to rest and close this bug :).

> On Mon, 20 Oct 2008 20:33:56 +0200
>
> Valerio Passini <valerio.passini@unicam.it> wrote:
> > > Can you do the followings?
> > >
> > > 1. the previous patch from Boris and plain 2.6.27.
> > >
> > > 2. If the above works, please the attached patch and plain 2.6.27
> >
> > This is the result of my tests.
> >
> > 1. I have applied the Boris' patch to 2.6.27 the day before yesterday and
> > I have used that patched kernel for burning CD without any problems
> > (indeed is my default kernel now).
> >
> > 2. Applying your patch doesn't reach the same result. The patched kernel
> > with your fixes is behaving from an user point of view as the plain
> > 2.6.27 kernel. Burning a CD is problematic because the main processor is
> > intensively working and the device buffer reaches 0% quite often,
> > obliging k3b to slowdown the burning speed.
> >
> > Waiting for your new patch :)
>
> I see, thanks a lot for testing.
>
> Can you reply to the thread on linux-ide to report the above results?

Here we are. :)

The above message is an answer to Fujita Tomonori, who sent to me the following patch:

diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index f16bb46..9caf63b 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1180,7 +1180,7 @@ static void cdrom_do_block_pc(ide_drive_t *drive, struct request *rq)
 		 * NOTE! The "len" and "addr" checks should possibly have
 		 * separate masks.
 		 */
-		alignment = queue_dma_alignment(q) | q->dma_pad_mask;
+		alignment = queue_dma_alignment(q) | 15;
 		if (addr & alignment || rq->data_len & alignment)
 			info->dma = 0;
 
@@ -1890,7 +1890,6 @@ static int ide_cdrom_setup(ide_drive_t *drive)
 
 	blk_queue_prep_rq(drive->queue, ide_cdrom_prep_fn);
 	blk_queue_dma_alignment(drive->queue, 31);
-	blk_queue_update_dma_pad(drive->queue, 15);
 	drive->queue->unplug_delay = (1 * HZ) / 1000;
 	if (!drive->queue->unplug_delay)
 		drive->queue->unplug_delay = 1;

It is fixed in Linus' tree now by:

commit 9bd27cba1aeacb6b12d05f4e5ed6361072f08fe0
("ide-cd: fix DMA alignment regression")