Opened 15 years ago

Closed 14 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 oco, 15 years ago

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.

comment:2 by oco, 14 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 stippi, 14 years ago

Resolution: fixed
Status: newclosed

Ok, thanks for the feedback. Just re-open in case you do run into it again.

Note: See TracTickets for help on using tickets.