Re: The future of the NSLU2-Linux project - your input is required!
- In article <iool83-qc6.ln1@...>,
> That being said, there is one little issue. I do think that 3 machinesRight.
> should be enough to get ~90% or more of the archive built; but to
> effectively do so, the machines should have more RAM. To demonstrate
> this, please have a look at
> <http://samba.grep.be/~wouter/wendy-trashing.txt>, which shows the
> output from a vmstat run while wendy was compiling a C++ program (the
> boost source package, to be exact). As you can clearly see, wendy needs
> to use a lot of swap, which horribly slows down the builds: both bob and
> wendy are capable of building about 10-20 C packages a day, but usually
> need multiple days for one C++ package; this is because the C++ compiler
> requires a lot more memory than the C compiler.
> If this project wants to pursue the goal of ending up as an official
> Debian architecture, then this will need to be remedied somehow.
Since I've posted this, someeone's offered beefier hardware as buildd
hosts, with more RAM and faster processors. This should go a long way to
remedying this issue.
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ ..../ / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ ..../ -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/
On 1/31/06, John Bowler <jbowler@...> wrote:
> From: Adrian Day
> >Running 'ls -lR /' will lock a ssh session.
> Well, can you still ping the slug? (I.e. does it still
> respond to ping?)
> I've never managed to lock a system (i.e. a hard kernel lock
> or a crash) by doing that, or the pretty much identical
> command "find /", and I do it quite a lot (it's a quick and
> easy way of getting CPU load).
> What gets locked exactly? Assuming the ping doesn't respond,
> does the power button work? What if you run a shell script to
> toggle the disk 1 led on/off:
> while true; do echo -n 100 >/sys/class/leds/disk-1/brightness; sleep 1; echo -n 0 >/sys/class/leds/disk-1/brightness; sleep 1; done
> Does that keep going? (Running in another ssh session). What
> happens when the LED is being made to flash from the kernel:
> echo timer >/sys/class/leds/disk-1/trigger
> echo 1000 >/sys/class/leds/disk-1/frequency
> Does it lock up then? (That would indicate a kernel crash).
It's definitely not a kernel crash. It just kills the current ssh
session. I'm at work now but will attempt to delve a little deeper
into this when I get home. I'm not alone - Jean Fabrice has
experienced similar problems - I'd posted something about this a week
or so back.
Like I said, I'll spend some time looking into this in more detail.
It's the least I can do compared to the considerable effort you and
others have put into the slug.