Re: Regression (gdm no longer shuts down) - 2.4.24.x and 2.6.25

[Jean Delvare]

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/