USB-stick keeps stalling my whole system!
Posted: 01 Sep 2014, 12:56
Hi boys, girls and others,
imagine this: I have a new 64GB USB-stick with Porteus installed on it.
But when I use it, Porteus more or less randomly just stalls while the
read/write-LED on the stick is flashing - for somewhat 30-60 seconds.
I've tried different filesystems, different desktops (KDE/LXDX/RazorQT),
using computers with more RAM, deactivating swap completely, removing the
wireless-drivers, setting the journaling to writeback+no barriers, and over
and over again trying to dump what the kernel is doing to the logs... AND
deactivating the logs, even deleting them... but to no use.
The only thing logged when I do a "echo l > /proc/sysrq-trigger" is this:
Aug 29 15:34:26 porteus kernel: [ 3062.646196] sending NMI to all CPUs:
Aug 29 15:34:27 porteus kernel: [ 3063.318139] SysRq : Show backtrace of all active CPUs
Many lines of it, and as far as I understand it, it's just saying I triggered
a backtrace of what the kernel was doing to be logged. And I already knew
that damn it! I didn't want to know what I was doing, I wanted to know what
program or kernel-module was occupying the usb-stick.
No matter what I do, over and over again Porteus keeps almost freezing up
for up to over a minute before it continues as if nothing happened.
And during this stall, iotop is not reacting, I can move the mouse and click
on icons, but the commands will only be executed once the USB-traffic stops.
And, the network-traffic usually also stalls more or less completely.
Mostly completely, but sometimes a few KBytes will pass through downstream.
Which is really a nerving since I'm often using Porteus in internet-cafes
where it's especially important to have as much stable network-traffic and
as little problems as possible.
These "stalls" occur much more often when I'm doing some hardcore downloading.
Which first made me suspect the filesystem, but after much tweaking and
benchmarking - I've found nothing wrong with it.
The lowest sustained writerate is 5,7MBytes/sec. The fastest 12,5MBytes/sec.
Read: constantly around 30MBytes/sec.
(it's a USB 3.0 -memory, but I currently only have access to USB 2.0-ports)
So... while I don't know what the read-write-activity is, I can still
estimate that the data-volume it has to do with is roundabout 300-600MBytes.
Which leaves me even more clueless since I just yesterday observed this
problem occurring even if I wasn't not doing anything at all. (!)
And I do seem to remember having more or less the same problem while using
Slax. So, could this have something to do with me stubbornly trying to run
Linux on a USB-stick? I don't see the problem with it. Because 90% of the
time Porteus etc works just fine. More than fine, I simply love it. It's just
these seconds of intense USB-activity that really sucks the fun out of it.
Does anyone know if Linux does some kind of "scrubbing" of flash-units?
Because with windows this never happens. But I have on the other hand never
tried to run windows off a usb-stick.
And yes, I've also read about linux "dirty" data and tried setting those
intervals higher, but - you guessed it - to no use. Problem still occurs.
My currently best guess is that the filesystem backlogs something
which it more or less in panic dumps onto the stick once and a while.
Never the less, I feel I've gotten stuck right now.
Therefore: anyone of you got any bright throughts on the matter?
JustME
imagine this: I have a new 64GB USB-stick with Porteus installed on it.
But when I use it, Porteus more or less randomly just stalls while the
read/write-LED on the stick is flashing - for somewhat 30-60 seconds.
I've tried different filesystems, different desktops (KDE/LXDX/RazorQT),
using computers with more RAM, deactivating swap completely, removing the
wireless-drivers, setting the journaling to writeback+no barriers, and over
and over again trying to dump what the kernel is doing to the logs... AND
deactivating the logs, even deleting them... but to no use.
The only thing logged when I do a "echo l > /proc/sysrq-trigger" is this:
Aug 29 15:34:26 porteus kernel: [ 3062.646196] sending NMI to all CPUs:
Aug 29 15:34:27 porteus kernel: [ 3063.318139] SysRq : Show backtrace of all active CPUs
Many lines of it, and as far as I understand it, it's just saying I triggered
a backtrace of what the kernel was doing to be logged. And I already knew
that damn it! I didn't want to know what I was doing, I wanted to know what
program or kernel-module was occupying the usb-stick.
No matter what I do, over and over again Porteus keeps almost freezing up
for up to over a minute before it continues as if nothing happened.
And during this stall, iotop is not reacting, I can move the mouse and click
on icons, but the commands will only be executed once the USB-traffic stops.
And, the network-traffic usually also stalls more or less completely.
Mostly completely, but sometimes a few KBytes will pass through downstream.
Which is really a nerving since I'm often using Porteus in internet-cafes
where it's especially important to have as much stable network-traffic and
as little problems as possible.
These "stalls" occur much more often when I'm doing some hardcore downloading.
Which first made me suspect the filesystem, but after much tweaking and
benchmarking - I've found nothing wrong with it.
The lowest sustained writerate is 5,7MBytes/sec. The fastest 12,5MBytes/sec.
Read: constantly around 30MBytes/sec.
(it's a USB 3.0 -memory, but I currently only have access to USB 2.0-ports)
So... while I don't know what the read-write-activity is, I can still
estimate that the data-volume it has to do with is roundabout 300-600MBytes.
Which leaves me even more clueless since I just yesterday observed this
problem occurring even if I wasn't not doing anything at all. (!)
And I do seem to remember having more or less the same problem while using
Slax. So, could this have something to do with me stubbornly trying to run
Linux on a USB-stick? I don't see the problem with it. Because 90% of the
time Porteus etc works just fine. More than fine, I simply love it. It's just
these seconds of intense USB-activity that really sucks the fun out of it.
Does anyone know if Linux does some kind of "scrubbing" of flash-units?
Because with windows this never happens. But I have on the other hand never
tried to run windows off a usb-stick.
And yes, I've also read about linux "dirty" data and tried setting those
intervals higher, but - you guessed it - to no use. Problem still occurs.
My currently best guess is that the filesystem backlogs something
which it more or less in panic dumps onto the stick once and a while.
Never the less, I feel I've gotten stuck right now.
Therefore: anyone of you got any bright throughts on the matter?
JustME