Bug 52575

Created attachment 29554 [details]
This is data that I was able to copy down after one of the events, all other events spew similar data

Is this the 2.4.6-3.1 or 2.4.7-2 kernel ?

This is the 2.4.7-2 kernel, Roswell Beta 2

Does it still do this if you boot with "apm=off" on the commandline of the
kernel ?

Is this the vaio with the Athlon/Duron CPU ?

Sorry but I'm unable to try the "apm=off" thing had to get my laptop ready for
work Monday...

Also yes this laptop has the Duron CPU, /proc/cupinfo follows:

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 6
model		: 3
model name	: AMD Duron(tm) Processor
stepping	: 1
cpu MHz		: 800.052
cache size	: 64 KB
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips	: 1595.80

Same problem.

Athlon 1.33Ghz/266

KT7A-RAID, two hard disks, one on /dev/hde (seawolf) and /dev/hdg (roswell),
CDRW on /dev/hda. Note, mobo BIOS is latest -- 3R. Disks are not in a RAID
configration, merely using the controller.

This was the original release,  I wasn't aware if Beta 2 included new ISO's or
everything was via up2date. 

Note that this is a new system configuration and upgrading kernels on the 7.1
disk is giving me the same problem, ie kernel panic on startup. The default 7.1
kernel works fine. Only uprades causing the kernel panic. I believe this is a
kernel RAM disk issue, though I've never had to run mkinitrd before.  

cnkeller: did you upgrade to the i686 or to the athlon kernel ?

arjanv:

Roswell: since it doesn't boot, I haven't upgraded anything obviously, nor have
I burned any copies of the newer roswell releases. This appears to be a kernel
or filesystem based problem.

On 7.1: i've tried 2.4.3 (failed) and 2.4.7-2 (failed).2.4.2 (default works fine).

It fails with LILO or GRUB and fails with or without a kernel ramdisk.

KT7A-RAID -- latest BIOS -- 3R
HPT370: two disks (/dev/hde & /dev/hdg non-RAID) with /dev/hda being a CDROM

The error message is along the following lines: 232k freed, unable to open file
system on /dev/hde, kernel panic, try passing init= to the kernel. This is with
a kernel ramdisk created. Note that on the working 2.4.2 kernel, no ram disk is
used.

If you need the exact error message, I can copy it down tonight.

Arjan, sorry also forgot to add something. On the roswell list, somone is seeing
the exact behavior I am with an Asus A7V. I guess the Highpoint controller and
Promise controllers are sharing the same code?

> the exact behavior I am with an Asus A7V. I guess the Highpoint controller and
> Promise controllers are sharing the same code?

They share most likely the same bug: the bios marks the disk as raid and is then
handled as raid partition, not a normal one.

However this is unrelated to the vaio oops I think.

Promise Fasttrak(tm) Softwareraid driver for linux version 0.02
No raid array found
Highpoint HPT370 Softwareraid driver for linux version 0.01
No raid array found


should be what the kernel says. If it DOES find arrays, you (or the bios) have
made raid partitions and then ignored them. Can you please check this ?

cnkeller: can you try the 2.4.3-17 kernel at
http://people.redhat.com/arjanv/testkernels ?
it's the same as 2.4.3-12 with one change I like to see if it makes a difference
(and with a reiserfs bug fixed)

I will check the kernel message regarding "No raid array found" as soon as I get
home tonight. I do not ever recall making a RAID, so if it does find the array,
it's news to me. :-) 

I will also download the 2.4.3-12 kernel tonight and get back to you guys ASAP.
It's starting to become apparent that this is a different bug than the VAIO,
should we open a new bug ID?

It sounds like cnkeller's problem is that same as 62651.

That's 52651 in case you were really confused (as I was).

Arjan,

Using the 2.4.3-17 kernel results in the following:

.
.
.
md.c: sizeof(mdp_super_t) = 4096
autodetecting RAID array
autorun...
...autorun DONE
NET4: Linux TCP/IP 1.0 for NET4.0
.
.
.
EXT2-fs: unable to read superblock
isofs_read_super: bread failed, dev21 :0a, iso_blknum=16, block=32
kernel panic: VFS: Unable to mount root fs on 21: 0a

Okay, compiled the 2.4.7-2 kernel from rawhide. I had very high hopes when I saw
the software RAID with HPT370 option. No dice, same result of being unable to
read the superblock of EXT-2. The error messages were similar to those on bug
52651. I tried with and without a kernel ramdisk. 

Also, it did print out the message "No raid array found" after the Highpoint
HPT370 message. 

Arjan,

Sorry for the long delay. I've been testing a few of your kernels from your
homepage. It seems that you've fixed the problem. What was the problem and I'm
assuming it will make it into the final 7.2? I believe the latest one I'm using
is -19. At any rate, this bug can now be closed from my point of view; though
turns out that my situation was a little different than the original report.

This sounds similar to a problem I am having.  I bought a Sony Vaio FXA32 last
night and 7.2 panics when the kernel loads.  Something about problem reading
virtual memory.  I loaded 7.1 and it works.  I can give more info but I would
have to load 7.2 and reload 7.1 etc. etc.  Let me know if you need me too.  This
is an AMD Duron.

Found this information which might be it.  Have to find time to try this.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.0/0048.html

I also found another person with this problem but no solution.
http://marc.theaimsgroup.com/?l=linux-kernel&m=100482241923313&w=2

Any ideas of where to go from here would be great or maybe someone already has
more info on this...

We're actually having the same problem with enigma on a PCG-FX215 (AMD Duron I
imagine). I'm guessing the way to solving it is with by using the i686 kernel?

Update: by passing "noathlon" on the kernel line, the machine booted fine.

Passing "noathlon" on the kernel line fixed my machine too, WooHoo!  Thanks
cnkeller.  I would think this will be a problem with all Sony Vaios (maybe
specific to Athlon chip).  I wonder if FX215 is really an Athlon or Intel
though, I was told FXA=AMD and FX=Intel.  

I'm not sure how cnkeller came across this fix but after many hours I never
found it till this thread and his post.  A search for "noathlon" on RH and
Google only turn up kernel release notes.  I wish I could make this information
more available as I'm sure it affects all Sony Vaio owners installing 7.2.

I'm a bit confused whether this problem relates to the original problem
submitted.  I think maybe something should be added to the RH 7.2 documentation
about this fix.

The noathlon _is_ in the documentation, in fact, it's even in the release notes
on every CD, and also in the release notes that you can view during the
installation ;(

unfortunately the installer kernel will not run on my new hardware. here is a
copy of the email i sent to the vallhalla-list

i will try passing the noathlon to the boot kernel and see if this corrects the
problem.


when i try to run the installer the kernel panics and of course shuts down.

my new system
tyan s2460 motherboard
dual athlon mp 1800+
lsi logic lsiu160 ultra 160 scsi card (64 bit pci)
4x 9 gig quantum disks
24x ide cdrom (master on primary ide controller)
dlink systems gigabit ethernet dge 500t (32 bit pci)
1 gig ram (registered ecc pc 2100 sdram)


in the bios all on board peripherals are turned off (both serial, all four usb,
parallel port, floppy, and secondary ide) except primary ide

the following is left on display when kernel panics (unfortunately i cannot
scroll back so this is all i could get):
pde=00000000
oops: 0000
cpu 0
eip: 0010:[<c011458e>] not tainted
eflags: 00010286
eip is at 2.4.18-3boot
eax:33eca000  ebx:c0265f18  ecx:f7ecbfa0  edx:c025dc08
esi:33eca000  edi:00000000  ebp:c026f28  esp:c0265f14
ds:0018  es:0018  ss:0018
process swapper pid:0   stack page=c0265000

stack
00000000    00000001    33eca000    c011e83c    00000000    c0265f38    c011469f
   33eca000
00000000    00000046    c011e6eb    33eca000    00000000    c0290e70    00000000
   00000046
c011b813    0011b749    00000000    00000001    c0290e80    fffffffe    c011b58
   c0290e80

call trace [<c011e83c>]
[<c011469f>]
[<c011e6eb>]
[<c011b813>]
[<c011b749>]
[<c011b58f>]
[<c01099b8>]
[<c0105000>]
[<c010bea8>]
[<c0106b74>]
[<c0105000>]
[<c0106b97>]
[<c0106bdc>]

code 8b 56 20 8d 04 d2 8d 04 c2 8d 04 42 c1 ed 04 8d 88 00 05 29

interrupt handler - not synching

i read in the errata and found that the 2.4.18-3 kernel has a race condition
that will cause a panic with ext3 filesystem. since i have nothing installed on
this machine yet i don't know if this is the problem.
i have downloaded the latest iso disk images but the checksum matches the last
image i downloaded so i don't believe the 2.4.18-4 kernel is included and
without an install i can't apply the patches.

 andreazaroff:that looks like a different issue :(

yes it is a different issue.

the noathlon parameter did nothing when passed to the installer kernel (thanks
for the email :( but i did read the docs prior to posting), as i suspected it
would not, since the docs all refer to a post install situation as is everyone
else commenting on this bug. i probably should have posted in another place or
not at all.

for whatever it is worth
i resolved the problem. it seems to have been hardware related. upon careful
observation i noticed the kernel panic allways happend at the same place in the
install right, right after it probed the scsi adapter for devices and found
them. there was a bunch of text that scrolled off of the screen that went by so
fast i could not see it clearly. i think it was related to the panic, though i
can not really say for sure.

one of two things could have resolved the problem since i did them at the same
time and the installer ran afterwards i really don't know which it was.


on the tyan motherboard there is a bios setting called "smp version". it can be
set to either 1.4 or 1.1. i changed the setting to 1.1 as the description stated
that some operating systems need the 1.1 setting to operate properly

i used the scsi setup utility to initialize all of my drives.
my guess would be the smp version, then again it may just have been coincidence.

since it installed  my system has been up for 5 days without a hiccup running an
athlon optimized kernel (no noathlon parameter).

Closing. Assuming the VIA chipset flaw worked around by all current errata