Opened 16 years ago
Closed 15 years ago
#3400 closed bug (fixed)
PANIC: could not write back block 6293 (General system error) under heavy load
Reported by: | oco | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Add-Ons | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
It used to be an operation timed out, but i have added
result = acquire_sem_etc(device->notify, 1, B_RELATIVE_TIMEOUT, 0);
in usb_disk_transfer_data. I have also increased the timeout to 5000000. I am not sure if it is a good idea (i am a newbie in this area). It was to get rid of the "acquire_sem failed while waiting for data transfer" message.
The problem occur while running the freepascal test suite on a partition on the USB drive. I can reproduce the problem each time. The test suite run ok on an IDE partition.
Now, the syslog show this :
usb_disk: sending or receiving of the data failed
usb error control pipe 19: timeout wainting for queued request to complete
usb error control pipe 19: timeout wainting for queued request to complete
usb error control pipe 19: timeout wainting for queued request to complete
usb_disk: write fails with 0xffffffff
usb error control pipe 19: timeout wainting for queued request to complete
usb error control pipe 19: timeout wainting for queued request to complete
usb error control pipe 19: timeout wainting for queued request to complete
usb_disk: read fails with 0xffffffff
file_cache: read pages failed: General system error
usb_disk: sending the command block wrapper failed
usb error control pipe 19: timeout waiting for queud request to complete
usb error control pipe 19: timeout waiting for queud request to complete
usb error control pipe 19: timeout waiting for queud request to complete
usb_disk: write fails with 0xffffffff
Change History (3)
comment:1 by , 16 years ago
comment:2 by , 15 years ago
After hrev34655, because it might fix problems under heavy load, i have tried to reproduce many, many times this problem. I was unable to reproduce it anymore on the same hardware. I think this ticket could be closed. If not hrev34655, the problem was probably fixed since last begeistert (if i remember correctly i was still able to reproduce it there).
comment:3 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Ok, thanks for the feedback. Just re-open in case you do run into it again.
After fixing a bug in Freepascal's RTL under Haiku, the problem occur less frequently on my older laptop, but still occur. On my newer laptop, the problem does not occur anymore with the same USB hard drive and the same revision.
The bug was about signal handling. Each Freepascal program were generating lots of vm_soft_fault in the syslog. The alternative signal stack was not initialized correctly. And hundreds of them are loaded during the test suite.
Now, maybe the problem is related to some hardware in my old laptop. I will bring the offending computer at next BeGeistert in case someone is interested to investigate more.