Date: Wed, 26 Dec 2001 09:37:26 -0800 (PST) From: Ross Lippert <ripper@eskimo.com> To: gadde@cs.duke.edu Cc: freebsd-stable@freebsd.org Subject: that atapi cdrom problem Message-ID: <200112261737.JAA21301@eskimo.com>
next in thread | raw e-mail | index | archive | help
I was looking through the trace you have which was placed in
kern-pr/31460. I cannot say for sure that I have found the
bug, but I am sure I have found a terrible wrongness, I'm sure.
You correctly noted that your bytecount was way way wacky. Another
similar pr on this subject has a similarly corrupted bytecount in
his stacktrace (pr kern/31530).
bytecount looks like a negative int. Some checking reveals that
bytecount should be unsigned. Personally, I like using unsigned, it
gives me all 32 bits and sometimes I need them, but every once in a
while it bites me in the ass because I forget that loops of the form
(ui = unsigned)
while(ui > 0){ui-=something;}
are not going to do what you want unless something is exactly 1 or ui.
I'm not sure, but I wonder if there is a gcc warning for when someone
uses (ui > 0) when (ui != 0) is the equivalent.
If you look in atapi_read:/sys/dev/ata/atapi-all.c you will see such
a bogosity.
I believe that this error results in one being able to handle read
requests which are 0x800 bytes or fewer and heaven help you otherwise.
There are also two bogosities of that sort in ata-disk. Just grep and
see.
I am cc-ing freebsd-stable so that someone can explain to me how these
subtractions are justified, for I am no expert on kernel internals --
I'm just an expert on my own unsigned bugs and this looks like one.
-r
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112261737.JAA21301>