|
|
|
|
|
|
  |
Page 355 of 359 [5372 Posts]
|
View previous topic :: View next topic
Goto page:
Previous
1,
2,
3,
...,
353,
354,
355,
356,
357,
358,
359
Next
|
| Author |
Message |
iforone
*nix forums Guru
Joined: 28 Dec 2005
Posts: 330
|
 Posted: Sat Jul 08, 2006 4:40 am Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Andrew Sackville-West wrote:
| Quote: | On Fri, Jul 07, 2006 at 11:08:00AM +0200, Dominique Dumont wrote:
Andrew Sackville-West <andrew@farwestbilliards.com> writes:
now on to finding the source of my hard locks. ugh./
Be sure to check the temperature of your CPU. (been there)
yeah, another good idea. unfortunately, that's a no go either. I'm
running at a pretty steady 132 F/ 56 C right now with it climbing to
about 140F, but no more when I'm pushing it. Also, it seems more
common when I'm NOT working. Also, doesn't crop up when I leave some
crunching job running overnight (like a big transcode job or something).
I ran memtest all night with no problems at all. Also ran stesscpu for
a while with no probs. I'm beginning to think, as i crawl through my
memory, that it might be related to some acpi stuff I was fooling
with. we'll see.
These locks are particularly frustrating as they leave no trace in the
logs. the logs just stop until they come up from the reboot. I've seen
it happen while I'm working maybe two or three times... just lock
right up and be totally gone. screen looks fine, nothing responds, no
ssh, no response to keyboard (capslock/numlock frozen) etc. Sometimes
even the restart button on the box won't work and I'll have to force a
shutdown with the 4-second power button press. So I have no doubts
that its locking up tight. This is part of why I think it might be
related to that acpi stuff as it seems to happen a lot when I'm NOT
working at it. perhaps the bios is trying to suspend something and it
causes a problem?
|
I'm running a dual-boot;
[hdc] Debian Sarge (3.1r2, kernel 2.6.8-3-686)
[hda] win98
Couple of thoughts;
* I notice the "nobody" account/group(?) start thrashing late at night, when
the monitor (only) has been sleeping for a little, which translates into me not
using the system and it's resources at that time (idle). I ran 'top' when I
heard this going on (fearing a rootkit), and found 'nobody' using 'find' IIRC
....I suspect updating the databases ('updatedb'), or 'inodes' or the ext3
journal, or defragging (the linux way) - likely being triggered as a 'cron'
job/task perhaps(?)...yet pushed off in time until there are ebough system
resources available -- I'm still not sure exactly what it's doing, but the 1st
time it happened, I 'kill -9 PID' of the processID found using 'top'. It killed
it alright, but only until the system had 'rested' and off to the races it
went, once again.
ACPI hmm.. Let's see output of 'dmesg | grep ACPI'
Do you use an 'acpi=force' kernel boot option in GRUB/Lilo ??
I do on this ~1999 PII, 350MHz 100FSB, 192MB RAM;
~$ cat /grub/boot/menu.lst
=============
[...]
title Debian GNU/Linux, kernel 2.6.8-3-686
root (hd1,0)
kernel /boot/vmlinuz-2.6.8-3-686 root=/dev/hdc1 ro acpi=force
initrd /boot/initrd.img-2.6.8-3-686
savedefault
boot
[...]
=============
[ anecdotal rantings ensue]
* My Keyboard died recently, it was possessed by evil demons, satanic minions,
and Linda Blair :-8 -- After experiencing some similar hard lockups, (yet only
after returning after having been away for awhile on this box), I finally
_refused_ to yank the power cord -- this last time. (The default ATX 4sec.
constant depress doesn't quite work anymore  ) - and no, it's not the BIOS,
nor power management setting that's wrong.
I started POUNDING on the keyboard -- any/all combos -- full open flat hands
and all 
I ended up with a Keyboard that would not only NOT let me into the BIOS (F2),
it would NOT let me type ANYTHING at all !! -- Even after a hard kill and a
cold boot (actually many of them)....and many PS/2 cable yanks/plugging ins of
both the Rodent and Keyboard, with system running and sometimes not
running........
I found eventually that these "7" keys were the ONLY ones that would output
anything, and only sometimes..
These magic 7 keys are/were; (NumLock On -->) __3,4,5,6, 'Alt', ']', '[''__
(brackets)
Oh, the NumLock was fritzzing all the time, -- sometimes the CapLock would go
on by poushing the TAB key.
....and the ONLY output of all these 7 was the SAME (a BACKSLASH character!!!)
-- yep, each one of the diff 7 keys output a '\' (...or was it '/' forward
slash), I forget. But I was determind to fix it at all costs! Thinking it was
some sort of software issue, but after realizing I could NOT boot to a LiveCD
and use the keyboard, nor could I enter the BIOS, I though I munged my SuperI/O
chip's Keyboard Controller :-(
I even ReFlashed the BIOS :-p
More than once...
I also moved the CMOS jumper and "Maintenance mode" and booted...nada
I then REmoved the jumper for *Recovery Mode*, which turned out to be the ONLY
way I could Flash (using a Floppy and listening for beep codes), because I
could not hit <ENTER> once booted into the Intel Flash utility <mad!>.
Long story end is -- I got a NEW Keyboard (actually used), fired her up, and
All is Well !!
[ /anecdotal rantings end ]
I'm not sure that (above tale) was meaningful at all to you - but wanted to
share my exp., perhaps it'll spark/ignite some ideas.
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
 |
iforone
*nix forums Guru
Joined: 28 Dec 2005
Posts: 330
|
| Posted: Sat Jul 08, 2006 8:40 am Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Willie Wonka wrote:
| Quote: | Couple of thoughts;
* I notice the "nobody" account/group(?) start thrashing late at night, when
the monitor (only) has been sleeping for a little, which translates into me
not
using the system and it's resources at that time (idle). I ran 'top' when I
heard this going on (fearing a rootkit), and found 'nobody' using 'find' IIRC
...I suspect updating the databases ('updatedb'), or 'inodes' or the ext3
journal, or defragging (the linux way) - likely being triggered as a 'cron'
job/task perhaps(?)...yet pushed off in time until there are ebough system
resources available -- I'm still not sure exactly what it's doing, but the
1st
time it happened, I 'kill -9 PID' of the processID found using 'top'. It
killed
it alright, but only until the system had 'rested' and off to the races it
went, once again.
|
Yep...
Look what I found in /etc/updatedb.conf
=========
[...]
# run find as this user
LOCALUSER="nobody"
export LOCALUSER
# cron.daily/find: run at this priority -- higher number means lower priority
# (this is relative to the default which cron sets, which is usually +5)
NICE=10
export NICE
=========
Not that this is the cause of your lockups...but could be, or may be just a
'catalyst'. I would imagine the NICE= entry is responsible for amount of
priority, as noted in the above commented lines.
Back to you and Memtest86;
I too have used the Knoppix CD and type this at the prompt;
Boot: memtest86
Just did a bit of searching my local HD, and it turns out I hadn't yet
installed memtest86+ this time around - so I just recently installed it, since
I want to see if the 'update-grub' command would do what it says in the
AutoMagic section.
I recall having 'memtest86' as a GRUB option in the past - so after I run the
update, I'll be back to let you know (since you seemed to have a little trouble
using memtest86+ at first... I guess you thought/think you have to actually
edit (comment/uncomment the "memtest86" line) the /boot/grub/menu.lst file --
but according to AutoMagic, you shouldn't have to. The 'update-grub' command is
all that's needed.
It's important to distinquish between *memtest86* and *memtest86+* - the latter
is newer;
Run these commands for info/explanation;
~$ apt-cache show memtest86
~$ apt-cache show memtest86+
Just to summarize - the newer memtest86*+* is for more recent hardware, and
likely updated with many bugs worked out.
"Memtest86+ is based on memtest86 3.0, and adds support for recent
hardware, as well as a number of general-purpose improvements,
including many patches to memtest86 available from various sources."
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
iforone
*nix forums Guru
Joined: 28 Dec 2005
Posts: 330
|
| Posted: Sat Jul 08, 2006 9:30 am Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Willie Wonka wrote:
| Quote: | Back to you and Memtest86;
I too have used the Knoppix CD and type this at the prompt;
Boot: memtest86
Just did a bit of searching my local HD, and it turns out I hadn't yet
installed memtest86+ this time around - so I just recently installed it,
since
I want to see if the 'update-grub' command would do what it says in the
AutoMagic section.
I recall having 'memtest86' as a GRUB option in the past - so after I run the
update, I'll be back to let you know (since you seemed to have a little
trouble
using memtest86+ at first... I guess you thought/think you have to actually
edit (comment/uncomment the "memtest86" line) the /boot/grub/menu.lst file --
but according to AutoMagic, you shouldn't have to. The 'update-grub' command
is
all that's needed.
|
Okey dokey;
Back from the Update-grub procedure and have NOT yet rebooted, but look at the
output;
Recall that I ran 'sudo apt-get install memtest86+' beforehand -- Oh, I also
did 'sudo updatedb', which I do directly after every app type install, so the
system can find what it needs.
~$ sudo update-grub
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Searching for splash image... none found, skipping...
Found kernel: /boot/vmlinuz-2.6.8-3-686
Found kernel: /boot/vmlinuz-2.6.8-2-386
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done
Note the 'memtest86+.bin' entry ;-)
So now when I reboot I'll have that option...
hth someone
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Andrew Sackville-West
*nix forums Guru
Joined: 22 Mar 2005
Posts: 606
|
| Posted: Sat Jul 08, 2006 7:20 pm Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
On Fri, Jul 07, 2006 at 09:22:59PM -0700, Willie Wonka wrote:
[... stuff about cron jobs ...]
definitely this is not my issue as it happens at any time of
day. Also, this is truly a hard lock -- no disk activity, no response
of any kind from any stimulus I can come up with. In fact, if the
machine is in a state where the screen is automatically turned off
(power saving mode) the screen will not reactivate.
| Quote: |
ACPI hmm.. Let's see output of 'dmesg | grep ACPI'
|
andrew@basement:~$ dmesg | grep ACPI
BIOS-e820: 000000000dfec000 - 000000000dfef000 (ACPI data)
BIOS-e820: 000000000dfff000 - 000000000e000000 (ACPI NVS)
ACPI: RSDP (v000 ASUS ) @ 0x000f8070
ACPI: RSDT (v001 ASUS A7N266VM 0x42302e31 MSFT 0x31313031) @
0x0dfec000
ACPI: FADT (v001 ASUS A7N266VM 0x42302e31 MSFT 0x31313031) @
0x0dfec100
ACPI: BOOT (v001 ASUS A7N266VM 0x42302e31 MSFT 0x31313031) @
0x0dfec040
ACPI: MADT (v001 ASUS A7N266VM 0x42302e31 MSFT 0x31313031) @
0x0dfec080
ACPI: DSDT (v001 ASUS A7N266VM 0x00001000 MSFT 0x0100000b) @
0x00000000
ACPI: PM-Timer IO Port: 0xe408
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl edge)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ9 used by override.
Using ACPI (MADT) for SMP configuration information
ACPI: bus type pci registered
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 16 1 *5
ACPI: PCI Interrupt Link [LNKB] (IRQs 16 1 *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 16 1 *0, disabled.
ACPI: PCI Interrupt Link [LNKD] (IRQs 16 1 *5
ACPI: PCI Interrupt Link [LNKE] (IRQs 19) *11
ACPI: PCI Interrupt Link [LNKF] (IRQs 20 21 22) *5
ACPI: PCI Interrupt Link [LNKU] (IRQs 20 21 22) *10
ACPI: PCI Interrupt Link [LNKI] (IRQs 20 21 22) *10
ACPI: PCI Interrupt Link [LNKJ] (IRQs 20 21 22) *5
ACPI: PCI Interrupt Link [LNKK] (IRQs 20 21 22) *11
ACPI: PCI Interrupt Link [LNKM] (IRQs 20 21 22) *0, disabled.
ACPI: PCI Root Bridge [PCI0] (0000:00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI2._PRT]
pnp: PnP ACPI init
pnp: PnP ACPI: found 17 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
ACPI wakeup devices:
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: PCI Interrupt Link [LNKI] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [LNKI] -> GSI 22 (level,
high) -> IRQ 177
ACPI: PCI Interrupt Link [LNKU] enabled at IRQ 21
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKU] -> GSI 21 (level,
high) -> IRQ 185
ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKU] -> GSI 21 (level,
high) -> IRQ 185
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 18
ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [LNKD] -> GSI 18 (level,
high) -> IRQ 193
ACPI: PCI Interrupt Link [LNKK] enabled at IRQ 20
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LNKK] -> GSI 20 (level,
high) -> IRQ 201
ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 19
ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKE] -> GSI 19 (level,
high) -> IRQ 209
andrew@basement:~$
| Quote: |
Do you use an 'acpi=force' kernel boot option in GRUB/Lilo ??
I do on this ~1999 PII, 350MHz 100FSB, 192MB RAM;
|
nope. there is some acpi setting in the BIOS that is turned on, can't
remember what it is exactly, will post in after next
reboot. meanwhile, I found I had apcid turned on from some acpi stuff
I was playing with a few months ago. I've update-rc.d remove'd it and
haven't had a problem in a day and a half (knock wood). I"m going to
go at this thing from the ground up again starting with all BIOS
settings and... heh... logging my actions, there's a novel thought.
| Quote: |
[ anecdotal rantings ensue]
...
[ /anecdotal rantings end ]
|
well. that's quite a tale. All I can say is, if the keyboard doesn't
seem to work right, maybe next time try a new keyboard first? he
he. on that note, i've heard several tales of keyboards being
resurrected by putting them through the dishwasher... I'd google it
first, but if you have a dead keyboard, it certainly wouldn't
hurt. I'm sure it'll void the warranty though.
A |
|
| Back to top |
|
|
Andrew Sackville-West
*nix forums Guru
Joined: 22 Mar 2005
Posts: 606
|
| Posted: Sat Jul 08, 2006 7:20 pm Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
On Sat, Jul 08, 2006 at 02:02:42AM -0700, Willie Wonka wrote:
| Quote: |
~$ sudo update-grub
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Searching for splash image... none found, skipping...
Found kernel: /boot/vmlinuz-2.6.8-3-686
Found kernel: /boot/vmlinuz-2.6.8-2-386
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done
Note the 'memtest86+.bin' entry ;-)
So now when I reboot I'll have that option...
|
I googled the memtest issue and found one good hit that said you have
to burn the img directly to a floppy. I've done that with dd and it
works like a charm, boots right into memtest. It must be some grub
related issue that prevents it from booting properly from within
grub. maybe grub is occupying the memory it tries to load
to. Regardless, I've run memtest for about 13 hours with no
errors. another culprit eliminated.
A |
|
| Back to top |
|
|
iforone
*nix forums Guru
Joined: 28 Dec 2005
Posts: 330
|
| Posted: Sat Jul 08, 2006 8:10 pm Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Andrew Sackville-West wrote:
| Quote: | On Sat, Jul 08, 2006 at 02:02:42AM -0700, Willie Wonka wrote:
~$ sudo update-grub
Searching for GRUB installation directory ... found: /boot/grub .
Testing for an existing GRUB menu.list file... found: /boot/grub/menu.lst .
Searching for splash image... none found, skipping...
Found kernel: /boot/vmlinuz-2.6.8-3-686
Found kernel: /boot/vmlinuz-2.6.8-2-386
Found kernel: /boot/memtest86+.bin
Updating /boot/grub/menu.lst ... done
Note the 'memtest86+.bin' entry ;-)
So now when I reboot I'll have that option...
I googled the memtest issue and found one good hit that said you have
to burn the img directly to a floppy. I've done that with dd and it
works like a charm, boots right into memtest. It must be some grub
related issue that prevents it from booting properly from within
grub. maybe grub is occupying the memory it tries to load
to. Regardless, I've run memtest for about 13 hours with no
errors. another culprit eliminated.
|
Oh... so you *can* and do have a choice for memtest86+ in the GRUB menu ?
And when you try to run it from there (using up/down arrows to select it) , it
Hangs? and gives you that "Out of memory" error you stated earlier ?
FWIW, when I recently installed memtest86*+*, I inadvertantly installed
_memtest86_ (no '+' -- the Older version)...so I first 'sudo apt-get remove
--purge memtest86' and only *then* did I install memtest86+, and then I ran
'sudo updatedb', and consequently, 'sudo update-grub' and that was it  .
FWIW - No manual editing of /boot/grub/menu.lst was necessary.
Do you have the older "memtest86" installed too? (perhaps conflicts with '+'
version).
If that's not the problem, perhaps try the older memtest86 (withOUT the '+'),
since you said that's older hardware.. Some of the newer versions
routines/tests may conflict with something (?) But I see you're all set anyways
with the floppy I just wouldn't/can't *rely* on a floppy for maintaining
crucial data whatsoever.
I have NOT yet *chosen* memtest86+ from my GRUB menu, but it's there now, and I
will try to boot into it during next reboot ;-)
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
iforone
*nix forums Guru
Joined: 28 Dec 2005
Posts: 330
|
| Posted: Sat Jul 08, 2006 8:30 pm Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Andrew Sackville-West wrote:
| Quote: | On Fri, Jul 07, 2006 at 09:22:59PM -0700, Willie Wonka wrote:
ACPI hmm.. Let's see output of 'dmesg | grep ACPI'
andrew@basement:~$ dmesg | grep ACPI
BIOS-e820: 000000000dfec000 - 000000000dfef000 (ACPI data)
BIOS-e820: 000000000dfff000 - 000000000e000000 (ACPI NVS)
[snip] |
For comparison reasons only -- here's mine;
---------------
~$ dmesg | grep ACPI
BIOS-e820: 000000000bffdc00 - 000000000bfffc00 (ACPI data)
BIOS-e820: 000000000bfffc00 - 000000000c000000 (ACPI NVS)
ACPI disabled because your bios is from 2000 and too old
ACPI: Subsystem revision 20040326
ACPI: Interpreter disabled.
-----------------
Whoops!!
I forgot to add one VERY IMPORTANT point when running *update-grub*
Remember to Copy down ANY/ALL Kernel and Initrd CUSTOM Boot settings!!
They are within the AutoMagic area (usually) - and running 'update-grub' gives
grub the authority to alter any custom settings to defaults (I.e.; it'll wipe
out your custom options and replace them with the defaults).
Fortunately for me, I only had that one kernel option (acpi=force) that I can
recall and easily add back (using 'sudo nano /boot/grub/menu.lst' to edit and
save the file)
So;
I'll refrain from posting mine anyway (once I reboot after customizing menu.lst
again ) -- since you already have seemingly solved your issue ...
| Quote: | Do you use an 'acpi=force' kernel boot option in GRUB/Lilo ??
I do on this ~1999 PII, 350MHz 100FSB, 192MB RAM;
nope. there is some acpi setting in the BIOS that is turned on, can't
remember what it is exactly, will post in after next
reboot. meanwhile, I found I had apcid turned on from some acpi stuff
I was playing with a few months ago. I've update-rc.d remove'd it and
haven't had a problem in a day and a half (knock wood). I"m going to
go at this thing from the ground up again starting with all BIOS
settings and... heh... logging my actions, there's a novel thought.
|
Excellent!
Glad to hear it -- my system is one of the first ACPIU compliant, and there's
no BIOS setting for enabling/disabling ACPI, but there is the "Power" page,
which controls APM settings.
| Quote: | well. that's quite a tale. All I can say is, if the keyboard doesn't
seem to work right, maybe next time try a new keyboard first? he
he.
|
Yeah - but I'm stubborn as an Ox, and I needed to test my skills ;-0
Last resort (replace hardware) was such that if it didn't work, I'd be really
fuming -- perhaps that's why I held off for so long, and was trying to decipher
these type kernel messages;
-------------
Jul 3 08:17:04 localhost kernel: atkbd.c: Keyboard on isa0060/serio0 reports
too many keys pressed
..
Jul 3 08:17:39 localhost last message repeated 7 times
Jul 3 08:18:38 localhost last message repeated 12 times
Jul 3 08:19:37 localhost last message repeated 12 times
Jul 3 08:20:41 localhost last message repeated 13 times
Jul 3 08:21:41 localhost last message repeated 12 times
------------
ad-nauseum... :-(
| Quote: | on that note, i've heard several tales of keyboards being
resurrected by putting them through the dishwasher... I'd google it
first, but if you have a dead keyboard, it certainly wouldn't
hurt. I'm sure it'll void the warranty though.
|
Yeah, I know -- Thanks -- and that's definitely something I'd *do*
But she's already got too many bullet holes in her :-p
Besides the SpaceBar key had been semi-broken (physically) for quite sometime
already.
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Mumia W.
*nix forums Guru Wannabe
Joined: 08 May 2006
Posts: 153
|
| Posted: Sat Jul 08, 2006 9:40 pm Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Willie Wonka wrote:
| Quote: | [...]
Whoops!!
I forgot to add one VERY IMPORTANT point when running *update-grub*
Remember to Copy down ANY/ALL Kernel and Initrd CUSTOM Boot settings!!
[...]
|
That's not a bad idea, but it's not necessary either. From
/boot/grub/menu.lst:
## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specifiv kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
# kopt=root=/dev/hda1 ro
So you would possibly use this:
# kopt=root=/dev/hda1 ro acpi=force
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Andrew Sackville-West
*nix forums Guru
Joined: 22 Mar 2005
Posts: 606
|
| Posted: Sat Jul 08, 2006 10:30 pm Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
On Sat, Jul 08, 2006 at 12:48:44PM -0700, Willie Wonka wrote:
| Quote: |
I googled the memtest issue and found one good hit that said you have
to burn the img directly to a floppy. I've done that with dd and it
works like a charm, boots right into memtest. It must be some grub
related issue that prevents it from booting properly from within
grub. maybe grub is occupying the memory it tries to load
to. Regardless, I've run memtest for about 13 hours with no
errors. another culprit eliminated.
Oh... so you *can* and do have a choice for memtest86+ in the GRUB menu ?
And when you try to run it from there (using up/down arrows to select it) , it
Hangs? and gives you that "Out of memory" error you stated earlier ?
|
exactly. I also used the install script that comes in the package:
mame-memtest86+-boot-floppy which puts a grub and a copy of the .bin
file on a floppy... same problem.
| Quote: |
FWIW, when I recently installed memtest86*+*, I inadvertantly installed
_memtest86_ (no '+' -- the Older version)...so I first 'sudo apt-get remove
--purge memtest86' and only *then* did I install memtest86+, and then I ran
'sudo updatedb', and consequently, 'sudo update-grub' and that was it .
FWIW - No manual editing of /boot/grub/menu.lst was necessary.
Do you have the older "memtest86" installed too? (perhaps conflicts with '+'
version).
|
nope.
| Quote: |
If that's not the problem, perhaps try the older memtest86 (withOUT the '+'),
since you said that's older hardware.. Some of the newer versions
routines/tests may conflict with something (?) But I see you're all set anyways
with the floppy I just wouldn't/can't *rely* on a floppy for maintaining
crucial data whatsoever.
|
no no crucial data, just a quick setup for the memtest. subsequently I
got a copy of ultimate boot cd which includes a couple versions of
memtest along with way too much other dangerous stuff ;0
| Quote: |
I have NOT yet *chosen* memtest86+ from my GRUB menu, but it's there now, and I
will try to boot into it during next reboot
|
cool, I;m curious to see if others get the same results as I.
A |
|
| Back to top |
|
|
iforone
*nix forums Guru
Joined: 28 Dec 2005
Posts: 330
|
| Posted: Sun Jul 09, 2006 6:10 am Post subject:
Re: diagnosing hard-locks [was memtest+ won't load]
|
|
|
Andrew Sackville-West wrote:
| Quote: | On Sat, Jul 08, 2006 at 12:48:44PM -0700, Willie Wonka wrote:
I have NOT yet *chosen* memtest86+ from my GRUB menu, but it's there now,
and I
will try to boot into it during next reboot ;-)
cool, I;m curious to see if others get the same results as I.
|
Hi...
Yes -- it works perfectly
I rebooted into GRUB and chose the memtest86+ entry and it ran fine...
Here's my menu.lst entry for it -- (hd1,0) is my Linux drive - /dev/hdc, where
my kernels are as well....(/dev/hdb (PrimarySlave) is an optical CDRW)
---------------
[...]
title Debian GNU/Linux, kernel memtest86+
root (hd1,0)
kernel /boot/memtest86+.bin
boot
### END DEBIAN AUTOMAGIC KERNELS LIST
[...]
--------------
Again, I'm on an Intel 440BX PII (350MHz), 100FSB, 192MB RAM - circa 1999/2000
Using Debian Sarge 3.1r2 (IA32 arch);
~$ uname -a
Linux <host> 2.6.8-3-686 #1 Thu May 25 02:27:57 UTC 2006 i686 GNU/Linux
I'm in the process of upgrading completely (dist-upgrade) to "testing" ATM ;-)
p.s.
More; helpful hardware utilities perhaps that I use a lot (as well as 'lspci
-vv' as root)
'dmidecode'
'hwinfo'
Regards
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
john znuck
*nix forums beginner
Joined: 01 Jul 2006
Posts: 3
|
| Posted: Mon Jul 10, 2006 8:10 am Post subject:
re: list of problems
|
|
|
# prefork MPM
# StartServers ......... number of server
processes to start
# MinSpareServers ...... minimum number of server processes which are kept spare
# MaxSpareServers ...... maximum number of server processes which are kept spare
# MaxClients ........... maximum number of server processes allowed to start
# MaxRequestsPerChild .. maximum number of requests a server process serves
<IfModule prefork.c>
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 20
MaxRequestsPerChild 0
</IfModule>
Ron, on my problem No.2 the number of StartServers explains it, right?
As to problem 3, i have not double-clicked. this happens after i upgrade to pre8 fr pre7.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com |
|
| Back to top |
|
|
Ken Moffat
*nix forums beginner
Joined: 12 Jul 2006
Posts: 1
|
| Posted: Wed Jul 12, 2006 5:30 am Post subject:
Re: hostname for sqwebmail
|
|
|
Found this old post and wondered if there is an answer to setting the
hostname on outgoing posts for sqwebmail. My outgoing smtp mail uses
the local box hostname instead of the fully qualified domain name of the
server.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
max@hyre.net
*nix forums beginner
Joined: 18 Apr 2006
Posts: 4
|
| Posted: Wed Jul 12, 2006 5:20 pm Post subject:
Re: Winner
|
|
|
Does this apply to all of Debian? Or just debian-user subscribers.
| Quote: | Winners are advice to keep this award confidential
|
OK, I won't tell anyone. Don't any of you either!
| Quote: | The Luckyday Lotto Awards is proudly sponsored by the Microsoft
Corporation
|
Oops---maybe this is fishy after all...
:-)
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Greg Ryman
*nix forums beginner
Joined: 12 Jul 2006
Posts: 1
|
| Posted: Wed Jul 12, 2006 6:10 pm Post subject:
Re: Shutdown my Laptop? Why should I?
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I would say to do a reboot and possible a file system check once a month
to avoid corruption and unintended loss of data. Other then that, you
don't need to reboot.
David R. Litwin wrote:
| Quote: | I have a year old Toshiba Intel Mobil P4 laptop using Sid. I recently
downloaded two large files via BitTorrent. As I wanted to have them as
quickly as I could, I decided to leave my laptop on until they were fully
downloaded, rebooting only for
upgrades. I noticed no real difference in performance (maybe Azureus
was hogging a bit more memory after a few days).
The question is this: Why should I ever turn off my laptop on a normal
occasion (normal being every-day, standard, stationary usage)? If I don't
want it on, I can suspend it in some way: Waking-up is faster than
booting-up.
I'm keen to hear your opinions, O members.
Cheers.
|
- --
Greg Ryman
Network Engineering Supervisor
Candylogic, LLC.
gregr@candylogic.com
949-916-4444 x.203
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
iD8DBQFEtTUw3nq9k6G+PM0RAtGcAKCcj6QEeC3ABwiE08eQ7mHCGcSOVwCfeuQK
dZIudS1u9C2Bxqiv1qi2OYQ=
=FVb+
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Digby Tarvin
*nix forums Guru Wannabe
Joined: 25 Jan 2006
Posts: 178
|
| Posted: Wed Jul 12, 2006 7:00 pm Post subject:
Re: Shutdown my Laptop? Why should I?
|
|
|
On Wed, Jul 12, 2006 at 10:45:20AM -0700, Greg Ryman wrote:
| Quote: | I would say to do a reboot and possible a file system check once a month
to avoid corruption and unintended loss of data. Other then that, you
don't need to reboot.
|
I would also suggest a reboot any time you use apt to do an upgrade,
or otherwise change or reconfigure your system. It is much easier to
solve a booting problem if you can remember what has changed since it
was last working...
It is the same logic as for servers which run 24/7.
Regards,
DigbyT
--
Digby R. S. Tarvin digbyt(at)digbyt.com
http://www.digbyt.com
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
| |
Page 355 of 359 [5372 Posts]
|
Goto page:
Previous
1,
2,
3,
...,
353,
354,
355,
356,
357,
358,
359
Next
View previous topic :: View next topic
|
|
The time now is Tue Jan 06, 2009 10:42 am | All times are GMT
|
|
Loans | Debt Consolidation | Computer Repair | Free Advertising | Movie stars
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
Distributions
»
Debian
