Re: 2.2.19 Crash Help, please

2001-05-11 Thread Collectively Unconscious

Ah, the very tail end of an oops.

That explains it, I've never had one so long that everything else had 
scrolled off the screen. 2.2.x has been stable enough that I only have 
gotten a kernel oops from hardware errors, mainly when I get an nmi from
bad memory so I've never had to worry about decoding before this.

I like that in an OS, thanks! :)

For the curious, here it is decoded:

[<8010997c>]
Code: 8b 4a 04 85 c9 74 22 8b 5a 18 8b 02 89 01 8b 0a 85 c9 74 08

Code:   Before first symbol <_IP>: <===
Code:   Before first symbol   0:8b 4a 04
movl   0x4(%edx),%ecx <===
Code:  0003 Before first symbol   3:85 c9
testl  %ecx,%ecx
Code:  0005 Before first symbol   5:74 22
je  0029 Before first symbol
Code:  0007 Before first symbol   7:8b 5a 18
movl   0x18(%edx),%ebx
Code:  000a Before first symbol   a:8b 02
movl   (%edx),%eax
Code:  000c Before first symbol   c:89 01
movl   %eax,(%ecx)
Code:  000e Before first symbol   e:8b 0a
movl   (%edx),%ecx
Code:  0010 Before first symbol  10:85 c9
testl  %ecx,%ecx
Code:  0012 Before first symbol  12:74 08
je  001c Before first symbol


We're going to test that machine and see if we can reproduce it. If we
can, my first suspect is a hardware error since we have several
indentical machines which aren't getting this oops.

Jay

On Fri, 11 May 2001, Erik Mouw wrote:

> On Fri, May 11, 2001 at 07:32:41AM -0500, Collectively Unconscious wrote:
> > I had an NFS server crash in an unfamiliar way.
> > 
> > 2.2.19 smp 2xPIII 450 
> > 
> > The screen was filled with varitions of [<8010997c>] and at the bottom of
> > the screen was the following:
> > 
> > Code: 8b 4a 04 85 c9 74 22 8b 5a 18 8b 02 89 01 8b 0a 85 c9 74 08
> > 
> > Can anyone clue me in on this?
> 
> You have to decode the Oops to make it useful. See the files
> REPORTING-BUGS and Documentation/oops-tracing.txt in the kernel source
> tree.
> 
> 
> Erik
> 
> PS: Instead of *replying* to an existing thread, you'd better *start* a
> new thread ("compose" instead of "reply"). If I killed the "write
> to dvd ram" thread I wouldn't have seen your message at all.
> 
> -- 
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
> of Electrical Engineering, Faculty of Information Technology and Systems,
> Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
> Phone: +31-15-2783635  Fax: +31-15-2781843  Email: [EMAIL PROTECTED]
> WWW: http://www-ict.its.tudelft.nl/~erik/
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



2.2.19 Crash Help, please

2001-05-11 Thread Collectively Unconscious

I had an NFS server crash in an unfamiliar way.

2.2.19 smp 2xPIII 450 

The screen was filled with varitions of [<8010997c>] and at the bottom of
the screen was the following:

Code: 8b 4a 04 85 c9 74 22 8b 5a 18 8b 02 89 01 8b 0a 85 c9 74 08

Can anyone clue me in on this?

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: Wrong free inodes count in kernels 2.0 and 2.2

2001-05-02 Thread Collectively Unconscious


On Wed, 2 May 2001, [iso-8859-1] Samuli Kärkkäinen wrote:

> I get repeatably both in 2.0 and 2.2 serieses of kernels the following kind
> of errors:
> 
> 2.2 kernels (several, including 2.2.18):
>   EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes 
>count in group 768, stored = 984, counted = 717
>   EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes 
>count in group 769, stored = 1005, counted = 717
>   EXT2-fs error (device ide1(22,6)): ext2_check_inodes_bitmap: Wrong free inodes 
>count in group 777, stored = 998, counted = 901
>   [ many similar lines deleted ]
> 
> and sometimes with 2.2 kernel, soon after the errors above:
>   EXT2-fs error (device ide1(22,1)): ext2_new_inode: Free inodes count corrupted in 
>group 414 
>   last message repeated 795 times

We were getting this error on 4 of our arrays. We weren't able to track
down the original error, but the continuing problem turned out to be that
in "correcting" the errors fsck did not restore the drive to a stable
state and it would eventually corrupt itself again. 

If this is the same problem, force fsck until it no longer finds any
errors on the drive.

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



[OT] linux on pda was Re: [PATCH] Single user linux

2001-04-27 Thread Collectively Unconscious

On Fri, 27 Apr 2001, Robert Varga wrote:

> On Wed, Apr 25, 2001 at 10:34:56AM +1000, Daniel Stone wrote:
> > On Wed, Apr 25, 2001 at 01:16:03AM +0100, Alan Cox wrote:
> > > > > Quit being a naysayer. UNIX on a PDA is a wet dream.
> > > > What real value does it have, apart from the geek "look at me, I'm using
> > > > bash" value?

Hmm...How about free and open source, uniform app base, easy access by
third party vendors.

Also it seems to me last I checked PDA's were at least equvalent to the
386 which is ostensibly the bottom linux rung.

As for the objection about slow compile times, get real. No PDA is going
to compile anything. All compilations happen on your desktop with a
crosscompiler. PDA's are for running handy little apps, not development
work.

Or are we saying M$ CE is as good as it gets. :P

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: BUG: USB/Reboot

2001-04-27 Thread Collectively Unconscious

On Tue, 24 Apr 2001, Alan Cox wrote:

> > If USB is disabled on a server works MB reboots hang in 2.2.x
> 
> In almost all cases a hang after Linux reboots the system and it not coming
> back to the BIOS is a BIOS bug.
> 
> You can confirm this by asking the kernel to do a real bios reboot with
> the reboot= option
> 
For those besides me who were wondering where this is documented, 
find . ! -type d ! -type l -exec grep "reboot=" {} \; -print
of /usr/src/linux revealed that it is only documented in
./Documentation/Changes

Here is the pertinant paragraph:

General Information
===

now performs a cold reboot instead of a warm reboot
for increased hardware compatibility.  If you want a warm reboot and
know it works on your hardware, add a "reboot=warm" command line option
in LILO.  A small number of machines need "reboot=bios" to reboot via
the BIOS.

Note that ./Documentation/kernel-parameters.txt only contains:
reboot= [BUGS=ix86]

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Re: BUG: USB/Reboot

2001-04-25 Thread Collectively Unconscious

I'm not familiar with that option, where would I be setting it? Or even
better, where is it documented?

I'll inform server works of this problem.

Thanks,
Jay

On Tue, 24 Apr 2001, Alan Cox wrote:

> > If USB is disabled on a server works MB reboots hang in 2.2.x
> 
> In almost all cases a hang after Linux reboots the system and it not coming
> back to the BIOS is a BIOS bug.
> 
> You can confirm this by asking the kernel to do a real bios reboot with
> the reboot= option
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



BUG: USB/Reboot

2001-04-24 Thread Collectively Unconscious

If USB is disabled on a server works MB reboots hang in 2.2.x

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Kernel Panic 2.2.19pre11

2001-03-09 Thread Collectively Unconscious

On Tyan Thunderbird 2510 MBd with server works le bios and dual eepro100
82559 nics running 2.2.19pre11 and either Donald's driver 1.13 or intel's
driver 1.5.5a we get the following kernel panic after about 6 hrs of run:

Kernel panic:
shput: under: 
80194fa2:1480
put:584

This is not running with the nics bonded.

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



Reboot fails 2.2.19pre11 SMP

2001-03-09 Thread Collectively Unconscious

Using a server works le bios and kernel 2.2.19pre11 SMP
we get the following message at the end of any reboot attempt (including
the magic alt-sysrq-b):

Disabling symmetric IO mode ... ... done

and then the system freezes requiring a manual reset.

Since we are looking at 100 of these to expand our cluster, it is a non
trivial annoyance, any help would be appreciated.

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



I/O problem with sustained writes

2001-03-02 Thread Collectively Unconscious

We are having a problem with writes.
They start at 14 M/s for the first hour and then drop to 2.5 M/s and stay
that way. Reads do not seem effected and we've noticed this on the 2.2.16,
2.2.17, 2.2.18 and now the 2.2.19pre11 kernels.

These are SMP P-IIIs from 450 to 800 MHz. Redhat 6.2

Jay

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/