Created attachment 4155 [details]
config-2.6.10-rc2-bauxite.17

My kernel config file.

I'm not sure it's due to therm_adt746x: Nothing i2c-related changed in it. Can
you try therm_adt746x.c from 2.6.10-rc2 in 2.6.9 (just replace the file), and
see if it reproduces. If not, the problem is possibly due to i2c changes in
2.6.10-rc2.

Also try the inverse, therm_adt746x.c from 2.6.9 in 2.6.10-rc2, and see if it
reproduces. If yes, the problem is very probably due to i2c changes in 2.6.10-rc2.

Thanks
Colin

Copy therm_adt746x.c from kernel source 2.6.9 and recompile kernel 2.6.10-rc2.
When I modprobe therm_adt746x, it segmentation fault again.

Maybe you are right.

Thanks for your help.

Thanks for your quick answer. You may ask on linux-kernel mailing list. It may
be an i2c bug, or a kobject-related one, or maybe something in your config. 

Created attachment 4160 [details]
Properly define the i2c_client owner

Not sure it'll prevent the oops, but still worth a try, and should probably be
applied to the main tree anyway.

doesn't seem correct:

drivers/macintosh/therm_adt746x.c: In function `attach_one_thermostat':
drivers/macintosh/therm_adt746x.c:381: error: structure has no member named `owner'

? :)

Created attachment 4161 [details]
Properly define the i2c_client owner

Not sure it'll prevent the oops, but still worth a try, and should probably be
applied to the main tree anyway.

Comment on attachment 4161 [details]
Properly define the i2c_client owner

Duplicate due to bugzilla.kernel.org being half responsive.

Created attachment 4162 [details]
Properly define the i2c_driver owner

What about this one then?

This one compiles ok, can you push it to Andrew or do you want me to do so? 

BTW, would you happen to know why my driver and therm_windtunnel define
.attach_adapter and .detach_adapter by address (&attach_thermostat), while
therm_pm72 does not ?

Thanks,
Colin

I will send a broader patch to Greg and Andrew, as it seems that the other
therm_* drivers need it too.

As for .attach_adapter and .detach_adapter, they are function pointers so these
are addresses, whether you use & or not. Both constructs are similar for gcc as
far as I know.

I wonder if my patch will be sufficient to solve Jie's problem though.

Me too, espacially since I have no problems with my driver in 2.6.10-rc2... 

Differences related to I2C, between my .config and Jie's are the following:
He has 
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
CONFIG_I2C_KEYWEST=y

and I have
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_KEYWEST=m

Maybe related?

Created attachment 4163 [details]
Cleanup macintoch/therm_* i2c driver structures

Looks like kobjects prefer if their name fit in 20 bytes so they should be 19
chararcters max. therm_adt746x and therm_windtunnel are longer than that with
24 and 23 characters, respectively.

This patch fixes that among other cleanups. Jie, please give it a try and let
me know if it helps.

Apply Delvare's patch ( attachment 4162 [details] ) and recompile kernel 2.6.10-rc2 with 
the same kernel configuration file.  It seems that the phenomenon is same as 
befor.

# modprobe therm_adt746x
adt746x: Thermostat bus: 1, address: 0x2e, limit_adjust: 0, fan_speed: -1
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C0116DE8 LR: C0117C88 SP: C7053DB0 REGS: c7053d00 TRAP: 0300    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00008124, DSISR: 40000000
TASK = cf2c07e0[4038] 'modprobe' THREAD: c7052000Last syscall: 128
GPR00: 0000000C C7053DB0 CF2C07E0 00008124 FFFFFFFE C02270C8 C7053E50 0000000A
GPR08: FFFFFFFF 00008124 C02270C9 C7053DE8 84002424 1001E284 100013A4 00000000
GPR16: 00000000 00000000 00000000 00000000 100013A4 10019080 10019040 00000000
GPR24: 00000019 CC728DE0 FFFFFFFF C7053E50 00008124 00000000 CC728DF8 CC728DE0
NIP [c0116de8] strnlen+0x10/0x40
LR [c0117c88] vsnprintf+0x554/0x74c
Call trace:
 [c01143e4] kobject_set_name+0xc8/0xec
 [c015be44] bus_add_driver+0x44/0x10c
 [c015c52c] driver_register+0x30/0x40
 [c0193c84] i2c_add_driver+0x68/0x12c
 [d6857170] thermostat_init+0x170/0x3b0 [therm_adt746x]
 [c00334c0] sys_init_module+0x224/0x324
 [c00042e0] ret_from_syscall+0x0/0x44
Segmentation fault

Apply the new patch ( attachment 4163 [details] ). It worked.

# modprobe therm_adt746x
adt746x: Thermostat bus: 1, address: 0x2e, limit_adjust: 0, fan_speed: -1
adt746x: ADT7460 initializing
adt746x: Lowering max temperatures from 73, 80, 109 to 70, 50, 70
# lsmod
Module                  Size  Used by
therm_adt746x          12508  0
hci_usb                16224  2
rfcomm                 48092  0
l2cap                  28836  5 rfcomm
bluetooth              64332  7 hci_usb,rfcomm,l2cap
af_packet              21320  2
ipv6                  323272  10
joydev                 12000  0
usbhid                 55136  0
ohci_hcd               26824  0
eth1394                24712  0
ehci_hcd               38436  0
usbcore               147280  5 hci_usb,usbhid,ohci_hcd,ehci_hcd
ohci1394               41924  0
dm_mod                 73992  6
evdev                  11968  2
sr_mod                 23396  0
snd_powermac           48132  0
snd_pcm_oss            67940  0
snd_mixer_oss          23296  1 snd_pcm_oss
snd_pcm               115096  2 snd_powermac,snd_pcm_oss
snd_timer              29316  1 snd_pcm
snd                    67736  5 
snd_powermac,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer
soundcore              11876  1 snd
snd_page_alloc         11620  1 snd_pcm
sbp2                   28208  0
scsi_mod              119840  2 sr_mod,sbp2
ieee1394              448744  3 eth1394,ohci1394,sbp2
ide_cd                 50052  0
cdrom                  50940  2 sr_mod,ide_cd
generic                 5248  0 [permanent]
unix                   32152  54

great, thanks for the patch Jean!
Can you push to Andrew before 2.6.10?

Thanks.

I'll push it to Greg or Andrew or Linus, whoever wants it, but maybe not before
2.6.10 as there is no regression as far as I can see (the problem was already
there before, just not triggering). I'm also not certain why the code which is
supposed to handle names longer than 19 bytes won't work in this case, so maybe
my patch isn't the proper way to fix the problem.

Sure. I'd rather like thermal control working in every kernel release, that's
why I'd like a fix in maintree now that the bug triggers...

Adding Greg to Cc: 
You may be interested, looks like the code in kobject.c::kobject_set_name fails
with strings longer than KOBJ_NAME_LEN.

The oops has already been fixed in the latest -bk tree.  It was because
of the use of varargs.  It would work on some archs properly, and others
not at all.

Jean, please send me the other patch in an email, I'll add it to my queue.