Description of Problem:
I have successfully been burning CDs with my Freecom CD writer (USB) for a while
now (patches for RedHat), but recently the volume of data that i burn has
crossed the 300MB line. Now, about the time the burning process gets to 299 or
300 MB, the writer stops, and about a minute or two later, the computer crashes.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Hook up a Freecom burner to the USB port and burn a CD larger than 300 MB.
If i stay in graphical user mode, the machine simply locks up and the LEDs on
the keyboard flash. If i switch over to the first virtual console, i get lots of
kernel error messages (then it freezes up). Normally these do not appear in the
log, but i got lucky this time, and some were there.
I really ought to be able to burn a CD.
Athlon XP 1700+, Freecom drive that was part of a special deal through the
German company Karstadt, but it looks like nothing more than a repackaged
version of one of their portables.
Created attachment 68044 [details]
Created attachment 68084 [details]
Finally got the complete, normal console output on crash.
I have come closer to finding the problem. It is NOT a problem of being able to
burn more than 300MB. One specific file in my possession will always cause this
problem. That file is openssl095a-0.9.5a-14.i386.rpm from the RedHat updates
download site (for 7.3). As i say, any time i burn that file (alone or with
other files), the machine crashes as soon as it starts burning the OpenSSL RPM.
Man, I am sorry for all the blanks you had to waste to diagnose this.
Thanks for the perfect trace, I am looking into it. It is a tad
CD-RW, my friend. Didn't waste a single blank. :) I have another bit of news
that probably won't help, but i'll toss it in for what it's worth: One of the
following three files causes the same thing: the LSB update RPM, the two libpng
update RPMs. Those being the most recent updates from RedHat's site, of course.
I can't tell You which one, because while trying to burn the CD last night, it
rebooted my system and hosed the root filesystem. It took some real magic to get
things working again, and in only 90 minutes, but with certain drawbacks (the
filesystem is no longer ext3; i had to revert back to ext2). Nonetheless, i
understandably approach burning another test CD with trepidation.
Is anything happening on this bug? I'm still afraid to burn CDs, and i normally
burn patches for RedHat onto CD so i can always have it with me. Computer
security is my field, and i feel naked without up-to-date patches...
Sorry to say, stalled.
Can you try with the receint errata 2.4.20-18, please?
Sorry to waste your wonderful console capture... I need something
fresher to press it with upstream.
No problem! Okay, for the record:
<4 arjones@server ~>uname -a
Linux server.pipasoft.com 2.4.20-18.9 #1 Thu May 29 06:54:41 EDT 2003 i686
athlon i386 GNU/Linux
Obviously (from the kernel version), this is RH 9.
Change in results: This time, there were no blinking LED's, and the machine did
not crash so absolutely as before. This time, freecom reset was called, and so
on and so forth, as seen in the (new) attached dump, and there was output to the
console due to a NULL pointer dereference, but the machine was still sort of
hobbling along. Anything i tried to do after that, though (including logging in
from a virtual console as root so i could try rebooting) brought more console
dumps (everything after the first one in the attachment), until eventually
nothing could be done but hard reboot the machine.
Created attachment 92153 [details]
We have 2.4.20-18.7, which at least should fix the oops.
One other guy says the freecom still does not work properly.
Would you test and provide some report?
I'm sorry to take so long getting back to You, but i'm VERY busy at the moment.
I'm afraid that i don't understand what You want me to test. Did You want me to
test 2.4.20-18.7? I guess i could do that (though probably not for another 2
weeks or more), though i personally fail to see the point. I use Red Hat Linux 9
Could You please clarify Your comments? Thanks!
I meant that all the io_requiest_lock dropping and also SMP fixes
to usb-uhci might make a difference. Of course, if you move to RHL 9,
it's only to the better; the only difference would be that release
suffix is going to be .9 in errata kernels. All 2.4.20's are done
from the same source.
How does the 2.4.20-20.9 work?
I suspect you cannot live that long without a burner, so what's the
workaround? Burning small images only?