Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261667AbUCBPQO (ORCPT ); Tue, 2 Mar 2004 10:16:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261670AbUCBPQO (ORCPT ); Tue, 2 Mar 2004 10:16:14 -0500 Received: from inventor.gentoo.org ([216.223.235.2]:3456 "EHLO meep.gentoo.org") by vger.kernel.org with ESMTP id S261667AbUCBPQL (ORCPT ); Tue, 2 Mar 2004 10:16:11 -0500 Subject: firewire good, USB printing fixed, CD-ROM block device IO errors near end of media From: Daniel Robbins To: Paulo Marques Cc: "Barry K. Nathan" , Jens Axboe , Greg KH , linux-kernel@vger.kernel.org, Mike@kordik.net, kpfleming@backtobasicsmgmt.com In-Reply-To: <40448799.5030508@grupopie.com> References: <1077933682.14653.23.camel@wave.gentoo.org> <20040228021040.GA14836@kroah.com> <20040229095139.GH3149@suse.de> <20040301074348.GA7646@ip68-4-255-84.oc.oc.cox.net> <40448799.5030508@grupopie.com> Content-Type: text/plain Organization: Gentoo Technologies, Inc. Message-Id: <1078240684.10224.36.camel@wave.gentoo.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 02 Mar 2004 08:18:04 -0700 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1775 Lines: 44 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 - 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/