Re: Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- From: Jean Delvare <khali@xxxxxxxxxxxx>
- Date: Wed, 26 Mar 2008 20:10:31 +0100
On Wed, 26 Mar 2008 17:37:01 +0000, Ken Moffat wrote:
On Wed, Mar 26, 2008 at 04:19:34PM +0100, Jean Delvare wrote:
Hi Ken,
On Tue, 25 Mar 2008 20:07:14 +0000, Ken Moffat wrote:
Hi,
on one of my boxes, I've got a problem with gdm and kernels newer
than 2.6.24 (tested on 2.6.24.2, 2.6.24.4). If I try to restart or
shut down from gdm, the window disappears but the X background remains
and the box stays in runlevel 5 until I switch to a tty and shut it
down (as root) or give it a 3-fingered salute to reboot.
I have to admit that I am very skeptical. The i2c-viapro driver deals
with the motherboard's SMBus. It's not related in any way to gdm nor
drm, so I just can't see how it could cause the problem you report.
What gave you the idea to try unloading this driver?
Your skepticism seems reasonable. I tried this after I went back
to the "bad" 2.6.24.4 (to see if there was anything in the X log)
only to discover it was now shutting sown ok. I knew I had
forgotten to change the extraversion when I reverted the patch, so
I figured it must be something in the modules (i.e. the good ones
overwrote the bad ones - dunno if they all load or not).
The fact is that there is no i2c-viapro change in 2.6.24.2 nor .4, and
in fact no i2c change at all. So if anything changed in this driver,
this has to be a side effect of some (non-i2c) header file change.
That's a long shot, though.
After going back to 2.6.24.2 where I'd first seen this, I had a
look at what was loaded - only r8169, w83627hf with hwmon_vid, and
i2c_viapro. I tried hwmon_vid and w83627hf but it didn't help.
Then I tried i2c_viapro and it seemed to fix it.
Did you try unloading r8169 instead? It's certainly less easy to test,
but I think it's worth a try. The only thing that unloading i2c-viapro
really does is unbinding a PCI device and removing a PCI driver. So, if
for some reason shaking the PCI bits solves your problem, then maybe
unloading r8169 would have the same effect.
You could also try reloading i2c-viapro after unloading it. I wonder if
your problem will be back or not. (Not that I would be able to come up
to any conclusion either way...)
Do you have I2C or SMBus devices connected to the SMBus on that machine?
If you don't know, i2cdetect should tell.
After modprobing i2c-dev I get
root@bluesbreaker /home/ken #i2cdetect -l
i2c-0 i2c monid I2C
adapter
i2c-1 i2c dvi I2C
adapter
i2c-2 i2c vga I2C
adapter
i2c-3 i2c crt2 I2C
adapter
i2c-4 smbus SMBus Via Pro adapter at 0400
SMBus adapter
[ nothing shows on 1 ]
root@bluesbreaker /home/ken #i2cdetect 2
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-2.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
Totally unrelated, but FYI: the chip at 0x50 is an EDID EEPROM in your
display (which the radeonfb driver can use to switch to the correct
resolution / refresh rate.)
[ othing shows on 3 ]
Just in case... You might want to check that the problem is still
present with the radeonfb driver not built into your kernel (and
not loaded as a module either). Framebuffer drivers and X can fight
for resources sometimes.
root@bluesbreaker /home/ken #i2cdetect 4
WARNING! This program can confuse your I2C bus, cause data loss and
worse!
I will probe file /dev/i2c-4.
I will probe address range 0x03-0x77.
Continue? [Y/n]
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 2f
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- 69 -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
OK... 0x50 and 0x51 are the SPD EEPROMs on your two memory modules. At
0x69 you have a clock chip. At 0x2f... maybe a hardware monitoring
chip, maybe something else. But more importantly, no driver attached to
any of these chips. So, the mysterious effect of unloading the
i2c-viapro driver can't be explained by an i2c chip driver detaching
from its device. So, again, I really can't see how i2c can be involved
in your problem.
Good luck,
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Follow-Ups:
- Re: [i2c] Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- From: Trent Piepho
- Re: [i2c] Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- References:
- Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- From: Ken Moffat
- Re: Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- From: Jean Delvare
- Re: Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- From: Ken Moffat
- Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- Prev by Date: Re: ISA -> ISA_ (Re: [GIT PATCH] ACPI patches for 2.6.25-rc6)
- Next by Date: Re: What if a TLB flush needed to sleep?
- Previous by thread: Re: Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- Next by thread: Re: [i2c] Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25
- Index(es):
Relevant Pages
|
