Latest working kernel version: 2.6.25 Earliest failing kernel version: 2.6.26 Distribution: Debian lenny Hardware Environment: ABit IP35-pro Bios rev 16 (2008-march-18) Software Environment: Linux 2.6.26 #2 SMP i686 abituguru3 is the first module loaded on boot (added in /etc/modules) Problem Description: uguru3 is not recognized on boot since i upgraded to kernel 2.6.26 but it works after force. Steps to reproduce: $ modprobe abituguru3 ; dmesg | tail -1 abituguru3: no Abit uGuru3 found, data = 0x00, cmd = 0x4C $ modprobe abituguru3 ; dmesg | tail -2 abituguru3: Assuming Abit uGuru3 is present because of "force" parameter abituguru3: found Abit uGuru3, motherboard ID: 001A (Abit IP35 Pro) $ rmmod abituguru3 $ modprobe abituguru3 ; dmesg | tail -1 abituguru3: found Abit uGuru3, motherboard ID: 001A (Abit IP35 Pro)
Can you please see if http://userweb.kernel.org/~akpm/mmotm/broken-out/hwmon-fix-loading-of-abituguru3-on-abit-ip35-pro-with-bios-17.patch fixes it?
Unfortunately it won't. Alain's cmd_val is 0x4C which isn't covered by the growing list of exceptional cases in abituguru3_detect(). It's now clear to me that this detect function is completely bogus on at least the IP35 Pro. Without vendor documentation I think abituguru3_detect() should simply be removed and this driver should depend on CONFIG_DMI. Effectively the driver would be force-installed on all supported mainboards. I think this is reasonable because AFAIK the uguru chip cannot be disabled.
I forgot to mention that it isn't enough to use the DMI checks already present in the driver. These only check the mainboard vendor information. Not all ABIT boards have a uguru chip. Therefore the driver would have to be enhanced to check the mainboard model itself. This information is already vaguely available in the driver (which has a list of supported mainboards). Unfortunately some of these are marked as "unknown", and I don't know why.
Alistair, Thanks for bringing this to my attention! I agree that in the future we should fully move to DMI based detection for the abituguru3. But for now we can't as I don't know all the DMI identification strings for all uguru3 equipped mainboards. So I would like to suggest the following: 1) Start building a list of DMI board strings for the motherboards, starting with the IP35-pro, as that one seems to be causing all the problems. 2) Use that list to detect the uguru, and only fall back to the current detect code if the motherboard is not found on that list. Alistair, could you write a patch for this, I think it would be best to add the DMI board strings to the already existing motherboard data table, then we can quickly see if we have the list complete (and thus completely remove the old detection). More in general Alistair, would you consider becoming the maintainer of the uguru3 driver? I don't own and never have owned an uguru3 motherboard, I only wrote this driver (with much help from some kind testers) as I also wrote the uguru (1 & 2) driver, for which I do own a board. Except for this detection problems, there has been very little maintainance needed, also it is good to from time to time grab the latest windows util, install it under wine, and see if there are ini files describing new motherboards there, which you can then add to the table in the driver. Unfortunately said windows ini files do not contain the DMI board string.
I will write the patch and would be happy to take over maintenance of this driver. I'll post the patch ASAP, hopefully it's still not too late for 2.6.27. Thanks.
(In reply to comment #5) > I will write the patch and would be happy to take over maintenance of this > driver. Cool and thanks, my plate is full enough as it is. I've just checked what the latest version of the windows uguru utility is and that is v3.1.0.9, which contains no motherboards not yet known by the kernel driver. I'll attach a little perl script (written by someone else) which is convienient for converting new windows motherboard ini files to the data struct used in the driver.
Created attachment 17055 [details] promised perl script
Created attachment 17056 [details] Use DMI more aggressively in abituguru3, fixing IP35 Pro regressions This patch should fix the issue forever more (tm). Andrew, is there a chance in hell of this getting into 2.6.27? Mark Hoffman just announced he's stepping down as the hwmon maintainer, so who should these be sent to? You? Additionally, I don't know if you'd prefer the patches were broken up; at the moment this patch modifies MAINTAINERS in the same swoop as the driver.
(In reply to comment #8) > Andrew, is there a chance in hell of this getting into 2.6.27? Mark Hoffman > just announced he's stepping down as the hwmon maintainer, so who should > these > be sent to? You? > Yes Andrew is the correct person to send hwmon patches to now. I don't know how well Andrew reads his bugzilla spam :) So please send him the patch in a direct mail and cc the lm_sensors list. Also feel free to add a: Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl> Line in the patch.
du message de bugme-daemon@bugzilla.kernel.org du 1 Aug > http://bugzilla.kernel.org/show_bug.cgi?id=11212 > > > > > > ------- Comment #9 from jwrdegoede@fedoraproject.org 2008-08-01 09:20 > ------- > (In reply to comment #8) > > Andrew, is there a chance in hell of this getting into 2.6.27? Mark Hoffman > > just announced he's stepping down as the hwmon maintainer, so who should > these > > be sent to? You? > > > > Yes Andrew is the correct person to send hwmon patches to now. I don't know > how > well Andrew reads his bugzilla spam :) So please send him the patch in a > direct > mail and cc the lm_sensors list. Also feel free to add a: > Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl> > Line in the patch. > > > -- > Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > Hello, sorry to be late, i had some problem with my computer (gnome hardly support multiple updates of debian lenny :)) as you said, the patches does make the detector work. I found this problem strange because the chip was detected until last kernel upgrade. Maybe its related to other options in the kernel... I don't know. if you need other tests or informations, don't hesitate, i'll do my best to help. regards
We're not really sure why the number changes but I suspect it's garbage until a certain point in the boot sequence. The vendor probably doesn't even bother probing for the Windows tool, and I'm guessing the Linux driver does so only based on observation. What the probe was doing here was acting as a barrier to stop people loading the driver if they didn't have the hardware. This new way acts as a much better barrier. Thanks for testing the patches.