Hi, Alfred! Thanks for the update. It had been running for >24h without any issues. :-) But, I can't help myself, I still do the switch of NORMAL_POLICY_CACHED_WAITTIME from default 6 to 5 on my system: Overall appearance feels better with this setting, and it's a purely subjective impression, of course.
must inform you, that I have some issues with your kernel patches. The problems occour with the actual kernel, with the 4.5 kernel and with the your test patches too.
Heavy writes to USB Sticks and SD cards leads to a hard lock of the kernel. Only hard power off is possible than. I using f3write/f3read to test the speed of USB sticks and ckeck for errors (fake sticks). Tested different filesystems (ext4, exfat, f2fs) and different io schedulers (noop, bfq). Nearly always a crash. In opposite to the original bfs (using it with the zen-kernel) and the vanilla kernel, there was no crash at all. Anyone other with the same problem?
@Mike Any lucky to capture the crash log when it happens? And any detail steps for your testing? So I can try to reproduce it and if it can be, it would be easier to find the cause.
sorry, no crash log (I have disabled mostly all of the debug features within the kernel config, I know, not so helpful ;) ). Test procedure is simple, plug in a USB thumb drive and start f3write (see http://oss.digirati.com.br/f3/). I can't remember correct, if I always used one of my USB3 ports, or if that happened with the USB2 ports too. But doesn't matter, because with the integrated SD Card drive it crashes too. Most times the crash occurs immediately, sometimes after some minutes writing to the drives. As I already wrote, I needed some time to drill down the cause to your kernel patches, because I swap/test here gc-kernel, zen-kernel and default OpenSuse kernel.
I have done a quick f3write test with the integrated SD slot on my machine. The result is OK and no crash. I will try other fs type on another sd card later.
So would you confirm which USB port(USB3 or USB2 one) has the issue and what type of usb stick(2 or 3) you used for testing?
Do you happen to have another machine tested and have same issue?
testing with 4.6.2-gc. No problems so far with another computer, no crashes on writing to USB thumb drives and SD card (USB card reader). Compiling the gc kernel again with the same .config as the zen kernel on my laptop to exclude some differences. I think, I'm going crazy, no crash during writing to USB thumb drives. But juhu, I'm not crazy, it crashes writing to my micro SD within my internal card reader ;). Verified by the zen kernel, with it no crash at all. Testing with a 3. computer wasn't successful, because the kernel doesn't boot there. Until now, don't know why. (Here again, same .config with zen kernel does boot without problems). So will test further.
PS: MicroSD card 64 GB Lexar class 10 with ext4 without journal.
@Mike I think you mean the -vrq patch? I have done ext4 f3write test for an 64 SD card and no crash happended. Based on current information, the crash may due to -vrq scheduler and your internal sd reader driver doesn't work well, maybe the driver trigger vrq scheduler crash or vrq scheduler trigger the issue in the driver which we don't know unless we have further crash trace log.
yes of course, I am on linux-4.6.y-vrq, the git folder is only named linux-gc. And if I remember correct, there isn't any gc anymore with new kernels ;) I would try to compile the kernel with some debugging information, what exactly should I activate in the .config?
set these debug options from your link, but doesn't help. Nothing in log. Hard lockup of the kernel. Crash does occur after some time writing to the SD card. No clue why.
@Mike Sorry to hear that. A few ways I can suggest for your issue 1. Try to use a debug console and set the kernel debug level to lowest to capture kernel message to the console as more as possible, login to system in console mode and do the test in console. 2. Try to find out if there any module options for this driver module and see if it can bypass this issue by setting different options.
Hi, Alfred!
ReplyDeleteThanks for the update. It had been running for >24h without any issues. :-)
But, I can't help myself, I still do the switch of NORMAL_POLICY_CACHED_WAITTIME from default 6 to 5 on my system: Overall appearance feels better with this setting, and it's a purely subjective impression, of course.
BR Manuel Krause
@Manuel
DeleteThanks for the input. I will reconsider the 5ms setting as default after performance tests.
Hi Alfred,
ReplyDeletemust inform you, that I have some issues with your kernel patches. The problems occour with the actual kernel, with the 4.5 kernel and with the your test patches too.
Heavy writes to USB Sticks and SD cards leads to a hard lock of the kernel. Only hard power off is possible than.
I using f3write/f3read to test the speed of USB sticks and ckeck for errors (fake sticks). Tested different filesystems (ext4, exfat, f2fs) and different io schedulers (noop, bfq). Nearly always a crash. In opposite to the original bfs (using it with the zen-kernel) and the vanilla kernel, there was no crash at all.
Anyone other with the same problem?
Regards sysitos
@Mike
DeleteAny lucky to capture the crash log when it happens?
And any detail steps for your testing? So I can try to reproduce it and if it can be, it would be easier to find the cause.
BR Alfred
Hi Alfred,
Deletesorry, no crash log (I have disabled mostly all of the debug features within the kernel config, I know, not so helpful ;) ).
Test procedure is simple, plug in a USB thumb drive and start f3write (see http://oss.digirati.com.br/f3/). I can't remember correct, if I always used one of my USB3 ports, or if that happened with the USB2 ports too. But doesn't matter, because with the integrated SD Card drive it crashes too.
Most times the crash occurs immediately, sometimes after some minutes writing to the drives.
As I already wrote, I needed some time to drill down the cause to your kernel patches, because I swap/test here gc-kernel, zen-kernel and default OpenSuse kernel.
Regards sysitos
Hi Mike,
DeleteI have done a quick f3write test with the integrated SD slot on my machine. The result is OK and no crash. I will try other fs type on another sd card later.
So would you confirm which USB port(USB3 or USB2 one) has the issue and what type of usb stick(2 or 3) you used for testing?
Do you happen to have another machine tested and have same issue?
BR Alfred
Hi Alfred,
Deletetesting with 4.6.2-gc. No problems so far with another computer, no crashes on writing to USB thumb drives and SD card (USB card reader). Compiling the gc kernel again with the same .config as the zen kernel on my laptop to exclude some differences. I think, I'm going crazy, no crash during writing to USB thumb drives. But juhu, I'm not crazy, it crashes writing to my micro SD within my internal card reader ;). Verified by the zen kernel, with it no crash at all. Testing with a 3. computer wasn't successful, because the kernel doesn't boot there. Until now, don't know why. (Here again, same .config with zen kernel does boot without problems).
So will test further.
PS: MicroSD card 64 GB Lexar class 10 with ext4 without journal.
Regards sysitos
@Mike
DeleteI think you mean the -vrq patch?
I have done ext4 f3write test for an 64 SD card and no crash happended. Based on current information, the crash may due to -vrq scheduler and your internal sd reader driver doesn't work well, maybe the driver trigger vrq scheduler crash or vrq scheduler trigger the issue in the driver which we don't know unless we have further crash trace log.
BR Alfred
Hi Chen,
ReplyDeleteyes of course, I am on linux-4.6.y-vrq, the git folder is only named linux-gc. And if I remember correct, there isn't any gc anymore with new kernels ;)
I would try to compile the kernel with some debugging information, what exactly should I activate in the .config?
Regards sysitos
For debug options, pls reference to my another post http://cchalpha.blogspot.com/2015/07/41-vrq-reworking.html
DeleteBR Alfred
Hi Alfred,
Deleteset these debug options from your link, but doesn't help. Nothing in log. Hard lockup of the kernel. Crash does occur after some time writing to the SD card. No clue why.
PS: lsusb shows: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Regards sysitos
@Mike
DeleteSorry to hear that. A few ways I can suggest for your issue
1. Try to use a debug console and set the kernel debug level to lowest to capture kernel message to the console as more as possible, login to system in console mode and do the test in console.
2. Try to find out if there any module options for this driver module and see if it can bypass this issue by setting different options.
BR Alfred