From: Daniel Robbins <drobbins@gentoo.org>
To: Paulo Marques <pmarques@grupopie.com>
Cc: "Barry K. Nathan" <barryn@pobox.com>, Jens Axboe <axboe@suse.de>,
Greg KH <greg@kroah.com>,
linux-kernel@vger.kernel.org, Mike@kordik.net,
kpfleming@backtobasicsmgmt.com
Subject: firewire good, USB printing fixed, CD-ROM block device IO errors near end of media
Date: Tue, 02 Mar 2004 08:18:04 -0700 [thread overview]
Message-ID: <1078240684.10224.36.camel@wave.gentoo.org> (raw)
In-Reply-To: <40448799.5030508@grupopie.com>
On Tue, 2004-03-02 at 06:09, Paulo Marques wrote:
> Barry K. Nathan wrote:
>
> >
> > + /* We must increment writecount here, and not at the
> > + * end of the loop. Otherwise, the final loop iteration may
> > + * be skipped, leading to incomplete printer output.
> > + */
>
> I'm affraid this is my fault, for correcting a bug and letting another one take
> its place :(
>
> It seems that this patch squashes them both. It should go in ASAP.
Sorry I have been unable to test the fix; Gentoo Linux 2004.0 just got
released and I just became... err... ultra-busy? But it does look like
others who experienced the exact problem I was having now have
functional USB, so I'd expect it to work for me too.
I'm now experiencing kernel problems (apparently this isn't a new thing)
related to how Linux maps a CD-ROM to a block device -- problems using
dd to verify a burnt CD, where the kernel spits back random IO error
messages as it nears the end of the burned area.
If anyone is interested, you can learn more about the problems in the
following thread (I am experiencing the exact problems of the original
poster.) The posts from Joerg Schilling are probably most helpful in
finding a kernel solution to this problem:
http://lists.debian.org/cdwrite/2003/cdwrite-200310/threads.html#00009
zisofs makes a filesystem-based verify of a CD quite a time-consuming
and inefficient process (due to seeking,) so it would be nice if a "dd"
or "readcd"-based linear CD verify worked reliably under Linux.
Regards,
Daniel
next prev parent reply other threads:[~2004-03-02 15:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-28 2:01 2.6.3-bk9 QA testing: firewire good, USB printing dead Daniel Robbins
2004-02-28 2:10 ` Greg KH
2004-02-28 2:57 ` Daniel Robbins
2004-02-28 3:39 ` Kevin P. Fleming
2004-02-28 6:44 ` Greg KH
2004-02-28 21:22 ` Mike
2004-02-29 9:51 ` Jens Axboe
2004-03-01 7:43 ` [PATCH] " Barry K. Nathan
2004-03-01 8:02 ` Jens Axboe
2004-03-02 3:01 ` Mike
2004-03-02 13:09 ` Paulo Marques
2004-03-02 15:18 ` Daniel Robbins [this message]
2004-03-02 19:26 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1078240684.10224.36.camel@wave.gentoo.org \
--to=drobbins@gentoo.org \
--cc=Mike@kordik.net \
--cc=axboe@suse.de \
--cc=barryn@pobox.com \
--cc=greg@kroah.com \
--cc=kpfleming@backtobasicsmgmt.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pmarques@grupopie.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox