sg_write kernel logging flood

[Tobias Jakobi]

Hi there paranoia devs,

I was hoping to find here an answer to this problem:
I just updated my system to linux kernel 2.6.21 and also switched to the
new ATA layer. Now mplayer (which internally seems to use cdparanoia)
also needs the kernel sg module to get access to the optical drives (I
use mplayer for CDDA playback). I modprobed sg and could playback the
CDDAs, but as long as data is extracted from the drive the kernel log is
filled with:

sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing
data in;
   program mplayer not setting count and/or reply_len properly

I found that this problem is not new:
http://readlist.com/lists/vger.kernel.org/linux-kernel/25/125901.html

Sadly it still exists, and even when usiny cdparanoia (standalone) it
fills the kernel log. Now I'm searching for a (non-hacky) patch to get
this working correctly. I could comment out the logging command from
sg.c, but that would be more a hack. Any idea how to fix this?

uname -a:
Linux voodoomaster 2.6.21-gentoo-r3 #1 Sat Jul 7 20:10:22 CEST 2007
x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux

cdparanoia III release 9.8 (March 23, 2001)
(C) 2001 Monty <monty@...> and Xiphophorus

Thanks,
Tobias

_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[R. Bernstein]

Does cd-paranoia from libcdio (http://www.gnu.org/software/libcdio)
give the same problem as well? If not, there probably a way around
this.

Tobias Jakobi writes:
 > Hi there paranoia devs,
 >
 > I was hoping to find here an answer to this problem:
 > I just updated my system to linux kernel 2.6.21 and also switched to the
 > new ATA layer. Now mplayer (which internally seems to use cdparanoia)
 > also needs the kernel sg module to get access to the optical drives (I
 > use mplayer for CDDA playback). I modprobed sg and could playback the
 > CDDAs, but as long as data is extracted from the drive the kernel log is
 > filled with:
 >
 > sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing
 > data in;
 >    program mplayer not setting count and/or reply_len properly
 >
 > I found that this problem is not new:
 > http://readlist.com/lists/vger.kernel.org/linux-kernel/25/125901.html
 >
 > Sadly it still exists, and even when usiny cdparanoia (standalone) it
 > fills the kernel log. Now I'm searching for a (non-hacky) patch to get
 > this working correctly. I could comment out the logging command from
 > sg.c, but that would be more a hack. Any idea how to fix this?
 >
 > uname -a:
 > Linux voodoomaster 2.6.21-gentoo-r3 #1 Sat Jul 7 20:10:22 CEST 2007
 > x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
 >
 > cdparanoia III release 9.8 (March 23, 2001)
 > (C) 2001 Monty <monty@...> and Xiphophorus
 >
 > Thanks,
 > Tobias
 >
 > _______________________________________________
 > Paranoia mailing list
 > Paranoia@...
 > http://lists.xiph.org/mailman/listinfo/paranoia
 >
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[Douglas Gilbert-2]

Tobias Jakobi wrote:

> Hi there paranoia devs,
>
> I was hoping to find here an answer to this problem:
> I just updated my system to linux kernel 2.6.21 and also switched to the
> new ATA layer. Now mplayer (which internally seems to use cdparanoia)
> also needs the kernel sg module to get access to the optical drives (I
> use mplayer for CDDA playback). I modprobed sg and could playback the
> CDDAs, but as long as data is extracted from the drive the kernel log is
> filled with:
>
> sg_write: data in/out 16464/16464 bytes for SCSI command 0xbe--guessing
> data in;
>    program mplayer not setting count and/or reply_len properly
>
> I found that this problem is not new:
> http://readlist.com/lists/vger.kernel.org/linux-kernel/25/125901.html

This warning was added to the sg driver (not by me) to
annoy the crap out of maintainers (and users) of apps that:
   1) continue to use the sg version 2 or earlier interface, and
   2) use the old interface in a slightly ambiguous way

The sg version 3 interface has been available since lk 2.4.0
which seems to postdate the version of cdparanoia that you are
using. Surely there are newer versions of cdparanoia around
that don't have this problem.

> Sadly it still exists, and even when usiny cdparanoia (standalone) it
> fills the kernel log. Now I'm searching for a (non-hacky) patch to get
> this working correctly. I could comment out the logging command from
> sg.c, but that would be more a hack. Any idea how to fix this?
>
> uname -a:
> Linux voodoomaster 2.6.21-gentoo-r3 #1 Sat Jul 7 20:10:22 CEST 2007
> x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
>
> cdparanoia III release 9.8 (March 23, 2001)
> (C) 2001 Monty <monty@...> and Xiphophorus

March 23, 2001 ???

Doug Gilbert
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[xiphmont]

On 7/8/07, Douglas Gilbert <dgilbert@...> wrote:
> This warning was added to the sg driver (not by me) to
> annoy the crap out of maintainers (and users) of apps that:
>    1) continue to use the sg version 2 or earlier interface, and
>    2) use the old interface in a slightly ambiguous way

When the old interface arbitrarily got something wrong, it was
necessary to end run around it in hacky ways.

Eg, the old interface (actually, lower layers) will often abort DMA
early with no error message and hand back a buffer half full of
garbage and claim successful completion.  The only way to get around
that is to force-fill the transfer buffer with a known pattern first
by abusing the transfer direction flag.  This is not 'ambiguous'.
This is 'I'm forced to do absurd things to get simple transfers to
work reliably'.  The interface authors and I agreed at the time this
should be as upported behavior because it was way easier than fixing
the rest of the kernel. Welcome to Linux.  Here's a party hat and some
Chlorpram.

<flame target="not dgilbert">

If some new maintainer decided that this was 'not cool' I hope they
also bothered to implement DMA completion status reporting.
Otherwise, whining about it in their
Livejournal^H^H^H^H^H^H^H^H^Hkernel log is not going to solve the
original problem of unreliable transfers.

I'll note that brand spanking new SGIO *also* allows prefill of a DMA
transfer buffer for exactly the reason I state above: Last I looked,
most drivers are swallowing DMA errors and never reporting.  So I'm
guessing SG3 is also still broken this way, and someone needs to go
remove the idiot 'waaaah!  Stop touching me!' kernel log message.

Or we could all just buy Macs.  I hear they can do simple transfers
from CDROM pretty well.

</flame>

> March 23, 2001 ???

There's a new release that's on hold because it turns out using SGIO
on SATA cdrom drives is a good way to panic the kernel.  I should
release it anyway as 'incentive' for the kernel maintainers to 'fix'
their 'code'.

If you don't have a SATA cdrom, the cdparanoia10pre in SVN is fully up
to date with the latest kernel interfaces in that it will prefer SGIO
over SG.  If you force it to use SG, you will still get the whiny
kernel log messages because the kernel log message is ill considered.

Cheers,
Monty
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[Tobias Jakobi]

xiphmont@... wrote:

> Eg, the old interface (actually, lower layers) will often abort DMA
> early with no error message and hand back a buffer half full of
> garbage and claim successful completion.  The only way to get around
> that is to force-fill the transfer buffer with a known pattern first
> by abusing the transfer direction flag.  This is not 'ambiguous'.
> This is 'I'm forced to do absurd things to get simple transfers to
> work reliably'.  The interface authors and I agreed at the time this
> should be as upported behavior because it was way easier than fixing
> the rest of the kernel. Welcome to Linux.  Here's a party hat and some
> Chlorpram.

Is this problem with aborted transfers still existent? I'm only a normal
end-user but I'm surprised that such major bugs still exist...

>
> <flame target="not dgilbert">
>
> If some new maintainer decided that this was 'not cool' I hope they
> also bothered to implement DMA completion status reporting.
> Otherwise, whining about it in their
> Livejournal^H^H^H^H^H^H^H^H^Hkernel log is not going to solve the
> original problem of unreliable transfers.
>
> I'll note that brand spanking new SGIO *also* allows prefill of a DMA
> transfer buffer for exactly the reason I state above: Last I looked,
> most drivers are swallowing DMA errors and never reporting.  So I'm
> guessing SG3 is also still broken this way, and someone needs to go
> remove the idiot 'waaaah!  Stop touching me!' kernel log message.
>
> Or we could all just buy Macs.  I hear they can do simple transfers
>> from CDROM pretty well.

I hope that the switch to the new ATA layer increases the work done on
the SCSI code, maybe making this hacks obsolete.

> There's a new release that's on hold because it turns out using SGIO
> on SATA cdrom drives is a good way to panic the kernel.  I should
> release it anyway as 'incentive' for the kernel maintainers to 'fix'
> their 'code'.
>
> If you don't have a SATA cdrom, the cdparanoia10pre in SVN is fully up
> to date with the latest kernel interfaces in that it will prefer SGIO
> over SG.  If you force it to use SG, you will still get the whiny
> kernel log messages because the kernel log message is ill considered.
Good to know. If I have some spare time I'm going to test from SVN.
Maybe Gentoo should update their ebuild, especially since the latest
version in the portage tree is from 2001.

And I didn't mean to start some flame war, so be nice to each other : -)

Bye,
Tobias

_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[Pim Zandbergen]

xiphmont@... wrote:

> There's a new release that's on hold because it turns out using SGIO
> on SATA cdrom drives is a good way to panic the kernel.  I should
> release it anyway as 'incentive' for the kernel maintainers to 'fix'
> their 'code'.
>
> If you don't have a SATA cdrom, the cdparanoia10pre in SVN is fully up
> to date with the latest kernel interfaces in that it will prefer SGIO
> over SG.  If you force it to use SG, you will still get the whiny
> kernel log messages because the kernel log message is ill considered.
>

I felt brave and tried it anyway. Works just fine for me!
- cdparanoia10pre
- kernel 2.6.22.1
- Lite-ON LH-20A1S
- Intel ICH8 SATA controller (BIOS set to IDE mode)

Hope this helps,
Pim

_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[Tobias Jakobi]

Hi Pim,

I've just downloaded the current cdparanoia source from SVN and it did
indead compile fine. But I still get the kernel flooding.

uname -a:
Linux leena 2.6.21-gentoo-r4 #1 PREEMPT Fri Jul 13 17:10:07 CEST 2007
i686 Intel(R) Celeron(R) M processor 1.50GHz GenuineIntel GNU/Linux

The optical drive is just a normal PATA one. Using cd-paranoia from
libcdio seems to solve my problem.
I would just like to know where the differences between the project are?

Thanks,
Tobias

_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[xiphmont]

On 7/19/07, Tobias Jakobi <liquid.acid@...> wrote:
> Hi Pim,
>
> I've just downloaded the current cdparanoia source from SVN and it did
> indead compile fine. But I still get the kernel flooding.

I expect you have an old version still installed and the version of
the interface lib installed in /usr/lib is being used over the version
of the interface lib you built and installed on /usr/local/lib.  Use
ldd to make sure.

The SVN version will always prefer SGIO over SG.

Monty
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[Tobias Jakobi]

> I expect you have an old version still installed and the version of
> the interface lib installed in /usr/lib is being used over the version
> of the interface lib you built and installed on /usr/local/lib.  Use
> ldd to make sure.
>
> The SVN version will always prefer SGIO over SG.
>
> Monty

Oh sorry, I didn't even think about that. I just compiled it on a different machine where I uninstalled cdparanoia previously. After installing the new SVN build I had to run ldconfig (maybe the dynamic links were faulty). After that cdparanoia works. I doesn't work when removing the sg module, so the sg devices seem to be crucial for it to work, am I right?

Regards,
Tobias

--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger
_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia

[Douglas Gilbert-2]

xiphmont@... wrote:

> On 7/19/07, Tobias Jakobi <liquid.acid@...> wrote:
>> Hi Pim,
>>
>> I've just downloaded the current cdparanoia source from SVN and it did
>> indead compile fine. But I still get the kernel flooding.
>
> I expect you have an old version still installed and the version of
> the interface lib installed in /usr/lib is being used over the version
> of the interface lib you built and installed on /usr/local/lib.  Use
> ldd to make sure.
>
> The SVN version will always prefer SGIO over SG.

I think I know what you mean. The SG_IO ioctl was first introduced
in sg driver at the start of the lk 2.4 series. By the start of
the lk 2.6 series the SG_IO ioctl was _also_ found in the block layer
(and the st and osst drivers, amongst others).

So it should be safe to use the SG_IO ioctl on any device given
by the user in the cdparanoia invocation. If it fails, then it
is only worth trying the async write()/read() interface
   a) the device given is a sg node,and
   b) 1) the app need async, or
      2) a lk 2.2 (or lk 2.0) series kernel is detected


Doug Gilbert

_______________________________________________
Paranoia mailing list
Paranoia@...
http://lists.xiph.org/mailman/listinfo/paranoia