Hello,
I just forgot to remove CONFIG_I2C_SIS96X=y in my kernel (minimum support
possible for my PC hardware based on VIA, no module at all) and get a one
minute delay at boot when trying to probe this non existing device in
2.6.16-rc5.
Maybe the abscence test should be quicker.
Cheers,
Etienne.
___________________________________________________________________________
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.
T?l?chargez sur http://fr.messenger.yahoo.com
Hi Etienne,
On 2006-03-13, Etienne Lorrain wrote:
> I just forgot to remove CONFIG_I2C_SIS96X=y in my kernel (minimum
> support possible for my PC hardware based on VIA, no module at all)
> and get a one minute delay at boot when trying to probe this non
> existing device in 2.6.16-rc5.
> Maybe the abscence test should be quicker.
The SIS96x SMBus is a PCI chip, so if it doesn't exist in a given
system, no code at all should be executed. So I have a hard time
believing it takes one minute. How do you know for sure that _this_
driver causing the delay? Did you actually try to rebuild without
CONFIG_I2C_SIS96X?
P.S.: The sensors list you tried to write to no more exists at this
address, see http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
instead.
--
Jean Delvare
Hi Jean Delvare,
--- Jean Delvare <[email protected]> wrote:
> On 2006-03-13, Etienne Lorrain wrote:
> > I just forgot to remove CONFIG_I2C_SIS96X=y in my kernel (minimum
> > support possible for my PC hardware based on VIA, no module at all)
> > and get a one minute delay at boot when trying to probe this non
> > existing device in 2.6.16-rc5.
> > Maybe the abscence test should be quicker.
>
> The SIS96x SMBus is a PCI chip, so if it doesn't exist in a given
> system, no code at all should be executed. So I have a hard time
> believing it takes one minute. How do you know for sure that _this_
> driver causing the delay? Did you actually try to rebuild without
> CONFIG_I2C_SIS96X?
Sorry, I was just assuming that while probing I2C hardware one per one, if one line
is diplayed for each driver I do not have - then the kernel will at least display
one line if it found something.
I have this lspci:
etienne@ubuntu:~/linux/linux-2.6.16-rc5-gujin$ lspci
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge
(rev 80)
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
0000:00:06.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 81)
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
(rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C
PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97
Audio Controller (rev 50)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon
7500]
And the fault on an ubuntu 5.10 system when using linux-2.6.16-rc5 is:
Mar 10 19:39:12 ubuntu kernel: [ 40.522970] PCI: Via IRQ fixup for 0000:00:10.2, from 9
to 5
Mar 10 19:39:12 ubuntu kernel: [ 40.525792] uhci_hcd 0000:00:10.2: UHCI Host Controller
Mar 10 19:39:12 ubuntu kernel: [ 40.528663] uhci_hcd 0000:00:10.2: new USB bus
registered, assigned bus number 4
Mar 10 19:39:12 ubuntu kernel: [ 40.531529] uhci_hcd 0000:00:10.2: irq 21, io base
0x0000ec00
Mar 10 19:39:12 ubuntu kernel: [ 40.534489] usb usb4: configuration #1 chosen from 1
choice
Mar 10 19:39:12 ubuntu kernel: [ 40.537419] hub 4-0:1.0: USB hub found
Mar 10 19:39:12 ubuntu kernel: [ 40.540284] hub 4-0:1.0: 2 ports detected
Mar 10 19:39:12 ubuntu kernel: [ 40.646920] sl811: driver sl811-hcd, 19 May 2005
Mar 10 19:39:12 ubuntu kernel: [ 40.886717] usb 2-1: new full speed USB device using
uhci_hcd and address 2
Mar 10 19:39:12 ubuntu kernel: [ 41.040225] usb 2-1: configuration #1 chosen from 1
choice
Mar 10 19:39:12 ubuntu kernel: [ 41.045260] hub 2-1:1.0: USB hub found
Mar 10 19:39:12 ubuntu kernel: [ 41.050218] hub 2-1:1.0: 3 ports detected
Mar 10 19:39:12 ubuntu kernel: [ 41.398463] usb 2-2: new low speed USB device using
uhci_hcd and address 3
Mar 10 19:39:12 ubuntu kernel: [ 41.605819] usb 2-2: configuration #1 chosen from 1
choice
Mar 10 19:39:12 ubuntu kernel: [ 42.129448] usbcore: registered new driver usblp
Mar 10 19:39:12 ubuntu kernel: [ 42.132207] drivers/usb/class/usblp.c: v0.13: USB
Printer Device Class driver
Mar 10 19:39:12 ubuntu kernel: [ 42.134959] Initializing USB Mass Storage driver...
Mar 10 19:39:12 ubuntu kernel: [ 42.137734] usbcore: registered new driver usb-storage
Mar 10 19:39:12 ubuntu kernel: [ 42.140486] USB Mass Storage support registered.
Mar 10 19:39:12 ubuntu kernel: [ 42.143247] usbcore: registered new driver libusual
Mar 10 19:39:12 ubuntu kernel: [ 42.145980] usbcore: registered new driver hiddev
Mar 10 19:39:12 ubuntu kernel: [ 42.196484] input: HID 1241:1111 as /class/input/input0
Mar 10 19:39:12 ubuntu kernel: [ 42.199159] input: USB HID v1.10 Mouse [HID 1241:1111]
on usb-0000:00:10.0-2
Mar 10 19:39:12 ubuntu kernel: [ 42.201870] usbcore: registered new driver usbhid
Mar 10 19:39:12 ubuntu kernel: [ 42.204535] drivers/usb/input/hid-core.c: v2.6:USB HID
core driver
Mar 10 19:39:12 ubuntu kernel: [ 42.207244] usbcore: registered new driver microtekX6
Mar 10 19:39:12 ubuntu kernel: [ 42.209986] mice: PS/2 mouse device common for all mice
Mar 10 19:39:12 ubuntu kernel: [ 42.258776] input: AT Translated Set 2 keyboard as
/class/input/input1
Mar 10 19:39:12 ubuntu kernel: [ 42.261682] input: PC Speaker as /class/input/input2
Mar 10 19:39:12 ubuntu kernel: [ 42.264394] i2c /dev entries driver
Mar 10 19:39:12 ubuntu kernel: [ 42.267552] i2c-parport: using default base 0x378
Mar 10 19:39:12 ubuntu kernel: [ 42.270260] i2c-pca-isa: i/o base 0x000330. irq 10
Mar 10 19:39:12 ubuntu kernel: [ 42.273590] i2c-sis96x version 1.0.0
Mar 10 19:39:12 ubuntu kernel: [ 119.507926] : Detection failed at step 3
Mar 10 19:39:12 ubuntu kernel: [ 119.755830] hdaps: supported laptop not found!
Mar 10 19:39:12 ubuntu kernel: [ 119.758363] hdaps: driver init failed (ret=-6)!
Mar 10 19:39:12 ubuntu kernel: [ 119.775788] md: linear personality registered for level
-1
Mar 10 19:39:12 ubuntu kernel: [ 119.778344] md: raid0 personality registered for level
0
So I did the long way of disabling each I2C driver one per one, the last is the one,
as usual:
[*] ALI1535
[*] ALI1563
[*] ALI15x3
[*] AMD 756/766/768/8111 and nVidia nForce
[*] SMBus multiplexing on the Tyan S4882
[*] AMD 8111
[*] Intel 82801 (ICH)
[*] Intel 810/815
[*] Intel PIIX4
[*] Nvidia nForce2, nForce3 and nForce4
[*] Parallel port adapter (light)
[*] S3/VIA (Pro)Savage
[*] S3 Savage 4
[*] NatSemi SCx200 ACCESS.bus
[*] SiS 5595
[*] SiS 630/730
[ ] SiS 96x
[ ] VIA 82C586B
[ ] VIA 82C596/82C686/823x
[ ] Voodoo 3
[ ] PCA9564 on an ISA bus
Removing the last PCA9564 gives me:
Mar 13 21:46:48 ubuntu kernel: [ 47.699704] input: AT Translated Set 2 keyboard as
/class/input/input1
Mar 13 21:46:48 ubuntu kernel: [ 47.702667] input: PC Speaker as /class/input/input2
Mar 13 21:46:48 ubuntu kernel: [ 47.705445] i2c /dev entries driver
Mar 13 21:46:48 ubuntu kernel: [ 47.708637] i2c-parport: using default base 0x378
Mar 13 21:46:48 ubuntu kernel: [ 70.366096] hdaps: supported laptop not found!
Mar 13 21:46:48 ubuntu kernel: [ 70.368750] hdaps: driver init failed (ret=-6)!
Which is a strong improvement. Note that I do not have an ISA bus on this machine...
Following a bit:
removing "Dallas Semiconductor DS1337 and DS1339 Real Time Clock" does nothing
removing "EEPROM reader" changes to:
Mar 13 22:12:54 ubuntu kernel: [ 45.365457] input: PC Speaker as /class/input/input2
Mar 13 22:12:54 ubuntu kernel: [ 45.368197] i2c /dev entries driver
Mar 13 22:12:54 ubuntu kernel: [ 61.957048] rtc8564: cant init ctrl1
Mar 13 22:12:54 ubuntu kernel: [ 61.997032] : Detection failed at step 3
Mar 13 22:12:54 ubuntu kernel: [ 62.132994] hdaps: supported laptop not found!
Mar 13 22:12:54 ubuntu kernel: [ 62.135578] hdaps: driver init failed (ret=-6)!
Removing "Philips PCF8574 and PCF8574A" and "Philips PCF8591" (and "Epson 8564 RTC chip"
because of the previous error message) so no more anything in "Miscellaneous I2C Chip
support" and just the "VIA 82C586B" in "I2C Hardware Bus support", I get:
Mar 13 22:21:42 ubuntu kernel: [ 72.252791] input: PC Speaker as /class/input/input2
Mar 13 22:21:42 ubuntu kernel: [ 72.255555] i2c /dev entries driver
Mar 13 22:21:42 ubuntu kernel: [ 72.258868] hdaps: supported laptop not found!
Mar 13 22:21:42 ubuntu kernel: [ 72.261560] hdaps: driver init failed (ret=-6)!
Adding (embedded centric) drivers for (embedded centric) company which respect
international copyright regulations (and so the GPL) is OK; but not if that delays
so much booting...
Etienne.
___________________________________________________________________________
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.
T?l?chargez sur http://fr.messenger.yahoo.com
Hi Etienne,
On 2006-03-13, Etienne Lorrain wrote:
> > > I just forgot to remove CONFIG_I2C_SIS96X=y in my kernel (minimum
> > > support possible for my PC hardware based on VIA, no module at all)
> > > and get a one minute delay at boot when trying to probe this non
> > > existing device in 2.6.16-rc5.
> > > Maybe the abscence test should be quicker.
> >
> > The SIS96x SMBus is a PCI chip, so if it doesn't exist in a given
> > system, no code at all should be executed. So I have a hard time
> > believing it takes one minute. How do you know for sure that _this_
> > driver causing the delay? Did you actually try to rebuild without
> > CONFIG_I2C_SIS96X?
>
> Sorry, I was just assuming that while probing I2C hardware one per one,
> if one line is diplayed for each driver I do not have - then the kernel
> will at least display one line if it found something.
This is the way it should work, but unfortunately our i2c bus drivers
don't follow these rules. Almost all of them keep quiet when loaded
(except for i2c-sis96x, as you found out by yourself) but they also keep
quiet (unless debug is enabled) when a supported device is found, which
is not so good.
Mark, can you provide a patch to your i2c-sis96x driver so that it'll
keep quiet when no supported device is found?
We should probably have these drivers display something when they find a
supported chip. There are many drivers affected though (we have 41 real
i2c bus drivers by now) and many of them would need to be fixed, it
represents much more work if we want to do it properly. If anyone wants
to take his/her chance...
> I have this lspci:
> (...)
> 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
> (...)
> 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
Off-topic, but it's quite strange. Your south bridge cannot be a VT8237R
and a VT8235 at the same time...
> And the fault on an ubuntu 5.10 system when using linux-2.6.16-rc5 is:
> (...)
> Mar 10 19:39:12 ubuntu kernel: [ 42.264394] i2c /dev entries driver
> Mar 10 19:39:12 ubuntu kernel: [ 42.267552] i2c-parport: using default
> base 0x378
> Mar 10 19:39:12 ubuntu kernel: [ 42.270260] i2c-pca-isa: i/o base
> 0x000330. irq 10
> Mar 10 19:39:12 ubuntu kernel: [ 42.273590] i2c-sis96x version 1.0.0
> Mar 10 19:39:12 ubuntu kernel: [ 119.507926] : Detection failed at step 3
This message is from the w83792d driver. This is a debug message, it
shouldn't be displayed here; the driver needs to be fixed.
> Mar 10 19:39:12 ubuntu kernel: [ 119.755830] hdaps: supported laptop not
> found!
> Mar 10 19:39:12 ubuntu kernel: [ 119.758363] hdaps: driver init failed
> (ret=-6)!
> So I did the long way of disabling each I2C driver one per one, the last
> is the one, as usual:
> [*] ALI1535
> [*] ALI1563
> [*] ALI15x3
> [*] AMD 756/766/768/8111 and nVidia nForce
> [*] SMBus multiplexing on the Tyan S4882
> [*] AMD 8111
> [*] Intel 82801 (ICH)
> [*] Intel 810/815
> [*] Intel PIIX4
> [*] Nvidia nForce2, nForce3 and nForce4
> [*] Parallel port adapter (light)
> [*] S3/VIA (Pro)Savage
> [*] S3 Savage 4
> [*] NatSemi SCx200 ACCESS.bus
> [*] SiS 5595
> [*] SiS 630/730
> [ ] SiS 96x
> [ ] VIA 82C586B
> [ ] VIA 82C596/82C686/823x
> [ ] Voodoo 3
> [ ] PCA9564 on an ISA bus
>
> Removing the last PCA9564 gives me:
> Mar 13 21:46:48 ubuntu kernel: [ 47.699704] input: AT Translated Set 2
> keyboard as /class/input/input1
> Mar 13 21:46:48 ubuntu kernel: [ 47.702667] input: PC Speaker
> as /class/input/input2
> Mar 13 21:46:48 ubuntu kernel: [ 47.705445] i2c /dev entries driver
> Mar 13 21:46:48 ubuntu kernel: [ 47.708637] i2c-parport: using default
> base 0x378
> Mar 13 21:46:48 ubuntu kernel: [ 70.366096] hdaps: supported laptop not
> found!
> Mar 13 21:46:48 ubuntu kernel: [ 70.368750] hdaps: driver init failed
> (ret=-6)!
You should also drop "Parallel port adapter (light)", it might cause
the same kind of delays and probably explains (part of) the 23 second
delay remaining.
> Which is a strong improvement. Note that I do not have an ISA bus on
> this machine...
I bet you do. You certainly don't have an ISA *slot*, but you must have
an ISA bus. Legacy devices (PS/2 keyboard and mouse, serial and parallel
ports...) and super-I/O (LPC) chips still use it.
> Following a bit:
> removing "Dallas Semiconductor DS1337 and DS1339 Real Time Clock" does
> nothing removing "EEPROM reader" changes to:
> Mar 13 22:12:54 ubuntu kernel: [ 45.365457] input: PC Speaker
> as /class/input/input2
> Mar 13 22:12:54 ubuntu kernel: [ 45.368197] i2c /dev entries driver
> Mar 13 22:12:54 ubuntu kernel: [ 61.957048] rtc8564: cant init ctrl1
> Mar 13 22:12:54 ubuntu kernel: [ 61.997032] : Detection failed at step 3
> Mar 13 22:12:54 ubuntu kernel: [ 62.132994] hdaps: supported laptop not
> found!
> Mar 13 22:12:54 ubuntu kernel: [ 62.135578] hdaps: driver init failed
> (ret=-6)!
>
> Removing "Philips PCF8574 and PCF8574A" and "Philips PCF8591" (and "Epson
> 8564 RTC chip" because of the previous error message) so no more anything
> in "Miscellaneous I2C Chip support" and just the "VIA 82C586B" in "I2C
> Hardware Bus support", I get:
>
> Mar 13 22:21:42 ubuntu kernel: [ 72.252791] input: PC Speaker
> as /class/input/input2
> Mar 13 22:21:42 ubuntu kernel: [ 72.255555] i2c /dev entries driver
> Mar 13 22:21:42 ubuntu kernel: [ 72.258868] hdaps: supported laptop
> not found!
> Mar 13 22:21:42 ubuntu kernel: [ 72.261560] hdaps: driver init failed
> (ret=-6)!
>
> Adding (embedded centric) drivers for (embedded centric) company which
> respect international copyright regulations (and so the GPL) is OK; but
> not if that delays so much booting...
You should continue your hunting session in Device drivers > Hardware
Monitoring support. Many of these drivers are for i2c chips, which are
sometimes hard to detect, so we do a lot of probes at load time. I guess
that you have them all built into your kernel, which is bad idea. You
really should only include the ones your embedded systems have a chance
to ever include. Your big boot delay is most certainly caused by these
in combination of the i2c-parport-light bus driver.
When loading an i2c chip driver, the driver will scan all available i2c
busses, and on each bus it'll probe all addresses where the chip could
be. If you have some stuck i2c bus (which happens when using drivers
like i2c-parport-light or i2c-pca-isa when you don't have the
hardware), the probing on these i2c busses will be *very* slow (you have
to wait for the timeout on every transaction). So if you include each
and every hardware monitoring driver into your kernel, many of which are
i2c chip drivers, you end up with lots of probes done at boot time and
this takes a lot of time.
So, if modules are not an option, you really should discard all hardware
monitoring drivers you know you won't need (the sensors-detect script
can tell you which drivers you need).
That being said, the key problem being stuck i2c busses, it's even more
important to get rid of these. You can use "i2cdetect -l" to list all
detected i2c bus, so you'll see if you have any unwanted bus left. If
you do, you'll have to find out where the drivers hide in the
configuration menu, and unselect them.
Hope that helps,
--
Jean Delvare
Hi Jean, Etienne:
<snip>
> On 2006-03-13, Etienne Lorrain wrote:
> > Sorry, I was just assuming that while probing I2C hardware one per one,
> > if one line is diplayed for each driver I do not have - then the kernel
> > will at least display one line if it found something.
* Jean Delvare <[email protected]> [2006-03-14 10:43:54 +0100]:
> This is the way it should work, but unfortunately our i2c bus drivers
> don't follow these rules. Almost all of them keep quiet when loaded
> (except for i2c-sis96x, as you found out by yourself) but they also keep
> quiet (unless debug is enabled) when a supported device is found, which
> is not so good.
>
> Mark, can you provide a patch to your i2c-sis96x driver so that it'll
> keep quiet when no supported device is found?
Lots of drivers printk messages when they load - IMO it's useful info.
E.g. how else could Etienne discover that he accidentally built a kernel
with dozens of i2c bus drivers (and probably all of the hwmon drivers)
built-in by accident?
(But, I'll send the trivial patch to lm-sensors list if you still want it.)
<snip>
> > Removing the last PCA9564 gives me:
> > Mar 13 21:46:48 ubuntu kernel: [ 47.699704] input: AT Translated Set 2
> > keyboard as /class/input/input1
> > Mar 13 21:46:48 ubuntu kernel: [ 47.702667] input: PC Speaker
> > as /class/input/input2
> > Mar 13 21:46:48 ubuntu kernel: [ 47.705445] i2c /dev entries driver
> > Mar 13 21:46:48 ubuntu kernel: [ 47.708637] i2c-parport: using default
> > base 0x378
> > Mar 13 21:46:48 ubuntu kernel: [ 70.366096] hdaps: supported laptop not
> > found!
> > Mar 13 21:46:48 ubuntu kernel: [ 70.368750] hdaps: driver init failed
> > (ret=-6)!
>
> You should also drop "Parallel port adapter (light)", it might cause
> the same kind of delays and probably explains (part of) the 23 second
> delay remaining.
<snip>
Wow, that's a huge delay. One alternative would be for i2c slaves to behave
more like USB and do the probing asynchronous to driver load; i.e. 'modprobe
w83627hf' returns before the chip is actually recognized and attached.
OTOH, that brings up all the related problems. E.g., you could no longer
expect this simple fragment of a RC script to work...
modprobe i2c-sis96x
modprobe asb100
sensors -s
Short of fixing all that... one has to accept that (1) i2c bus probing is
slow, and (2) some i2c busses themselves are not reliably detectable...
...thus (3) it's a bad idea to build all of that into your monolithic kernel.
As Jean suggests, either use modules or build only the drivers for hardware
you actually have.
Regards,
--
Mark M. Hoffman
[email protected]
Hi Mark,
On 2006-03-15, Mark M. Hoffman wrote:
> Lots of drivers printk messages when they load - IMO it's useful info.
> E.g. how else could Etienne discover that he accidentally built a kernel
> with dozens of i2c bus drivers (and probably all of the hwmon drivers)
> built-in by accident?
The size of the kernel would be a good hint to start with, the boot time
would complement that, and a quick look at .config is the definitive
answer. What the i2c-sis96x driver message did here is cause Etienne to
accuse this driver for the boot delay he was observing, while other
drivers are in fact responsible for it, so it did not help at all.
If all drivers were actually printking messages when they load,
monolithic kernels would be a mess (not that I much understand the point
of such monolithic kernels, but...) You wouldn't be able to tell from
the boot log which drivers are actually used by the system, and which
aren't.
> Wow, that's a huge delay. One alternative would be for i2c slaves to
> behave more like USB and do the probing asynchronous to driver load;
> i.e. 'modprobe w83627hf' returns before the chip is actually recognized
> and attached.
You mean that the i2c subsystem would finally be rewritten from scratch
to comply with the driver model? I'm waiting for your patches :)
> OTOH, that brings up all the related problems. E.g., you could no longer
> expect this simple fragment of a RC script to work...
>
> modprobe i2c-sis96x
> modprobe asb100
> sensors -s
I guess we would have to use hotplug instead then.
> Short of fixing all that... one has to accept that (1) i2c bus probing
> is slow, and (2) some i2c busses themselves are not reliably
> detectable...
Things can be improved still. The busses which cannot be reliably
detected could test themselves, and discard themselves if they find they
don't work. This is much the spirit of the bit_test parameter of the
i2c-algo-bit module; it could be made the default. i2c-algo-pca could be
added a similar option.
Also, the i2c subsystem is currently relying on general probing for
almost everything. Whenever you load an i2c chip driver, it'll probe
all the i2c busses for supported chips. We tried to limit the probing
area by introducing the concept of "classes", and we now only probe
the busses which share a class with the i2c chip driver. Not all drivers
have been modified to take benefit of that class check though, and the
i2c core doesn't enforce it at the moment; it is all based on drivers
cooperation. So there is room for improvement here.
Last, sometimes you know exactly where the chip is, yet the i2c core
doesn't offer a way to skip the probing step and attach the driver
directly to the device. I'm working on a way to do that, and hope to
have something ready to show soon. This should speed up the driver load
quite a bit.
Thanks,
--
Jean Delvare
>
>> I have this lspci:
>> (...)
>> 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
>> (...)
>> 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
>
>Off-topic, but it's quite strange. Your south bridge cannot be a VT8237R
>and a VT8235 at the same time...
>
Where does it say that the southbridge is 35 and 37 at the same time? (The
only thing that's different between the two lspci lines is the vtABCD
number...)
Or it looks like there's another of these "strange" cases:
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo
MVP3/Pro133x AGP]
0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South]
(rev 23)
Jan Engelhardt
--
Hi Jean:
(cc'ed lm-sensors ML)
[user reports waiting ~23 seconds for i2c/hwmon stuff to init in a
monolithic kernel build]
> On 2006-03-15, Mark M. Hoffman wrote:
> > Wow, that's a huge delay. One alternative would be for i2c slaves to
> > behave more like USB and do the probing asynchronous to driver load;
> > i.e. 'modprobe w83627hf' returns before the chip is actually recognized
> > and attached.
>
* Jean Delvare <[email protected]> [2006-03-15 10:01:47 +0100]:
> You mean that the i2c subsystem would finally be rewritten from scratch
> to comply with the driver model? I'm waiting for your patches :)
Heh, 'spose I asked for that.
> > OTOH, that brings up all the related problems. E.g., you could no longer
> > expect this simple fragment of a RC script to work...
> >
> > modprobe i2c-sis96x
> > modprobe asb100
> > sensors -s
>
> I guess we would have to use hotplug instead then.
>
> > Short of fixing all that... one has to accept that (1) i2c bus probing
> > is slow, and (2) some i2c busses themselves are not reliably
> > detectable...
>
> Things can be improved still. The busses which cannot be reliably
> detected could test themselves, and discard themselves if they find they
> don't work. This is much the spirit of the bit_test parameter of the
> i2c-algo-bit module; it could be made the default. i2c-algo-pca could be
> added a similar option.
>
> Also, the i2c subsystem is currently relying on general probing for
> almost everything. Whenever you load an i2c chip driver, it'll probe
> all the i2c busses for supported chips. We tried to limit the probing
> area by introducing the concept of "classes", and we now only probe
> the busses which share a class with the i2c chip driver. Not all drivers
> have been modified to take benefit of that class check though, and the
> i2c core doesn't enforce it at the moment; it is all based on drivers
> cooperation. So there is room for improvement here.
>
> Last, sometimes you know exactly where the chip is, yet the i2c core
> doesn't offer a way to skip the probing step and attach the driver
> directly to the device. I'm working on a way to do that, and hope to
> have something ready to show soon. This should speed up the driver load
> quite a bit.
Here's a start: why does i2c-parport[-light] have a default adapter type?
Loading it with the default could be considered an accident by definition.
It takes ~6 seconds to load all of kernel/drivers/hwmon/*.ko on a test box
here with i2c-parport-light present (but without any adapter hardware).
With this patch, that drops to ~1 second.
---
This patch forces the user to specify what type of adapter is present when
loading i2c-parport or i2c-parport-light. If none is specified, the driver
init simply fails - instead of assuming adapter type 0.
This alleviates the sometimes lengthy boot time delays which can be caused
by accidentally building one of these into a kernel along with several i2c
slave drivers that have lengthy probe routines (e.g. hwmon drivers).
Signed-off-by: Mark M. Hoffman <[email protected]>
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/i2c-parport-light.c
+++ linux-2.6.16-rc6/drivers/i2c/busses/i2c-parport-light.c
@@ -121,9 +121,14 @@ static struct i2c_adapter parport_adapte
static int __init i2c_parport_init(void)
{
- if (type < 0 || type >= ARRAY_SIZE(adapter_parm)) {
+ if (type < 0) {
+ printk(KERN_WARNING "i2c-parport: adapter type unspecified\n");
+ return -ENODEV;
+ }
+
+ if (type >= ARRAY_SIZE(adapter_parm)) {
printk(KERN_WARNING "i2c-parport: invalid type (%d)\n", type);
- type = 0;
+ return -ENODEV;
}
if (base == 0) {
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/i2c-parport.h
+++ linux-2.6.16-rc6/drivers/i2c/busses/i2c-parport.h
@@ -90,7 +90,7 @@ static struct adapter_parm adapter_parm[
},
};
-static int type;
+static int type = -1;
module_param(type, int, 0);
MODULE_PARM_DESC(type,
"Type of adapter:\n"
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/i2c-parport.c
+++ linux-2.6.16-rc6/drivers/i2c/busses/i2c-parport.c
@@ -241,9 +241,14 @@ static struct parport_driver i2c_parport
static int __init i2c_parport_init(void)
{
- if (type < 0 || type >= ARRAY_SIZE(adapter_parm)) {
+ if (type < 0) {
+ printk(KERN_WARNING "i2c-parport: adapter type unspecified\n");
+ return -ENODEV;
+ }
+
+ if (type >= ARRAY_SIZE(adapter_parm)) {
printk(KERN_WARNING "i2c-parport: invalid type (%d)\n", type);
- type = 0;
+ return -ENODEV;
}
return parport_register_driver(&i2c_parport_driver);
--
Mark M. Hoffman
[email protected]
Hi Jan,
On 2006-03-15, Jan Engelhardt wrote:
> > > I have this lspci:
> > > (...)
> > > 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
> > > (...)
> > > 0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
> >
> > Off-topic, but it's quite strange. Your south bridge cannot be a
> > VT8237R and a VT8235 at the same time...
>
> Where does it say that the southbridge is 35 and 37 at the same time?
> (The only thing that's different between the two lspci lines is the
> vtABCD number...)
"The only thing that's different is the thing you said was different."
:)
It looked strange to me because I have two systems with a VT8237R and on
both, lspci says "VT8237" for both the PCI and the ISA bridges. So the
result provided by Etienne suggests that a different (supposedly
earlier) version of the VT8237R has a different ISA bridge sub-device
embedded.
Not that it really matters, anyway, so I probably shouldn't have
commented on it in the first place.
> Or it looks like there's another of these "strange" cases:
>
> 0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo
> MVP3/Pro133x AGP]
> 0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C596 ISA [Mobile South]
> (rev 23)
There are many of these, indeed. South bridges include several
sub-devices, and it is very frequent that chip manufacturers do not
upgrade all these sub-devices when they release a new version of their
chip.
My original comment was really related to the specific case of the
VT8237R, not general.
Thanks,
--
Jean Delvare
Hi Mark,
On 2006-03-16, Mark M. Hoffman wrote:
> Here's a start: why does i2c-parport[-light] have a default adapter
> type?
I think I made it look as closely as possible like the old
i2c-philips-par driver, which is was replacing, so that users could
switch with the least effort.
> Loading it with the default could be considered an accident by
> definition. It takes ~6 seconds to load all of
> kernel/drivers/hwmon/*.ko on a test box here with i2c-parport-light
> present (but without any adapter hardware). With this patch, that
> drops to ~1 second.
Note that the same result could be achieved by using
i2c_algo_bit.bit_test=1, which is why I was suggesting to make it the
default. Doing so would also help the radeonfb driver users: this one
creates up to 4 i2c busses and at least one does not work for me (I
guess it depends on how the chip was wired on the graphics adapter),
causing significant delays on when loading i2c chip drivers afterwards.
I wonder if i2c_algo_bit.bit_test=1 can cause problems. Why wasn't it
made the default in the first place?
> This patch forces the user to specify what type of adapter is present
> when loading i2c-parport or i2c-parport-light. If none is specified,
> the driver init simply fails - instead of assuming adapter type 0.
>
> This alleviates the sometimes lengthy boot time delays which can be
> caused by accidentally building one of these into a kernel along with
> several i2c slave drivers that have lengthy probe routines (e.g. hwmon
> drivers).
This makes sense, no adapter type is more likely to be found than the
others. So I like the patch and am willing to accept it. However, given
that it changes the default behavior, and makes the "type" module
parameter mandatory, a short notice in the documentation and/or Kconfig
would be welcome, don't you think?
Thanks,
--
Jean Delvare
>> Jean Delvare wrote:
>> Mark, can you provide a patch to your i2c-sis96x driver so that it'll
>> keep quiet when no supported device is found?
>
>Mark M. Hoffman wrote:
>Lots of drivers printk messages when they load - IMO it's useful info.
>E.g. how else could Etienne discover that he accidentally built a kernel
>with dozens of i2c bus drivers (and probably all of the hwmon drivers)
>built-in by accident?
I did not built with all hwmon drivers because I could determine what I
had on my mainboard. For me, because the kernel say it enters the I2C
system by the line:
Mar 13 21:46:48 kernel: [ 47.705445] i2c /dev entries driver
It could print a line when finished probing all those I2C drivers by a
line like:
Mar 13 21:46:48 kernel: [ 50.705445] i2c driver found: aaa-i2c, bbb-i2c.
And then I can have a clue on what to include in my monolitic build.
I do not care about such timeout on _one_ build, as long as I know what
to do for next build. Another possibility is to print a line when an I2C
detection has failed: you know that it has taken quite a lot of time and
it should not have been done in the first place (even for a module
because this module should not have been inserted).
It also protect the I2C group from people like me complainning
because completely unrelated messages like
Mar 13 22:12:54 kernel: [ 61.997032] : Detection failed at step 3
Elsewhere Jean Delvare wrote:
> That being said, the key problem being stuck i2c busses, it's even more
> important to get rid of these. You can use "i2cdetect -l" to list all
> detected i2c bus, so you'll see if you have any unwanted bus left.
I do not have this i2cdetect software installed on my system.
> If all drivers were actually printking messages when they load,
> monolithic kernels would be a mess (not that I much understand the
> point of such monolithic kernels, but...) You wouldn't be able to tell from
> the boot log which drivers are actually used by the system, and which
> aren't.
Maybe it is only me, and I am totally wrong, but it seems that the
resulting _monolitic_ kernel is quicker.
- Maybe it is quicker because a lot of modules try to insert themself
and fails as an autodetection subsystem in some distributions.
- Maybe because fetching a lot of files (kernel modules) at boot
time creates a lot of disk activity - and it is better to load everything
at startup by the bootloader (hint: Gujin).
- Maybe it is quicker because when loading a module there is a lot
of addresses to resolve at run time and that takes time, instead of
doing it once when you are linking the monolitic kernel.
- Maybe it is simply (correct me if I am wrong) because modules
_have_ to be compiled as a relocatable library (because the load
address of code and data segment isn't known) and that is acheived
by the compiler by fixing register %ebx to the base address - and
on i386 removing one of the 4 (or 6) general purpose register
produces code which is a lot slower (up to the point you do not care
for which processor you compile the kernel: the improvement done
by one or two added instruction/features do not compensate for this
kind of loss).
Maybe also managing the tree /lib/modules/* and the initrd take
more time than simply doing once a clean linux/.config and
maintaining this file by saying "No" to most added drivers...
Cheers,
Etienne.
___________________________________________________________________________
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.
T?l?chargez sur http://fr.messenger.yahoo.com
Hi Jean:
> On 2006-03-16, Mark M. Hoffman wrote:
> > Loading it with the default could be considered an accident by
> > definition. It takes ~6 seconds to load all of
> > kernel/drivers/hwmon/*.ko on a test box here with i2c-parport-light
> > present (but without any adapter hardware). With this patch, that
> > drops to ~1 second.
* Jean Delvare <[email protected]> [2006-03-16 09:46:51 +0100]:
> Note that the same result could be achieved by using
> i2c_algo_bit.bit_test=1, which is why I was suggesting to make it the
> default. Doing so would also help the radeonfb driver users: this one
> creates up to 4 i2c busses and at least one does not work for me (I
> guess it depends on how the chip was wired on the graphics adapter),
> causing significant delays on when loading i2c chip drivers afterwards.
>
> I wonder if i2c_algo_bit.bit_test=1 can cause problems. Why wasn't it
> made the default in the first place?
It doesn't look very reliable to me. E.g. if there happens to be bus
traffic during the bus test, it fails. If it gets past that, it gets
worse...
5. A START condition immediately followed by a STOP condition
(void message) is an illegal format.
- I2C Bus Specification, Version 2.1 (page 14)
Unless I read it wrong, that's exactly what the bus test will do.
> > This patch forces the user to specify what type of adapter is present
> > when loading i2c-parport or i2c-parport-light. If none is specified,
> > the driver init simply fails - instead of assuming adapter type 0.
> >
> > This alleviates the sometimes lengthy boot time delays which can be
> > caused by accidentally building one of these into a kernel along with
> > several i2c slave drivers that have lengthy probe routines (e.g. hwmon
> > drivers).
>
> This makes sense, no adapter type is more likely to be found than the
> others. So I like the patch and am willing to accept it. However, given
> that it changes the default behavior, and makes the "type" module
> parameter mandatory, a short notice in the documentation and/or Kconfig
> would be welcome, don't you think?
OK - patch to follow.
Regards,
--
Mark M. Hoffman
[email protected]
This patch forces the user to specify what type of adapter is present when
loading i2c-parport or i2c-parport-light. If none is specified, the driver
init simply fails - instead of assuming adapter type 0.
This alleviates the sometimes lengthy boot time delays which can be caused
by accidentally building one of these into a kernel along with several i2c
slave drivers that have lengthy probe routines (e.g. hwmon drivers).
Kconfig and documentation updated accordingly.
Signed-off-by: Mark M. Hoffman <[email protected]>
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/i2c-parport-light.c
+++ linux-2.6.16-rc6/drivers/i2c/busses/i2c-parport-light.c
@@ -121,9 +121,14 @@ static struct i2c_adapter parport_adapte
static int __init i2c_parport_init(void)
{
- if (type < 0 || type >= ARRAY_SIZE(adapter_parm)) {
+ if (type < 0) {
+ printk(KERN_WARNING "i2c-parport: adapter type unspecified\n");
+ return -ENODEV;
+ }
+
+ if (type >= ARRAY_SIZE(adapter_parm)) {
printk(KERN_WARNING "i2c-parport: invalid type (%d)\n", type);
- type = 0;
+ return -ENODEV;
}
if (base == 0) {
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/i2c-parport.h
+++ linux-2.6.16-rc6/drivers/i2c/busses/i2c-parport.h
@@ -90,7 +90,7 @@ static struct adapter_parm adapter_parm[
},
};
-static int type;
+static int type = -1;
module_param(type, int, 0);
MODULE_PARM_DESC(type,
"Type of adapter:\n"
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/i2c-parport.c
+++ linux-2.6.16-rc6/drivers/i2c/busses/i2c-parport.c
@@ -241,9 +241,14 @@ static struct parport_driver i2c_parport
static int __init i2c_parport_init(void)
{
- if (type < 0 || type >= ARRAY_SIZE(adapter_parm)) {
+ if (type < 0) {
+ printk(KERN_WARNING "i2c-parport: adapter type unspecified\n");
+ return -ENODEV;
+ }
+
+ if (type >= ARRAY_SIZE(adapter_parm)) {
printk(KERN_WARNING "i2c-parport: invalid type (%d)\n", type);
- type = 0;
+ return -ENODEV;
}
return parport_register_driver(&i2c_parport_driver);
--- linux-2.6.16-rc6.orig/drivers/i2c/busses/Kconfig
+++ linux-2.6.16-rc6/drivers/i2c/busses/Kconfig
@@ -284,7 +284,10 @@ config I2C_PARPORT
This driver is a replacement for (and was inspired by) an older
driver named i2c-philips-par. The new driver supports more devices,
and makes it easier to add support for new devices.
-
+
+ An adapter type parameter is now mandatory. Please read the file
+ Documentation/i2c/busses/i2c-parport for details.
+
Another driver exists, named i2c-parport-light, which doesn't depend
on the parport driver. This is meant for embedded systems. Don't say
Y here if you intend to say Y or M there.
--- linux-2.6.16-rc6.orig/Documentation/i2c/busses/i2c-parport
+++ linux-2.6.16-rc6/Documentation/i2c/busses/i2c-parport
@@ -12,18 +12,21 @@ meant as a replacement for the older, in
teletext adapters)
It currently supports the following devices:
- * Philips adapter
- * home brew teletext adapter
- * Velleman K8000 adapter
- * ELV adapter
- * Analog Devices evaluation boards (ADM1025, ADM1030, ADM1031, ADM1032)
- * Barco LPT->DVI (K5800236) adapter
+ * (type=0) Philips adapter
+ * (type=1) home brew teletext adapter
+ * (type=2) Velleman K8000 adapter
+ * (type=3) ELV adapter
+ * (type=4) Analog Devices ADM1032 evaluation board
+ * (type=5) Analog Devices evaluation boards: ADM1025, ADM103[01]
+ * (type=6) Barco LPT->DVI (K5800236) adapter
These devices use different pinout configurations, so you have to tell
the driver what you have, using the type module parameter. There is no
way to autodetect the devices. Support for different pinout configurations
can be easily added when needed.
+Earlier kernels defaulted to type=0 (Philips). But now, if the type
+parameter is missing, the driver will simply fail to initialize.
Building your own adapter
-------------------------
--
Mark M. Hoffman
[email protected]
Hi Etienne:
> >Mark M. Hoffman wrote:
> >Lots of drivers printk messages when they load - IMO it's useful info.
> >E.g. how else could Etienne discover that he accidentally built a kernel
> >with dozens of i2c bus drivers (and probably all of the hwmon drivers)
> >built-in by accident?
* Etienne Lorrain <[email protected]> [2006-03-16 11:53:32 +0100]:
> I did not built with all hwmon drivers because I could determine what I
> had on my mainboard.
Really? If you don't have all the hwmon drivers built in, then I'm not
sure how the i2c subsystem could take so long to init. Can we see the
entire kernel config please?
> For me, because the kernel say it enters the I2C
> system by the line:
> Mar 13 21:46:48 kernel: [ 47.705445] i2c /dev entries driver
That message comes from the (optional) Linux i2c ioctl interface. It is not
the whole core.
> It could print a line when finished probing all those I2C drivers by a
> line like:
> Mar 13 21:46:48 kernel: [ 50.705445] i2c driver found: aaa-i2c, bbb-i2c.
Actually, it can't do that. The i2c core doesn't know anything about
"done probing". It probes whenever a new master or slave driver is
registered, which could happen at any time.
> And then I can have a clue on what to include in my monolitic build.
> I do not care about such timeout on _one_ build, as long as I know what
> to do for next build. Another possibility is to print a line when an I2C
> detection has failed: you know that it has taken quite a lot of time and
> it should not have been done in the first place (even for a module
> because this module should not have been inserted).
Why don't you just use the sensors-detect script from the lm-sensors project
to see what hardware you have? If you don't have a kernel with all of the
i2c-bus drivers built as modules, you could probably just boot knoppix and
run the script from there.
> It also protect the I2C group from people like me complainning
> because completely unrelated messages like
> Mar 13 22:12:54 kernel: [ 61.997032] : Detection failed at step 3
That particular message is displayed by accident; it's a bug. Jean already
ack'ed that.
Regards,
--
Mark M. Hoffman
[email protected]
--- "Mark M. Hoffman" wrote:
> * Etienne Lorrain [2006-03-16 11:53:32 +0100]:
> > I did not built with all hwmon drivers because I could determine what I
> > had on my mainboard.
>
> Really? If you don't have all the hwmon drivers built in, then I'm not
> sure how the i2c subsystem could take so long to init. Can we see the
> entire kernel config please?
That is the real 2.6.16 with only CONFIG_I2C_VIAPRO=y (the only I2C module loaded
using Knoppix on my motherboard) (full .config attached):
Mar 20 22:12:34 ubuntu kernel: [ 102.107512] input: PC Speaker as /class/input/input2
Mar 20 22:12:34 ubuntu kernel: [ 102.110230] i2c /dev entries driver
Mar 20 22:12:34 ubuntu kernel: [ 102.151923] : Detection failed at step 3
Mar 20 22:12:34 ubuntu kernel: [ 102.287882] hdaps: supported laptop not found!
Mar 20 22:12:34 ubuntu kernel: [ 102.290460] hdaps: driver init failed (ret=-6)!
Mar 20 22:12:34 ubuntu kernel: [ 102.299862] md: linear personality registered for level
-1
etienne@ubuntu:~/linux/linux-2.6.16$ diff .config-initial .config
4c4
< # Mon Mar 20 21:36:32 2006
---
> # Mon Mar 20 22:03:44 2006
885c885
< # CONFIG_I2C_PCA_ISA is not set
---
> CONFIG_I2C_PCA_ISA=y
892c892
< # CONFIG_SENSORS_EEPROM is not set
---
> CONFIG_SENSORS_EEPROM=y
896c896
< # CONFIG_SENSORS_RTC8564 is not set
---
> CONFIG_SENSORS_RTC8564=y
etienne@ubuntu:~/linux/linux-2.6.16$
Leads to 21 seconds delay:
Mar 20 22:16:34 ubuntu kernel: [ 47.768105] drivers/usb/input/hid-core.c: v2.6:USB HID
core driver
Mar 20 22:16:34 ubuntu kernel: [ 47.770813] usbcore: registered new driver microtekX6
Mar 20 22:16:34 ubuntu kernel: [ 47.773540] mice: PS/2 mouse device common for all mice
Mar 20 22:16:34 ubuntu kernel: [ 47.822537] input: AT Translated Set 2 keyboard as
/class/input/input1
Mar 20 22:16:34 ubuntu kernel: [ 47.825434] input: PC Speaker as /class/input/input2
Mar 20 22:16:34 ubuntu kernel: [ 47.828153] i2c /dev entries driver
Mar 20 22:16:34 ubuntu kernel: [ 47.831032] i2c-pca-isa: i/o base 0x000330. irq 10
Mar 20 22:16:34 ubuntu kernel: [ 68.239670] : Detection failed at step 3
Mar 20 22:16:34 ubuntu kernel: [ 68.375633] hdaps: supported laptop not found!
Mar 20 22:16:34 ubuntu kernel: [ 68.378227] hdaps: driver init failed (ret=-6)!
Mar 20 22:16:34 ubuntu kernel: [ 68.387599] md: linear personality registered for level
-1
BTW, someone knows what are those messages just after startup:
Mar 20 22:12:34 ubuntu kernel: No module symbols loaded - kernel modules not enabled.
Mar 20 22:12:34 ubuntu kernel: >[ 93.075610] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.075649] test 4:
Mar 20 22:12:34 ubuntu kernel: [ 93.075692] 697eaf0aca3a3aea3a75164746ffaa79
Mar 20 22:12:34 ubuntu kernel: [ 93.076226] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.076266] test 5:
Mar 20 22:12:34 ubuntu kernel: [ 93.076309] 56461ef2342edc00f9bab995690efd4c
Mar 20 22:12:34 ubuntu kernel: [ 93.076857] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.076896] test 6:
Mar 20 22:12:34 ubuntu kernel: [ 93.076941] 6b1ab7fe4bd7bf8f0b62e6ce61b9d0cd
Mar 20 22:12:34 ubuntu kernel: [ 93.077475] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.077514] test 7:
Mar 20 22:12:34 ubuntu kernel: [ 93.077559] 6f630fad67cda0ee1fb1f562db3aa53e
Mar 20 22:12:34 ubuntu kernel: [ 93.078093] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.078133]
Mar 20 22:12:34 ubuntu kernel: [ 93.078134] testing hmac_md5 across pages
Mar 20 22:12:34 ubuntu kernel: [ 93.078269] test 1:
Mar 20 22:12:34 ubuntu kernel: [ 93.078314] 750c783e6ab0b503eaa86e310a5db738
Mar 20 22:12:34 ubuntu kernel: [ 93.078848] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.078889]
Mar 20 22:12:34 ubuntu kernel: [ 93.078890] testing hmac_sha1
Mar 20 22:12:34 ubuntu kernel: [ 93.078973] test 1:
Mar 20 22:12:34 ubuntu kernel: [ 93.079020] b617318655057264e28bc0b6fb378c8ef146be00
Mar 20 22:12:34 ubuntu kernel: [ 93.079678] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.079717] test 2:
Mar 20 22:12:34 ubuntu kernel: [ 93.079762] effcdf6ae5eb2fa2d27416d5f184df9c259a7c79
Mar 20 22:12:34 ubuntu kernel: [ 93.080432] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.080472] test 3:
Mar 20 22:12:34 ubuntu kernel: [ 93.080517] 125d7342b9ac11cd91a39af48aa17b4f63f175d3
Mar 20 22:12:34 ubuntu kernel: [ 93.081175] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.081214] test 4:
Mar 20 22:12:34 ubuntu kernel: [ 93.081260] 4c9007f4026250c6bc8414f9bf50c86c2d7235da
Mar 20 22:12:34 ubuntu kernel: [ 93.081917] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.081957] test 5:
Mar 20 22:12:34 ubuntu kernel: [ 93.082649] 4c1a03424b55e07fe7f27be1d58bb9324a9a5a04
Mar 20 22:12:34 ubuntu kernel: [ 93.083307] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.083347] test 6:
Mar 20 22:12:34 ubuntu kernel: [ 93.083394] aa4ae5e15272d00e95705637ce8a3b55ed402112
Mar 20 22:12:34 ubuntu kernel: [ 93.084051] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.084090] test 7:
Mar 20 22:12:34 ubuntu kernel: [ 93.084138] e8e99d0f45237d786d6bbaa7965c7808bbff1a91
Mar 20 22:12:34 ubuntu kernel: [ 93.084808] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.084848]
Mar 20 22:12:34 ubuntu kernel: [ 93.084849] testing hmac_sha1 across pages
Mar 20 22:12:34 ubuntu kernel: [ 93.084936] test 1:
Mar 20 22:12:34 ubuntu kernel: [ 93.084981] effcdf6ae5eb2fa2d27416d5f184df9c259a7c79
Mar 20 22:12:34 ubuntu kernel: [ 93.085639] pass
Mar 20 22:12:34 ubuntu kernel: [ 93.085681]
Regards,
Etienne.
___________________________________________________________________________
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.
T?l?chargez sur http://fr.messenger.yahoo.com
Hi Mark,
> This patch forces the user to specify what type of adapter is present when
> loading i2c-parport or i2c-parport-light. If none is specified, the driver
> init simply fails - instead of assuming adapter type 0.
>
> This alleviates the sometimes lengthy boot time delays which can be caused
> by accidentally building one of these into a kernel along with several i2c
> slave drivers that have lengthy probe routines (e.g. hwmon drivers).
>
> Kconfig and documentation updated accordingly.
Good patch, thanks, I've applied it. The only change I made is:
> + * (type=5) Analog Devices evaluation boards: ADM1025, ADM103[01]
I expanded it to "ADM1025, ADM1030, ADM1031", because I think it's
important to be able to just grep chip names in the documentation files
(or source code, for that matter.)
Thanks,
--
Jean Delvare
Hi Etienne, Ian:
Etienne: sorry for the delay... I have't forgotten about you.
Recap for Ian: Etienne was suffering very long delays at boot time due
to some combination of I2C / hwmon drivers built-in (not modular) to
his kernel.
* Etienne Lorrain <[email protected]> [2006-03-21 00:00:37 +0100]:
> --- "Mark M. Hoffman" wrote:
> > * Etienne Lorrain [2006-03-16 11:53:32 +0100]:
> > > I did not built with all hwmon drivers because I could determine what I
> > > had on my mainboard.
> >
> > Really? If you don't have all the hwmon drivers built in, then I'm not
> > sure how the i2c subsystem could take so long to init. Can we see the
> > entire kernel config please?
>
> That is the real 2.6.16 with only CONFIG_I2C_VIAPRO=y (the only I2C module loaded
> using Knoppix on my motherboard) (full .config attached):
OK: you didn't have all the hwmon/sensors drivers built in, just seven of
them. ;) This really is not a good idea. In an ideal world, these drivers
would notice that the hardware is not present and move on. But I2C/SMBus is
not like PCI. There is no single ID to read and test. This hardware is only
recognized based on heuristics. And the probing itself takes time: especially
if you have a very slow I2C bus. More on that later...
> 885c885
> < # CONFIG_I2C_PCA_ISA is not set
> ---
> > CONFIG_I2C_PCA_ISA=y
This alone is the cause of the delay. (I have confirmed it by running some
similar .configs here.) You almost certainly don't own this specialized
piece of hardware. Worse still, that particular driver has no code to detect
whether or not the hardware is present. I cc'ed the listed driver author
(Ian) just in case this might be corrected... but I guess there is no way
to fix it.
So the delay is (1) an I2C bus driver that is not actually present, trying to
probe for (2) seven different sensors chip drivers that certainly aren't present
on the nonexistent bus. Timeouts ensue.
So unless Ian knows a better way to detect that bus driver... the best I can
advise is to *not* build in those drivers for hardware that you do not have.
Regards,
--
Mark M. Hoffman
[email protected]
--- "Mark M. Hoffman" <[email protected]> wrote:
> > 885c885
> > < # CONFIG_I2C_PCA_ISA is not set
> > ---
> > > CONFIG_I2C_PCA_ISA=y
>
> This alone is the cause of the delay. (I have confirmed it by running some
> similar .configs here.) You almost certainly don't own this specialized
> piece of hardware. Worse still, that particular driver has no code to detect
> whether or not the hardware is present. I cc'ed the listed driver author
> (Ian) just in case this might be corrected... but I guess there is no way
> to fix it.
>
> So the delay is (1) an I2C bus driver that is not actually present, trying to
> probe for (2) seven different sensors chip drivers that certainly aren't present
> on the nonexistent bus. Timeouts ensue.
>
> So unless Ian knows a better way to detect that bus driver... the best I can
> advise is to *not* build in those drivers for hardware that you do not have.
OK, I know the I2C protocol, and I can imagine a hardware board which does
not have a way to detect its own presence - or the presence of its own ISA bus.
What I dislike the most is that, after the driver has taken more than 20
seconds to probe something it did not find, it did not display anything to
say "either there is a hardware problem, or you should disable me".
Are you sure that there isn't any distribution around trying to insert
_all_ the modules to do hardware detection?
Note that most I2C driver detect abscence of the hardware in a lot less than
a second: most of the I2C system is fine.
Regards,
Etienne.
___________________________________________________________________________
Nouveau : t?l?phonez moins cher avec Yahoo! Messenger ! D?couvez les tarifs exceptionnels pour appeler la France et l'international.
T?l?chargez sur http://fr.messenger.yahoo.com
Hello Etienne:
* Etienne Lorrain <[email protected]> [2006-03-29 11:26:28 +0200]:
> --- "Mark M. Hoffman" <[email protected]> wrote:
> > > 885c885
> > > < # CONFIG_I2C_PCA_ISA is not set
> > > ---
> > > > CONFIG_I2C_PCA_ISA=y
> >
> > This alone is the cause of the delay. (I have confirmed it by running some
> > similar .configs here.) You almost certainly don't own this specialized
> > piece of hardware. Worse still, that particular driver has no code to detect
> > whether or not the hardware is present. I cc'ed the listed driver author
> > (Ian) just in case this might be corrected... but I guess there is no way
> > to fix it.
> >
> > So the delay is (1) an I2C bus driver that is not actually present, trying to
> > probe for (2) seven different sensors chip drivers that certainly aren't present
> > on the nonexistent bus. Timeouts ensue.
> >
> > So unless Ian knows a better way to detect that bus driver... the best I can
> > advise is to *not* build in those drivers for hardware that you do not have.
>
> OK, I know the I2C protocol, and I can imagine a hardware board which does
> not have a way to detect its own presence - or the presence of its own ISA bus.
> What I dislike the most is that, after the driver has taken more than 20
> seconds to probe something it did not find, it did not display anything to
> say "either there is a hardware problem, or you should disable me".
I repeat just once more: the supported method for identifying hwmon/sensors
chips is a Perl script called sensors-detect that is distributed with the
lm-sensors package.
> Are you sure that there isn't any distribution around trying to insert
> _all_ the modules to do hardware detection?
No, because that is not supported. All of the major distributions package
lm-sensors, and AFAIK they all build hwmon/sensors as modules. They don't
insert any of them by default. If a distro was silly enough to blindly
insert them all... then it would take forever to boot and nobody would use
it.
> Note that most I2C driver detect abscence of the hardware in a lot less than
> a second: most of the I2C system is fine.
Feel free to write a patch for drivers/busses/i2c/i2c-pca-isa.c; I don't
have that hardware myself. Otherwise, my final advice is:
Patient: It hurts when I do this.
Doctor: Don't do that.
Regards,
--
Mark M. Hoffman
[email protected]
On Tue, 2006-03-28 at 22:45 -0500, Mark M. Hoffman wrote:
>
> This alone is the cause of the delay. (I have confirmed it by running
> some similar .configs here.) You almost certainly don't own this
> specialized piece of hardware. Worse still, that particular driver
> has no code to detect whether or not the hardware is present. I cc'ed
> the listed driver author (Ian) just in case this might be corrected...
> but I guess there is no way to fix it.
>
> So the delay is (1) an I2C bus driver that is not actually present,
> trying to probe for (2) seven different sensors chip drivers that
> certainly aren't present on the nonexistent bus. Timeouts ensue.
>
> So unless Ian knows a better way to detect that bus driver... the best
> I can advise is to *not* build in those drivers for hardware that you
> do not have.
I don't work at Arcom anymore so I don't have access to the hardware,
but I don't know of a better way off the top of my head how to detect
the presence of the PCA chip.
You are unlikely to have the particular PC/104 card the driver was
written for. If I recall correctly PCA chip itself doesn't do ISA (it
has simple processor bus chip select type arrangement I think) but the
PC/104 card in question has a small CPLD which does the address decoding
for ISA. I guess you are unlikely to find another ISA card which has the
PCA chip on it.
It's possible that you might have an embedded board with the PCA chip
directly on it -- but if you don't then I don't know why you would
enable the driver.
Ian.
--
Ian Campbell
To save a single life is better than to build a seven story pagoda.