On Mon, 5 Nov 2007, Neil Brown wrote:
On Sunday November 4, [EMAIL PROTECTED] wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
root 274 0.0 0.0 0 0 ?
On Sunday November 4, [EMAIL PROTECTED] wrote:
> # ps auxww | grep D
> USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
> root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
> root 274 0.0 0.0 0 0 ?DOct21 13:00 [pdflush]
>
Michael Tokarev wrote:
> Justin Piszcz wrote:
>> On Sun, 4 Nov 2007, Michael Tokarev wrote:
> []
>>> The next time you come across something like that, do a SysRq-T dump and
>>> post that. It shows a stack trace of all processes - and in particular,
>>> where exactly each task is stuck.
>
>> Yes
Please cc me on replies; I'm not on the list.
I don't know if this is fixable, or even if it *should* be fixed,
but: summary: shortly after the state of the machine is "2
independent mdadm --monitor instances, resyncing", the
machine totally locks up. Details follow.
I boot my machine from a US
Bill Davidsen wrote:
I don't understand your point, unless there's a Linux bootloader in the
BIOS it will boot whatever 512 bytes are in sector 0. So if that's crap
it doesn't matter what it would do if it was valid, some other bytes
came off the drive instead. Maybe Windows, since there seem
Hi,
I finished copying all data from old disc hdc to my shiny new
RAID5 array (/dev/hda3 /dev/sda3 missing). Next step is to create a
partition on hdc and add it to the array. And so I did this:
# mdadm --add /dev/md1 /dev/hdc3
But then I had a problem - the /dev/hdc3 was a spare, it didn't
resy
On Sun, 4 Nov 2007, Michael Tokarev wrote:
Justin Piszcz wrote:
On Sun, 4 Nov 2007, Michael Tokarev wrote:
[]
The next time you come across something like that, do a SysRq-T dump and
post that. It shows a stack trace of all processes - and in particular,
where exactly each task is stuck.
Justin Piszcz wrote:
> On Sun, 4 Nov 2007, Michael Tokarev wrote:
[]
>> The next time you come across something like that, do a SysRq-T dump and
>> post that. It shows a stack trace of all processes - and in particular,
>> where exactly each task is stuck.
> Yes I got it before I rebooted, ran th
On Sun, 4 Nov 2007, BERTRAND Joël wrote:
Justin Piszcz wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
root 274 0.0 0.0 0 0 ?DOct21 13:0
Justin Piszcz wrote:
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
root 274 0.0 0.0 0 0 ?DOct21 13:00 [pdflush]
After several days/weeks, this i
Justin Piszcz wrote:
> # ps auxww | grep D
> USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
> root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
> root 274 0.0 0.0 0 0 ?DOct21 13:00 [pdflush]
>
> After several days/wee
Time to reboot, before reboot:
top - 07:30:23 up 13 days, 13:33, 10 users, load average: 16.00, 15.99, 14.96
Tasks: 221 total, 7 running, 209 sleeping, 0 stopped, 5 zombie
Cpu(s): 0.0%us, 25.5%sy, 0.0%ni, 74.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8039432k total, 1744356k used,
# ps auxww | grep D
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
root 273 0.0 0.0 0 0 ?DOct21 14:40 [pdflush]
root 274 0.0 0.0 0 0 ?DOct21 13:00 [pdflush]
After several days/weeks, this is the second time this
13 matches
Mail list logo
