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
Created attachment 4731 [details] ksymoops process of oops Ksymoops output when "sensors" is run with savagefb/eeprom
Created attachment 4732 [details] Config file of kernel This is the kernel configuration of the kernel in which in kysmoops was generated
Created attachment 4744 [details] Call memset and memcpy with correct data size
Can you please give a try to the proposed patch? The oops should hopefully not happen anymore.
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.
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.
Created attachment 4751 [details] Fix Vaio EEPROM detection
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.
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.
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.
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
Guys, is all this fixed in 2.6.12-rc5?
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.