Bug 4347
| Summary: | savavgefb ddc eeprom oops when "sensors" used as non-root | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Salah Coronya (salahx) |
| Component: | I2C | Assignee: | 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
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. |