[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#403051: marked as done (linux-image-2.6.18-3-686: lm78 hwmon driver stopped working on upgrade from Sarge)

Your message dated Fri, 04 May 2007 20:15:44 +0200
with message-id <871whwo3ov.fsf@obelix.mork.no>
and subject line linux-image-2.6.18-3-686: lm78 hwmon driver stopped working on upgrade from Sarge
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message --- 
Package: linux-image-2.6.18-3-686
Version: 2.6.18-7
Severity: normal

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

lm78 hwmon stopped working after upgrading from Sarge (kernel-image-2.6.8-3-686 
version 2.6.8-16sarge6) to Etch (linux-image-2.6.18-3-686 version 2.6.18-7).

The system is an Asus P2L97S, having a LM78-J on ISA port 0x290.  This used to 
show up as the directory /sys/bus/i2c/drivers/lm78/0-0290/. After upgrading,
this directory has disappeared:

canardo:/home/bjorn# lsmod|grep lm78
lm78                   15988  0 
i2c_isa                 5152  1 lm78
hwmon_vid               2784  1 lm78
i2c_core               19680  6 lm78,i2c_dev,i2c_algo_bit,i2c_isa,eeprom,i2c_piix4
canardo:/home/bjorn# ls -l /sys/bus/i2c/drivers/lm78/
total 0
- --w------- 1 root root 4096 2006-12-14 12:20 bind
lrwxrwxrwx 1 root root    0 2006-12-14 12:20 module -> ../../../../module/lm78
- --w------- 1 root root 4096 2006-12-14 12:20 unbind


sensors-detect still finds the chip:
...
Some chips are also accessible through the ISA I/O ports. We have to
write to arbitrary I/O ports to probe them. This is usually safe though.
Yes, you do have ISA I/O ports even if you do not have any ISA slots!
Do you want to scan the ISA I/O ports? (YES/no): 
Probing for `National Semiconductor LM78' at 0x290...       No
Probing for `National Semiconductor LM78-J' at 0x290...     Success!
    (confidence 6, driver `lm78')
Probing for `National Semiconductor LM79' at 0x290...       No
...
Driver `lm78' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `National Semiconductor LM78-J' (confidence: 6)
...
 
But sensors can't read anything (as expected since the sysfs entries are missing):
canardo:/home/bjorn# sensors
No sensors found!
Make sure you loaded all the kernel drivers you need.
Try sensors-detect to find out which these are.


Let me know if you need more information about the system.



Bjørn

- -- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (700, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.18-3-686 depends on:
ii  coreutils                     5.97-5     The GNU core utilities
ii  debconf [debconf-2.0]         1.5.8      Debian configuration management sy
ii  initramfs-tools [linux-initra 0.85c      tools for generating an initramfs
ii  module-init-tools             3.3-pre3-1 tools for managing Linux kernel mo

Versions of packages linux-image-2.6.18-3-686 recommends:
pn  libc6-i686                    <none>     (no description available)

- -- debconf information:
  linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/kimage-is-a-directory:
  linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true
  shared/kernel-image/really-run-bootloader: true
  linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true
  linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true
  linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686:
  linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk:
  linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686:
  linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false
  linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686:

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFFgThz10rqkowbIskRAucmAKCS/YiFi5tVyuL/XHnDO8Vu4cEcsACfdtrr
TvPdOWSXIMYTf3kgkedikP8=
=tBXe
-----END PGP SIGNATURE-----

--- End Message ---
--- Begin Message --- 
Bjørn Mork <bjorn@mork.no> writes:

> lm78 hwmon stopped working after upgrading from Sarge (kernel-image-2.6.8-3-686 
> version 2.6.8-16sarge6) to Etch (linux-image-2.6.18-3-686 version 2.6.18-7).
>
> The system is an Asus P2L97S, having a LM78-J on ISA port 0x290.  

This seems to be a motherboard bug.  Workaround:  boot with 
"pnpacpi=off"


I'll document a few details here for others Googling for answers to this
problem.  


With default settings in 2.6.18 (i.e. using PnP ACPI), I get this:


ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
PCI quirk: region e400-e43f claimed by PIIX4 ACPI
PCI quirk: region e800-e80f claimed by PIIX4 SMB
PIIX4 devres B PIO at 0290-0297
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:02: ioport range 0xe400-0xe43f could not be reserved
pnp: 00:02: ioport range 0xe800-0xe80f has been reserved
pnp: 00:02: ioport range 0x294-0x297 has been reserved



The bug is the ioport range 0x294-0x297, which is quite obviously wrong.
It should have matched the "PIIX4 devres B" line.  The result is that
request_region() in lm78.c fails. 


If I turn off  PnP ACPI, I get:


ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
PCI quirk: region e400-e43f claimed by PIIX4 ACPI
PCI quirk: region e800-e80f claimed by PIIX4 SMB
PIIX4 devres B PIO at 0290-0297
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fd1a0
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xd1d0, dseg 0xf0000
PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:0f: ioport range 0x290-0x297 has been reserved
pnp: 00:0f: ioport range 0xe400-0xe43f could not be reserved
pnp: 00:0f: ioport range 0xe800-0xe83f could not be reserved


lm78 works as it should with this, using the ioports at 0x290-0x297.

I suspect there are more bugs here too, looking at how the range
"0xe800-0xe80f" changed to "0xe800-0xe83f" without PnP ACPI.

Googling for "ioport range 0x294-0x297 has been reserved" makes me
suspect that this bug is present in quite a few P2Bxx and P2L97xx
motherboards by Asus.  They are old now, but there are probably still
many in use since they were quite popular 10 years ago.


I guess the faulty port range comes from this part of the ACPI DSDT
(disassembled using iasl):

            Device (PX40)
            {
                Name (_ADR, 0x00040000)
                OperationRegion (PIRQ, PCI_Config, 0x60, 0x04)
                Field (PIRQ, ByteAcc, NoLock, Preserve)
                {
                    PIRA,   8, 
                    PIRB,   8, 
                    PIRC,   8, 
                    PIRD,   8
                }

                Device (SYSR)
                {
                    Name (_HID, EisaId ("PNP0C02"))
                    Method (_CRS, 0, NotSerialized)
                    {
                        Name (BUF1, ResourceTemplate ()
                        {
                            IO (Decode16,
                                0x0000,             // Range Minimum
                                0x0000,             // Range Maximum
                                0x01,               // Alignment
                                0x40,               // Length
                                _Y06)
                            IO (Decode16,
                                0x0000,             // Range Minimum
                                0x0000,             // Range Maximum
                                0x01,               // Alignment
                                0x10,               // Length
                                _Y07)
                            IO (Decode16,
                                0x0294,             // Range Minimum
                                0x0294,             // Range Maximum
                                0x01,               // Alignment
                                0x04,               // Length
                                )



Is this something that should/could be worked around?  Or is using
pnpacpi=off the correct workaround here?



Bjørn

--- End Message ---
Reply to: