mmu_context_overflow

mmu_context_overflow

[Geert Uytterhoeven]

I found this in my kernel message log:

| mmu_context_overflow

running 2.4.1 from January 31 on a CHRP LongTrail with 604e.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mmu_context_overflow

[Dan Malek]

Geert Uytterhoeven wrote:
>
> I found this in my kernel message log:
>
> | mmu_context_overflow
>
> running 2.4.1 from January 31 on a CHRP LongTrail with 604e.

I'm assuming this occurred just once.  It's really no big deal
(except it is a one-time overhead to invalidate all contexts).
If it continues to happen, let me know and I'll ask for more
system information.

Thanks.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mmu_context_overflow

[christopher.murtagh]

On Thu, 15 Feb 2001, Dan Malek wrote:
>Geert Uytterhoeven wrote:
>>
>> I found this in my kernel message log:
>>
>> | mmu_context_overflow
>>
>> running 2.4.1 from January 31 on a CHRP LongTrail with 604e.
>
>I'm assuming this occurred just once.  It's really no big deal
>(except it is a one-time overhead to invalidate all contexts).
>If it continues to happen, let me know and I'll ask for more
>system information.

 I just saw this message for the first time on one of my machines (G4/450)
as well. I've been getting a lot of 'eth0: transmit timed out, resetting'
which would freeze the network in kernel 2.2.17 (I'm now running 2.2.18,
which seems to survive it). My machine is taking on about 120,000 http
requests per hour though and there doesn't seem to be any effect on the
performance. Is this something I should worry about?

 Any info would be much appreciated.

Cheers,

Chris

http://www.mcgill.ca/secretaboutbox/
--

Christopher Murtagh
Webmaster / Web Communications Group
McGill University
Montreal, Quebec
Canada


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mmu_context_overflow

[Benjamin Herrenschmidt]

> I just saw this message for the first time on one of my machines (G4/450)
>as well. I've been getting a lot of 'eth0: transmit timed out, resetting'
>which would freeze the network in kernel 2.2.17 (I'm now running 2.2.18,
>which seems to survive it). My machine is taking on about 120,000 http
>requests per hour though and there doesn't seem to be any effect on the
>performance. Is this something I should worry about?
>
> Any info would be much appreciated.

No, I don't think you should worry about these. those messages simply
need that the kernel ran out of VSIDs and had to re-assign them all. It's
perfectly harmless as long as it doesn't happen too often.

I'm more concerned about your network problems however. I beleive the
chip is a GMAC chip with a 5201 PHY (can you confirm ?). With 2.2.18, you
should not have transmit timeouts. If you have some, then there's either
a bug in the driver (which seemed to be rock-solid so far) or, we are
hitting a HW issue.

Does the gmac driver display some version informations when the kernel boots ?

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mmu_context_overflow

[christopher.murtagh]

On Thu, 15 Feb 2001, Benjamin Herrenschmidt wrote (regarding mmu
overflow):
>No, I don't think you should worry about these. those messages simply
>need that the kernel ran out of VSIDs and had to re-assign them all. It's
>perfectly harmless as long as it doesn't happen too often.

Thanks very much for the info Ben. So far I have only seen it once. Knock
on wood.

regarding eth0 transmit timeouts:
>I'm more concerned about your network problems however. I beleive the
>chip is a GMAC chip with a 5201 PHY (can you confirm ?). With 2.2.18,
>you should not have transmit timeouts. If you have some, then there's
>either a bug in the driver (which seemed to be rock-solid so far) or, we
>are hitting a HW issue.
>
>Does the gmac driver display some version informations when the kernel boots ?

Here is the info I pulled out of my last boot log:

eth0: GMAC at 00:30:65:44:e2:ee, driver v1.3k2
eth0 PHY ID: 0x00406212
eth0 Found Broadcom BCM5201 PHY

 I usually get 3 of these a day, sometimes 2, sometimes 4, mostly they
coincide with really high traffic periods (150k http request per hour -
this server is 99% http traffic), but I have had some at what seem to be
low traffic periods (but this is rare).

 I haven't seen this on any of our other G4s, but none of them are taking
on anywhere near that amount of traffic. Do you suspect it might be a
hardware problem with this particular machine?

Cheers,

Chris

info about the machine: http://www.mcgill.ca/secretaboutbox/

--

Christopher Murtagh
Webmaster / Web Communications Group
McGill University
Montreal, Quebec
Canada


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: mmu_context_overflow

[Benjamin Herrenschmidt]

> I usually get 3 of these a day, sometimes 2, sometimes 4, mostly they
>coincide with really high traffic periods (150k http request per hour -
>this server is 99% http traffic), but I have had some at what seem to be
>low traffic periods (but this is rare).
>
> I haven't seen this on any of our other G4s, but none of them are taking
>on anywhere near that amount of traffic. Do you suspect it might be a
>hardware problem with this particular machine?

Well, it's possible that it's an HW bug. I also suspect a software bug
that was fixed, but AFAIK, 1.3 is ok. If the driver manages to reset the
PHY and continue to operate properly, then things are nice. I'll still,
on my side, check for possible race conditions in the ring Tx code when
load is really high.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/