|
Jan 26 |
comment |
Spreading stdin to parallel processes I doubt any standard utility will do this; I would roll my own, perhaps using Python. How large in bytes is the list of files? I ask because using the pipe being unblocked to indicate idle means the processes' workloads can be out of balance by one pipe buffer (by default, 64K; always at least 4K), perhaps more if the process buffers internally. If that's not acceptable, you'll need a new mechanism. |
|
Jan 19 |
awarded | Critic |
|
Jan 14 |
awarded | Mortarboard |
|
Jan 12 |
awarded | Commentator |
|
Jan 12 |
comment |
Determining cause of Linux kernel panic Not sure. I'm a software guy; this is the limit of my expertise. |
|
Jan 11 |
comment |
Determining cause of Linux kernel panic All it means to me is that your processor isn't working. Probably the overclocking, maybe the other thing you mentioned (it's not something I've heard about), maybe a defective unit. |
|
Jan 11 |
comment |
Determining cause of Linux kernel panic Sweet. Updated my answer as well. |
|
Jan 11 |
revised |
Determining cause of Linux kernel panic more info |
|
Jan 11 |
revised |
Determining cause of Linux kernel panic more info |
|
Jan 10 |
comment |
Determining cause of Linux kernel panic Actually, I take that back. On Ubuntu, there is a linux-crashdump package you can install fairly easily to automatically put crashes in /var/crash. What distribution are you using? |
|
Jan 10 |
comment |
Determining cause of Linux kernel panic One of those little quirks. :-/ There's no fundamental reason Ubuntu or RedHat couldn't set up a nice kdump-based system for crash logging and display out of the box, but no one's done it as far as I know. |
|
Jan 10 |
comment |
How to pass a CTRL-D to a command line within a script? I don't think the premise of the question is correct. As others have said, ctrl+D means end-of-file (more formally: causes bash to close the pipe connected to the child process's stdin). cat and uuencode shouldn't read from stdin with those arguments. mail's stdin is closed when the subshell left of the pipe ends. You say that it's hanging for ctrl-D, but I don't think that's true. What did you actually observe? |
|
Jan 10 |
comment |
Determining cause of Linux kernel panic I don't think overclocking failures are as obvious as that to spot in the logs; I'm not a processor expert, but it's not like the whole processor correctly handles the clock cycle or indicates to the OS somehow that it missed it. Let me know if you have trouble getting logs, but IMHO by far the easiest way to know if it's an overclocking problem is to see if it happens when not overclocking. |
|
Jan 10 |
answered | Determining cause of Linux kernel panic |
|
Sep 13 |
awarded | Yearling |
|
Apr 10 |
comment |
32 bit appplication on 64 bit linux not working All I can say from this log is that there was a problem on or near line 34 of /usr/local/bin/ztemtApp/zteusbserial/below2.6.27/usb-serial.c. You'll need to post a link to that file (and possible other ones it #includes) for anyone to help. |
|
Sep 15 |
revised |
How can I tell if the pipe buffer is full? fixed heredoc quoting |
|
Sep 15 |
revised |
How can I tell if the pipe buffer is full? fixed typo |
|
Sep 15 |
revised |
How can I tell if the pipe buffer is full? added dtrace script |
|
Sep 15 |
awarded | Supporter |