[gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Joseph]

I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
AV8,
I have two problems:

1.) Kernel panic - not syncing: Aiee, killing interupt handler.
It appear during every few hours during compiling, I've seen other folks
having the same problem but no solution.

2,) I'm constantly getting the error when I try to emerge kde 
kde-base/kdebase-3.4.1-r1 failed 
Function kde_compile, line 164, 

I've tried re-emerge qt, it did not help 
my make.conf: 
CFLAGS="-march=k8 -O2" 
CHOST="x86_64-pc-linux-gnu" 
CXXFLAGS="${CFLAGS}" 
MAKEOPTS="-j2"

I've tried new kde-split, same error.
Somebody pointed out that it has something do to with gcc-3.4.3-r1 but
this is the only stable version available on AMD64.

So, I have this new box - good for nothing, well it might run
Windows :-( 

#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Patrick Rutkowski]

On Wednesday 20 July 2005 22:08, Joseph wrote:
> I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
> AV8,
> I have two problems:
>
> 1.) Kernel panic - not syncing: Aiee, killing interupt handler.
> It appear during every few hours during compiling, I've seen other folks
> having the same problem but no solution.
>
> 2,) I'm constantly getting the error when I try to emerge kde
> kde-base/kdebase-3.4.1-r1 failed
> Function kde_compile, line 164,
>
> I've tried re-emerge qt, it did not help
> my make.conf:
> CFLAGS="-march=k8 -O2"
> CHOST="x86_64-pc-linux-gnu"
> CXXFLAGS="${CFLAGS}"
> MAKEOPTS="-j2"
>
> I've tried new kde-split, same error.
> Somebody pointed out that it has something do to with gcc-3.4.3-r1 but
> this is the only stable version available on AMD64.
>
> So, I have this new box - good for nothing, well it might run
> Windows :-(
>
> #Joseph

So try the unstable gcc :-D

In all seriousness, this seams like an issue destined for a more specific 
mailing list; try to contact others who have this issue and you can work it 
out together.

It's very puzzling, good luck (hopefully someone on this gentoo list can help 
too).
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Joseph]

On Wed, 2005-07-20 at 22:23 -0400, Patrick Rutkowski wrote:
> On Wednesday 20 July 2005 22:08, Joseph wrote:
> > I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
> > AV8,
> > I have two problems:
> >
> > 1.) Kernel panic - not syncing: Aiee, killing interupt handler.
> > It appear during every few hours during compiling, I've seen other folks
> > having the same problem but no solution.
> >
> > 2,) I'm constantly getting the error when I try to emerge kde
> > kde-base/kdebase-3.4.1-r1 failed
> > Function kde_compile, line 164,
> >
> > I've tried re-emerge qt, it did not help
> > my make.conf:
> > CFLAGS="-march=k8 -O2"
> > CHOST="x86_64-pc-linux-gnu"
> > CXXFLAGS="${CFLAGS}"
> > MAKEOPTS="-j2"
> >
> > I've tried new kde-split, same error.
> > Somebody pointed out that it has something do to with gcc-3.4.3-r1 but
> > this is the only stable version available on AMD64.
> >
> > So, I have this new box - good for nothing, well it might run
> > Windows :-(
> >
> > #Joseph
> 
> So try the unstable gcc :-D
> 
> In all seriousness, this seams like an issue destined for a more specific 
> mailing list; try to contact others who have this issue and you can work it 
> out together.
> 
> It's very puzzling, good luck (hopefully someone on this gentoo list can help 
> too).

Eventually, I'll try to go back to gcc-3.3-something and maybe I'll be
able to compile KDE.
With kernel panic I just have to live with it, maybe someday they will
solve it.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Zac Medico]

Joseph wrote:
> I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
> AV8,
> I have two problems:
> 
> 1.) Kernel panic - not syncing: Aiee, killing interupt handler.
> It appear during every few hours during compiling, I've seen other folks
> having the same problem but no solution.
> 
> 2,) I'm constantly getting the error when I try to emerge kde 
> kde-base/kdebase-3.4.1-r1 failed 
> Function kde_compile, line 164, 
> 
> I've tried re-emerge qt, it did not help 
> my make.conf: 
> CFLAGS="-march=k8 -O2" 
> CHOST="x86_64-pc-linux-gnu" 
> CXXFLAGS="${CFLAGS}" 
> MAKEOPTS="-j2"
> 
> I've tried new kde-split, same error.
> Somebody pointed out that it has something do to with gcc-3.4.3-r1 but
> this is the only stable version available on AMD64.
> 
> So, I have this new box - good for nothing, well it might run
> Windows :-( 
> 
> #Joseph

Well, it's got something to do with the kernel ;-).  What kernel version is it?  If it's not 2.6.12, I'd try that, first thing.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Joseph]

On Wed, 2005-07-20 at 19:57 -0700, Zac Medico wrote:
> Joseph wrote:
> > I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
> > AV8,
> > I have two problems:
> > 
> > 1.) Kernel panic - not syncing: Aiee, killing interupt handler.
> > It appear during every few hours during compiling, I've seen other folks
> > having the same problem but no solution.
> > 
> > 2,) I'm constantly getting the error when I try to emerge kde 
> > kde-base/kdebase-3.4.1-r1 failed 
> > Function kde_compile, line 164, 
> > 
> > I've tried re-emerge qt, it did not help 
> > my make.conf: 
> > CFLAGS="-march=k8 -O2" 
> > CHOST="x86_64-pc-linux-gnu" 
> > CXXFLAGS="${CFLAGS}" 
> > MAKEOPTS="-j2"
> > 
> > I've tried new kde-split, same error.
> > Somebody pointed out that it has something do to with gcc-3.4.3-r1 but
> > this is the only stable version available on AMD64.
> > 
> > So, I have this new box - good for nothing, well it might run
> > Windows :-( 
> > 
> > #Joseph
> 
> Well, it's got something to do with the kernel ;-).  What kernel version is it?  If it's not 2.6.12, I'd try that, first thing.
> 
> Zac

I'm on gentoo-sources 2.6.12-gentoo-r6 it makes no difference.  
So I either get a kernel panic or kdebase-3.4.1-r1 fails.

I think kdebase-3.4.1 should be masked as unstable.  
I was googling and noticed that a lot of people have similar problem,
but no solution.  

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Zac Medico]

Joseph wrote:
> On Wed, 2005-07-20 at 19:57 -0700, Zac Medico wrote:
> 
>>Joseph wrote:
>>
>>>I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
>>>AV8,
>>>I have two problems:
>>>
>>>1.) Kernel panic - not syncing: Aiee, killing interupt handler.
>>>It appear during every few hours during compiling, I've seen other folks
>>>having the same problem but no solution.
>>>
>>>2,) I'm constantly getting the error when I try to emerge kde 
>>>kde-base/kdebase-3.4.1-r1 failed 
>>>Function kde_compile, line 164, 
>>>
>>>I've tried re-emerge qt, it did not help 
>>>my make.conf: 
>>>CFLAGS="-march=k8 -O2" 
>>>CHOST="x86_64-pc-linux-gnu" 
>>>CXXFLAGS="${CFLAGS}" 
>>>MAKEOPTS="-j2"
>>>
>>>I've tried new kde-split, same error.
>>>Somebody pointed out that it has something do to with gcc-3.4.3-r1 but
>>>this is the only stable version available on AMD64.
>>>
>>>So, I have this new box - good for nothing, well it might run
>>>Windows :-( 
>>>
>>>#Joseph
>>
>>Well, it's got something to do with the kernel ;-).  What kernel version is it?  If it's not 2.6.12, I'd try that, first thing.
>>
>>Zac
> 
> 
> I'm on gentoo-sources 2.6.12-gentoo-r6 it makes no difference.  
> So I either get a kernel panic or kdebase-3.4.1-r1 fails.
> 
> I think kdebase-3.4.1 should be masked as unstable.  
> I was googling and noticed that a lot of people have similar problem,
> but no solution.  
> 

Mask kde because building it triggers a kernel bug?  I think not.  It's probably related to your hardware and/or kernel config.  Is it happening with split ebuilds too?  Is there anything interesting in the output of dmesg or /var/log/messages leading up to this?

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Joseph]

[snip]
> > I'm on gentoo-sources 2.6.12-gentoo-r6 it makes no difference.  
> > So I either get a kernel panic or kdebase-3.4.1-r1 fails.
> > 
> > I think kdebase-3.4.1 should be masked as unstable.  
> > I was googling and noticed that a lot of people have similar problem,
> > but no solution.  
> > 
> 
> Mask kde because building it triggers a kernel bug?  I think not.
> It's probably related to your hardware and/or kernel config.  Is it
> happening with split ebuilds too?  Is there anything interesting in
> the output of dmesg or /var/log/messages leading up to this?
> 
> Zac

I wasn't thinking about masking KDE but gcc-3.4.1 on AMD64 platform and
make stable 3.3 version.  I run onto one posting claiming that there is
some kind of bug in gcc-3.4.1 (and this version is the only stable
version on AMD64.

If I knew I'm going to have so much problem with AMD64, I would have
gone with x86.
So WARNING to everybody: A8V + Sata Drive + AMD64 3000 = DISASTER (for
now).

I have two other boxes running Gentoo on x86 and they are rock solid.
If any kind of problem pops-up I can solve it withing an hour or faster.
But these two problem on AMD64 turned this machine to a piece of junk
(suitable only for Windows).

Split KDE-ebuild is effected as well.
I couldn't find anything in dmesg, what might be causing it.  If it was
a kernel configuration I would imaging somebody would discover it, but
there are only suggestion that don't work.  It most likely some bug in
some kind of kernel driver pertaining to Sata Drive or AMD64

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Zac Medico]

Joseph wrote:
> [snip]
> 
>>>I'm on gentoo-sources 2.6.12-gentoo-r6 it makes no difference.  
>>>So I either get a kernel panic or kdebase-3.4.1-r1 fails.
>>>
>>>I think kdebase-3.4.1 should be masked as unstable.  
>>>I was googling and noticed that a lot of people have similar problem,
>>>but no solution.  
>>>
>>
>>Mask kde because building it triggers a kernel bug?  I think not.
>>It's probably related to your hardware and/or kernel config.  Is it
>>happening with split ebuilds too?  Is there anything interesting in
>>the output of dmesg or /var/log/messages leading up to this?
>>
>>Zac
> 
> 
> I wasn't thinking about masking KDE but gcc-3.4.1 on AMD64 platform and
> make stable 3.3 version.  I run onto one posting claiming that there is
> some kind of bug in gcc-3.4.1 (and this version is the only stable
> version on AMD64.
> 
> If I knew I'm going to have so much problem with AMD64, I would have
> gone with x86.
> So WARNING to everybody: A8V + Sata Drive + AMD64 3000 = DISASTER (for
> now).
> 
> I have two other boxes running Gentoo on x86 and they are rock solid.
> If any kind of problem pops-up I can solve it withing an hour or faster.
> But these two problem on AMD64 turned this machine to a piece of junk
> (suitable only for Windows).
> 
> Split KDE-ebuild is effected as well.
> I couldn't find anything in dmesg, what might be causing it.  If it was
> a kernel configuration I would imaging somebody would discover it, but
> there are only suggestion that don't work.  It most likely some bug in
> some kind of kernel driver pertaining to Sata Drive or AMD64
> 

Maybe you should try gcc-3.4.4?  You could go with a 32-bit userland until the problem is resolved.  You can do that with a 64-bit kernel if you have IA32 emulation enabled (hopefully you won't encounter the same bug).

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Joseph]

[snip]
> > 
> > I wasn't thinking about masking KDE but gcc-3.4.1 on AMD64 platform and
> > make stable 3.3 version.  I run onto one posting claiming that there is
> > some kind of bug in gcc-3.4.1 (and this version is the only stable
> > version on AMD64.
> > 
> > If I knew I'm going to have so much problem with AMD64, I would have
> > gone with x86.
> > So WARNING to everybody: A8V + Sata Drive + AMD64 3000 = DISASTER (for
> > now).
> > 
> > I have two other boxes running Gentoo on x86 and they are rock solid.
> > If any kind of problem pops-up I can solve it withing an hour or faster.
> > But these two problem on AMD64 turned this machine to a piece of junk
> > (suitable only for Windows).
> > 
> > Split KDE-ebuild is effected as well.
> > I couldn't find anything in dmesg, what might be causing it.  If it was
> > a kernel configuration I would imaging somebody would discover it, but
> > there are only suggestion that don't work.  It most likely some bug in
> > some kind of kernel driver pertaining to Sata Drive or AMD64
> > 
> 
> Maybe you should try gcc-3.4.4?  You could go with a 32-bit userland
> until the problem is resolved.  You can do that with a 64-bit kernel
> if you have IA32 emulation enabled (hopefully you won't encounter the
> same bug).
> 
> Zac

Thank you, that is a good suggestion.
I'll be running memtest86 all night, just to be sure.
And tomorrow I'll try gcc-3.4.4 it this will not help I'll try IA32
emulation.  Though, I'll have to find some more info in this, how to do
it.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Zac Medico]

Joseph wrote:
> [snip]
> 
>>>I wasn't thinking about masking KDE but gcc-3.4.1 on AMD64 platform and
>>>make stable 3.3 version.  I run onto one posting claiming that there is
>>>some kind of bug in gcc-3.4.1 (and this version is the only stable
>>>version on AMD64.
>>>
>>>If I knew I'm going to have so much problem with AMD64, I would have
>>>gone with x86.
>>>So WARNING to everybody: A8V + Sata Drive + AMD64 3000 = DISASTER (for
>>>now).
>>>
>>>I have two other boxes running Gentoo on x86 and they are rock solid.
>>>If any kind of problem pops-up I can solve it withing an hour or faster.
>>>But these two problem on AMD64 turned this machine to a piece of junk
>>>(suitable only for Windows).
>>>
>>>Split KDE-ebuild is effected as well.
>>>I couldn't find anything in dmesg, what might be causing it.  If it was
>>>a kernel configuration I would imaging somebody would discover it, but
>>>there are only suggestion that don't work.  It most likely some bug in
>>>some kind of kernel driver pertaining to Sata Drive or AMD64
>>>
>>
>>Maybe you should try gcc-3.4.4?  You could go with a 32-bit userland
>>until the problem is resolved.  You can do that with a 64-bit kernel
>>if you have IA32 emulation enabled (hopefully you won't encounter the
>>same bug).
>>
>>Zac
> 
> 
> Thank you, that is a good suggestion.
> I'll be running memtest86 all night, just to be sure.
> And tomorrow I'll try gcc-3.4.4 it this will not help I'll try IA32
> emulation.  Though, I'll have to find some more info in this, how to do
> it.
> 

It's easy, just enable it in your kernel config.  You can use 32-bit module-init-tools to modprobe 64-bit modules.  You need a 64-bit environment to build 64-bit stuff but you can chroot into a stage3 for that.  Read the amd64 technotes part about 32-bit compatibility: http://www.gentoo.org/proj/en/base/amd64/technotes/index.xml?part=1&chap=4

BTW, gcc-3.4.1 is no longer stable on amd64 but gcc-3.4.3-r1 is: http://packages.gentoo.org/packages/?category=sys-devel;name=gcc

Zac


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Wed, 2005-07-20 at 22:02 -0700, Zac Medico wrote:
[snip]
> > Thank you, that is a good suggestion.
> > I'll be running memtest86 all night, just to be sure.
> > And tomorrow I'll try gcc-3.4.4 it this will not help I'll try IA32
> > emulation.  Though, I'll have to find some more info in this, how to do
> > it.
> > 
> 
> It's easy, just enable it in your kernel config.  You can use 32-bit module-init-tools to modprobe 64-bit modules.  You need a 64-bit environment to build 64-bit stuff but you can chroot into a stage3 for that.  Read the amd64 technotes part about 32-bit compatibility: http://www.gentoo.org/proj/en/base/amd64/technotes/index.xml?part=1&chap=4
> 
> BTW, gcc-3.4.1 is no longer stable on amd64 but gcc-3.4.3-r1 is: http://packages.gentoo.org/packages/?category=sys-devel;name=gcc
> 
> Zac
> 

I think they solved the problem with gcc-3.4.3-r1
The only problem is left is the Kernel Panic:
Kernel panic - not syncing: Aiee, killing interupt handler.

Every few packages it emerges it the machine hangs up on kernel panic.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> 
> I think they solved the problem with gcc-3.4.3-r1
> The only problem is left is the Kernel Panic:
> Kernel panic - not syncing: Aiee, killing interupt handler.
> 
> Every few packages it emerges it the machine hangs up on kernel panic.
> 

So, 1) and 2) from your original email are completely separate issues?  If so, I was confused and thought they were related somehow.

You've definitely got a kernel bug there.  Have you searched to see if anyone else has experienced this problem?  Like Patrick said in the first reply, you might need to pursue this one upstream with the kernel developers.

Zac
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Thu, 2005-07-21 at 11:47 -0700, Zac Medico wrote:
> Joseph wrote:
> > 
> > I think they solved the problem with gcc-3.4.3-r1
> > The only problem is left is the Kernel Panic:
> > Kernel panic - not syncing: Aiee, killing interupt handler.
> > 
> > Every few packages it emerges it the machine hangs up on kernel panic.
> > 
> 
> So, 1) and 2) from your original email are completely separate issues?  If so, I was confused and thought they were related somehow.
> 
> You've definitely got a kernel bug there.  Have you searched to see if anyone else has experienced this problem?  Like Patrick said in the first reply, you might need to pursue this one upstream with the kernel developers.
> 
> Zac

Both bugs are back. 
I've tried to emerge kde-meta (split kde ebuild) and it hang up on:
ERROR: kde-base/kdepim-kresources-3.4.1 filed.

Few lines above it starts with:
Code: 48 89 4a 08 ...
RIP <fffff...> {buffered_rmqueue+262} RSP <ffff...>
CR2: ffff...
libtool: link: '/usr/kde/3.4/lib64/libDCOP.la' is not a valid libtool
archive 
make[4]: *** [kabc_kolab.la] Error 1

This is a new install so I can not retype all the errors by hand.
Anyhow, I think I have enough compiling on AMD64,  I've been trying to
install something since last Friday and still not getting anywhere, so
after almost one week of compiling it didn't achieve anything. 

I'll try to install Ubuntu on this box and see what happens.
Thanks everybody for your help.

#Joseph


-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> 
> Both bugs are back. 
> I've tried to emerge kde-meta (split kde ebuild) and it hang up on:
> ERROR: kde-base/kdepim-kresources-3.4.1 filed.
> 
> Few lines above it starts with:
> Code: 48 89 4a 08 ...
> RIP <fffff...> {buffered_rmqueue+262} RSP <ffff...>
> CR2: ffff...
> libtool: link: '/usr/kde/3.4/lib64/libDCOP.la' is not a valid libtool
> archive 
> make[4]: *** [kabc_kolab.la] Error 1
> 
> This is a new install so I can not retype all the errors by hand.
> Anyhow, I think I have enough compiling on AMD64,  I've been trying to
> install something since last Friday and still not getting anywhere, so
> after almost one week of compiling it didn't achieve anything. 
> 
> I'll try to install Ubuntu on this box and see what happens.
> Thanks everybody for your help.
> 
> #Joseph
> 
> 

Maybe you just need to run fix_libtool_files.sh, which is normal after a compiler upgrade.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

[snip]
> 
> Maybe you just need to run fix_libtool_files.sh, which is normal after a compiler upgrade.
> 
> Zac

I don't know if that helped but it deeps running for over 20min. so
hopefully maybe I'll be done by Sunday.  If not I will have to take a
drastic measure and move to another dystro; which I don't like but don't
have very many options.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> [snip]
> 
>>Maybe you just need to run fix_libtool_files.sh, which is normal after a compiler upgrade.
>>
>>Zac
> 
> 
> I don't know if that helped but it deeps running for over 20min. so
> hopefully maybe I'll be done by Sunday.  If not I will have to take a
> drastic measure and move to another dystro; which I don't like but don't
> have very many options.
> 

It shouldn't take too long, 20 minutes seems excessive.  Does it seem like it's doing anything?  If not do ctrl-c to kill it, then maybe run it again.  Also, use a process manager (ps will do it) to find out what program it's hung up in.

I like Portage so much that I'd rather use all GRP packages than go back to an rpm based distro.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Thu, 2005-07-21 at 15:31 -0700, Zac Medico wrote:
> Joseph wrote:
> > [snip]
> > 
> >>Maybe you just need to run fix_libtool_files.sh, which is normal after a compiler upgrade.
> >>
> >>Zac
> > 
> > 
> > I don't know if that helped but it deeps running for over 20min. so
> > hopefully maybe I'll be done by Sunday.  If not I will have to take a
> > drastic measure and move to another dystro; which I don't like but don't
> > have very many options.
> > 
> 
> It shouldn't take too long, 20 minutes seems excessive.  Does it seem like it's doing anything?  If not do ctrl-c to kill it, then maybe run it again.  Also, use a process manager (ps will do it) to find out what program it's hung up in.
> 
> I like Portage so much that I'd rather use all GRP packages than go back to an rpm based distro.
> 
> Zac

I wasn't clear, the computer runs usually for 20 to 30minus and kernel
panic comes up on the screen.  I'm still googling for some solutions and
I can only find some suggestion; no clear answer.

I think I went too fast for AMD64; I should have stayed with x86 and old
good IDE drive.
Somebody suggested: "Enabling 32 bit mode for the drives in the BIOS to
cure this problem."  I'll check my Bios the next time it will crash :-/

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> 
> I wasn't clear, the computer runs usually for 20 to 30minus and kernel
> panic comes up on the screen.  I'm still googling for some solutions and
> I can only find some suggestion; no clear answer.
> 
> I think I went too fast for AMD64; I should have stayed with x86 and old
> good IDE drive.
> Somebody suggested: "Enabling 32 bit mode for the drives in the BIOS to
> cure this problem."  I'll check my Bios the next time it will crash :-/
> 

If the only problem is the sata controller then you can try interfacing your hard drive some other way until the sata driver situation clears up.

I actually boot my system off of a 3.5" hard drive that's in an external usb 2.0 enclosure.  That way I can plug into practically any computer and have my complete gentoo system!  I've even though about buying USB 2.0/IDE bridges for internal use (rather than for an external enclosure) because they are inexpensive and allow for hot swapping.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Thu, 2005-07-21 at 17:09 -0700, Zac Medico wrote:
> Joseph wrote:
> > 
> > I wasn't clear, the computer runs usually for 20 to 30minus and kernel
> > panic comes up on the screen.  I'm still googling for some solutions and
> > I can only find some suggestion; no clear answer.
> > 
> > I think I went too fast for AMD64; I should have stayed with x86 and old
> > good IDE drive.
> > Somebody suggested: "Enabling 32 bit mode for the drives in the BIOS to
> > cure this problem."  I'll check my Bios the next time it will crash :-/
> > 
> 
> If the only problem is the sata controller then you can try
> interfacing your hard drive some other way until the sata driver
> situation clears up.
> 
> I actually boot my system off of a 3.5" hard drive that's in an
> external usb 2.0 enclosure.  That way I can plug into practically any
> computer and have my complete gentoo system!  I've even though about
> buying USB 2.0/IDE bridges for internal use (rather than for an
> external enclosure) because they are inexpensive and allow for hot
> swapping.

I was browsing the net and I've noticed that a lot of people are getting
similar error and a lot of them mentioned SCSI drive.  I happened with
back to kernel 2.4 and 1999 year so it could be related to SCSI driver,
not sure about it.

I've taken the cover off to allow more air into the box (most of my
other boxes run without any covers).  If I still get that error:
Kernel panic - not syncing: Aiee, killing interupt handler.

I'll buy an IDE drive and put this SATA drive on a shelve, and see if
will make a difference.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Bob Sanders]

On Thu, 21 Jul 2005 16:50:49 -0600
Joseph <syscon@interbaun.com> wrote:


> 
> I wasn't clear, the computer runs usually for 20 to 30minus and kernel
> panic comes up on the screen.  I'm still googling for some solutions and
> I can only find some suggestion; no clear answer.
> i

I think you have hardware problems - maybe a heat issue.  have you tried running
with the covers off and a fan blowing onto the system?

> I think I went too fast for AMD64; I should have stayed with x86 and old
> good IDE drive.
> Somebody suggested: "Enabling 32 bit mode for the drives in the BIOS to
> cure this problem."  I'll check my Bios the next time it will crash :-/
>i

Yes, 32-bit should be enabled, but I can't see where it would cause this problem.

fwiw - this is being sent from an AMD64 3000, nforce3 chipset, Shuttle box, IDE drive,
running Gentoo - 

 # uname -av
Linux chi 2.6.12-gentoo-r4 #1 Mon Jul 11 19:02:55 PDT 2005 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

[ I] kde-base/kdebase (3.4.1-r1):  KDE base packages: the desktop, panel, window
[ I] sys-devel/gcc (3.4.3-r1):  The GNU Compiler Collection. Includes C/C++, 

Bob
-  
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

[snip]
> 
> I think you have hardware problems - maybe a heat issue.  have you tried running
> with the covers off and a fan blowing onto the system?

I've checked: CPU temp. was 40C and MB temp was 29C
Though, I've taken the cover off and run it for a while without cover.

> 
> > I think I went too fast for AMD64; I should have stayed with x86 and old
> > good IDE drive.
> > Somebody suggested: "Enabling 32 bit mode for the drives in the BIOS to
> > cure this problem."  I'll check my Bios the next time it will crash :-/
> >i
> 
> Yes, 32-bit should be enabled, but I can't see where it would cause this problem.

I couldn't find the 32-bit mode feature in BIOS setting.
Under what menu is it?

Previously as was able to compile only few packages running for 20min
before crashing.
Now, I was able to keep compiling for about 2-hours before kernel panic
showed up.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Bob Sanders]

On Thu, 21 Jul 2005 18:46:42 -0600
Joseph <syscon@interbaun.com> wrote:


> I couldn't find the 32-bit mode feature in BIOS setting.
> Under what menu is it?
> 

Usually associated with the IDE controller or drives.  Most newer bios' have it
set to - AUTO, which should switch it into 32-bit, aka LBA mode.  Probably
under - Integrated Peripherals.

It may also say something like - IDE Primary MASTER UDMA  Auto.

> Previously as was able to compile only few packages running for 20min
> before crashing.
> Now, I was able to keep compiling for about 2-hours before kernel panic
> showed up.
>

>From what you've said, I think it might be useful to remove the cpu heatsink
and check the state of the thermal material.  Look to see if the cpu is in full
contact with it.  The downside to doing this is the thermal material is single use
only.  You'll need some alcohol to remove the material, after inspecting, then
some decent Thermal compound to replace it.

While it's been shown not to make a lot of difference in the short run, I tend
to prefer the Artic Silver products because they are stable over time.  The normal
white grease drys out as do some others.  The single use thermal pads are fine
and generally work well.

Bob 
-  

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Bob Sanders wrote:
> On Thu, 21 Jul 2005 16:50:49 -0600
> Joseph <syscon@interbaun.com> wrote:
> 
> 
> 
>>I wasn't clear, the computer runs usually for 20 to 30minus and kernel
>>panic comes up on the screen.  I'm still googling for some solutions and
>>I can only find some suggestion; no clear answer.
>>i
> 
> 
> I think you have hardware problems - maybe a heat issue.  have you tried running
> with the covers off and a fan blowing onto the system?
> 
> 

Good thinking Bob! That 20 to 30 minutes certainly seems symptomatic of overheating.

I've been confused throughout this whole thread thinking that the kernel panic and kde compile were somehow related.  I know, sounds crazy, but that's how I interpreted Joseph's explanation of the situation.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Thu, 2005-07-21 at 19:05 -0700, Zac Medico wrote:
> Bob Sanders wrote:
> > On Thu, 21 Jul 2005 16:50:49 -0600
> > Joseph <syscon@interbaun.com> wrote:
> > 
> > 
> > 
> >>I wasn't clear, the computer runs usually for 20 to 30minus and kernel
> >>panic comes up on the screen.  I'm still googling for some solutions and
> >>I can only find some suggestion; no clear answer.
> >>i
> > 
> > 
> > I think you have hardware problems - maybe a heat issue.  have you tried running
> > with the covers off and a fan blowing onto the system?
> > 
> > 
> 
> Good thinking Bob! That 20 to 30 minutes certainly seems symptomatic of overheating.
> 
> I've been confused throughout this whole thread thinking that the kernel panic and kde compile were somehow related.  I know, sounds crazy, but that's how I interpreted Joseph's explanation of the situation.
> 
> Zac

The latest news.
After taking the cover off; the temp. of the CPU went down by 3C  to 37C
and Motherboard down by 3C as well to 26C. but that still didn't prevent
the the kernel panic message:
Kernel panic - not syncing: Aiee, killing interupt handler.

So my next solution is to get another Drive but an IDE type and put the
SATA one on the shelf, and reinstall Gentoo.  

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Jamie Dobbs]

> The latest news.
> After taking the cover off; the temp. of the CPU went down by 3C  to 37C
> and Motherboard down by 3C as well to 26C. but that still didn't prevent
> the the kernel panic message:
> Kernel panic - not syncing: Aiee, killing interupt handler.
>
> So my next solution is to get another Drive but an IDE type and put the
> SATA one on the shelf, and reinstall Gentoo.

If you haven't done so already I'd recommend a thorough memory check
before you do anything else, I have seen (albiet on rare occassions)
faulty RAM causing these sorts of issues.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 14:46 +1200, Jamie Dobbs wrote:
> > The latest news.
> > After taking the cover off; the temp. of the CPU went down by 3C  to 37C
> > and Motherboard down by 3C as well to 26C. but that still didn't prevent
> > the the kernel panic message:
> > Kernel panic - not syncing: Aiee, killing interupt handler.
> >
> > So my next solution is to get another Drive but an IDE type and put the
> > SATA one on the shelf, and reinstall Gentoo.
> 
> If you haven't done so already I'd recommend a thorough memory check
> before you do anything else, I have seen (albiet on rare occassions)
> faulty RAM causing these sorts of issues.
> 

I've run memtest86 last night 17-passes, not a single error.
So it is not the memory.  It could be the Sata Via driver in the Kernel.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

[snip]
> 
> The latest news.
> After taking the cover off; the temp. of the CPU went down by 3C  to 37C
> and Motherboard down by 3C as well to 26C. but that still didn't prevent
> the the kernel panic message:
> Kernel panic - not syncing: Aiee, killing interupt handler.
> 
> So my next solution is to get another Drive but an IDE type and put the
> SATA one on the shelf, and reinstall Gentoo.  

Another theory I have is that it could be related to IRQ timing /
sharing of the Serial SATA with PCI slot 3 on the A8V motherboard.  
They are sharing the same IRQ base on the information from the Manual,
though the manual is not saying which IRQ is it.
How can I find out?
Maybe I can disable or select option RESERVER for that IRQ from Bios.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> [snip]
> 
>>The latest news.
>>After taking the cover off; the temp. of the CPU went down by 3C  to 37C
>>and Motherboard down by 3C as well to 26C. but that still didn't prevent
>>the the kernel panic message:
>>Kernel panic - not syncing: Aiee, killing interupt handler.
>>
>>So my next solution is to get another Drive but an IDE type and put the
>>SATA one on the shelf, and reinstall Gentoo.  
> 
> 
> Another theory I have is that it could be related to IRQ timing /
> sharing of the Serial SATA with PCI slot 3 on the A8V motherboard.  
> They are sharing the same IRQ base on the information from the Manual,
> though the manual is not saying which IRQ is it.
> How can I find out?
> Maybe I can disable or select option RESERVER for that IRQ from Bios.
> 

It looks like you can do "lspci -vv" to get the IRQ.  At least an IRQ problem would be consistent with the "killing interrupt handler" message you got.  BTW, you get a full oops message out of this?  That might be useful for debugging.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Thu, 2005-07-21 at 22:09 -0700, Zac Medico wrote:
> Joseph wrote:
> > [snip]
> > 
> >>The latest news.
> >>After taking the cover off; the temp. of the CPU went down by 3C  to 37C
> >>and Motherboard down by 3C as well to 26C. but that still didn't prevent
> >>the the kernel panic message:
> >>Kernel panic - not syncing: Aiee, killing interupt handler.
> >>
> >>So my next solution is to get another Drive but an IDE type and put the
> >>SATA one on the shelf, and reinstall Gentoo.  
> > 
> > 
> > Another theory I have is that it could be related to IRQ timing /
> > sharing of the Serial SATA with PCI slot 3 on the A8V motherboard.  
> > They are sharing the same IRQ base on the information from the Manual,
> > though the manual is not saying which IRQ is it.
> > How can I find out?
> > Maybe I can disable or select option RESERVER for that IRQ from Bios.
> > 
> 
> It looks like you can do "lspci -vv" to get the IRQ.  At least an IRQ problem would be consistent with the "killing interrupt handler" message you got.  BTW, you get a full oops message out of this?  That might be useful for debugging.
> 
> Zac

Finally I was able to emerge KDE, it really took a lot of time.
Though, looking at the motherboard's ASUS A8V IRQ setting:
They put a lot of devices on IRQ5:

skge - network controller
libata - I think this is sata ATA controller
ethci_Hcd:usb2, usb2
VIA8237 - sound ship

No wonder I'm having problem (and some others) with Sata Drive, if it is
sharing an IRQ with so many devices.  In comparison IDE controller have
all their own IRQ's  Primary IRQ 14 and Secondary IRQ 15

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
>>>
>>>Another theory I have is that it could be related to IRQ timing /
>>>sharing of the Serial SATA with PCI slot 3 on the A8V motherboard.  
>>>They are sharing the same IRQ base on the information from the Manual,
>>>though the manual is not saying which IRQ is it.
>>>How can I find out?
>>>Maybe I can disable or select option RESERVER for that IRQ from Bios.
>>>
>>
>>It looks like you can do "lspci -vv" to get the IRQ.  At least an IRQ problem would be consistent with the "killing interrupt handler" message you got.  BTW, you get a full oops message out of this?  That might be useful for debugging.
>>
>>Zac
> 
> 
> Finally I was able to emerge KDE, it really took a lot of time.
> Though, looking at the motherboard's ASUS A8V IRQ setting:
> They put a lot of devices on IRQ5:
> 
> skge - network controller
> libata - I think this is sata ATA controller
> ethci_Hcd:usb2, usb2
> VIA8237 - sound ship
> 
> No wonder I'm having problem (and some others) with Sata Drive, if it is
> sharing an IRQ with so many devices.  In comparison IDE controller have
> all their own IRQ's  Primary IRQ 14 and Secondary IRQ 15
> 

Great! So, did you physically remove the sata drive?  The sata drivers are still enabled though?  The ouput from dmesg should give you an idea what drivers the kernel is actively using.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

> > Finally I was able to emerge KDE, it really took a lot of time.
> > Though, looking at the motherboard's ASUS A8V IRQ setting:
> > They put a lot of devices on IRQ5:
> > 
> > skge - network controller
> > libata - I think this is sata ATA controller
> > ethci_Hcd:usb2, usb2
> > VIA8237 - sound ship
> > 
> > No wonder I'm having problem (and some others) with Sata Drive, if it is
> > sharing an IRQ with so many devices.  In comparison IDE controller have
> > all their own IRQ's  Primary IRQ 14 and Secondary IRQ 15
> > 
> 
> Great! So, did you physically remove the sata drive?  The sata drivers are still enabled though?  The ouput from dmesg should give you an idea what drivers the kernel is actively using.
> 
> Zac

No, I still have the same Sata Drive is just I'm playing with IRQ
assignment and configuration.
I've changed to BIOS PnP to YES, so my skge (network controller) and
libata (Sata Controller are shifted to  IRQ 10

But it makes me wonder both controllers on the Motherboard are different
chips, so why do they share IRQ?  Is there a way to shift them to a
different IRQ since Linux control IRQ assignment now? 

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
>>>Finally I was able to emerge KDE, it really took a lot of time.
>>>Though, looking at the motherboard's ASUS A8V IRQ setting:
>>>They put a lot of devices on IRQ5:
>>>
>>>skge - network controller
>>>libata - I think this is sata ATA controller
>>>ethci_Hcd:usb2, usb2
>>>VIA8237 - sound ship
>>>
>>>No wonder I'm having problem (and some others) with Sata Drive, if it is
>>>sharing an IRQ with so many devices.  In comparison IDE controller have
>>>all their own IRQ's  Primary IRQ 14 and Secondary IRQ 15
>>>
>>
>>Great! So, did you physically remove the sata drive?  The sata drivers are still enabled though?  The ouput from dmesg should give you an idea what drivers the kernel is actively using.
>>
>>Zac
> 
> 
> No, I still have the same Sata Drive is just I'm playing with IRQ
> assignment and configuration.
> I've changed to BIOS PnP to YES, so my skge (network controller) and
> libata (Sata Controller are shifted to  IRQ 10
> 
> But it makes me wonder both controllers on the Motherboard are different
> chips, so why do they share IRQ?  Is there a way to shift them to a
> different IRQ since Linux control IRQ assignment now? 
> 

A quick look through linux/Documentation/kernel-parameters.txt shows that many drivers support direct irq assignment.  Also, linux/Documentation/pnp.txt may be of use.

Considering the positive results that you've gotten so far, it seems like you may be on the right track here.  It makes me less concerned about any possible overheating, but if you wanted to be paranoid about it, you could get another heat probe to double check the readings from the first one ;-).

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 09:27 -0700, Zac Medico wrote:
> Joseph wrote:
> >>>Finally I was able to emerge KDE, it really took a lot of time.
> >>>Though, looking at the motherboard's ASUS A8V IRQ setting:
> >>>They put a lot of devices on IRQ5:
> >>>
> >>>skge - network controller
> >>>libata - I think this is sata ATA controller
> >>>ethci_Hcd:usb2, usb2
> >>>VIA8237 - sound ship
> >>>
> >>>No wonder I'm having problem (and some others) with Sata Drive, if it is
> >>>sharing an IRQ with so many devices.  In comparison IDE controller have
> >>>all their own IRQ's  Primary IRQ 14 and Secondary IRQ 15
> >>>
> >>
> >>Great! So, did you physically remove the sata drive?  The sata drivers are still enabled though?  The ouput from dmesg should give you an idea what drivers the kernel is actively using.
> >>
> >>Zac
> > 
> > 
> > No, I still have the same Sata Drive is just I'm playing with IRQ
> > assignment and configuration.
> > I've changed to BIOS PnP to YES, so my skge (network controller) and
> > libata (Sata Controller are shifted to  IRQ 10
> > 
> > But it makes me wonder both controllers on the Motherboard are different
> > chips, so why do they share IRQ?  Is there a way to shift them to a
> > different IRQ since Linux control IRQ assignment now? 
> > 
> 
> A quick look through linux/Documentation/kernel-parameters.txt shows
> that many drivers support direct irq assignment.  Also,
> linux/Documentation/pnp.txt may be of use.
> 
> Considering the positive results that you've gotten so far, it seems
> like you may be on the right track here.  It makes me less concerned
> about any possible overheating, but if you wanted to be paranoid about
> it, you could get another heat probe to double check the readings from
> the first one ;-).
> 
> Zac

Yes, it looks like a gold mind of information but at the moment it is
beyond my comprehension especially that I'm looking for quick
verification.
I'll settle for a simple solution, disable BIOS Network Controller, put
another network card on a PCI bus (making sure they are on a different
IRQ) and try to re-emerge kde.  If it will compile without any problem
it would mean I've solved the problem.

Another problem with that ASUS A8V motherboard is that they put all
additional USB (above 4) on the same IRQ as Sata Controller and Network
Controller.
This is very bad design, having high demanding resources on the same
IRQ.
In addition they put Floppy Controller on a separate IRQ 6 without
ability to re-assign it.  So one IRQ 6 is waisted if you don't have
floppy drive.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

[snip]

> > No, I still have the same Sata Drive is just I'm playing with IRQ
> > assignment and configuration.
> > I've changed to BIOS PnP to YES, so my skge (network controller) and
> > libata (Sata Controller are shifted to  IRQ 10
> > 
> > But it makes me wonder both controllers on the Motherboard are different
> > chips, so why do they share IRQ?  Is there a way to shift them to a
> > different IRQ since Linux control IRQ assignment now? 
> > 
> 
> A quick look through linux/Documentation/kernel-parameters.txt shows that many drivers support direct irq assignment.  Also, linux/Documentation/pnp.txt may be of use.
> 
> Considering the positive results that you've gotten so far, it seems like you may be on the right track here.  It makes me less concerned about any possible overheating, but if you wanted to be paranoid about it, you could get another heat probe to double check the readings from the first one ;-).
> 
> Zac

Here is what I have done:
1.) Disable Network controller on the motherboard and install another
one on PCI bus - this eliminate possible IRQ conflict.
But it didn't help.

2.) Removed the heatsink clean it with 99% isopropyl alcohol and applied
thin layer of new heatsink grease.

Nothing helped, still getting that message:
Kernel panic - not syncing: Aiee, killing interupt handler.

Next option, is to try to remove SATA drive and try to install Gentoo on
standard IDE drive; this would eliminate SCSI problem and/or buggy
driver.

Does anybody has any other solutions?

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Matt Randolph]

Joseph wrote:

>[snip]
>
>  
>
>>>No, I still have the same Sata Drive is just I'm playing with IRQ
>>>assignment and configuration.
>>>I've changed to BIOS PnP to YES, so my skge (network controller) and
>>>libata (Sata Controller are shifted to  IRQ 10
>>>
>>>But it makes me wonder both controllers on the Motherboard are different
>>>chips, so why do they share IRQ?  Is there a way to shift them to a
>>>different IRQ since Linux control IRQ assignment now? 
>>>
>>>      
>>>
>>A quick look through linux/Documentation/kernel-parameters.txt shows that many drivers support direct irq assignment.  Also, linux/Documentation/pnp.txt may be of use.
>>
>>Considering the positive results that you've gotten so far, it seems like you may be on the right track here.  It makes me less concerned about any possible overheating, but if you wanted to be paranoid about it, you could get another heat probe to double check the readings from the first one ;-).
>>
>>Zac
>>    
>>
>
>Here is what I have done:
>1.) Disable Network controller on the motherboard and install another
>one on PCI bus - this eliminate possible IRQ conflict.
>But it didn't help.
>
>2.) Removed the heatsink clean it with 99% isopropyl alcohol and applied
>thin layer of new heatsink grease.
>
>Nothing helped, still getting that message:
>Kernel panic - not syncing: Aiee, killing interupt handler.
>
>Next option, is to try to remove SATA drive and try to install Gentoo on
>standard IDE drive; this would eliminate SCSI problem and/or buggy
>driver.
>
>Does anybody has any other solutions?
>
>  
>
This isn't exactly a solution and its just a stab in the dark, but...

You're using -march=k8, If I recall.  I've read that this causes (or 
used to cause) problems for some people.  I believe it had to do with 
poor support by some versions of gcc.  I'm sure this is probably no 
longer the case, but I haven't heard one way or the other.  I'm using 
-march=athlon64 without any trouble.  I don't think you can change this 
flag after the initial installation, though. 

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

[snip]

> >Here is what I have done:
> >1.) Disable Network controller on the motherboard and install another
> >one on PCI bus - this eliminate possible IRQ conflict.
> >But it didn't help.
> >
> >2.) Removed the heatsink clean it with 99% isopropyl alcohol and applied
> >thin layer of new heatsink grease.
> >
> >Nothing helped, still getting that message:
> >Kernel panic - not syncing: Aiee, killing interupt handler.
> >
> >3.) Next option, is to try to remove SATA drive and try to install Gentoo on
> >standard IDE drive; this would eliminate SCSI problem and/or buggy
> >driver.
> >
> >Does anybody has any other solutions?
> >
> >  
> >
> This isn't exactly a solution and its just a stab in the dark, but...
> 
> You're using -march=k8, If I recall.  I've read that this causes (or 
> used to cause) problems for some people.  I believe it had to do with 
> poor support by some versions of gcc.  I'm sure this is probably no 
> longer the case, but I haven't heard one way or the other.  I'm using 
> -march=athlon64 without any trouble.  I don't think you can change this 
> flag after the initial installation, though. 
> 
> -- 
> "Pluralitas non est ponenda sine necessitate" - W. of O.
> 

Well, your were right, it was a stab in a dark and I missed.
I've removed the Sata Drive put in some 15Gb IDE drive and started from
scratch.
I didn't even had a chance to install all from the handbook when I got
to the point:
9.d. Optional: File Indexing and try to emerge "slocate" and of cause
got a 
Kernel panic - not syncing: Aiee, killing interupt handler.

I've eliminated option 1.)   2.)  and 3.) IDE drive (see above):

So my next option to try would be as you suggest, I will try:
4.)  "-march-athlon64"  in make.conf  instead of "-march=k8" as handbook
suggest (I'll start from scratch again).
5.)  arctic silver compound as per Robert suggestion
6.) replace the mother-board 
7.) replace the CPU
8.) go to Windows XP : -)  (I have to keep sense of humor to keep my
sanity as I've been trying to solve this problem for a week).

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Bob Sanders]

On Fri, 22 Jul 2005 17:52:09 -0600
Joseph <syscon@interbaun.com> wrote:


> > >Does anybody has any other solutions?
> > >i

There are a few tools that will allow you to do some diagnosing.

These will isolate your harddrive and drive controllers.

 app-benchmarks/bonnie (2.0.6):  Performance Test of Filesystem I/O using standard C library calls.
 app-benchmarks/bonnie++ (1.93c):  Hard drive bottleneck testing benchmark suite.

If is is the motherboard, it should fall over pretty quick.

Another tool I like is - 

  app-benchmarks/stress (0.18.6):  Imposes stressful loads on different aspects of the system.

You'll have to add - app-benchmarks/stress x86, to your /etc/portage/package.keywords
as they don't have the amd64 keyword in the ebuild.  It builds and runs fine. 

Stress allows you to load all or parts of the system up for a defined period of time.  It's
even possible to run the system out of resources.  It's a real nice test of system stabilty.
All except the Xserver and that's easy to add by running 3 of the rss-glx screensavers
from a term while running stress.  And if you make the virtual memory component large
enough at runtime, the system will start swapping.

This line will get the load up to about 20 and cause about 500MB of swapping
to occur on a 1P amd64 system with 1 GB of main memory -

  stress --cpu 16 --io 4 --vm 2 --vm-bytes 1024M --timeout 60s -d 2

Change the timeout to be around 5 minutes or 600 seconds.  Get a tail -f /var/log/messages
or use root-tail.  And get a top running in another term.

Bob
-  
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

[snip]

Thank you for suggestion, I'm re-installing Gentoo and definitely run
these tools.

For sure I have some hardware "memory" problem as my latest error
message is:

"Uhhuh. NMI received. Dazed and confused, but trying to continue 
You probably have a hardware problem with your RAM chips
NMI: IOCK error (debug interrupt?)
CPU 0
Modules linked in: evdev via_rhine mii parport_pc parport ahci sata_uli
sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil sata_promis libata
sbp2 ohci1934 ieee1394 usb_storage ohci_hcd uhci_hcd ehci_hcd usbcore
Pid: 5626, comm: rsync Not tainted 2.6.11-gentoo-r3-k8
RIP: 0010:[<ffff....."

Though I've run memtest86 two day ago and 17-passes went without any
errors.
 
-- 
#Joseph

> 
> There are a few tools that will allow you to do some diagnosing.
> 
> These will isolate your harddrive and drive controllers.
> 
>  app-benchmarks/bonnie (2.0.6):  Performance Test of Filesystem I/O using standard C library calls.
>  app-benchmarks/bonnie++ (1.93c):  Hard drive bottleneck testing benchmark suite.
> 
> If is is the motherboard, it should fall over pretty quick.
> 
> Another tool I like is - 
> 
>   app-benchmarks/stress (0.18.6):  Imposes stressful loads on different aspects of the system.
> 
> You'll have to add - app-benchmarks/stress x86, to your /etc/portage/package.keywords
> as they don't have the amd64 keyword in the ebuild.  It builds and runs fine. 
> 
> Stress allows you to load all or parts of the system up for a defined period of time.  It's
> even possible to run the system out of resources.  It's a real nice test of system stabilty.
> All except the Xserver and that's easy to add by running 3 of the rss-glx screensavers
> from a term while running stress.  And if you make the virtual memory component large
> enough at runtime, the system will start swapping.
> 
> This line will get the load up to about 20 and cause about 500MB of swapping
> to occur on a 1P amd64 system with 1 GB of main memory -
> 
>   stress --cpu 16 --io 4 --vm 2 --vm-bytes 1024M --timeout 60s -d 2
> 
> Change the timeout to be around 5 minutes or 600 seconds.  Get a tail -f /var/log/messages
> or use root-tail.  And get a top running in another term.
> 
> Bob
> -  

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> [snip]
> 
> Thank you for suggestion, I'm re-installing Gentoo and definitely run
> these tools.
> 
> For sure I have some hardware "memory" problem as my latest error
> message is:
> 
> "Uhhuh. NMI received. Dazed and confused, but trying to continue 
> You probably have a hardware problem with your RAM chips
> NMI: IOCK error (debug interrupt?)
> CPU 0
> Modules linked in: evdev via_rhine mii parport_pc parport ahci sata_uli
> sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil sata_promis libata
> sbp2 ohci1934 ieee1394 usb_storage ohci_hcd uhci_hcd ehci_hcd usbcore
> Pid: 5626, comm: rsync Not tainted 2.6.11-gentoo-r3-k8
> RIP: 0010:[<ffff....."
> 
> Though I've run memtest86 two day ago and 17-passes went without any
> errors.
>  

How may ram modules do you have, any spares?  Maybe you can stress test them one at a time.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

> > Though I've run memtest86 two day ago and 17-passes went without any
> > errors.
> >  
> 
> How may ram modules do you have, any spares?  Maybe you can stress test them one at a time.
> 
> Zac

I have two memory sticks; and yes I run them individually as well.
Though Francesco made good pointer.  I'll borrow two sticks from another
machine and try to run it as well.
-------- quote------
Sometimes memtest doesn't stress enough the hardware, see:
http://people.redhat.com/dledford/memtest.html
------- end quote-----
along with Bob, who pointed me to some good gentoo hardware utility the
I possibly will be able to run tomorrow.
It is definitely a hardware problem.
I'll let you know once I find out.
 
-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: update - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
>>>Though I've run memtest86 two day ago and 17-passes went without any
>>>errors.
>>> 
>>
>>How may ram modules do you have, any spares?  Maybe you can stress test them one at a time.
>>
>>Zac
> 
> 
> I have two memory sticks; and yes I run them individually as well.
> Though Francesco made good pointer.  I'll borrow two sticks from another
> machine and try to run it as well.
> -------- quote------
> Sometimes memtest doesn't stress enough the hardware, see:
> http://people.redhat.com/dledford/memtest.html
> ------- end quote-----
> along with Bob, who pointed me to some good gentoo hardware utility the
> I possibly will be able to run tomorrow.
> It is definitely a hardware problem.
> I'll let you know once I find out.
>  

Lots of good advice.  I've been taking notes ;-).

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Zac Medico]

Joseph wrote:
> On Thu, 2005-07-21 at 19:05 -0700, Zac Medico wrote:
> 
>>Bob Sanders wrote:
>>
>>>On Thu, 21 Jul 2005 16:50:49 -0600
>>>Joseph <syscon@interbaun.com> wrote:
>>>
>>>
>>>
>>>
>>>>I wasn't clear, the computer runs usually for 20 to 30minus and kernel
>>>>panic comes up on the screen.  I'm still googling for some solutions and
>>>>I can only find some suggestion; no clear answer.
>>>>i
>>>
>>>
>>>I think you have hardware problems - maybe a heat issue.  have you tried running
>>>with the covers off and a fan blowing onto the system?
>>>
>>>
>>
>>Good thinking Bob! That 20 to 30 minutes certainly seems symptomatic of overheating.
>>
>>I've been confused throughout this whole thread thinking that the kernel panic and kde compile were somehow related.  I know, sounds crazy, but that's how I interpreted Joseph's explanation of the situation.
>>
>>Zac
> 
> 
> The latest news.
> After taking the cover off; the temp. of the CPU went down by 3C  to 37C
> and Motherboard down by 3C as well to 26C. but that still didn't prevent
> the the kernel panic message:
> Kernel panic - not syncing: Aiee, killing interupt handler.
> 
> So my next solution is to get another Drive but an IDE type and put the
> SATA one on the shelf, and reinstall Gentoo.  
> 

Ideally, it would be nice if you could test this idea before taking such a large step.  Maybe you can boot from a livecd, reproduce the error, and then try to reproduce the error again without your sata driver loaded.

Zac
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

> > The latest news.
> > After taking the cover off; the temp. of the CPU went down by 3C  to 37C
> > and Motherboard down by 3C as well to 26C. but that still didn't prevent
> > the the kernel panic message:
> > Kernel panic - not syncing: Aiee, killing interupt handler.
> > 
> > So my next solution is to get another Drive but an IDE type and put the
> > SATA one on the shelf, and reinstall Gentoo.  
> > 
> 
> Ideally, it would be nice if you could test this idea before taking such a large step.  Maybe you can boot from a livecd, reproduce the error, and then try to reproduce the error again without your sata driver loaded.
> 
> Zac

I have an old IDE drive, maybe I can squeeze Gentoo on it for testing.
Bob has a good idea too regarding the CPU compound under the heat-sink
but at CPU temp. 39C I don't see how that could cause any problem.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Martins Steinbergs]

my bid is:

1) is that sata_via kernel/module actualy loading?
2) update bios
3) check mbr

hope i'm not wastig your time. I have similar box, except sata drive, but lot 
of sata stuf is loadin'
Linux 2.6.11.11 #1 Fri Jun 17 11:19:52 EEST 2005 x86_64 AMD Athlon(tm) 64 
Processor 3200+ AuthenticAMD GNU/Linux


martins



On Friday 22 July 2005 07:26, Joseph wrote:
> > > The latest news.
> > > After taking the cover off; the temp. of the CPU went down by 3C  to
> > > 37C and Motherboard down by 3C as well to 26C. but that still didn't
> > > prevent the the kernel panic message:
> > > Kernel panic - not syncing: Aiee, killing interupt handler.
> > >
> > > So my next solution is to get another Drive but an IDE type and put the
> > > SATA one on the shelf, and reinstall Gentoo.
> >
> > Ideally, it would be nice if you could test this idea before taking such
> > a large step.  Maybe you can boot from a livecd, reproduce the error, and
> > then try to reproduce the error again without your sata driver loaded.
> >
> > Zac
>
> I have an old IDE drive, maybe I can squeeze Gentoo on it for testing.
> Bob has a good idea too regarding the CPU compound under the heat-sink
> but at CPU temp. 39C I don't see how that could cause any problem.
>
> --
> #Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

> > I have an old IDE drive, maybe I can squeeze Gentoo on it for testing.
> > Bob has a good idea too regarding the CPU compound under the heat-sink
> > but at CPU temp. 39C I don't see how that could cause any problem.
> >
> > --
> > #Joseph

No matter what the temp sensors are reading, your problem definitely sounds 
like it's heat related. Temp sensor readings can, and often are not accurate, 
sometimes to an amazing degree. I don't know what type of sensor your cpu 
uses, but if it's the type under the cpu, it might not be in good contact 
with the cpu itself, thus giving false readings, I wouldn't be surprised if 
your cpu temp was really  over 50C.   In my experience, temps over 50C. with 
AMD 32bit cpus start giving problems like this, no matter what AMD says about 
it. Seeing as how you have an AMD 64, I'm not sure about the sensor type- all 
I'm saying is that the readings can vary wildly, and are not to be trusted, 
especially considering your current problems.

Robert Crawford
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 10:00 -0400, Robert Crawford wrote:
> > > I have an old IDE drive, maybe I can squeeze Gentoo on it for testing.
> > > Bob has a good idea too regarding the CPU compound under the heat-sink
> > > but at CPU temp. 39C I don't see how that could cause any problem.
> > >
> > > --
> > > #Joseph
> 
> No matter what the temp sensors are reading, your problem definitely sounds 
> like it's heat related. Temp sensor readings can, and often are not accurate, 
> sometimes to an amazing degree. I don't know what type of sensor your cpu 
> uses, but if it's the type under the cpu, it might not be in good contact 
> with the cpu itself, thus giving false readings, I wouldn't be surprised if 
> your cpu temp was really  over 50C.   In my experience, temps over 50C. with 
> AMD 32bit cpus start giving problems like this, no matter what AMD says about 
> it. Seeing as how you have an AMD 64, I'm not sure about the sensor type- all 
> I'm saying is that the readings can vary wildly, and are not to be trusted, 
> especially considering your current problems.
> 
> Robert Crawford\

I'll try to get to the bottom of it.

1.) First, I have noticed that the Sata Controller share one IRQ with
Network Controller, this is not a good combination.  I don't know if it
is possible to re-assign and IRQ so they will be on a different one
(BIOS does not have this option).
If not I'll install another network card and disable the one on the
Motherboard.

2.) Heat could be a problem as you have mentioned, I'll try to change
the thermal padding under the heatsink.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

One other thought- I don't recall seeing any mention of this in this thread.  
Are you sure your heatsink/fan combo is rated for your AMD 64 cpu?

On Friday 22 July 2005 11:26 am, Joseph wrote:
> On Fri, 2005-07-22 at 10:00 -0400, Robert Crawford wrote:
> > > > I have an old IDE drive, maybe I can squeeze Gentoo on it for
> > > > testing. Bob has a good idea too regarding the CPU compound under the
> > > > heat-sink but at CPU temp. 39C I don't see how that could cause any
> > > > problem.
> > > >
> > > > --
> > > > #Joseph
> >
> > No matter what the temp sensors are reading, your problem definitely
> > sounds like it's heat related. Temp sensor readings can, and often are
> > not accurate, sometimes to an amazing degree. I don't know what type of
> > sensor your cpu uses, but if it's the type under the cpu, it might not be
> > in good contact with the cpu itself, thus giving false readings, I
> > wouldn't be surprised if your cpu temp was really  over 50C.   In my
> > experience, temps over 50C. with AMD 32bit cpus start giving problems
> > like this, no matter what AMD says about it. Seeing as how you have an
> > AMD 64, I'm not sure about the sensor type- all I'm saying is that the
> > readings can vary wildly, and are not to be trusted, especially
> > considering your current problems.
> >
> > Robert Crawford\
>
> I'll try to get to the bottom of it.
>
> 1.) First, I have noticed that the Sata Controller share one IRQ with
> Network Controller, this is not a good combination.  I don't know if it
> is possible to re-assign and IRQ so they will be on a different one
> (BIOS does not have this option).
> If not I'll install another network card and disable the one on the
> Motherboard.
>
> 2.) Heat could be a problem as you have mentioned, I'll try to change
> the thermal padding under the heatsink.
>
> --
> #Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Going to Ubuntu - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 11:56 -0400, Robert Crawford wrote:
> One other thought- I don't recall seeing any mention of this in this thread.  
> Are you sure your heatsink/fan combo is rated for your AMD 64 cpu?
> 

The heatsink came with the CPU, so I assume it should be adequate.
In addition I just check the CPU temp. in Bios and it went down to 35C.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 10:00 -0400, Robert Crawford wrote:
> > > I have an old IDE drive, maybe I can squeeze Gentoo on it for testing.
> > > Bob has a good idea too regarding the CPU compound under the heat-sink
> > > but at CPU temp. 39C I don't see how that could cause any problem.
> > >
> > > --
> > > #Joseph
> 
> No matter what the temp sensors are reading, your problem definitely sounds 
> like it's heat related. Temp sensor readings can, and often are not accurate, 
> sometimes to an amazing degree. I don't know what type of sensor your cpu 
> uses, but if it's the type under the cpu, it might not be in good contact 
> with the cpu itself, thus giving false readings, I wouldn't be surprised if 
> your cpu temp was really  over 50C.   In my experience, temps over 50C. with 
> AMD 32bit cpus start giving problems like this, no matter what AMD says about 
> it. Seeing as how you have an AMD 64, I'm not sure about the sensor type- all 
> I'm saying is that the readings can vary wildly, and are not to be trusted, 
> especially considering your current problems.
> 
> Robert Crawford

Now I tend to lean towards your solution.
It could be heat related.
I've disable on-board network and add standard PCI card on a IRQ3
(separate IRQ); so the SATA controller has its own IRQ as well.

The computer freesed once during "emerge sync" without any error
message, and with error during emerge Apache.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

If you are using the thermal pad, tape, or grease  that came with the stock  
heatsink, you might try using some arctic silver compound instead. It's good 
for a 3-5C. drop from the regular stuff. Sometimes even the AMD approved 
stock heatsinks don't do the job, and you might need to get a better one 
(assuming heat is the problem). I build a lot of computers, and with AMD 
cpus, overkill in the cooling dept. is sometimes necessary.

Robert Crawford

On Friday 22 July 2005 03:31 pm, Joseph wrote:
> On Fri, 2005-07-22 at 10:00 -0400, Robert Crawford wrote:
> > > > I have an old IDE drive, maybe I can squeeze Gentoo on it for
> > > > testing. Bob has a good idea too regarding the CPU compound under the
> > > > heat-sink but at CPU temp. 39C I don't see how that could cause any
> > > > problem.
> > > >
> > > > --
> > > > #Joseph
> >
> > No matter what the temp sensors are reading, your problem definitely
> > sounds like it's heat related. Temp sensor readings can, and often are
> > not accurate, sometimes to an amazing degree. I don't know what type of
> > sensor your cpu uses, but if it's the type under the cpu, it might not be
> > in good contact with the cpu itself, thus giving false readings, I
> > wouldn't be surprised if your cpu temp was really  over 50C.   In my
> > experience, temps over 50C. with AMD 32bit cpus start giving problems
> > like this, no matter what AMD says about it. Seeing as how you have an
> > AMD 64, I'm not sure about the sensor type- all I'm saying is that the
> > readings can vary wildly, and are not to be trusted, especially
> > considering your current problems.
> >
> > Robert Crawford
>
> Now I tend to lean towards your solution.
> It could be heat related.
> I've disable on-board network and add standard PCI card on a IRQ3
> (separate IRQ); so the SATA controller has its own IRQ as well.
>
> The computer freesed once during "emerge sync" without any error
> message, and with error during emerge Apache.
>
> --
> #Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 16:29 -0400, Robert Crawford wrote:
> If you are using the thermal pad, tape, or grease  that came with the stock  
> heatsink, you might try using some arctic silver compound instead. It's good 
> for a 3-5C. drop from the regular stuff. Sometimes even the AMD approved 
> stock heatsinks don't do the job, and you might need to get a better one 
> (assuming heat is the problem). I build a lot of computers, and with AMD 
> cpus, overkill in the cooling dept. is sometimes necessary.
> 
> Robert Crawford
> 

As I posted earlier:
----------
Here is what I have done:
1.) Disable Network controller on the motherboard and install another
one on PCI bus - this eliminate possible IRQ conflict.
But it didn't help.

2.) Removed the heatsink clean it with 99% isopropyl alcohol and applied
thin layer of new heatsink grease.

Nothing helped, still getting that message:
Kernel panic - not syncing: Aiee, killing interupt handler.

Next option, is to try to remove SATA drive and try to install Gentoo on
standard IDE drive; this would eliminate SCSI problem and/or buggy
driver.
-----------

If the IDE drive will not solve the problem I'll try as you suggest that
"arctic silver compound" (or just run that useless box only during
Winter - here in Edmonton sometimes it gets down to -40C it might
help :-> 

I'm simply running out of ideas.

[snip]
-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

Joseph,
Sorry- I haven't been reading this thread from the beginning, so I might have 
missed some of your first posts.

If we eliminate heat as the problem (not saying we absolutely have), I'm 
starting to think it could be a misconfigured kernel, or kernel bug itself.

What kernel are you you currently using?  It might be worth a try compiling a 
new one, making sure all config options are correct for your system.

One question (maybe you answered this before):
Have you booted to a live cd like Knoppix or Slax, and the same problem 
occurs?  If it does still happen, that would eliminate your kernel and/or 
hard drive as the source of the problem, and again focus back on the heat 
issue.

If it doesn't happen, after being booted to a live cd for several hours of 
heavy usage, that would eliminate the heat issue. 

Robert


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Matt Randolph]

Robert Crawford wrote:

>Joseph,
>Sorry- I haven't been reading this thread from the beginning, so I might have 
>missed some of your first posts.
>
>If we eliminate heat as the problem (not saying we absolutely have), I'm 
>starting to think it could be a misconfigured kernel, or kernel bug itself.
>
>What kernel are you you currently using?  It might be worth a try compiling a 
>new one, making sure all config options are correct for your system.
>
>One question (maybe you answered this before):
>Have you booted to a live cd like Knoppix or Slax, and the same problem 
>occurs?  If it does still happen, that would eliminate your kernel and/or 
>hard drive as the source of the problem, and again focus back on the heat 
>issue.
>
>If it doesn't happen, after being booted to a live cd for several hours of 
>heavy usage, that would eliminate the heat issue. 
>
>Robert
>
>
>  
>
Excellent idea, but I'd suggest Kanotix 64 instead of Knoppix or Slax.  
Unless there are 64-bit versions of those that I don't know about.

-- 
"Pluralitas non est ponenda sine necessitate" - W. of O.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

Yeah- Kanotix is great- I forgot about that one. I just burnt a copy of the 
latest 32 bit version- it's a wonderful distro, although I'm still basicallya 
Gentoo man!


On Friday 22 July 2005 06:49 pm, Matt Randolph wrote:
> Robert Crawford wrote:
> >Joseph,
> >Sorry- I haven't been reading this thread from the beginning, so I might
> > have missed some of your first posts.
> >
> >If we eliminate heat as the problem (not saying we absolutely have), I'm
> >starting to think it could be a misconfigured kernel, or kernel bug
> > itself.
> >
> >What kernel are you you currently using?  It might be worth a try
> > compiling a new one, making sure all config options are correct for your
> > system.
> >
> >One question (maybe you answered this before):
> >Have you booted to a live cd like Knoppix or Slax, and the same problem
> >occurs?  If it does still happen, that would eliminate your kernel and/or
> >hard drive as the source of the problem, and again focus back on the heat
> >issue.
> >
> >If it doesn't happen, after being booted to a live cd for several hours of
> >heavy usage, that would eliminate the heat issue.
> >
> >Robert
>
> Excellent idea, but I'd suggest Kanotix 64 instead of Knoppix or Slax.
> Unless there are 64-bit versions of those that I don't know about.
>
> --
> "Pluralitas non est ponenda sine necessitate" - W. of O.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Fri, 2005-07-22 at 17:24 -0400, Robert Crawford wrote:
> Joseph,
> Sorry- I haven't been reading this thread from the beginning, so I might have 
> missed some of your first posts.
> 
> If we eliminate heat as the problem (not saying we absolutely have), I'm 
> starting to think it could be a misconfigured kernel, or kernel bug itself.

I'm just following handbook AMD64 instruction, so everything boots OK
after installation (if I don't get the kernel panic).

> What kernel are you you currently using?  It might be worth a try compiling a 
> new one, making sure all config options are correct for your system.

I'm on gentoo-source 2.6.12-r6 (the newest one)

> One question (maybe you answered this before):
> Have you booted to a live cd like Knoppix or Slax, and the same problem 
> occurs?  If it does still happen, that would eliminate your kernel and/or 
> hard drive as the source of the problem, and again focus back on the heat 
> issue.
> 
> If it doesn't happen, after being booted to a live cd for several hours of 
> heavy usage, that would eliminate the heat issue. 

It does not happen when I do some light stuff computing, only during
compilation, when I'm emerging something.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

On Friday 22 July 2005 07:57 pm, Joseph wrote:
> On Fri, 2005-07-22 at 17:24 -0400, Robert Crawford wrote:
> > Joseph,
> > Sorry- I haven't been reading this thread from the beginning, so I might
> > have missed some of your first posts.
> >
> > If we eliminate heat as the problem (not saying we absolutely have), I'm
> > starting to think it could be a misconfigured kernel, or kernel bug
> > itself.
>
> I'm just following handbook AMD64 instruction, so everything boots OK
> after installation (if I don't get the kernel panic).
>
> > What kernel are you you currently using?  It might be worth a try
> > compiling a new one, making sure all config options are correct for your
> > system.
>
> I'm on gentoo-source 2.6.12-r6 (the newest one)
>
> > One question (maybe you answered this before):
> > Have you booted to a live cd like Knoppix or Slax, and the same problem
> > occurs?  If it does still happen, that would eliminate your kernel and/or
> > hard drive as the source of the problem, and again focus back on the heat
> > issue.
> >
> > If it doesn't happen, after being booted to a live cd for several hours
> > of heavy usage, that would eliminate the heat issue.
>
> It does not happen when I do some light stuff computing, only during
> compilation, when I'm emerging something.
>
> --
> #Joseph

OK- if it doesn't happen during light computing stuff, and only with very cpu 
intensive stuff like compiling, I feel virtually certain it is a cpu heat 
issue.  IMHO, there's not really any other reasonable explanation. 

Have you investigated the cpu voltage setting in the bios (if your Asus board 
has one to adjust it)?  It's probably set at default for the cpu, but if it's 
set too high, that will cause cpu overheating, especially with a borderline 
heatsink/fan.  I'm not sure what the default voltage of your cpu should be- 
look it up on the net, or it is coded on the cpu numbers, if you have the 
code. For example, the Athlon 64 3200+ has a default operating voltage of 
1.50 volts. This link shows an example of the cpu codes written on the chips, 
and what the markings mean.

http://www.digital-daily.com/cpu/amd-athlon64/

Robert
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

I went back to Sata Drive and started from scratch and when I tried to
do "emerge --sync"  I got this error:

"Uhhuh. HMI received. Dazed and confused, but trying to continue 
You probably have a hardware problem with your RAM chips
NMI: IOCK error (debug interrupt?)
CPU 0
Modules linked in: evdev via_rhine mii parport_pc parport ahci sata_uli
sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil sata_promis libata
sbp2 ohci1934 ieee1394 usb_storage ohci_hcd uhci_hcd ehci_hcd usbcore
Pid: 5626, comm: rsync Not tainted 2.6.11-gentoo-r3-k8
RIP: 0010:[<ffff....."

Is it problem with my standard memory or CPU memory cache?
I'v run memtest86 two day ago and 17-passes went without any errors.

-- 
#Joseph

On Fri, 2005-07-22 at 21:32 -0400, Robert Crawford wrote:
> On Friday 22 July 2005 07:57 pm, Joseph wrote:
> > On Fri, 2005-07-22 at 17:24 -0400, Robert Crawford wrote:
> > > Joseph,
> > > Sorry- I haven't been reading this thread from the beginning, so I might
> > > have missed some of your first posts.
> > >
> > > If we eliminate heat as the problem (not saying we absolutely have), I'm
> > > starting to think it could be a misconfigured kernel, or kernel bug
> > > itself.
> >
> > I'm just following handbook AMD64 instruction, so everything boots OK
> > after installation (if I don't get the kernel panic).
> >
> > > What kernel are you you currently using?  It might be worth a try
> > > compiling a new one, making sure all config options are correct for your
> > > system.
> >
> > I'm on gentoo-source 2.6.12-r6 (the newest one)
> >
> > > One question (maybe you answered this before):
> > > Have you booted to a live cd like Knoppix or Slax, and the same problem
> > > occurs?  If it does still happen, that would eliminate your kernel and/or
> > > hard drive as the source of the problem, and again focus back on the heat
> > > issue.
> > >
> > > If it doesn't happen, after being booted to a live cd for several hours
> > > of heavy usage, that would eliminate the heat issue.
> >
> > It does not happen when I do some light stuff computing, only during
> > compilation, when I'm emerging something.
> >
> > --
> > #Joseph
> 
> OK- if it doesn't happen during light computing stuff, and only with very cpu 
> intensive stuff like compiling, I feel virtually certain it is a cpu heat 
> issue.  IMHO, there's not really any other reasonable explanation. 
> 
> Have you investigated the cpu voltage setting in the bios (if your Asus board 
> has one to adjust it)?  It's probably set at default for the cpu, but if it's 
> set too high, that will cause cpu overheating, especially with a borderline 
> heatsink/fan.  I'm not sure what the default voltage of your cpu should be- 
> look it up on the net, or it is coded on the cpu numbers, if you have the 
> code. For example, the Athlon 64 3200+ has a default operating voltage of 
> 1.50 volts. This link shows an example of the cpu codes written on the chips, 
> and what the markings mean.
> 
> http://www.digital-daily.com/cpu/amd-athlon64/
> 
> Robert

-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Francesco Talamona]

On Saturday 23 July 2005 03:56, Joseph wrote:
> I went back to Sata Drive and started from scratch and when I tried
> to do "emerge --sync"  I got this error:
>
> "Uhhuh. HMI received. Dazed and confused, but trying to continue
> You probably have a hardware problem with your RAM chips
> NMI: IOCK error (debug interrupt?)
> CPU 0
> Modules linked in: evdev via_rhine mii parport_pc parport ahci
> sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil
> sata_promis libata sbp2 ohci1934 ieee1394 usb_storage ohci_hcd
> uhci_hcd ehci_hcd usbcore Pid: 5626, comm: rsync Not tainted
> 2.6.11-gentoo-r3-k8
> RIP: 0010:[<ffff....."
>
> Is it problem with my standard memory or CPU memory cache?
> I'v run memtest86 two day ago and 17-passes went without any errors.
>

Sometimes memtest doesn't stress enough the hardware, see:
http://people.redhat.com/dledford/memtest.html

It's so simple that you can also run it on top of a live CD like 
Kanotix...

Ciao
	Francesco
-- 
Linux Version 2.6.11-gentoo-r11, Compiled #1 Thu Jun 23 05:26:18 Local 
time zone must be set--see zic manu
One 2.2GHz AMD Athlon 64 Processor, 2GB RAM, 4325.37 Bogomips Total
aemaeth
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Sat, 2005-07-23 at 07:43 +0200, Francesco Talamona wrote:
> On Saturday 23 July 2005 03:56, Joseph wrote:
> > I went back to Sata Drive and started from scratch and when I tried
> > to do "emerge --sync"  I got this error:
> >
> > "Uhhuh. HMI received. Dazed and confused, but trying to continue
> > You probably have a hardware problem with your RAM chips
> > NMI: IOCK error (debug interrupt?)
> > CPU 0
> > Modules linked in: evdev via_rhine mii parport_pc parport ahci
> > sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil
> > sata_promis libata sbp2 ohci1934 ieee1394 usb_storage ohci_hcd
> > uhci_hcd ehci_hcd usbcore Pid: 5626, comm: rsync Not tainted
> > 2.6.11-gentoo-r3-k8
> > RIP: 0010:[<ffff....."
> >
> > Is it problem with my standard memory or CPU memory cache?
> > I'v run memtest86 two day ago and 17-passes went without any errors.
> >
> 
> Sometimes memtest doesn't stress enough the hardware, see:
> http://people.redhat.com/dledford/memtest.html
> 
> It's so simple that you can also run it on top of a live CD like 
> Kanotix...
> 
> Ciao

I was trying to run this Red Hat memtest.sh script.
So I copied the linux.tar.gz (45Mb file) to /tmp directory.

Though when I try to run the script as user it keeps complaining:
mv: cannot stat `linux': No such file or directory
mv: cannot stat `linux': No such file or directory

What am I missing?
Since I possibly have a bad memory stick it would be good idea to put
this script to a test.
memtest86 did 17-passes on this memory and didn't detect any errors.

So, I borrowed two good memory sticks from my backup server, and the new
box is happy so far, compiled some kind of 27Mb lib-file without any
kernel panic.

I would like to run this Red-Hat memtest.sh script on these two stick,
but I'm missing something (I'm not that good in reading the scripts :-/
Can anybody have a pick at it and tell me what is it looking for?

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Richard Fish]

Joseph wrote:

>I was trying to run this Red Hat memtest.sh script.
>So I copied the linux.tar.gz (45Mb file) to /tmp directory.
>
>Though when I try to run the script as user it keeps complaining:
>mv: cannot stat `linux': No such file or directory
>mv: cannot stat `linux': No such file or directory
>
>  
>

Does "tar -tzvf linux.tar.gz" show the top-level directory as "linux", 
or "linux-2....".  If the latter, do the following to make a suitable 
tar.gz for the script (it is easier than fixing the script!):

tar -xzvf linux.tar.gz
mv "linux-*" linux
tar -czvf linux.tar.gz linux

HTH
-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

On Sat, 2005-07-23 at 10:16 +0200, Richard Fish wrote:
> Joseph wrote:
> 
> >I was trying to run this Red Hat memtest.sh script.
> >So I copied the linux.tar.gz (45Mb file) to /tmp directory.
> >
> >Though when I try to run the script as user it keeps complaining:
> >mv: cannot stat `linux': No such file or directory
> >mv: cannot stat `linux': No such file or directory
> >
> >  
> >
> 
> Does "tar -tzvf linux.tar.gz" show the top-level directory as "linux", 
> or "linux-2....".  If the latter, do the following to make a suitable 
> tar.gz for the script (it is easier than fixing the script!):
> 
> tar -xzvf linux.tar.gz
> mv "linux-*" linux
> tar -czvf linux.tar.gz linux
> 
> HTH
> -Richard

That did it.
Though it complained when I did 
mv "linux-*" linux 
it wanted full dir name:
mv linux-2.6.12 linux

This test is running right now on my main server, 
though when I try to run it on the new box it keeps complaining:
-bash: ./memtest.sh: /bin/bash2: bad interpreter: No such file or
directory

On both boxes the I have bash-3.0 so what is it looking for?

I've run some emerge overnight with the memory sticks from my backup
server and it run just fine.
Now, what I want to do is to run this Red Hat memtest.sh and memtest86
on the new box (on the new memory stick) to compare the results.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Francesco Talamona]

On Saturday 23 July 2005 18:58, Joseph wrote:
> On Sat, 2005-07-23 at 10:16 +0200, Richard Fish wrote:
> > Joseph wrote:
[...]
> -bash: ./memtest.sh: /bin/bash2: bad interpreter: No such file or
> directory
>
> On both boxes the I have bash-3.0 so what is it looking for?

Correct the first line of the script from "#!/bin/bash2" to 
"#!/bin/bash" and everything will be fine.

Ciao
	Francesco

-- 
Linux Version 2.6.11-gentoo-r11, Compiled #1 Thu Jun 23 05:26:18
One 2.2GHz AMD Athlon 64 Processor, 2GB RAM, 4325.37 Bogomips Total
aemaeth
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

> [...]
> > -bash: ./memtest.sh: /bin/bash2: bad interpreter: No such file or
> > directory
> >
> > On both boxes the I have bash-3.0 so what is it looking for?
> 
> Correct the first line of the script from "#!/bin/bash2" to 
> "#!/bin/bash" and everything will be fine.
> 
> Ciao
> 	Francesco

Thank you, yes that is what I did as soon as I posted the message.
Though it puzzle me whey it runs on my main server and not on the new
box?

Ps. my mean server pass the memtest.sh without any errors, I'm only
curious the  result of that bad rum sticks that pass memtest86 on the
new box.  I will re-run both test and post the results.

-- 
#Joseph
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Richard Fish]

Joseph wrote:

>>[...]
>>    
>>
>>>-bash: ./memtest.sh: /bin/bash2: bad interpreter: No such file or
>>>directory
>>>
>>>On both boxes the I have bash-3.0 so what is it looking for?
>>>      
>>>
>>Correct the first line of the script from "#!/bin/bash2" to 
>>"#!/bin/bash" and everything will be fine.
>>
>>Ciao
>>	Francesco
>>    
>>
>
>Thank you, yes that is what I did as soon as I posted the message.
>Though it puzzle me whey it runs on my main server and not on the new
>box?
>
>Ps. my mean server pass the memtest.sh without any errors, I'm only
>curious the  result of that bad rum sticks that pass memtest86 on the
>new box.  I will re-run both test and post the results.
>  
>

My guess is still that if you relax the memory timings in the BIOS, the 
"bad" RAM will start to work fine.  Of course, *I* would still return it 
and get RAM that actually performs to the specs on the box, but that's 
just me! :->

-Richard


-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [SOLVED - CONCLUSION] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Joseph]

Summary: 
For those who didn't follow up the thread, I was investigating an error
message:
"Kernel panic - not syncing: Aiee, killing interrupt handler."  where
the computer comes to a complete freeze, the only thing that works is
the power switch.

The error appears only under heavy load like compiling.  This is a new
box Asus A8V, AMD64, 1Gb or RAM (PC3200 DDR400 Kingston RAM)  and Sata
200Gb
I was able to find out that "Aiee" is a hardware error, Intel has a nice
article about it:
http://resource.intel.com/telecom/support/tnotes/tnbyos/2000/tn062.htm

So following this lead I was looking and trying to pin-point hardware
error.
It took me one week to investigate trying different solutions like:

1.) I Run memtest86 first time, got some errors, so I run the same test
on individual sticks (I have 2 x 512Mb), the individual sticks passed
the test without errors.
I exchanged the sticks between two slots and run the memtest86 again
overnight.  The test completed 17-passes without any error.
So I excluded Memory as a culprit. 

2.) I disabled Network controller on the motherboard and installed
another
one on PCI bus - this eliminated possible IRQ conflict, the Sata Drive
on channel-0 was sharing an IRQ with Network controller.
But it didn't help.

3.) I removed the heatsink, cleaned it with 99% isopropyl alcohol and
applied a
thin layer of new heatsink grease.
Did not help.  But I still wanted to try  as per Robert C. suggestion:
"some arctic silver compound instead. It's good for a 3-5C. drop from
the regular stuff."  
Anyhow, I opened the box cover, and the temp. of the CPU dropped from
about 40C to about 35C / 36C so I decided to follow some other leads
first.

4.) I removed SATA drive and tried to install Gentoo on
standard IDE drive; this would eliminate SCSI problem and/or buggy
driver.
Did not help, I haven't had a chance to do a complete base installation
when I got the same error message:
"Kernel panic - not syncing: Aiee, killing interrupt handler."  

I got a lead from Francesco T.
''Sometimes memtest doesn't stress enough the hardware, see:
http://people.redhat.com/dledford/memtest.html 
..."

So it made me think again about the memory. I swapped the two sticks
with the two sticks from one of my Backup Server PC2100 2x512Mb

So I downloaded some linux source  kernel but it needs to be modified as
the Red Hat memtest.sh is looking for "linux" top-level directory not
some "linux-2.6.-something". 
Instead of modifying the script it is easier to just modify the
kernel-source (as per Richard F help):
tar -xzvf linux.tar.gz
mv linux-* linux
tar -czvf linux.tar.gz linux

and one more thing, change the first line of the script:
 #!/bin/bash2
to:
 #!/bin/bash

I run the RedHad memory test on my main server (different box 20-passes
standard script setup) and it went just fine.  It finished with an empty
line "no error" as weg-page suggest:
---quote----
How do you know if your memory passed?

Very simple. If you run that script from the command line on your
computer and it completes without ever spewing a single message onto
your screen, then you passed. If you get messages from diff about
differences between files or any other anomolies such as that, then you
failed.
---end quote-----

I run some compiling and did not receive any errors or kernel panic I
did run the RedHat memory test on the memory stick from my backup server
and it finished without spilling a single error message.

So, at this point I know the problem is the memory stick
I put back the original memory stick, the Sata Drive, and used the on
board Network controller.
I tried to run the RedHad memtest.sh it freeze with the same kernel
panic:
"Kernel panic - not syncing: Aiee, killing interrupt handler."

It appears that the test only made into fourth-round when it freeze.
It did not spill any message into the screen it just freeze with the
kernel panic as always.  So I wasn't 100% sure that this would qualify
as failed memory test: 
"...f you get messages from diff about differences between files or any
other anomolies such as that, then you failed."
But I suppose, it would qualify, you be the judge.

Anyhow, I replaced the pair of stick with two new once run memtest.sh
30-passes it passed without spilling single "error" on the the line,
clean finish.
I was able to emerge "kde-meta" and it finished without a single hiccup.

Thank you ALL for all your suggestions help, it appears another mystery
has been solved.
So my conclusion: Do not rely on memtest86  

-- 
#Joseph

On Sat, 2005-07-23 at 20:23 +0200, Richard Fish wrote:
> Joseph wrote:
> 
> >>[...]
> >>    
> >>
> >>>-bash: ./memtest.sh: /bin/bash2: bad interpreter: No such file or
> >>>directory
> >>>
> >>>On both boxes the I have bash-3.0 so what is it looking for?
> >>>      
> >>>
> >>Correct the first line of the script from "#!/bin/bash2" to 
> >>"#!/bin/bash" and everything will be fine.
> >>
> >>Ciao
> >>	Francesco
> >>    
> >>
> >
> >Thank you, yes that is what I did as soon as I posted the message.
> >Though it puzzle me whey it runs on my main server and not on the new
> >box?
> >
> >Ps. my mean server pass the memtest.sh without any errors, I'm only
> >curious the  result of that bad rum sticks that pass memtest86 on the
> >new box.  I will re-run both test and post the results.
> >  
> >
> 
> My guess is still that if you relax the memory timings in the BIOS, the 
> "bad" RAM will start to work fine.  Of course, *I* would still return it 
> and get RAM that actually performs to the specs on the box, but that's 
> just me! :->
> 
> -Richard
> 
> 

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Richard Fish]

Joseph wrote:

>On Sat, 2005-07-23 at 10:16 +0200, Richard Fish wrote:
>  
>
>>Joseph wrote:
>>
>>    
>>
>>>I was trying to run this Red Hat memtest.sh script.
>>>So I copied the linux.tar.gz (45Mb file) to /tmp directory.
>>>
>>>Though when I try to run the script as user it keeps complaining:
>>>mv: cannot stat `linux': No such file or directory
>>>mv: cannot stat `linux': No such file or directory
>>>
>>> 
>>>
>>>      
>>>
>>Does "tar -tzvf linux.tar.gz" show the top-level directory as "linux", 
>>or "linux-2....".  If the latter, do the following to make a suitable 
>>tar.gz for the script (it is easier than fixing the script!):
>>
>>tar -xzvf linux.tar.gz
>>mv "linux-*" linux
>>tar -czvf linux.tar.gz linux
>>
>>HTH
>>-Richard
>>    
>>
>
>That did it.
>Though it complained when I did 
>mv "linux-*" linux 
>it wanted full dir name:
>mv linux-2.6.12 linux
>
>  
>

Sorry, my bad.  I should have left out the quotation marks.

>This test is running right now on my main server, 
>though when I try to run it on the new box it keeps complaining:
>-bash: ./memtest.sh: /bin/bash2: bad interpreter: No such file or
>directory
>
>On both boxes the I have bash-3.0 so what is it looking for?
>  
>

Ok, in this case it is an easy change to the script.  The first line says:

#!/bin/bash2

Change it to "#!/bin/bash" (without the quotation marks.. ;->)

-Richard

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Robert Crawford]

On Saturday 23 July 2005 03:43 am, Joseph wrote:
> So, I borrowed two good memory sticks from my backup server, and the new
> box is happy so far, compiled some kind of 27Mb lib-file without any
> kernel panic.
>
> I would like to run this Red-Hat memtest.sh script on these two stick,
> but I'm missing something (I'm not that good in reading the scripts :-/
> Can anybody have a pick at it and tell me what is it looking for?
>
> --
> #Joseph

This looks very promising- if you keep on compiling things without any more 
kernel panics, bad ram must have been the problem all along, and not the cpu 
heating issue.  I'd try a big compile of 2-3 hours just to check.

Don't know about the Red-Hat memtest script, but isn't there a memtest kernel 
on the Gentoo universal install disk you could boot from, and do the full 
test? 

Robert
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [New Development] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Richard Fish]

Joseph wrote:

>I went back to Sata Drive and started from scratch and when I tried to
>do "emerge --sync"  I got this error:
>
>"Uhhuh. HMI received. Dazed and confused, but trying to continue 
>You probably have a hardware problem with your RAM chips
>NMI: IOCK error (debug interrupt?)
>CPU 0
>Modules linked in: evdev via_rhine mii parport_pc parport ahci sata_uli
>sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil sata_promis libata
>sbp2 ohci1934 ieee1394 usb_storage ohci_hcd uhci_hcd ehci_hcd usbcore
>Pid: 5626, comm: rsync Not tainted 2.6.11-gentoo-r3-k8
>RIP: 0010:[<ffff....."
>
>Is it problem with my standard memory or CPU memory cache?
>I'v run memtest86 two day ago and 17-passes went without any errors.
>  
>

Does your BIOS have any options for memory timings?  If so, maybe you 
can try to back those off to more conservative values.

Memtest86 would probably not show a problem with memory timings, because 
it works in a very linear fasion.  Compiling or heavy IO (like you get 
with emerge --sync) accesses memory in a very random order.

-Richard
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: [Update] - was 1.) Kernel panic - not syncing: Aiee, killing interupt handler

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Fri, 22 Jul 2005 21:32:19 -0400, Robert Crawford wrote:

> OK- if it doesn't happen during light computing stuff, and only with
> very cpu intensive stuff like compiling, I feel virtually certain it is
> a cpu heat issue.  IMHO, there's not really any other reasonable
> explanation. 

A duff power supply? That would also tend to suffer under heavy load.


-- 
Neil Bothwick

I must have slipped a disk; my pack hurts.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Tero Grundström]

On Wed, 20 Jul 2005, Joseph wrote:

> I wasn't thinking about masking KDE but gcc-3.4.1 on AMD64 platform and
> make stable 3.3 version.  I run onto one posting claiming that there is
> some kind of bug in gcc-3.4.1 (and this version is the only stable
> version on AMD64.

I think that if you use cutting edge hardware you also need to use 
cutting edge software. For example the newer your kernel, the better 
support it probably has for your hardware.

It is the same with gcc, the newer the version the better your chances 
that issues with new processors like amd64 are fixed. It's building the 
code for your processor after all.

Consequently, you also need to use the newest software versions as they 
often have bugs fixed in order to support that new gcc...

--
T.G.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] 1.) Kernel panic - not syncing: Aiee, killing interupt handler; 2.) kdebase-3.4.1-r1 failed

[Christian Fischer]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

Am Thursday 21 July 2005 04:08 schrieb Joseph:
> I have a brand new (conservative box) AMD64 3000, Sata Drive with Asus
> AV8,
> I have two problems:
>
> 1.) Kernel panic - not syncing: Aiee, killing interupt handler.
> It appear during every few hours during compiling, I've seen other folks
> having the same problem but no solution.

Sorry, I've seen this thread to late to be just in time.
This is just for information.
I've installed my box completely new.
CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe"
Kernel 2.6.12-gentoo-r4 and r6
I got "Kernel panic - not syncing: Fatal exception in interrupt" by mounting 
the scsi-cdrom.
I took the same configuration like the old system, was 2.6.9-ac9.
I've testet 2.6.11-ac7 with the same config, works pretty well.

Regards
Christian


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]