[lm-sensors] abituguru3: no Abit uGuru3 found

[lm-sensors] abituguru3: no Abit uGuru3 found

[Nick Pasich]

Starting getting this error after upgrading from 2.6.26.2 to 2.6.27.10

 > modprobe -v abituguru3

FATAL: Error inserting abituguru3 
(/lib/modules/2.6.27.10-smp/kernel/drivers/hwmon/abituguru3.ko): No such 
device

syslog info:

Jan  7 20:00:46 localhost kernel: abituguru3: no Abit uGuru3 found, data 
= 0x00, cmd = 0xFF


Mother Board: Abit IP35 Pro

Anyone else experiencing the same thing??
 
Thanks,

Nick Pasich



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Hans de Goede]

Nick Pasich wrote:
> Starting getting this error after upgrading from 2.6.26.2 to 2.6.27.10
> 

Hmm, did you by any chance perhaps also did a BIOS update, BIOS update's are 
known to cause problems (which we know how to fix, but we need to do this on a 
motherboard by motherboard basis).

To fix this we need the output of the command dmidecode (run as root), redirect 
it to a log file:
dmidecode &> log

And attach the log file please.

Thanks & Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Nick Pasich]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

No BIOS update....

Here's the output from "dmidecode" Attached...

Thanks Again..

  Nick



Hans de Goede wrote:
> Nick Pasich wrote:
>> Starting getting this error after upgrading from 2.6.26.2 to 2.6.27.10
>>
>
> Hmm, did you by any chance perhaps also did a BIOS update, BIOS 
> update's are known to cause problems (which we know how to fix, but we 
> need to do this on a motherboard by motherboard basis).
>
> To fix this we need the output of the command dmidecode (run as root), 
> redirect it to a log file:
> dmidecode &> log
>
> And attach the log file please.
>
> Thanks & Regards,
>
> Hans
>

[-- Attachment #2: zz_dmidecode.txt --]
[-- Type: text/plain, Size: 10500 bytes --]

# dmidecode 2.9
SMBIOS 2.5 present.
35 structures occupying 1093 bytes.
Table at 0x000F0000.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: Phoenix Technologies, LTD
	Version: 6.00 PG
	Release Date: 09/06/2007
	Address: 0xE0000
	Runtime Size: 128 kB
	ROM Size: 1024 kB
	Characteristics:
		ISA is supported
		PCI is supported
		PNP is supported
		APM is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		5.25"/360 KB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 KB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		Print screen service is supported (int 5h)
		8042 keyboard services are supported (int 9h)
		Serial services are supported (int 14h)
		Printer services are supported (int 17h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		LS-120 boot is supported
		ATAPI Zip drive boot is supported
		BIOS boot specification is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: OEM
	Product Name: OEM
	Version: OEM
	Serial Number: OEM
	UUID: 00000000-0000-0000-0000-00508DB55429
	Wake-up Type: Power Switch
	SKU Number:  
	Family:  

Handle 0x0002, DMI type 2, 10 bytes
Base Board Information
	Manufacturer: http://www.abit.com.tw/
	Product Name: IP35 PRO(P35+ICH9R)
	Version: 1.x (BIOS:10)
	Serial Number:  

Handle 0x0003, DMI type 3, 17 bytes
Chassis Information
	Manufacturer: OEM
	Type: Desktop
	Lock: Not Present
	Version: OEM
	Serial Number:  
	Asset Tag:  
	Boot-up State: Unknown
	Power Supply State: Unknown
	Thermal State: Unknown
	Security Status: Unknown
	OEM Information: 0x00000000

Handle 0x0004, DMI type 4, 40 bytes
Processor Information
	Socket Designation: Socket 775
	Type: Central Processor
	Family: Other
	Manufacturer: Intel
	ID: FB 06 00 00 FF FB EB BF
	Version: Intel(R)
	Voltage: 0.0 V
	External Clock: 272 MHz
	Max Speed: 4000 MHz
	Current Speed: 2448 MHz
	Status: Populated, Enabled
	Upgrade: ZIF Socket
	L1 Cache Handle: 0x000A
	L2 Cache Handle: 0x000B
	L3 Cache Handle: Not Provided
	Serial Number:  
	Asset Tag:  
	Part Number:  
	Characteristics: None

Handle 0x0005, DMI type 5, 24 bytes
Memory Controller Information
	Error Detecting Method: 8-bit Parity
	Error Correcting Capabilities:
		None
	Supported Interleave: One-way Interleave
	Current Interleave: One-way Interleave
	Maximum Memory Module Size: 2048 MB
	Maximum Total Memory Size: 8192 MB
	Supported Speeds:
		Other
	Supported Memory Types:
		DIMM
	Memory Module Voltage: 5.0 V
	Associated Memory Slots: 4
		0x0006
		0x0007
		0x0008
		0x0009
	Enabled Error Correcting Capabilities:
		None

Handle 0x0006, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: A0
	Bank Connections: 0
	Current Speed: Unknown
	Type: DIMM
	Installed Size: 1024 MB (Single-bank Connection)
	Enabled Size: 1024 MB (Single-bank Connection)
	Error Status: OK

Handle 0x0007, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: A1
	Bank Connections: 2 3
	Current Speed: Unknown
	Type: DIMM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x0008, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: A2
	Bank Connections: 4
	Current Speed: Unknown
	Type: DIMM
	Installed Size: 1024 MB (Single-bank Connection)
	Enabled Size: 1024 MB (Single-bank Connection)
	Error Status: OK

Handle 0x0009, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: A3
	Bank Connections: 6 7
	Current Speed: Unknown
	Type: DIMM
	Installed Size: 2048 MB (Double-bank Connection)
	Enabled Size: 2048 MB (Double-bank Connection)
	Error Status: OK

Handle 0x000A, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Internal Cache
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 KB
	Maximum Size: 32 KB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x000B, DMI type 7, 19 bytes
Cache Information
	Socket Designation: External Cache
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: External
	Installed Size: 4096 KB
	Maximum Size: 4096 KB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Unknown
	System Type: Unknown
	Associativity: Unknown

Handle 0x000C, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: PRIMARY IDE
	Internal Connector Type: On Board IDE
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x000D, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: SECONDARY IDE
	Internal Connector Type: On Board IDE
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: Other

Handle 0x000E, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: FDD
	Internal Connector Type: On Board Floppy
	External Reference Designator: Not Specified
	External Connector Type: None
	Port Type: 8251 FIFO Compatible

Handle 0x000F, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: COM1
	Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
	External Reference Designator:  
	External Connector Type: DB-9 male
	Port Type: Serial Port 16450 Compatible

Handle 0x0010, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: COM2
	Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
	External Reference Designator:  
	External Connector Type: DB-9 male
	Port Type: Serial Port 16450 Compatible

Handle 0x0011, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: LPT1
	Internal Connector Type: DB-25 female
	External Reference Designator:  
	External Connector Type: DB-25 female
	Port Type: Parallel Port ECP/EPP

Handle 0x0012, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: Keyboard
	Internal Connector Type: PS/2
	External Reference Designator:  
	External Connector Type: PS/2
	Port Type: Keyboard Port

Handle 0x0013, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: PS/2 Mouse
	Internal Connector Type: PS/2
	External Reference Designator:  
	External Connector Type: PS/2
	Port Type: Mouse Port

Handle 0x0014, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: Not Specified
	Internal Connector Type: None
	External Reference Designator: USB0
	External Connector Type: Other
	Port Type: USB

Handle 0x0015, DMI type 8, 9 bytes
Port Connector Information
	Internal Reference Designator: Not Specified
	Internal Connector Type: None
	External Reference Designator: USB1
	External Connector Type: Other
	Port Type: USB

Handle 0x0016, DMI type 13, 22 bytes
BIOS Language Information
	Installable Languages: 3
		n|US|iso8859-1
		n|US|iso8859-1
		r|CA|iso8859-1
	Currently Installed Language: n|US|iso8859-1

Handle 0x0017, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 4 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

Handle 0x0018, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0017
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 1024 MB
	Form Factor: DIMM
	Set: None
	Locator: A0
	Bank Locator: Bank0/1
	Type: Unknown
	Type Detail: Synchronous
	Speed: 800 MHz (1.2 ns)
	Manufacturer: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x0019, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0017
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: A1
	Bank Locator: Bank2/3
	Type: Unknown
	Type Detail: Synchronous
	Speed: 800 MHz (1.2 ns)
	Manufacturer: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x001A, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0017
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 1024 MB
	Form Factor: DIMM
	Set: None
	Locator: A2
	Bank Locator: Bank4/5
	Type: Unknown
	Type Detail: Synchronous
	Speed: 800 MHz (1.2 ns)
	Manufacturer: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x001B, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0017
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: DIMM
	Set: None
	Locator: A3
	Bank Locator: Bank6/7
	Type: Unknown
	Type Detail: Synchronous
	Speed: 800 MHz (1.2 ns)
	Manufacturer: Not Specified
	Serial Number: Not Specified
	Asset Tag: Not Specified
	Part Number: Not Specified

Handle 0x001C, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0017FFFFFFF
	Range Size: 6 GB
	Physical Array Handle: 0x0017
	Partition Width: 0

Handle 0x001D, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0003FFFFFFF
	Range Size: 1 GB
	Physical Device Handle: 0x0018
	Memory Array Mapped Address Handle: 0x001C
	Partition Row Position: 1

Handle 0x001E, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00040000000
	Ending Address: 0x000BFFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0019
	Memory Array Mapped Address Handle: 0x001C
	Partition Row Position: 1

Handle 0x001F, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x000C0000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 1 GB
	Physical Device Handle: 0x001A
	Memory Array Mapped Address Handle: 0x001C
	Partition Row Position: 1

Handle 0x0020, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00100000000
	Ending Address: 0x0017FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x001B
	Memory Array Mapped Address Handle: 0x001C
	Partition Row Position: 1

Handle 0x0021, DMI type 32, 11 bytes
System Boot Information
	Status: No errors detected

Handle 0x0022, DMI type 127, 4 bytes
End Of Table


[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Hans de Goede]

Nick Pasich wrote:
> No BIOS update....
> 
> Here's the output from "dmidecode" Attached...
> 

Hmm, nasty. We've got "IP35 Pro(Intel P35-ICH9R)" as identifaction string in 
the driver, and your DMI table has: "IP35 PRO(P35+ICH9R)"

You should be able to work around your problem (for now) by doing this (as root):

modprobe abituguru3 force=1

After that, please do "dmesg" and copy paste the relevant (abituguru related) 
lines in your mail, that will help us diagnose this.

Thanks & Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Jean Delvare]

On Thu, 08 Jan 2009 13:02:38 +0100, Hans de Goede wrote:
> Nick Pasich wrote:
> > No BIOS update....
> > 
> > Here's the output from "dmidecode" Attached...
> > 
> 
> Hmm, nasty. We've got "IP35 Pro(Intel P35-ICH9R)" as identifaction string in 
> the driver, and your DMI table has: "IP35 PRO(P35+ICH9R)"
> 
> You should be able to work around your problem (for now) by doing this (as root):
> 
> modprobe abituguru3 force=1
> 
> After that, please do "dmesg" and copy paste the relevant (abituguru related) 
> lines in your mail, that will help us diagnose this.

Might be worth reading this discussion thread again:
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024522.html

We gave up on fixing it back then, but apparently there really is a
need. Alistair, do you have a patch?

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Alistair John Strachan]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Thursday 08 January 2009 17:09:43 Jean Delvare wrote:
> On Thu, 08 Jan 2009 13:02:38 +0100, Hans de Goede wrote:
> > Nick Pasich wrote:
> > > No BIOS update....
> > >
> > > Here's the output from "dmidecode" Attached...
> >
> > Hmm, nasty. We've got "IP35 Pro(Intel P35-ICH9R)" as identifaction string
> > in the driver, and your DMI table has: "IP35 PRO(P35+ICH9R)"
> >
> > You should be able to work around your problem (for now) by doing this
> > (as root):
> >
> > modprobe abituguru3 force=1
> >
> > After that, please do "dmesg" and copy paste the relevant (abituguru
> > related) lines in your mail, that will help us diagnose this.
>
> Might be worth reading this discussion thread again:
> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024522.html
>
> We gave up on fixing it back then, but apparently there really is a
> need. Alistair, do you have a patch?

I think the consensus we came to at the time was to switch to strncmp'ing a 
subset of the DMI string, but in this case we'll need strncasecmp. This isn't 
too terrible as false positives are pretty unlikely (we already check the 
board manufacturer too, which does seem to be unchanging). Hans?

Of course, if Abit start putting arbitrary spaces and hyphens into the names 
too, all bets are off. But I read that their motherboard division was ceasing 
operation soon so (alas) this shouldn't be a problem. :-)

Find attached a patch that should fix it (Nick, please test this if you can).

Jean, there's another DMI patch tested by Paul Hartman I've been holding onto. 
I'll send you a proper version of the patch in this email and the other DMI 
patch ASAP.

-- 
Cheers,
Alistair.

[-- Attachment #2: abituguru3-use-strncasecmp-substring-dmi-match.diff --]
[-- Type: text/x-patch, Size: 1554 bytes --]

diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
index 70bb854..ae75def 100644
--- a/drivers/hwmon/abituguru3.c
+++ b/drivers/hwmon/abituguru3.c
@@ -279,7 +279,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
 		{ "OTES1 Fan",		36, 2, 60, 1, 0 },
 		{ NULL, 0, 0, 0, 0, 0 } }
 	},
-	{ 0x0011, "AT8 32X(ATI RD580-ULI M1575)", {
+	{ 0x0011a, "AT8 32X", {
 		{ "CPU Core",		 0, 0, 10, 1, 0 },
 		{ "DDR",		 1, 0, 20, 1, 0 },
 		{ "DDR VTT",		 2, 0, 10, 1, 0 },
@@ -402,7 +402,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
 		{ "AUX3 Fan",		36, 2, 60, 1, 0 },
 		{ NULL, 0, 0, 0, 0, 0 } }
 	},
-	{ 0x0016, "AW9D-MAX       (Intel i975-ICH7)", {
+	{ 0x0016, "AW9D-MAX", {
 		{ "CPU Core",		 0, 0, 10, 1, 0 },
 		{ "DDR2",		 1, 0, 20, 1, 0 },
 		{ "DDR2 VTT",		 2, 0, 10, 1, 0 },
@@ -509,7 +509,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
 		{ "AUX3 FAN",		36, 2, 60, 1, 0 },
 		{ NULL, 0, 0, 0, 0, 0 } }
 	},
-	{ 0x001A, "IP35 Pro(Intel P35-ICH9R)", {
+	{ 0x001A, "IP35 Pro", {
 		{ "CPU Core",		 0, 0, 10, 1, 0 },
 		{ "DDR2",		 1, 0, 20, 1, 0 },
 		{ "DDR2 VTT",		 2, 0, 10, 1, 0 },
@@ -1139,7 +1139,9 @@ static int __init abituguru3_dmi_detect(void)
 
 	for (i = 0; abituguru3_motherboards[i].id; i++) {
 		const char *dmi_name = abituguru3_motherboards[i].dmi_name;
-		if (dmi_name && !strcmp(dmi_name, board_name))
+		if (!dmi_name)
+			continue;
+		if (!strncasecmp(board_name, dmi_name, strlen(dmi_name)))
 			break;
 	}
 

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Nick Pasich]

I applied the patch after applying your 2 other patches:

1) "eliminating whitespace"
2) "Switch the AW9D-MAX over from port probing to the
    preferred DMI probe method".

The patch applied and the module loaded without any problems.

Syslog Entry:
Jan 8 10:49:36 localhost kernel: abituguru3: found Abit uGuru3, 
motherboard ID: 001A


Thank You Guys Very Much,

    Nick Pasich

Alistair John Strachan wrote:
> On Thursday 08 January 2009 17:09:43 Jean Delvare wrote:
>   
>> On Thu, 08 Jan 2009 13:02:38 +0100, Hans de Goede wrote:
>>     
>>> Nick Pasich wrote:
>>>       
>>>> No BIOS update....
>>>>
>>>> Here's the output from "dmidecode" Attached...
>>>>         
>>> Hmm, nasty. We've got "IP35 Pro(Intel P35-ICH9R)" as identifaction string
>>> in the driver, and your DMI table has: "IP35 PRO(P35+ICH9R)"
>>>
>>> You should be able to work around your problem (for now) by doing this
>>> (as root):
>>>
>>> modprobe abituguru3 force=1
>>>
>>> After that, please do "dmesg" and copy paste the relevant (abituguru
>>> related) lines in your mail, that will help us diagnose this.
>>>       
>> Might be worth reading this discussion thread again:
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024522.html
>>
>> We gave up on fixing it back then, but apparently there really is a
>> need. Alistair, do you have a patch?
>>     
>
> I think the consensus we came to at the time was to switch to strncmp'ing a 
> subset of the DMI string, but in this case we'll need strncasecmp. This isn't 
> too terrible as false positives are pretty unlikely (we already check the 
> board manufacturer too, which does seem to be unchanging). Hans?
>
> Of course, if Abit start putting arbitrary spaces and hyphens into the names 
> too, all bets are off. But I read that their motherboard division was ceasing 
> operation soon so (alas) this shouldn't be a problem. :-)
>
> Find attached a patch that should fix it (Nick, please test this if you can).
>
> Jean, there's another DMI patch tested by Paul Hartman I've been holding onto. 
> I'll send you a proper version of the patch in this email and the other DMI 
> patch ASAP.
>
>   

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Hans de Goede]

Alistair John Strachan wrote:
> On Thursday 08 January 2009 17:09:43 Jean Delvare wrote:
>> On Thu, 08 Jan 2009 13:02:38 +0100, Hans de Goede wrote:
>>> Nick Pasich wrote:
>>>> No BIOS update....
>>>>
>>>> Here's the output from "dmidecode" Attached...
>>> Hmm, nasty. We've got "IP35 Pro(Intel P35-ICH9R)" as identifaction string
>>> in the driver, and your DMI table has: "IP35 PRO(P35+ICH9R)"
>>>
>>> You should be able to work around your problem (for now) by doing this
>>> (as root):
>>>
>>> modprobe abituguru3 force=1
>>>
>>> After that, please do "dmesg" and copy paste the relevant (abituguru
>>> related) lines in your mail, that will help us diagnose this.
>> Might be worth reading this discussion thread again:
>> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024522.html
>>
>> We gave up on fixing it back then, but apparently there really is a
>> need. Alistair, do you have a patch?
> 
> I think the consensus we came to at the time was to switch to strncmp'ing a 
> subset of the DMI string, but in this case we'll need strncasecmp. This isn't 
> too terrible as false positives are pretty unlikely (we already check the 
> board manufacturer too, which does seem to be unchanging). Hans?
> 

That was my idea too, just make the dmi string stored in the driver: "IP35 Pro" 
and do a strncasecmp for the length of the string in the driver, with the one 
from the BIOS, if it is a match assume we have found an abituguru3 equipped 
motherboard.

> Of course, if Abit start putting arbitrary spaces and hyphens into the names 
> too, all bets are off. But I read that their motherboard division was ceasing 
> operation soon so (alas) this shouldn't be a problem. :-)
> 

I didn't know that.

> Find attached a patch that should fix it (Nick, please test this if you can).
> 

Yes that is exactly what I had in mind, +1 :

Reviewed-By: Hans de Goede <hdegoede@redhat.com>

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Jean Delvare]

On Thu, 08 Jan 2009 20:21:35 +0100, Hans de Goede wrote:
> Alistair John Strachan wrote:
> > I think the consensus we came to at the time was to switch to strncmp'ing a 
> > subset of the DMI string, but in this case we'll need strncasecmp. This isn't 
> > too terrible as false positives are pretty unlikely (we already check the 
> > board manufacturer too, which does seem to be unchanging). Hans?
> 
> That was my idea too, just make the dmi string stored in the driver: "IP35 Pro" 
> and do a strncasecmp for the length of the string in the driver, with the one 
> from the BIOS, if it is a match assume we have found an abituguru3 equipped 
> motherboard.

That's not enough, because some board names match the beginning of
other supported board names (for example AW8 and AW8D.) So the algorithm
must really compare both strings on a
strip-everything-after-parenthesis-and-every-trailing-white-space basis.
That's a little more code, but still not rocket science, and that's the
only safe way.

(Actually, no, there's a second way: put the abituguru3_motherboards[]
entries in a clever order. But that could break easily, so I wouldn't
recommend it.)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Alistair John Strachan]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On Thursday 08 January 2009 18:09:40 Alistair John Strachan wrote:
> On Thursday 08 January 2009 17:09:43 Jean Delvare wrote:
[snip]
> > Might be worth reading this discussion thread again:
> > http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024522.html
> >
> > We gave up on fixing it back then, but apparently there really is a
> > need. Alistair, do you have a patch?

Find attached an alternative method which solves (I believe only potential) 
problems Jean pointed out at the time of the last thread. I think it's safe.

I've compromised by finding the first open bracket (it's fine if there are no 
brackets) and trimming any space from the sub-string. For example, here are 
the existing transformations:

"AW9D-MAX       (Intel i975-ICH7)" -> "AW9D-MAX"
"AT8 32X(ATI RD580-ULI M1575)" -> "AT8 32X"
"IP35 Pro(Intel P35-ICH9R)" -> "IP35 Pro"
"IN9 32X MAX(680i-MCP55PXE)" -> "IN9 32X MAX" (adding RSN)

And here are some hypothetical ones:

"AW9D      (Blah)" -> "AW9D"
"Abit Magic" -> "Abit Magic"

In the AW9D case, "AW9D" and "AW9D-MAX" are not considered to be the same 
motherboard, because the sub-string's length must exactly match that of the 
string in the motherboard entry. This is different to regular "strncasecmp" 
where they would be considered the same.

Find the patch attached. I'll probably go for this version if nobody finds any 
issues with it, otherwise the original patch I sent out is sufficient (since 
at the moment there are no boards falling into this hypothetical trap).

-- 
Cheers,
Alistair.

[-- Attachment #2: abituguru3-use-strncasecmp-substring-dmi-match-2.diff --]
[-- Type: text/x-patch, Size: 2229 bytes --]

diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
index 70bb854..16d3142 100644
--- a/drivers/hwmon/abituguru3.c
+++ b/drivers/hwmon/abituguru3.c
@@ -279,7 +279,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
 		{ "OTES1 Fan",		36, 2, 60, 1, 0 },
 		{ NULL, 0, 0, 0, 0, 0 } }
 	},
-	{ 0x0011, "AT8 32X(ATI RD580-ULI M1575)", {
+	{ 0x0011, "AT8 32X", {
 		{ "CPU Core",		 0, 0, 10, 1, 0 },
 		{ "DDR",		 1, 0, 20, 1, 0 },
 		{ "DDR VTT",		 2, 0, 10, 1, 0 },
@@ -402,7 +402,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
 		{ "AUX3 Fan",		36, 2, 60, 1, 0 },
 		{ NULL, 0, 0, 0, 0, 0 } }
 	},
-	{ 0x0016, "AW9D-MAX       (Intel i975-ICH7)", {
+	{ 0x0016, "AW9D-MAX", {
 		{ "CPU Core",		 0, 0, 10, 1, 0 },
 		{ "DDR2",		 1, 0, 20, 1, 0 },
 		{ "DDR2 VTT",		 2, 0, 10, 1, 0 },
@@ -509,7 +509,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
 		{ "AUX3 FAN",		36, 2, 60, 1, 0 },
 		{ NULL, 0, 0, 0, 0, 0 } }
 	},
-	{ 0x001A, "IP35 Pro(Intel P35-ICH9R)", {
+	{ 0x001A, "IP35 Pro", {
 		{ "CPU Core",		 0, 0, 10, 1, 0 },
 		{ "DDR2",		 1, 0, 20, 1, 0 },
 		{ "DDR2 VTT",		 2, 0, 10, 1, 0 },
@@ -1128,6 +1128,7 @@ static int __init abituguru3_dmi_detect(void)
 {
 	const char *board_vendor, *board_name;
 	int i, err = (force) ? 1 : -ENODEV;
+	size_t sublen;
 
 	board_vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
 	if (!board_vendor || strcmp(board_vendor, "http://www.abit.com.tw/"))
@@ -1137,9 +1138,20 @@ static int __init abituguru3_dmi_detect(void)
 	if (!board_name)
 		return err;
 
+	/* At the moment, we don't care about the part of the vendor
+	 * DMI string contained in brackets. Truncate the string at
+	 * the first occurance of a bracket. Trim any trailing space
+	 * from the substring.
+	 */
+	sublen = strcspn(board_name, "(");
+	while(sublen > 0 && board_name[sublen - 1] == ' ')
+		sublen--;
+
 	for (i = 0; abituguru3_motherboards[i].id; i++) {
 		const char *dmi_name = abituguru3_motherboards[i].dmi_name;
-		if (dmi_name && !strcmp(dmi_name, board_name))
+		if (!dmi_name || strlen(dmi_name) != sublen)
+			continue;
+		if (!strncasecmp(board_name, dmi_name, sublen))
 			break;
 	}
 

[-- Attachment #3: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Alistair John Strachan]

On Thursday 08 January 2009 19:45:13 Jean Delvare wrote:
> On Thu, 08 Jan 2009 20:21:35 +0100, Hans de Goede wrote:
> > Alistair John Strachan wrote:
> > > I think the consensus we came to at the time was to switch to
> > > strncmp'ing a subset of the DMI string, but in this case we'll need
> > > strncasecmp. This isn't too terrible as false positives are pretty
> > > unlikely (we already check the board manufacturer too, which does seem
> > > to be unchanging). Hans?
> >
> > That was my idea too, just make the dmi string stored in the driver:
> > "IP35 Pro" and do a strncasecmp for the length of the string in the
> > driver, with the one from the BIOS, if it is a match assume we have found
> > an abituguru3 equipped motherboard.
>
> That's not enough, because some board names match the beginning of
> other supported board names (for example AW8 and AW8D.) 

I have just sent out another patch which does this, but I must point out that 
AW8 and AW8D are not yet converted to DMI because I haven't received any user 
dmidecode information. Therefore this problem would only manifest if and when 
they were added.

Though we could add these boards preemptively, there's a risk that variants of 
the DMI string could be present that were not previously accounted for (not 
that I haven't already made this mistake with the IP35 Pro, but it's a case in 
point).

-- 
Cheers,
Alistair.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Hans de Goede]

Nick Pasich wrote:
> I applied the patch after applying your 2 other patches:
> 
> 1) "eliminating whitespace"
> 2) "Switch the AW9D-MAX over from port probing to the
>    preferred DMI probe method".
> 
> The patch applied and the module loaded without any problems.
> 
> Syslog Entry:
> Jan 8 10:49:36 localhost kernel: abituguru3: found Abit uGuru3, 
> motherboard ID: 001A
> 

1A is good, that is the same ID as we had for the other DMI string, so it looks 
like we're good to go with Alistair's patch.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Hans de Goede]

Alistair John Strachan wrote:
> On Thursday 08 January 2009 18:09:40 Alistair John Strachan wrote:
>> On Thursday 08 January 2009 17:09:43 Jean Delvare wrote:
> [snip]
>>> Might be worth reading this discussion thread again:
>>> http://lists.lm-sensors.org/pipermail/lm-sensors/2008-October/024522.html
>>>
>>> We gave up on fixing it back then, but apparently there really is a
>>> need. Alistair, do you have a patch?
> 
> Find attached an alternative method which solves (I believe only potential) 
> problems Jean pointed out at the time of the last thread. I think it's safe.
> 
> I've compromised by finding the first open bracket (it's fine if there are no 
> brackets) and trimming any space from the sub-string. For example, here are 
> the existing transformations:
> 
> "AW9D-MAX       (Intel i975-ICH7)" -> "AW9D-MAX"
> "AT8 32X(ATI RD580-ULI M1575)" -> "AT8 32X"
> "IP35 Pro(Intel P35-ICH9R)" -> "IP35 Pro"
> "IN9 32X MAX(680i-MCP55PXE)" -> "IN9 32X MAX" (adding RSN)
> 
> And here are some hypothetical ones:
> 
> "AW9D      (Blah)" -> "AW9D"
> "Abit Magic" -> "Abit Magic"
> 
> In the AW9D case, "AW9D" and "AW9D-MAX" are not considered to be the same 
> motherboard, because the sub-string's length must exactly match that of the 
> string in the motherboard entry. This is different to regular "strncasecmp" 
> where they would be considered the same.
> 
> Find the patch attached. I'll probably go for this version if nobody finds any 
> issues with it, otherwise the original patch I sent out is sufficient (since 
> at the moment there are no boards falling into this hypothetical trap).

Good catch Jean!

The new version looks good to me.

Regards,

Hans


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] abituguru3: no Abit uGuru3 found

[Jean Delvare]

Hi Alistair,

On Thu, 8 Jan 2009 19:53:04 +0000, Alistair John Strachan wrote:
> Find attached an alternative method which solves (I believe only potential) 
> problems Jean pointed out at the time of the last thread. I think it's safe.
> 
> I've compromised by finding the first open bracket (it's fine if there are no 
> brackets) and trimming any space from the sub-string. For example, here are 
> the existing transformations:
> 
> "AW9D-MAX       (Intel i975-ICH7)" -> "AW9D-MAX"
> "AT8 32X(ATI RD580-ULI M1575)" -> "AT8 32X"
> "IP35 Pro(Intel P35-ICH9R)" -> "IP35 Pro"
> "IN9 32X MAX(680i-MCP55PXE)" -> "IN9 32X MAX" (adding RSN)
> 
> And here are some hypothetical ones:
> 
> "AW9D      (Blah)" -> "AW9D"
> "Abit Magic" -> "Abit Magic"
> 
> In the AW9D case, "AW9D" and "AW9D-MAX" are not considered to be the same 
> motherboard, because the sub-string's length must exactly match that of the 
> string in the motherboard entry. This is different to regular "strncasecmp" 
> where they would be considered the same.
> 
> Find the patch attached. I'll probably go for this version if nobody finds any 
> issues with it, otherwise the original patch I sent out is sufficient (since 
> at the moment there are no boards falling into this hypothetical trap).

Review:

Please add a patch summary and your Signed-off-by line so that I can
push the patch upstream.

> diff --git a/drivers/hwmon/abituguru3.c b/drivers/hwmon/abituguru3.c
> index 70bb854..16d3142 100644
> --- a/drivers/hwmon/abituguru3.c
> +++ b/drivers/hwmon/abituguru3.c
> @@ -279,7 +279,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
>  		{ "OTES1 Fan",		36, 2, 60, 1, 0 },
>  		{ NULL, 0, 0, 0, 0, 0 } }
>  	},
> -	{ 0x0011, "AT8 32X(ATI RD580-ULI M1575)", {
> +	{ 0x0011, "AT8 32X", {
>  		{ "CPU Core",		 0, 0, 10, 1, 0 },
>  		{ "DDR",		 1, 0, 20, 1, 0 },
>  		{ "DDR VTT",		 2, 0, 10, 1, 0 },
> @@ -402,7 +402,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
>  		{ "AUX3 Fan",		36, 2, 60, 1, 0 },
>  		{ NULL, 0, 0, 0, 0, 0 } }
>  	},
> -	{ 0x0016, "AW9D-MAX       (Intel i975-ICH7)", {
> +	{ 0x0016, "AW9D-MAX", {
>  		{ "CPU Core",		 0, 0, 10, 1, 0 },
>  		{ "DDR2",		 1, 0, 20, 1, 0 },
>  		{ "DDR2 VTT",		 2, 0, 10, 1, 0 },
> @@ -509,7 +509,7 @@ static const struct abituguru3_motherboard_info abituguru3_motherboards[] = {
>  		{ "AUX3 FAN",		36, 2, 60, 1, 0 },
>  		{ NULL, 0, 0, 0, 0, 0 } }
>  	},
> -	{ 0x001A, "IP35 Pro(Intel P35-ICH9R)", {
> +	{ 0x001A, "IP35 Pro", {
>  		{ "CPU Core",		 0, 0, 10, 1, 0 },
>  		{ "DDR2",		 1, 0, 20, 1, 0 },
>  		{ "DDR2 VTT",		 2, 0, 10, 1, 0 },
> @@ -1128,6 +1128,7 @@ static int __init abituguru3_dmi_detect(void)
>  {
>  	const char *board_vendor, *board_name;
>  	int i, err = (force) ? 1 : -ENODEV;
> +	size_t sublen;
>  
>  	board_vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
>  	if (!board_vendor || strcmp(board_vendor, "http://www.abit.com.tw/"))
> @@ -1137,9 +1138,20 @@ static int __init abituguru3_dmi_detect(void)
>  	if (!board_name)
>  		return err;
>  
> +	/* At the moment, we don't care about the part of the vendor
> +	 * DMI string contained in brackets. Truncate the string at
> +	 * the first occurance of a bracket. Trim any trailing space

Spelling: occurrence.

> +	 * from the substring.
> +	 */
> +	sublen = strcspn(board_name, "(");

I didn't even know this function existed ;)

> +	while(sublen > 0 && board_name[sublen - 1] = ' ')

Coding style: space between "while" and opening parenthesis.

> +		sublen--;
> +
>  	for (i = 0; abituguru3_motherboards[i].id; i++) {
>  		const char *dmi_name = abituguru3_motherboards[i].dmi_name;
> -		if (dmi_name && !strcmp(dmi_name, board_name))
> +		if (!dmi_name || strlen(dmi_name) != sublen)
> +			continue;
> +		if (!strncasecmp(board_name, dmi_name, sublen))
>  			break;
>  	}
>  

Other than that, the patch looks OK to me.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors