|
Bugzilla – Full Text Bug Listing |
| Summary: | unreliable writing to external USB DVD-RAM | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Stanislav Brabec <sbrabec> |
| Component: | Kernel | Assignee: | Olaf Hering <ohering> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | mmarek, vojtech |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | hwinfo.dat.gz | ||
|
Description
Stanislav Brabec
2005-08-19 11:07:06 UTC
Created attachment 46677 [details]
hwinfo.dat.gz
Greg, here's one for you it seems. Cc'ing Jens in case it's block layer related. Additional note: The system was nearly unusable during DVD-RAM writing - sometimes application hang for 10 seconds or more, then it continues. This behavior was not experienced in 9.3. That message "reset high speed USB device" is not good. Means something really bad happened while communicating with the device. Does this dvd device have a built in power supply? Or does it get its power from the USB connection only? Is this the exact same hardware configuration as 9.3? No new or different devices plugged into the USB bus? does it work better if you disable hal, udevd and the like? Just to get rid of their polling. I tested that DVD-RAM today -- it was formated with ext3 (I'll can test other fs if needed). Tt was not that slow anymore, copying a 100MB file took about 1,5 min (including sync). But the files get corrupted quite often: # md5sum /tmp/100m-random /mnt/100m-random* f127ed04443587d89e215daec5bdfb67 /tmp/100m-random 957f4f32c94a8aef5514855610e129f1 /mnt/100m-random (*) 3b13fa35c5702d15fa4193dd55e70106 /mnt/100m-random.~1~ f127ed04443587d89e215daec5bdfb67 /mnt/100m-random.~2~ f127ed04443587d89e215daec5bdfb67 /mnt/100m-random.~3~ f127ed04443587d89e215daec5bdfb67 /mnt/100m-random.~4~ 711604593e0bd49d99fc9ac58ba849b4 /mnt/100m-random.~5~ dafbe450498d4966fdea057634f82894 /mnt/100m-random.~6~ # ls -lh /tmp/100m-random -rw-r--r-- 1 root root 100M Aug 23 09:25 /tmp/100m-random (*) The first copy was even OK until i wrote the last three. Other files are at least consistent among mounts/ejects. Aug 23 09:07:31 linux kernel: sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray Aug 23 09:25:22 linux kernel: JBD: barrier-based sync failed on sr0 - disabling barriers Aug 23 09:34:22 linux kernel: end_request: I/O error, dev sr0, sector 1175496 Aug 23 09:34:22 linux kernel: Buffer I/O error on device sr0, logical block 146937 Aug 23 09:34:22 linux kernel: lost page write due to I/O error on sr0 Aug 23 09:37:09 linux kernel: JBD: barrier-based sync failed on sr0 - disabling barriers Aug 23 09:40:23 linux kernel: JBD: barrier-based sync failed on sr0 - disabling barriers Aug 23 09:45:19 linux kernel: JBD: barrier-based sync failed on sr0 - disabling barriers Aug 23 09:55:50 linux kernel: JBD: barrier-based sync failed on sr0 - disabling barriers The "barrier-based sync" appeared short after first read/write after mount. The "end_request: I/O error" (09:34:22) appeared when I did the second copy (/mnt/100m-random.~1~ -- the first corrupted). Can you try a 2.6.14? ftp://ftp.suse.com/pub/people/olh/kernel/bug105964/ Could you provide x86_64 or SRPM packages, please? No error on 500MB of data. Writing time is 143sec for 100MB (approx. 1.07x on 3x medium with verification). so this is fixed in newer kernels? Yes. It looks so. Thanks. thanks for testing. there are too many changes, so I wont backport them to 10.0 |