Bug 4347

Summary: savavgefb ddc eeprom oops when "sensors" used as non-root
Product: Drivers Reporter: Salah Coronya (salahx)
Component: I2CAssignee: Jean Delvare (jdelvare)
Status: CLOSED CODE_FIX    
Severity: normal CC: greg
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.11.3 Subsystem:
Regression: --- Bisected commit-id:
Attachments: ksymoops process of oops
Config file of kernel
Call memset and memcpy with correct data size
EDID information read from eeprom as root and nonroot
Fix Vaio EEPROM detection
Combination of the 2 eeprom patches
Missing VIAO detection patch for 2.6.12-rc1

Description Salah Coronya 2005-03-15 23:31:17 UTC
Distribution: Gentoo (Linux ardvarc 2.6.11-gentoo-r2 #4 Wed Mar 9 15:50:59 CST
2005 i686 AMD Athlon(tm) XP 2000+ AuthenticAMD GNU/Linux)

Hardware Environment: Put-together machine 512M 

Output of lspci:
0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8375 [KM266/KL266] Host Bridge
0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
0000:00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
0000:00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
0000:00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1
Controller (rev 80)
0000:00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
0000:00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
0000:00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
0000:00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
0000:00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
0000:01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]


Software Environment: For this one, a stripped down 2.6.11.3 kernel (but its
occured since at least when savagefb was introduced)

Problem Description:
when "savagefb-i2c" is loaded, framebuffer console enabled and eeprom module
loaded or compiled in, if a non-root user runs the "sensors" command, the kernel
panics or reboots instantly

Steps to reproduce:

1) Compile kernel with "S3 Savage support", "Enable ddc2 support" and
"Framebuffer Console Support" compiled in.
2) Either compile in or load eeprom and i2c algorithm modules
3) Boot kernel with Command line: video=savagefb:1024x768-16@60
4) Run "sensors" command with eeprom in kernel (Either built-in or modprobed")
as a non-root user
Comment 1 Salah Coronya 2005-03-15 23:34:41 UTC
Created attachment 4731 [details]
ksymoops process of oops

Ksymoops output when "sensors" is run with savagefb/eeprom
Comment 2 Salah Coronya 2005-03-15 23:36:20 UTC
Created attachment 4732 [details]
Config file of kernel

This is the kernel configuration of the kernel in which in kysmoops was
generated
Comment 3 Jean Delvare 2005-03-17 11:13:09 UTC
Created attachment 4744 [details]
Call memset and memcpy with correct data size
Comment 4 Jean Delvare 2005-03-17 11:14:55 UTC
Can you please give a try to the proposed patch? The oops should hopefully not
happen anymore.
Comment 5 Salah Coronya 2005-03-17 21:13:07 UTC
Created attachment 4746 [details]
EDID information read from eeprom as root and nonroot

Yes, the oops is gone. There's only 1 issue with the fix: The EEPROM at 0x57
has different values as root and non-root. The parse-edid script (which is part
of the read-edid script at http://john.fremlin.de/programs/linux/read-edid/)
gives a warning when eeprom 0x0057 is fed into the standard input:

Output of parse-edid as root, on eeprom@0x0057: 

       # EDID version 1 revision 0
Section "Monitor"
	Identifier "SNY:5000"
	VendorName "SNY"
	ModelName "SNY:5000"
	# DPMS capabilities: Active off:yes  Suspend:yes  Standby:no

	Mode	"640x400"	# vfreq 70.100Hz, hfreq 31.475kHz
		DotClock	25.180000
		HTimings	640 656 752 800
		VTimings	400 412 414 449
		Flags	"+HSync" "-VSync"
	EndMode
	Mode	"640x350"	# vfreq 70.100Hz, hfreq 31.475kHz
		DotClock	25.180000
		HTimings	640 656 752 800
		VTimings	350 387 389 449
		Flags	"-HSync" "+VSync"
	EndMode
	Mode	"1x1"	# vfreq 38.609Hz, hfreq  9.961kHz
		DotClock	2.570000
		HTimings	1 2 3 258
		VTimings	1 1 18 258
	EndMode
	Mode	"1x1"	# vfreq 38.609Hz, hfreq  9.961kHz
		DotClock	2.570000
		HTimings	1 2 3 258
		VTimings	1 1 18 258
	EndMode
EndSection

Output of parse-edid as non-root, on eeprom@0x0057: 

/usr/sbin/parse-edid: parse-edid version 1.4.1
/usr/sbin/parse-edid: EDID checksum failed - data is corrupt. Continuing
anyway.

	# EDID version 1 revision 0
Section "Monitor"
	Identifier "@@@:0000"
	VendorName "@@@"
	ModelName "@@@:0000"
	# DPMS capabilities: Active off:yes  Suspend:yes  Standby:no

	Mode	"640x400"	# vfreq 70.100Hz, hfreq 31.475kHz
		DotClock	25.180000
		HTimings	640 656 752 800
		VTimings	400 412 414 449
		Flags	"+HSync" "-VSync"
	EndMode
	Mode	"640x350"	# vfreq 70.100Hz, hfreq 31.475kHz
		DotClock	25.180000
		HTimings	640 656 752 800
		VTimings	350 387 389 449
		Flags	"-HSync" "+VSync"
	EndMode
	Mode	"1x1"	# vfreq 38.609Hz, hfreq  9.961kHz
		DotClock	2.570000
		HTimings	1 2 3 258
		VTimings	1 1 18 258
	EndMode
	Mode	"1x1"	# vfreq 38.609Hz, hfreq  9.961kHz
		DotClock	2.570000
		HTimings	1 2 3 258
		VTimings	1 1 18 258
	EndMode
EndSection

All the other eeproms (rot or nonroot) return same result as the root version.

(Some of the modelines generated are clearly bogus, but that's probably some
other problem)

The monitor in question is a Sony CPD-100SV, which was sold with Sony Viao
desktop (now decomissioned). It's a 15 inch monitor, with (per the manual), a
horizontal rate of 31 to 65 kHZ and a vertical rate of 50 to 120 Hz.
Comment 6 Jean Delvare 2005-03-18 02:21:26 UTC
This second problem you mention is caused by a different bug in the eeprom
driver. There is some code in the driver which "hides" security-related
information found in Sony Vaio laptops EEPROM. The bug causes the hiding code to
trigger more often than it should. In fact, it will trigger on any EEPROM at
address 0x57 instead of just Sony Vaio laptops ones. This explains the problem
you observed. Patch follows.

I don't think this second problem is really critical. After all, data read from
EEPROM at 0x57 is the very same as data read from 0x50-0x56, right? So I don't
see any reason why someone would want to read it from 0x57.
Comment 7 Jean Delvare 2005-03-18 02:23:21 UTC
Created attachment 4751 [details]
Fix Vaio EEPROM detection
Comment 8 Salah Coronya 2005-03-18 08:15:56 UTC
Created attachment 4753 [details]
Combination of the 2 eeprom patches

Works just fine now with that patch - no more oops and all the EEPROM are read
correctly. Problem fixed.
Comment 9 Andrew Morton 2005-03-21 18:14:31 UTC
I think 2.6.12-rc1 had only one of these fixes.

Salah, could you please test 2.6.12-rc1 and let us know?

Thanks.
Comment 10 Salah Coronya 2005-03-21 21:46:59 UTC
Created attachment 4767 [details]
Missing VIAO detection patch for 2.6.12-rc1

The oops no longer occurs but the eeprom still appears corrupt at 0x57 when a
non-root user attempts to read it. 2.6.12-rc1 did not have the second fix.
Comment 11 Jean Delvare 2005-03-22 00:41:47 UTC
I confirm that. The oops is fixed in 2.6.12-rc1 but the erroneous Vaio detection
at 0x57 is not.

This second, non-critical fix has been pushed to Greg KH already, and is now
waiting to be applied to his bk-i2c tree:
http://archives.andrew.net.au/lm-sensors/msg30047.html
Comment 12 Andrew Morton 2005-05-25 16:09:29 UTC
Guys, is all this fixed in 2.6.12-rc5?
Comment 13 Jean Delvare 2005-05-26 00:25:06 UTC
Yes Andrew, it is. The first bug is fixed since 2.6.11.7/2.6.12-rc1, the second
since 2.6.12-rc2.