Current-Users archive

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

More "issues" with -current - i2c problems

I recently updated some of my machines from 6.99.23 (late July 2013) to 6.99.24 (mid October). After having fought and won a battle with the boot-loader, I'm now seeing some new problems, with i2c/piixpm.

The problems can be seen easily by using modload(8) to load the spdmem module. The module loads successfully and configures the two instances of the driver that should be present. Then, the kernel logs a timeout message from the piixpm(4) driver, and just "sits there" for several minutes; eventually, modload exits and I get a new shell prompt. (The delay is probably a result of the driver trying to read-and-checksum data from the ROMs on devices/instances at non-existent addresses.)

Now, this multi-minute delay is, by itself, pretty ugly. But things are even more screwed up at this point! If I reboot the machine, it seems that some sort of flags has been "tickled". The machine will power-off and then power-on, but it will not automatically boot. Pressing the "reset" button will start the boot process.

However, at this point the BIOS complains about something ("This CPU does not support the ASUS core-unlocker" or similar!), and requires me to enter BIOS Setup and save new settings. I have not seen any settings that actually need to be updated, but I must Save the new settings before I can boot!

I tried the same sequence of events, except I loaded the sdtemp module instead of spdmem. The long delay does not occur (as expected, since the sdtemp driver doesn't need to read any large amounts of ROM data). But the BIOS-is-corrupted problem still exists, and requires manual intervention in order to reboot.

I suspect that this behavior was introduced when i2c was modified (by soren?) to permit configurations that don't have hardwired i2c addresses. Both sdtemp and spdmem modules have hardwired addresses only, yet it would seem that the bus is being scanned and devices are being "probed" at addresses other than those that are explicitly referenced in these modules/drivers. (And one of these devices apparently has access to the BIOS's EPROM settings!)

I did notice that jdc introduced the ability to prevent indirect attach by setting the "i2c-indirect-config" property, but I don't know how this would be done on an amd64 machine, and it's not clear to me that I would still be able to attach driver instances when the module's ioconf file uses

        spdmem* at iic? addr 0x50

So, does anyone have any suggestions on how to proceed?

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index