amd64 2.6.11 oops on modprobe

PATCH In review Andrei Mikhailovsky 6 participants 18 messages Mar 5, 2005 – May 25, 2005 Media (V4L/DVB)

lore

Share & tools

lore

Andrei Mikhailovsky

author

2005-03-05 12:11 UTC #0 lore raw

I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.

Here is the output from dmesg:

Unable to handle kernel paging request at ffffffff880db000 RIP: 
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] 
CPU 0 
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa sk98lin
Pid: 2604, comm: modprobe Not tainted 2.6.11-amd64

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff880db000 CR3: 000000003e125000 CR4: 00000000000006e0 Process modprobe (pid: 2604, threadinfo ffff81003f6c4000, task ffff81003ed59700)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
       ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44

RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP <ffff81003f6c5b78>
CR2: ffffffff880db000

If anyone need more debugging info, I am ready to help

Signature · 1 line

Andrei Mikhailovsky

Randy.Dunlap

2005-03-06 01:05 UTC #1 lore raw

Quoted 42 lines · Andrei Mikhailovsky

I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.

Here is the output from dmesg:

Unable to handle kernel paging request at ffffffff880db000 RIP: <ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] CPU 0 Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
       ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

Quoted 8 lines

+126}
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44 RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP
<ffff81003f6c5b78>
CR2: ffffffff880db000
If anyone need more debugging info, I am ready to help

Hm, not much change in that driver from 2.6.10.

Is this easily reproducible?
If so, please boot with "kstack=32" for more stack dump. And send me your saa7110.o (object) file since mine isn't like yours.

Signature · 3 lines

~Randy

darn, kstack= needs to be added to kernel-parameters.txt...

Andrei Mikhailovsky

author

2005-03-06 13:34 UTC #2 lore raw

Hi Randy,

Done the kstack=32, here is the output:

cat /proc/cmdline
root=/dev/hda2 ro kstack=32 console=tty0

P.S. Yeah, this oops is repeatable; hapens everytime

Output-----

Unable to handle kernel paging request at ffffffff880db000 RIP: 
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3de65067 PTE 0
Oops: 0000 [1] 
CPU 0 
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003e9a3b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff8100067713a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff810037277400 R14: ffff81003e4efe00 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff880db000 CR3: 000000003fa2b000 CR4: 00000000000006e0 Process modprobe (pid: 3213, threadinfo ffff81003e9a2000, task ffff81003e8096c0)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e4efe28 
       ffff002a0001004e ffff81003e9a3b78 ffff81003e4efe28
ffff810037277400 
       ffff81003e4efe00 0000000000000000 ffff81003e4eff70
ffffffff880bf808 
       ffffffff880d9930 ffffffff880d9ab4 0000000000000000
0000000000000000 
       000000000000004e 0000000000000000 000000000000004e
0000000000000003 
       ffffffff880dab60 ffffffff802f6812 0000000000000000
ffffffff880dab50 
       ffffffff880bf808 ffffffff880bf9a8 ffffffff880bf908
ffffffff80474f90 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44

RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP <ffff81003e9a3b78>
CR2: ffffffff880db000

---Output end---

If you need any further info, please let me know

--
Andrei

Quoted 63 lines · Randy.Dunlap

Quoted 48 lines · Andrei Mikhailovsky
I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.
Here is the output from dmesg:
Unable to handle kernel paging request at ffffffff880db000 RIP: 
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] 
CPU 0 
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv
libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa sk98lin
Pid: 2604, comm: modprobe Not tainted 2.6.11-amd64
RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff880db000 CR3: 000000003e125000 CR4: 00000000000006e0 Process modprobe (pid: 2604, threadinfo ffff81003f6c4000, task ffff81003ed59700)
Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
       ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call
+126}
Quoted 6 lines
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44 
RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP <ffff81003f6c5b78>
CR2: ffffffff880db000
If anyone need more debugging info, I am ready to help
Hm, not much change in that driver from 2.6.10.
Is this easily reproducible?
If so, please boot with "kstack=32" for more stack dump. And send me your saa7110.o (object) file since mine isn't like yours.

Randy.Dunlap

2005-03-07 04:05 UTC #3 lore raw

Quoted 7 lines · Andrei Mikhailovsky

Hi Randy,
Done the kstack=32, here is the output:
cat /proc/cmdline root=/dev/hda2 ro kstack=32 console=tty0
P.S. Yeah, this oops is repeatable; hapens everytime

Well thanks, I've looked thru this but I'm not getting anywhere on it. Also, there aren't many changes in this driver or in the relevant I2C drivers between 2.6.10 and 2.6.11 AFAICT.

If the maintainer(s) of this don't see/know the problem here, we'll have to ask you to do a binary search on the 2.6.11-rcN patches to see when this began. Would you do that, please?

Andrei, you don't have CONFIG_PREEMPT enabled, right? Just checking.

Quoted 124 lines

Output-----

Unable to handle kernel paging request at ffffffff880db000 RIP: <ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3de65067 PTE 0
Oops: 0000 [1] CPU 0 Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003e9a3b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff8100067713a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff810037277400 R14: ffff81003e4efe00 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e4efe28 
       ffff002a0001004e ffff81003e9a3b78 ffff81003e4efe28
ffff810037277400 
       ffff81003e4efe00 0000000000000000 ffff81003e4eff70
ffffffff880bf808 
       ffffffff880d9930 ffffffff880d9ab4 0000000000000000
0000000000000000 
       000000000000004e 0000000000000000 000000000000004e
0000000000000003 
       ffffffff880dab60 ffffffff802f6812 0000000000000000
ffffffff880dab50 
       ffffffff880bf808 ffffffff880bf9a8 ffffffff880bf908
ffffffff80474f90 Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44 RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP

<ffff81003e9a3b78>
CR2: ffffffff880db000

---Output end---

If you need any further info, please let me know

--
Andrei

Quoted 59 lines · Randy.Dunlap

Quoted 42 lines · Andrei Mikhailovsky
I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.
Here is the output from dmesg:
Unable to handle kernel paging request at ffffffff880db000 RIP: <ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] CPU 0 Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv
libata snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc i2c_nforce2 it87 eeprom i2c_sensor i2c_isa sk98lin
Pid: 2604, comm: modprobe Not tainted 2.6.11-amd64
RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff880db000 CR3: 000000003e125000 CR4: 00000000000006e0 Process modprobe (pid: 2604, threadinfo ffff81003f6c4000, task ffff81003ed59700)
Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
      0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
      ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
      <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
      <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
      <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
      <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
      <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
      <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call
Quoted 8 lines
+126}
Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44 RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP
<ffff81003f6c5b78>
CR2: ffffffff880db000
If anyone need more debugging info, I am ready to help
Hm, not much change in that driver from 2.6.10.
Is this easily reproducible?
If so, please boot with "kstack=32" for more stack dump. And send me your saa7110.o (object) file since mine isn't like yours.

Signature · 1 line

~Randy

Randy.Dunlap

2005-03-07 05:14 UTC #4 lore raw

In reply to Andrei Mikhailovsky

Quoted 7 lines · Andrei Mikhailovsky

Hi Randy,
Done the kstack=32, here is the output:
cat /proc/cmdline root=/dev/hda2 ro kstack=32 console=tty0
P.S. Yeah, this oops is repeatable; hapens everytime

I have one other request. Load each (related) module one at a time, to make sure that there is no module racing going on here.

Something like (but I'm not sure about the order of these modprobes):

echo /bin/true > /proc/sys/kernel/hotplug

modprobe zr36067
modprobe videocodec
modprobe zr36060
modprobe adv7175
modprobe saa7110

Quoted 115 lines

Output-----

Unable to handle kernel paging request at ffffffff880db000 RIP: <ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3de65067 PTE 0
Oops: 0000 [1] CPU 0 Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003e9a3b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff8100067713a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff810037277400 R14: ffff81003e4efe00 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e4efe28 
       ffff002a0001004e ffff81003e9a3b78 ffff81003e4efe28
ffff810037277400 
       ffff81003e4efe00 0000000000000000 ffff81003e4eff70
ffffffff880bf808 
       ffffffff880d9930 ffffffff880d9ab4 0000000000000000
0000000000000000 
       000000000000004e 0000000000000000 000000000000004e
0000000000000003 
       ffffffff880dab60 ffffffff802f6812 0000000000000000
ffffffff880dab50 
       ffffffff880bf808 ffffffff880bf9a8 ffffffff880bf908
ffffffff80474f90 Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44 RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP

<ffff81003e9a3b78>
CR2: ffffffff880db000

---Output end---

If you need any further info, please let me know

--
Andrei

Quoted 50 lines · Randy.Dunlap

Quoted 48 lines · Andrei Mikhailovsky

I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.

Here is the output from dmesg:

Unable to handle kernel paging request at ffffffff880db000 RIP: <ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] CPU 0 Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
      0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
      ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
      <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
      <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
      <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
      <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
      <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
      <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44 RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP

<ffff81003f6c5b78>
CR2: ffffffff880db000

Signature · 1 line

~Randy

Randy.Dunlap

2005-03-07 22:42 UTC #5 lore raw

In reply to Andrei Mikhailovsky

Quoted 7 lines · Andrei Mikhailovsky

Hi Randy,
Done the kstack=32, here is the output:
cat /proc/cmdline root=/dev/hda2 ro kstack=32 console=tty0
P.S. Yeah, this oops is repeatable; hapens everytime

Hi Andrei,

I've been working on this with Daniel Staaf and Jean Delvare. Jean enabled some more/different I2C bit banging code in 2.6.11, and that causes callers to use it differently.

Specifically, in saa7110_write_block() now does this first "if" block instead of the "else" block:

	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
		struct saa7110 *decoder = i2c_get_clientdata(client);
		struct i2c_msg msg;
		u8 block_data[54];

		msg.len = 0;
		msg.buf = (char *) block_data;
		msg.addr = client->addr;
		msg.flags = client->flags;
***		while (len >= 1) {
			msg.len = 0;
			block_data[msg.len++] = reg;
			while (len-- >= 1 && msg.len < 54)
				block_data[msg.len++] =
				    decoder->reg[reg++] = *data++;
			ret = i2c_transfer(client->adapter, &msg, 1);
		}
	} else {
		while (len-- >= 1) {
			if ((ret = saa7110_write(client, reg++,
						 *data++)) < 0)
				break;
		}
	}

The *** marked loop never terminates and keep incrementing <data> until the oops occurs. Making a copy of <len> as signed instead of unsigned is a temporary fix for this. Jean will be proposing a real patch for that obfuscated loop.

Signature · 1 line

~Randy

Jean Delvare

2005-03-08 19:24 UTC #6 lore raw

[Randy Dunlap]

Quoted 3 lines

I've been working on this with Daniel Staaf and Jean Delvare. Jean enabled some more/different I2C bit banging code in 2.6.11, and that causes callers to use it differently.

Actually credits go to Ian Campbell for noticing that i2c-algo-bit was reporting less capabilities than it should have. Fixing this uncovered the bug in the saa7110 driver as a side effect but still was the right thing to do (this will let i2c chip drivers use faster i2c transfer commands wherever possible.)

Quoted 1 line

Jean will be proposing a real patch for that obfuscated loop.

I'd like to add details on what exactly the problems were in the original code, in the hope it can help make my patch easier to understand. As a side note, this was by far the crapiest code I read for the last few months.

Here's the faulty code, with my comments:

	u8 reg = *data++;
	(...)
	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
		struct saa7110 *decoder = i2c_get_clientdata(client);
		struct i2c_msg msg;

*1* u8 block_data[54];

		msg.len = 0;
		msg.buf = (char *) block_data;
		msg.addr = client->addr;
*2*		msg.flags = client->flags;
		while (len >= 1) {
			msg.len = 0;
			block_data[msg.len++] = reg;
*3*			while (len-- >= 1 && msg.len < 54)
				block_data[msg.len++] =
*4*				    decoder->reg[reg++] = *data++;
*5*			ret = i2c_transfer(client->adapter, &msg, 1);
		}
	} (...)

1* This local buffer is not needed. The original buffer (pointed to by data) is already properly formated for an i2c_transfer message.

2* i2c message flags and i2c client flags are essentially different things [1], so this line doesn't make any sense. In fact, it happens that client->flags contains I2C_CLIENT_ALLOW_USE (0x01) which will be interpreted as I2C_M_RD as a message flag, resulting in an I2C block *read* command instead of the expected I2C block write command. So, oops or not, there is no chance this code would do anything useful [2].

3* The oops is here. When len == 0, the test will fail but len will still be decreased. Because len is unsigned, this will result in a huge positive value, so the outer while loop will not be exited as expected. One hundred iterations later the oops occurs. Mental note: mixing while loop condition with counter decrement sounds like a generally bad idea. The code here clearly yields for a clean for loop.

4* Note that reg is not reset in the outer while loop, so it can take any arbitrarily large value, while decoder->reg is only 54 bytes long. So there is a potential buffer overrun here. More generally, the code makes it look like a message of an arbitrarily long length can be properly handled (split in 54-byte chunks), while several details would actually make it fail. Also note that sending messages longer than the number of registers makes no sense anyway, so not only the double while loop is complex and broken, but it is also totally useless as far as I can see.

5* Return value is not properly handled.

Considering that this code has been in there since 2003-08-21 (2.6.0-test3-bk9), I find it quite frightening that nobody noticed how broken it was until yesterday. Another frightening fact is that the i2c-algo-bit change made the whole Zoran-based family of devices unusable for the past 3 months or so in -mm and maybe 1.5 month in -bk/-rc and nobody reported. As far as I know, these boards are rather popular. The fact that no user of such board actually tested -mm or -rc for this period of time points out a problem. (And I am not attempting to revive a flame war of any kind, nor am I blaming anyone in particular, merely pointing out what I think is a serious problem.)

So here is my patch:

drivers/media/video/saa7110.c renamed from drivers/media/video/saa7110.c.orig +17 ~~-18~~

@@ -58,10 +58,12 @@
 #define SAA7110_MAX_INPUT	9	/* 6 CVBS, 3 SVHS */
 #define SAA7110_MAX_OUTPUT	0	/* its a decoder only */
 
-#define	I2C_SAA7110		0x9C	/* or 0x9E */
+#define I2C_SAA7110		0x9C	/* or 0x9E */
+
+#define SAA7110_NR_REG		0x35
 
 struct saa7110 {
-	unsigned char reg[54];
+	unsigned char reg[SAA7110_NR_REG];
 
 	int norm;
 	int input;

@@ -95,31 +97,28 @@
 		     unsigned int       len)
 {
 	int ret = -1;
-	u8 reg = *data++;
+	u8 reg = *data;		/* first register to write to */
 
-	len--;
+	/* Sanity check */
+	if (reg + (len - 1) > SAA7110_NR_REG)
+		return ret;
 
 	/* the saa7110 has an autoincrement function, use it if
 	 * the adapter understands raw I2C */
 	if (i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
 		struct saa7110 *decoder = i2c_get_clientdata(client);
 		struct i2c_msg msg;
-		u8 block_data[54];
 
-		msg.len = 0;
-		msg.buf = (char *) block_data;
+		msg.len = len;
+		msg.buf = (char *) data;
 		msg.addr = client->addr;
-		msg.flags = client->flags;
-		while (len >= 1) {
-			msg.len = 0;
-			block_data[msg.len++] = reg;
-			while (len-- >= 1 && msg.len < 54)
-				block_data[msg.len++] =
-				    decoder->reg[reg++] = *data++;
-			ret = i2c_transfer(client->adapter, &msg, 1);
-		}
+		msg.flags = 0;
+		ret = i2c_transfer(client->adapter, &msg, 1);
+
+		/* Cache the written data */
+		memcpy(decoder->reg + reg, data + 1, len - 1);
 	} else {
-		while (len-- >= 1) {
+		for (++data, --len; len; len--) {
 			if ((ret = saa7110_write(client, reg++,
 						 *data++)) < 0)
 				break;

@@ -192,7 +191,7 @@
 	return 0;
 }
 
-static const unsigned char initseq[] = {
+static const unsigned char initseq[1 + SAA7110_NR_REG] = {
 	0, 0x4C, 0x3C, 0x0D, 0xEF, 0xBD, 0xF2, 0x03, 0x00,
 	/* 0x08 */ 0xF8, 0xF8, 0x60, 0x60, 0x00, 0x86, 0x18, 0x90,
 	/* 0x10 */ 0x00, 0x59, 0x40, 0x46, 0x42, 0x1A, 0xFF, 0xDA,

I could load the modified driver on my own DC10+ board (just plugged-in for the tests) without oops. Unfortunately I am not able to test it any further (crappy motherboad and lack of video source and tv set).

The idea of the patch is to keep everything simple because there is no reason to do otherwise, and add some checks to prevent buffer overruns. I would appreciate if people familiar with this video chip could check that my code does the correct thing. I would also appreciate if users of Zoran-based boards could test it and confirm it works OK.

Thanks.

[1] Actually I found that there is one common flag between client and message, but this is a bad idea IMHO and should never be relied upon outside of i2c-core.

[2] I found 5 other drivers with the same problem: adv7170, adv7175, bt819, saa7114, saa7185, all used by Zoran-based boards. I'll post a separate patch for these drivers.

Signature · 1 line

Jean Delvare

Jean Delvare

2005-03-08 19:34 UTC #7 lore raw

PATCH 1/1 Fix i2c messsage flags in video drivers

Hi all,

While working on the saa7110 driver I found a problem with the way various video drivers (found on Zoran-based boards) prepare i2c messages to be used by i2c_transfer. The drivers improperly copy the i2c client flags as the message flags, while both sets are mostly unrelated. The net effect in this case is to trigger an I2C block read instead of the expected I2C block write. The fix is simply not to pass any flag, because none are needed.

I think this patch qualifies hands down as a "critical bug fix" to be included in whatever bug-fix-only trees exist these days. As far as I can see, all Zoran-based boards are broken in 2.6.11 without this patch.

Signed-off-by Jean Delvare <[email protected]>

drivers/media/video/adv7170.c renamed from drivers/media/video.orig/adv7170.c +1 -1

diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/adv7170.c linux-2.6.11-bk3/drivers/media/video/adv7170.c
@@ -130,7 +130,7 @@
 		u8 block_data[32];
 
 		msg.addr = client->addr;
-		msg.flags = client->flags;
+		msg.flags = 0;
 		while (len >= 2) {
 			msg.buf = (char *) block_data;
 			msg.len = 0;

drivers/media/video/adv7175.c renamed from drivers/media/video.orig/adv7175.c +1 -1

diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/adv7175.c linux-2.6.11-bk3/drivers/media/video/adv7175.c
@@ -126,7 +126,7 @@
 		u8 block_data[32];
 
 		msg.addr = client->addr;
-		msg.flags = client->flags;
+		msg.flags = 0;
 		while (len >= 2) {
 			msg.buf = (char *) block_data;
 			msg.len = 0;

drivers/media/video/bt819.c renamed from drivers/media/video.orig/bt819.c +1 -1

diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/bt819.c linux-2.6.11-bk3/drivers/media/video/bt819.c
@@ -146,7 +146,7 @@
 		u8 block_data[32];
 
 		msg.addr = client->addr;
-		msg.flags = client->flags;
+		msg.flags = 0;
 		while (len >= 2) {
 			msg.buf = (char *) block_data;
 			msg.len = 0;

drivers/media/video/saa7114.c renamed from drivers/media/video.orig/saa7114.c +1 -1

diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/saa7114.c linux-2.6.11-bk3/drivers/media/video/saa7114.c
@@ -163,7 +163,7 @@
 		u8 block_data[32];
 
 		msg.addr = client->addr;
-		msg.flags = client->flags;
+		msg.flags = 0;
 		while (len >= 2) {
 			msg.buf = (char *) block_data;
 			msg.len = 0;

drivers/media/video/saa7185.c renamed from drivers/media/video.orig/saa7185.c +1 -1

diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/saa7185.c linux-2.6.11-bk3/drivers/media/video/saa7185.c
@@ -118,7 +118,7 @@
 		u8 block_data[32];
 
 		msg.addr = client->addr;
-		msg.flags = client->flags;
+		msg.flags = 0;
 		while (len >= 2) {
 			msg.buf = (char *) block_data;
 			msg.len = 0;

Signature · 1 line

Jean Delvare

Chris Wright

2005-03-09 18:46 UTC #8 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Quoted 10 lines · * Jean Delvare ([email protected]) wrote:

Hi all,
While working on the saa7110 driver I found a problem with the way various video drivers (found on Zoran-based boards) prepare i2c messages to be used by i2c_transfer. The drivers improperly copy the i2c client flags as the message flags, while both sets are mostly unrelated. The net effect in this case is to trigger an I2C block read instead of the expected I2C block write. The fix is simply not to pass any flag, because none are needed.

Quoted 3 lines

I think this patch qualifies hands down as a "critical bug fix" to be included in whatever bug-fix-only trees exist these days. As far as I can see, all Zoran-based boards are broken in 2.6.11 without this patch.

Are people reporting this as a problem?

Signature · 1 line

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Jean Delvare

2005-03-09 21:57 UTC #9 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Hi Chris,

Quoted 8 lines

Quoted 8 lines
While working on the saa7110 driver I found a problem with the way various video drivers (found on Zoran-based boards) prepare i2c messages to be used by i2c_transfer. The drivers improperly copy the i2c client flags as the message flags, while both sets are mostly unrelated. The net effect in this case is to trigger an I2C block read instead of the expected I2C block write. The fix is simply not to pass any flag, because none are needed.

Quoted 6 lines

Quoted 4 lines
I think this patch qualifies hands down as a "critical bug fix" to be included in whatever bug-fix-only trees exist these days. As far as I can see, all Zoran-based boards are broken in 2.6.11 without this patch.
Are people reporting this as a problem?

Not that I know. For adv7175 it couldn't be reported so far anyway because people would hit the oops in saa7110 before (same board: DC10+, oops fixed in a different patch).

It is possible that people are able to get their board to still work without my patch, if the chips were properly configured in the first place and they don't attempt to reconfigure them (like norm change). I don't know the chips well enough to tell how probable this is.

Thanks,

Signature · 1 line

Jean Delvare

Chris Wright

2005-03-09 23:29 UTC #10 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Quoted 6 lines · * Jean Delvare ([email protected]) wrote:

Quoted 2 lines
Are people reporting this as a problem?
Not that I know. For adv7175 it couldn't be reported so far anyway because people would hit the oops in saa7110 before (same board: DC10+, oops fixed in a different patch).

Heh, right.

Quoted 4 lines

It is possible that people are able to get their board to still work without my patch, if the chips were properly configured in the first place and they don't attempt to reconfigure them (like norm change). I don't know the chips well enough to tell how probable this is.

According to offlist mail, it does "fix a bug that bothers people." So looks like a fine candidate, and is queued up for -stable.

thanks,
-chris

Signature · 1 line

Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Ronald S. Bultje

2005-03-10 09:25 UTC #11 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

In reply to Jean Delvare

Hi Jean,

I'm sorry for a late reply, mail is (still) misbehaving. I hope this arrives at all...

Quoted 4 lines · Jean Delvare

It is possible that people are able to get their board to still work without my patch, if the chips were properly configured in the first place and they don't attempt to reconfigure them (like norm change). I don't know the chips well enough to tell how probable this is.

I'm pretty sure the patch is correct, I trust you a lot more on that than myself (I still need to test it, though; but that's a detail). However, this statement is not correct. I test this driver daily, I still own a whole bunch of such cards. Even after hard reboots, they still just work. Norm changes, input changes, everything works. I test (and use) all of this. I would've noticed if it was really as broken as you're describing above.

Ronald

Jean Delvare

2005-03-10 10:59 UTC #12 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Hi Ronald,

[Jean Delvare]

Quoted 4 lines

It is possible that people are able to get their board to still work without my patch, if the chips were properly configured in the first place and they don't attempt to reconfigure them (like norm change). I don't know the chips well enough to tell how probable this is.

[Ronald S. Bultje]

Quoted 7 lines

I'm pretty sure the patch is correct, I trust you a lot more on that than myself (I still need to test it, though; but that's a detail). However, this statement is not correct. I test this driver daily, I still own a whole bunch of such cards. Even after hard reboots, they still just work. Norm changes, input changes, everything works. I test (and use) all of this. I would've noticed if it was really as broken as you're describing above.

I'm glad to learn you are testing things. Still the oops in saa7110 went unnoticed for the past 3 months, so I guess that either you don't have a DC10(+) in your test panel, or you did not test mm/rc kernels.

I've gone through the code again, and here is what I think is broken in 2.6.11 on the various Zoran-based boards. Then everyone will be free to pick any patch chunk he/she wants and apply it to any tree he/she likes.

BUZ:
Input (saa7111): works
Output (saa7185): no init, cannot set norm

DC10:
Input (saa7110): oops
Output (adv7175): no init, cannot set norm

DC30:
Input (vpx3220): works
Output (adv7175): no init, cannot set norm

LM33:
Input (bt819): no init
Output (bt856): works

LM33R10:
Input (saa7114): no init, cannot set norm
Output (adv7170): no init, cannot set norm

As you can see, all boards are affected at some level but every user might not be equally affected, depends whether you use input or output or both. Note that "no init" might not affect everyone either, depends on the chip init defaults and the user needs. Ronald, can you tell us what exactly in the above you are testing?

Personally I have only been able to test input on a DC10+ board (saa7110 driver). I lack hardware to test the output.

Hope that clarifies things,
--
Jean Delvare

Ronald S. Bultje

2005-03-10 11:32 UTC #13 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Hi Jean,

thanks for the reply.

Quoted 3 lines · Jean Delvare

I'm glad to learn you are testing things. Still the oops in saa7110 went unnoticed for the past 3 months, so I guess that either you don't have a DC10(+) in your test panel, or you did not test mm/rc kernels.

I indeed don't test RC/MM kernels. I'm fairly happy with the current driver status, so I'm not doing any active new development on it. I run standard Fedora kernels with CVS of the driver (which is the same as what's in 2.6.10).

Quoted 3 lines

BUZ:
Input (saa7111): works
Output (saa7185): no init, cannot set norm

I have this card, but it's no in my computer (not enough PCI slots). Last test is from a few months back. Other people (co-developers) test this for me whenever I make small driver changes. They report that it works, whatever that means. ;). I know they regularly use it for capture, so at least MJPEG capture and overlay display has to work to some degree. Output may be untested.

Quoted 7 lines

DC10:
Input (saa7110): oops
Output (adv7175): no init, cannot set norm
DC30:
Input (vpx3220): works
Output (adv7175): no init, cannot set norm

I have those two. Both work fine. I test raw capture, MJPEG capture and overlay display at least once a week. I don't get an oops on the DC10. I haven't tested output lately. I basically only test output when I make changes to the relevant modules, and I haven't done that lately. Last time I tested it (which must be around the time the driver was integrated into the kernel, so before 2.6.0...), it worked for me.

Quoted 7 lines

LM33:
Input (bt819): no init
Output (bt856): works
LM33R10:
Input (saa7114): no init, cannot set norm
Output (adv7170): no init, cannot set norm

See Buz.

Quoted 5 lines

As you can see, all boards are affected at some level but every user might not be equally affected, depends whether you use input or output or both. Note that "no init" might not affect everyone either, depends on the chip init defaults and the user needs. Ronald, can you tell us what exactly in the above you are testing?

My experience is not the same as yours, it seems... I cannot explain why, unfortunately. Again, I'm sure your patch is correct, I'm just reporting that I'm not seeing the same thing that you're seeing.

Ronald

Jean Delvare

2005-03-10 11:52 UTC #14 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Hi Ronald,

Quoted 7 lines

I indeed don't test RC/MM kernels. I'm fairly happy with the current driver status, so I'm not doing any active new development on it. I run standard Fedora kernels with CVS of the driver (which is the same as what's in 2.6.10).
(...)
My experience is not the same as yours, it seems... I cannot explain why, unfortunately. (...)

I can. You are using a 2.6.10 kernel at best (that's what FC3 updates have), and the bug is triggered by changes made to the i2c-algo-bit driver somewhere between 2.6.10 and 2.6.11. So it's not surprising that you don't see any problem. Note that the version of the media/video drivers you use is not relevant here. The bug has been there for over a year, but the code path where it lies was never taken until i2c-algo-bit was updated recently. What matters is the version of i2c-algo-bit.

So as long as you don't move to a 2.6.11 kernel, don't even bother trying my patches, because you will never hit the code that I am trying to fix.

Thanks,
--
Jean Delvare

Ronald S. Bultje

2005-03-10 12:18 UTC #15 lore raw

Re: [PATCH 2.6] Fix i2c messsage flags in video drivers

Hi Jean,

Quoted 7 lines · Jean Delvare

Quoted 2 lines
My experience is not the same as yours, it seems... I cannot explain why, unfortunately. (...)
I can. [..]
So as long as you don't move to a 2.6.11 kernel, don't even bother trying my patches, because you will never hit the code that I am trying to fix.

That makes sense. I'll try the >=.11 kernels sometime soon.

Thanks,
Ronald

Andrew Morton

2005-03-21 23:33 UTC #16 lore raw

In reply to Andrei Mikhailovsky

Quoted 3 lines · Andrei Mikhailovsky

I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.

Andrei, is this still happening in 2.6.12-rc1?

Thanks.

Quoted 56 lines

Here is the output from dmesg:

Unable to handle kernel paging request at ffffffff880db000 RIP: 
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] 
CPU 0 
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
       ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44

RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP <ffff81003f6c5b78>
CR2: ffffffff880db000

If anyone need more debugging info, I am ready to help

Signature · 1 line

Andrei Mikhailovsky

Andrew Morton

2005-05-25 22:24 UTC #17 lore raw

In reply to Andrei Mikhailovsky

Quoted 3 lines · Andrei Mikhailovsky

I get the oops during the boot up process. This did not happen in 2.6.10/2.6.9.

Is this bug still present in 2.6.12-rc5?

Thanks.

Quoted 56 lines

Here is the output from dmesg:

Unable to handle kernel paging request at ffffffff880db000 RIP: 
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
PGD 103027 PUD 105027 PMD 3ee64067 PTE 0
Oops: 0000 [1] 
CPU 0 
Modules linked in: adv7175 saa7110 zr36067 videocodec videodev sata_nv

RIP: 0010:[<ffffffff880d909f>]
<ffffffff880d909f>{:saa7110:saa7110_write_block+127}
RSP: 0018:ffff81003f6c5b78  EFLAGS: 00010287
RAX: 000000000000139f RBX: 00000000ffffec36 RCX: 000000000000002a
RDX: 000000000000009f RSI: 0000000000000001 RDI: ffffffff880bf838
RBP: 000000000000139f R08: 0000000000000000 R09: ffff81003efd63a8
R10: 0000000000000001 R11: ffffffff802f75d0 R12: ffffffff880db000
R13: ffff81003f3e0200 R14: ffff81003e0df200 R15: 0000000000000001
FS:  00002aaaaaac5520(0000) GS:ffffffff80500180(0000)

Stack: 0000000000000076 0000000000000000 0000000000000000
0000000000000000 
       0000000000000000 ffffffffffff0000 ffffffffffffffff
ffff81003e0df228 
       ffff002a0001004e ffff81003f6c5b78 
Call Trace:<ffffffff880d9930>{:saa7110:saa7110_detect_client+0} 
       <ffffffff880d9ab4>{:saa7110:saa7110_detect_client+388} 
       <ffffffff802f6812>{i2c_probe+642}
<ffffffff802f4c24>{i2c_add_adapter+468} 
       <ffffffff802f7928>{i2c_bit_add_bus+840}
<ffffffff880d7600>{:zr36067:init_dc10_cards+1536} 
       <ffffffff801468e1>{sys_init_module+5857}
<ffffffff80174de7>{do_lookup+55} 
       <ffffffff8021f440>{prio_tree_insert+48}
<ffffffff880d7000>{:zr36067:init_dc10_cards+0} 
       <ffffffff80113fff>{sys_mmap+191} <ffffffff8010e1fa>{system_call

+126}

Code: 41 0f b6 04 24 ff c5 49 ff c4 41 88 44 15 00 88 04 0c 8b 44

RIP <ffffffff880d909f>{:saa7110:saa7110_write_block+127} RSP <ffff81003f6c5b78>
CR2: ffffffff880db000

If anyone need more debugging info, I am ready to help

Signature · 1 line

Andrei Mikhailovsky