Hi folks,

I just ran into the following problem: Having updated my box to 2.6.12.3, 
I tried to start YaST2 and noticed a kernel panic (see below). Some quick
debugging brought the result that the kernel crashes while some user (not
even root ...) tries to access /proc/ioports. Is this a known problem and
if so, is a fix available?

Ooops and ksymoops-output is attached.

=============
Oops
=============

Unable to handle kernel paging request at virtual address e081e6a8
 printing eip:
c01d16b2
*pde = 1ff5b067
*pte = 00000000
Oops: 0000 [#1]
Modules linked in: snd_mixer_oss snd radeon drm dm_mod autofs4 af_packet ext3 jbd i810_audio ac97_codec soundcore b44 mii intel_agp agpgart i2c_i801 i2c_core ipw2200 firmware_class ieee80211 ieee80211_crypt parport_pc parport 8250 serial_core usbhid ohci_hcd uhci_hcd pcmcia yenta_socket rsrc_nonstatic pcmcia_core video thermal processor fan container button battery ac genrtc unionfs loop sbp2 ohci1394 ieee1394 usb_storage ub ehci_hcd usbcore
CPU:    0
EIP:    0060:[<c01d16b2>]    Not tainted VLI
EFLAGS: 00210297   (2.6.12.3) 
EIP is at vsnprintf+0x332/0x4d0
eax: e081e6a8   ebx: 0000000a   ecx: e081e6a8   edx: fffffffe
esi: c71760e9   edi: 00000000   ebp: c7176fff   esp: c457deb4
ds: 007b   es: 007b   ss: 0068
Process cat (pid: 3275, threadinfo=c457c000 task=c5052020)
Stack: c71760e2 c7176fff 00000323 00000000 00000010 00000004 00000002 00000001 
       ffffffff ffffffff c4f7d640 c031f3ad c4f7d640 000000dd c01789c7 c71760dd 
       00000f23 c03265ef c457df2c c03265dd c011e934 c4f7d640 c03265dd 00000000 
Call Trace:
 [<c01789c7>] seq_printf+0x37/0x60
 [<c011e934>] r_show+0x84/0x90
 [<c01784c6>] seq_read+0x1d6/0x2d0
 [<c0158b85>] vfs_read+0xe5/0x160
 [<c0158ea1>] sys_read+0x51/0x80
 [<c0102f79>] syscall_call+0x7/0xb
Code: 00 83 cf 01 89 44 24 24 eb bb 8b 44 24 48 8b 54 24 20 83 44 24 48 04 8b 08 b8 ec 2b 33 c0 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 83 e7 10 89 c3 75 20 

=============
Ksymoops
=============

>>EIP; c01d16b2 <vsnprintf+332/4d0>   <=====

>>eax; e081e6a8 <pg0+203236a8/3fb03400>
>>ecx; e081e6a8 <pg0+203236a8/3fb03400>
>>edx; fffffffe <__kernel_rt_sigreturn+1bbe/????>
>>esi; c71760e9 <pg0+6c7b0e9/3fb03400>
>>ebp; c7176fff <pg0+6c7bfff/3fb03400>
>>esp; c457deb4 <pg0+4082eb4/3fb03400>

Trace; c01789c7 <seq_printf+37/60>
Trace; c011e934 <r_show+84/90>
Trace; c01784c6 <seq_read+1d6/2d0>
Trace; c0158b85 <vfs_read+e5/160>
Trace; c0158ea1 <sys_read+51/80>
Trace; c0102f79 <syscall_call+7/b>

This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.

Code;  c01d1687 <vsnprintf+307/4d0>
00000000 <_EIP>:
Code;  c01d1687 <vsnprintf+307/4d0>
   0:   00 83 cf 01 89 44         add    %al,0x448901cf(%ebx)
Code;  c01d168d <vsnprintf+30d/4d0>
   6:   24 24                     and    $0x24,%al
Code;  c01d168f <vsnprintf+30f/4d0>
   8:   eb bb                     jmp    ffffffc5 <_EIP+0xffffffc5>
Code;  c01d1691 <vsnprintf+311/4d0>
   a:   8b 44 24 48               mov    0x48(%esp),%eax
Code;  c01d1695 <vsnprintf+315/4d0>
   e:   8b 54 24 20               mov    0x20(%esp),%edx
Code;  c01d1699 <vsnprintf+319/4d0>
  12:   83 44 24 48 04            addl   $0x4,0x48(%esp)
Code;  c01d169e <vsnprintf+31e/4d0>
  17:   8b 08                     mov    (%eax),%ecx
Code;  c01d16a0 <vsnprintf+320/4d0>
  19:   b8 ec 2b 33 c0            mov    $0xc0332bec,%eax
Code;  c01d16a5 <vsnprintf+325/4d0>
  1e:   81 f9 ff 0f 00 00         cmp    $0xfff,%ecx
Code;  c01d16ab <vsnprintf+32b/4d0>
  24:   0f 46 c8                  cmovbe %eax,%ecx
Code;  c01d16ae <vsnprintf+32e/4d0>
  27:   89 c8                     mov    %ecx,%eax
Code;  c01d16b0 <vsnprintf+330/4d0>
  29:   eb 06                     jmp    31 <_EIP+0x31>

This decode from eip onwards should be reliable

Code;  c01d16b2 <vsnprintf+332/4d0>
00000000 <_EIP>:
Code;  c01d16b2 <vsnprintf+332/4d0>   <=====
   0:   80 38 00                  cmpb   $0x0,(%eax)   <=====
Code;  c01d16b5 <vsnprintf+335/4d0>
   3:   74 07                     je     c <_EIP+0xc>
Code;  c01d16b7 <vsnprintf+337/4d0>
   5:   40                        inc    %eax
Code;  c01d16b8 <vsnprintf+338/4d0>
   6:   4a                        dec    %edx
Code;  c01d16b9 <vsnprintf+339/4d0>
   7:   83 fa ff                  cmp    $0xffffffff,%edx
Code;  c01d16bc <vsnprintf+33c/4d0>
   a:   75 f4                     jne    0 <_EIP>
Code;  c01d16be <vsnprintf+33e/4d0>
   c:   29 c8                     sub    %ecx,%eax
Code;  c01d16c0 <vsnprintf+340/4d0>
   e:   83 e7 10                  and    $0x10,%edi
Code;  c01d16c3 <vsnprintf+343/4d0>
  11:   89 c3                     mov    %eax,%ebx
Code;  c01d16c5 <vsnprintf+345/4d0>
  13:   75 20                     jne    35 <_EIP+0x35>

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss@madkiss.org        madkiss@debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/