Mount of root fs oopses on AMD K6, kernel option 'splash' did it...

Bug #8139 reported by Robin Elfrink
6
Affects Status Importance Assigned to Milestone
util-linux (Ubuntu)
Fix Released
Low
Herbert Xu

Bug Description

After successfull install of Ubuntu 4.10 PR system stops at boot while trying to
mount root. When removing the 'splash' kernel boot option from
/boot/grub/menu.lst the system boots fine. I do not see how 'splash' is related
to 'mount'.

Here's all I could find on the screen. Had to type it over by hand :)

---------------------------------
  Booting 'Ubuntu, kernel 2.6.8.1-2-386 '

root (hd0,4)

 Filesystem type is jfs, partition type 0x83

kernel /boot/vmlinuz-2.6.8.1-2-386 root=/dev/hda5 ro quiet splash

   [Linux-bzImage, setup=0x1400, size=0x109997]

initrd /boot/initrd.img-2.6.8.1-2-386

   [Linux-initrd @ 0x1fba9000, 0x437000 bytes]

savedefault

boot

Uncompressing Linux... Ok, booting the kernel.

Unable to handle kernel NULL pointer dereference at virtual address 0000000c

 printing eip:

*pde = 00000000

Oops: 0000 [#1]

PREEMPT

Modules linked in:

CPU: 0

EIP: 0060:[<c024bd90>] Not tainted

EFLAGS: 00010002 (2.6.8.1-2-386)

EIP is at __down+0x44/0xef

eax: 00000008 ebx: 00000286 ecx: dfaffe18 edx: dfafe000

esi: 00000000 edi: dfaffe20 ebp: dfedc600 esp: dfaffe0c

ds: 007b es: 007b ss: 0068

Process mount (pid: 193, threadinfo=dfafe000 task=dfedc600)

Stack: 00000001 dfedc600 c01161e1 00000000 00000000 00000001 00000000 00000282

       c13f6ce0 c028d8c0 dfb67000 0039d524 c024bf64 00000000 000009f2 1fb67000

       c017fb99 dfb92200 00000000 c13f6ce0 df99c718 00000000 dfb72420 c012dfdf

Call Trace:

 [<c01161e1>] default_wake_function+0x0/0x12

 [<c024bf64>] __down_failed+0x8/0xc

 [<c017fb99>] .text.lock.inode+0x7d/0x8c

 [<c012dfdf>] page_cache_read+0x53/0xb7

 [<c012e20b>] filemap_nopage+0x1c8/0x30d

 [<c013943a>] do_no_page+0xa6/0x2cf

 [<c0139797>] handle_mm_fault+0x6c/0x125

 [<c0114c0d>] do_page_fault+0x14d/0x49f

 [<c0143eb4>] filp_open+0x41/0x49

 [<c0157844>] dput+0x1a/0x1cc

 [<c0145675>] __fput+0xd5/0xf8

 [<c0144293>] filp_close+0x5a/0x63

 [<c0114ac0>] do_page_fault+0x0/0x49f

 [<c0106a1d>] error_code+0x2d/0x38

Code: 8b 50 04 89 44 24 0c 89 48 04 89 0a 89 54 24 10 ff 46 04 8b

 <6>note: mount[193] exited with preempt_count 1

Revision history for this message
Matt Zimmerman (mdz) wrote :

Very strange. I am quite confident that the 'splash' parameter should not have
any effect on the kernel at all, apart from the command line having an extra
parameter to ignore.

Can you add the 'splash' parameter back, and see if the crash returns?

Revision history for this message
Robin Elfrink (wobin) wrote :

(In reply to comment #1)

> Can you add the 'splash' parameter back, and see if the crash returns?

I did, still crashes. Maybe it is more fs related than cpu, splash scripts
probably just trigger something.

I have root on jfs. I'll go try another fs next.

Revision history for this message
Matt Zimmerman (mdz) wrote :

The "splash" parameter has only one effect, which is to suppress the "INIT
<version> booting" message from init. It certainly should not be causing your
kernel to panic.

Revision history for this message
Robin Elfrink (wobin) wrote :

I tried some other fs'es. ext3 is ok, xfs stalls at grub install before the
first reboot, reiserfs is ok. Must be something in the kernel I guess. I got
oops on sarge with 2.6.8 from sid as well on another k6, though I cannot
remember what oopsed.

Revision history for this message
Matt Zimmerman (mdz) wrote :

Is the bug triggered if you add "xxxxx" in place of splash (or some other string
of the same length in the same position)?

Revision history for this message
Herbert Xu (herbert-gondor) wrote :

(In reply to comment #5)
> Is the bug triggered if you add "xxxxx" in place of splash (or some other string
> of the same length in the same position)?

The bug is two-fold.

The direct cause is that e2fsprogs script again. It's causing every FS's probe
routine to be run. And sure enough one of them (cramfs) was buggy enough to crash.

So let's just remove the e2fsprogs script. We should also open a bug report in
upstream's Bugzilla about cramfs crashing while mounting a jfs filesystem.
Granted we shouldn't be mounting it in the first place, but it probably
shouldn't crash like this.

Revision history for this message
Matt Zimmerman (mdz) wrote :

OK, in this case, the problem is avoided by the new e2fsprogs:

e2fsprogs (1.35-6ubuntu1) warty; urgency=low

  * Remove ext3-add-journal.sh script. It overcomplicates the initrd setup,
    and the only problem it solves is to prevent a visible /.journal

 -- Matt Zimmerman <email address hidden> Sun, 19 Sep 2004 09:43:14 -0700

Will you file the cramfs bug upstream?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.