[oe-issues] [Bug 2516] Collie 2.6: bulk writing to SD gets stuck
bugzilla-daemon at tinman.treke.net
bugzilla-daemon at tinman.treke.net
Mon Jun 18 16:12:31 UTC 2007
http://bugs.openembedded.org/show_bug.cgi?id=2516
--- Comment #3 from Arieh Skliarouk <skliarieh at gmail.com> 2007-06-18 09:12:30 ---
Logs are useless as there are continuous lines like these:
Jan 1 00:22:36 collie user.debug kernel: locomospi: sent: char :0
Jan 1 00:22:36 collie user.debug kernel: locomospi: received: char :ff
And they never stop coming during the test. Besides, I think the problem can
easily be reproduced on any machine.
Could be that I am wrong, and the SD subsystem did not actually stuck. Could be
there are too much data buffered both in kernel and on SD hardware and SD
hardware has problems flushing it out if there are too much of them.
If I enable "echo 1 > /sys/bus/locomo-bus/drivers/locomo-spi/verbose", write
speed drops to 25kb/s. "echo 0 ..." raises it to about 150kb/s.
Here is vmstat for the last writes to the SD
#vmstat -n 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
...
3 4 0 8212 29616 14244 0 0 0 144 104 45643 20 80 0 0
2 4 0 8212 29616 14244 0 0 0 160 107 50865 16 84 0 0
4 5 0 8116 29616 14244 0 0 0 32 58 7006 17 83 0 0
3 5 0 8116 29616 14244 0 0 0 0 103 236 0 1 0 99
3 5 0 8116 29616 14244 0 0 0 0 104 235 0 0 0 100
3 5 0 8116 29616 14244 0 0 0 0 103 233 0 0 0 100
After that, command sync never exits:
# ps awx | grep sync
1280 pts/0 D+ 0:00 sync
#
Looks like kernel buffers are flushed to SD buffers, but SD system have not
finished writing them.
But why are there so much context switches? Will it be faster to employ
busy-waiting in the locomo_spi?
As a workaroung I can use "sync" option when mounting filesystem. Is there
similar option when working directly with media (e.g. mkfs.ext2, e2fsck) ?
--
Configure bugmail: http://bugs.openembedded.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Openembedded-issues
mailing list