Your message dated Fri, 04 May 2007 20:15:44 +0200 with message-id <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ---
