amd64 2.6.11 oops on modprobe

amd64 2.6.11 oops on modprobe

[Andrei Mikhailovsky]

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

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


-- 
Andrei Mikhailovsky

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: amd64 2.6.11 oops on modprobe

[Randy.Dunlap]

Andrei Mikhailovsky wrote:
> 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

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

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

Re: amd64 2.6.11 oops on modprobe

[Andrei Mikhailovsky]

[-- Attachment #1: Type: text/plain, Size: 5751 bytes --]

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
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: 3213, comm: modprobe Not tainted 2.6.11-amd64
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

On Sat, 2005-03-05 at 16:53 -0800, Randy.Dunlap wrote:
> Andrei Mikhailovsky wrote:
> > 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
> 
> 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.
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: amd64 2.6.11 oops on modprobe

[Randy.Dunlap]

Andrei Mikhailovsky wrote:
> 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.

> 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
> 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: 3213, comm: modprobe Not tainted 2.6.11-amd64
> 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
> 
> On Sat, 2005-03-05 at 16:53 -0800, Randy.Dunlap wrote:
> 
>>Andrei Mikhailovsky wrote:
>>
>>>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
>>
>>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

Re: amd64 2.6.11 oops on modprobe

[Randy.Dunlap]

Andrei Mikhailovsky wrote:
> 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

> 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
> 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: 3213, comm: modprobe Not tainted 2.6.11-amd64
> 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
> 
> On Sat, 2005-03-05 at 16:53 -0800, Randy.Dunlap wrote:
> 
>>Andrei Mikhailovsky wrote:
>>
>>>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


-- 
~Randy

Re: amd64 2.6.11 oops on modprobe

[Randy.Dunlap]

Andrei Mikhailovsky wrote:
> 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.

-- 
~Randy

Re: amd64 2.6.11 oops on modprobe

[Jean Delvare]

[Randy Dunlap]
> 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.)

> 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:

--- linux-2.6.11-bk3/drivers/media/video/saa7110.c.orig	Tue Mar  8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/saa7110.c	Tue Mar  8 12:02:45 2005
@@ -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.

-- 
Jean Delvare

[PATCH 2.6] Fix i2c messsage flags in video drivers

[Jean Delvare]

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 <khali@linux-fr.org>

diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/adv7170.c linux-2.6.11-bk3/drivers/media/video/adv7170.c
--- linux-2.6.11-bk3/drivers/media/video.orig/adv7170.c	Tue Mar  8 10:27:14 2005
+++ linux-2.6.11-bk3/drivers/media/video/adv7170.c	Tue Mar  8 12:19:04 2005
@@ -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;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/adv7175.c linux-2.6.11-bk3/drivers/media/video/adv7175.c
--- linux-2.6.11-bk3/drivers/media/video.orig/adv7175.c	Tue Mar  8 10:27:14 2005
+++ linux-2.6.11-bk3/drivers/media/video/adv7175.c	Tue Mar  8 12:18:57 2005
@@ -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;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/bt819.c linux-2.6.11-bk3/drivers/media/video/bt819.c
--- linux-2.6.11-bk3/drivers/media/video.orig/bt819.c	Tue Mar  8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/bt819.c	Tue Mar  8 12:18:51 2005
@@ -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;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/saa7114.c linux-2.6.11-bk3/drivers/media/video/saa7114.c
--- linux-2.6.11-bk3/drivers/media/video.orig/saa7114.c	Tue Mar  8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/saa7114.c	Tue Mar  8 12:18:20 2005
@@ -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;
diff -u -rN linux-2.6.11-bk3/drivers/media/video.orig/saa7185.c linux-2.6.11-bk3/drivers/media/video/saa7185.c
--- linux-2.6.11-bk3/drivers/media/video.orig/saa7185.c	Tue Mar  8 10:27:15 2005
+++ linux-2.6.11-bk3/drivers/media/video/saa7185.c	Tue Mar  8 12:18:12 2005
@@ -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;



-- 
Jean Delvare

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

[Chris Wright]

* Jean Delvare (khali@linux-fr.org) 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.
> 
> 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?

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

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

[Jean Delvare]

Hi Chris,

> > 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.
> 
> 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,
-- 
Jean Delvare

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

[Ronald S. Bultje]

Hi Jean,

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

On Wed, 9 Mar 2005, Jean Delvare wrote:
> 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

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

[Jean Delvare]

Hi Ronald,

[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.

[Ronald S. Bultje]
> 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

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

[Ronald S. Bultje]

Hi Jean,

thanks for the reply.

On Thu, 10 Mar 2005, Jean Delvare wrote:
> 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).

> 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.

> 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.

> 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.

> 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

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

[Jean Delvare]

Hi Ronald,

> 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

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

[Ronald S. Bultje]

Hi Jean,

On Thu, 10 Mar 2005, Jean Delvare wrote:
> > 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

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

[Chris Wright]

* Jean Delvare (khali@linux-fr.org) wrote:
> > 
> > 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.

> 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
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: amd64 2.6.11 oops on modprobe

[Andrew Morton]

Andrei Mikhailovsky <andrei@arhont.com> wrote:
>
> 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.

> 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
> 
> 
> -- 
> Andrei Mikhailovsky
> 

Re: amd64 2.6.11 oops on modprobe

[Andrew Morton]

Andrei Mikhailovsky <andrei@arhont.com> wrote:
>
> 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.

> 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
> 
> 
> -- 
> Andrei Mikhailovsky
>