More "issues" with -current - i2c problems

[Paul Goyette <paul%whooppee.com@localhost>]

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 whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------