Skip to contentSkip to conversation

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

PATCH Ken Moffat 3 participants 9 messages Mar 25, 2008 – Apr 1, 2008 1 message not in the archive

Subsystems (2)
Char and misc drivers I2C subsystem host drivers
lore
Share & tools
lore

Ken Moffat

author
#0 lore raw

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.

The same with 2.6.25-rc6-git8.

The only oddity in the logs is a large block of

Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message:
'GET_CONFIG greeter/SetPosition :0'
Mar 24 13:49:29 bluesbreaker gdmlogin[2995]:   Got response: 'OK
false'
Mar 24 13:49:29 bluesbreaker gdmlogin[2995]: Sending command:
'CLOSE'
Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message:
'CLOSE'
Mar 24 13:49:29 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In
loop
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login:
end verify for ''
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: No
login/Bad login
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In
loop
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login:
end verify for ''
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: No
login/Bad login
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In

loop
... about 165 repeats of these 3 lines, it seems to stop the messages on its own, then I ran shutdown and got the normal

Mar 24 13:50:02 bluesbreaker shutdown[3000]: shutting down for
system halt
Mar 24 13:50:02 bluesbreaker init: Switching to runlevel: 0
Mar 24 13:50:08 bluesbreaker logger: /etc/rc.d/init.d/rc called with
arg 0
Mar 24 13:50:08 bluesbreaker logger: /etc/rc.d/rc0.d/K01cups called

with arg stop
and so forth.

Yes, I've got a lot of debugging in there, I used this box to find
out why gdm-2.20 gave me a messy shutdown, and left it in after I reverted to gdm-2.18.

This only happens with 64-bit kernels, I've been using it as i686
without any issues.

While trying to debug this, I reverted the two drm patches from
2.6.24.1 (in 2.6.24.4) and normal behaviour was restored. I forgot to change the extraversion, which meant my modules were overwritten. When I later went back to the "bad 2.6.24.4" it shut down correctly. Examination showed i2c_viapro was the key - if I rmmod it in 2.6.24.x, gdm works correctly. For the record, my 32-bit config is very different, but does include i2c_viapro as a module.

So, I started to think it might be an i2c problem. But with
2.6.25-rc6-git8 I can't get gdm to work correctly, neither by reverting the patches, nor with rmmod, so for the moment I'm in the dark. My notes say that I managed to fix it one time on -rc6-git8, by 'rmmod i2c_viapro' before logging out, but all subsequent attempts to repeat this have failed.

FWIW, the via ISA bridge is a 1106:3227 (VIA_8237, also
described as VT8237R in i2c-viapro).

Going back to 2.6.24.4 and reverting only the following patch,
normal behaviour is restored:

drivers/char/drm/drm_vm.c +0 -0
index e8d50af..ef5e6b1 100644
@@ -506,6 +506,7 @@ static int drm_mmap_dma(struct file *filp,

struct vm_area_struct *vma)

        vma->vm_ops = &drm_vm_dma_ops;
 
        vma->vm_flags |= VM_RESERVED;   /* Don't swap */

+ vma->vm_flags |= VM_DONTEXPAND;

        vma->vm_file = filp;    /* Needed for drm_vm_open() */
        drm_vm_open_locked(vma);
@@ -655,6 +656,7 @@ static int drm_mmap_locked(struct file *filp,
struct vm_area_struct *vma)
                return -EINVAL; /* This should never happen. */
        }
        vma->vm_flags |= VM_RESERVED;   /* Don't swap */

+ vma->vm_flags |= VM_DONTEXPAND;

        vma->vm_file = filp;    /* Needed for drm_vm_open() */
        drm_vm_open_locked(vma);

I haven't been following 2.6.25 closely, but I assume that what got
applied to 2.6.24-stable was only part of the change to 2.6.25, and perhaps some other part of it is affecting me ?

.config.gz for 2.6.25-rc6-git8 is attached.

Ken

Signature · 1 line
das eine Mal als Tragödie, das andere Mal als Farce
#1 lore raw

Hi Ken,

Quoted 52 lines · Ken Moffat

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.

The same with 2.6.25-rc6-git8.

The only oddity in the logs is a large block of

Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message:
'GET_CONFIG greeter/SetPosition :0'
Mar 24 13:49:29 bluesbreaker gdmlogin[2995]:   Got response: 'OK
false'
Mar 24 13:49:29 bluesbreaker gdmlogin[2995]: Sending command:
'CLOSE'
Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message:
'CLOSE'
Mar 24 13:49:29 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In
loop
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login:
end verify for ''
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: No
login/Bad login
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In
loop
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login:
end verify for ''
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: No
login/Bad login
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In

loop
... about 165 repeats of these 3 lines, it seems to stop the messages on its own, then I ran shutdown and got the normal

Mar 24 13:50:02 bluesbreaker shutdown[3000]: shutting down for
system halt
Mar 24 13:50:02 bluesbreaker init: Switching to runlevel: 0
Mar 24 13:50:08 bluesbreaker logger: /etc/rc.d/init.d/rc called with
arg 0
Mar 24 13:50:08 bluesbreaker logger: /etc/rc.d/rc0.d/K01cups called

with arg stop
and so forth.

Yes, I've got a lot of debugging in there, I used this box to find
out why gdm-2.20 gave me a messy shutdown, and left it in after I reverted to gdm-2.18.

This only happens with 64-bit kernels, I've been using it as i686
without any issues.

Quoted 7 lines

While trying to debug this, I reverted the two drm patches from
2.6.24.1 (in 2.6.24.4) and normal behaviour was restored. I forgot to change the extraversion, which meant my modules were overwritten. When I later went back to the "bad 2.6.24.4" it shut down correctly. Examination showed i2c_viapro was the key - if I rmmod it in 2.6.24.x, gdm works correctly. For the record, my 32-bit config is very different, but does include i2c_viapro as a module.

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?

Do you have I2C or SMBus devices connected to the SMBus on that machine? If you don't know, i2cdetect should tell.

You say that your 32-bit and 64-bit configs are very different. It might be interesting to get them to match as much as possible. This could either point at a 64-bit specific problem, or isolate a kernel configuration option which causes the problem.

Quoted 7 lines

So, I started to think it might be an i2c problem. But with
2.6.25-rc6-git8 I can't get gdm to work correctly, neither by reverting the patches, nor with rmmod, so for the moment I'm in the dark. My notes say that I managed to fix it one time on -rc6-git8, by 'rmmod i2c_viapro' before logging out, but all subsequent attempts to repeat this have failed.

This brings a question: how many times (out of how many tries) did you manage to fix your 2.6.24.x kernel with "rmmod i2c-viapro"? If it's just 1 our of 1 try, it could be just luck? Did you try to rmmod any other driver?

Quoted 37 lines

FWIW, the via ISA bridge is a 1106:3227 (VIA_8237, also
described as VT8237R in i2c-viapro).

Going back to 2.6.24.4 and reverting only the following patch,
normal behaviour is restored:

drivers/char/drm/drm_vm.c +1 -0
index e8d50af..ef5e6b1 100644
@@ -506,6 +506,7 @@ static int drm_mmap_dma(struct file *filp,
 struct vm_area_struct *vma)
        vma->vm_ops = &drm_vm_dma_ops;
 
        vma->vm_flags |= VM_RESERVED;   /* Don't swap */
+       vma->vm_flags |= VM_DONTEXPAND;
 
        vma->vm_file = filp;    /* Needed for drm_vm_open() */

        drm_vm_open_locked(vma);
drivers/char/drm/drm_vm.c +1 -0
@@ -655,6 +656,7 @@ static int drm_mmap_locked(struct file *filp,
 struct vm_area_struct *vma)
                return -EINVAL; /* This should never happen. */
        }
        vma->vm_flags |= VM_RESERVED;   /* Don't swap */
+       vma->vm_flags |= VM_DONTEXPAND;
 
        vma->vm_file = filp;    /* Needed for drm_vm_open() */

        drm_vm_open_locked(vma);

I haven't been following 2.6.25 closely, but I assume that what got
applied to 2.6.24-stable was only part of the change to 2.6.25, and perhaps some other part of it is affecting me ?

.config.gz for 2.6.25-rc6-git8 is attached.

Ken

Signature · 1 line
Jean Delvare
author
#2 lore raw
Quoted 11 lines · Jean Delvare

Hi Ken,

Quoted 7 lines · Ken Moffat

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.

Quoted 4 lines

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).

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.

Quoted 3 lines

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: -- -- -- -- -- -- -- --
[ othing shows on 3 ]
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: -- -- -- -- -- -- -- --

Quoted 6 lines

You say that your 32-bit and 64-bit configs are very different. It might be interesting to get them to match as much as possible. This could either point at a 64-bit specific problem, or isolate a kernel configuration option which causes the problem.

I'll have a look at that.

[...]

Quoted 6 lines

This brings a question: how many times (out of how many tries) did you manage to fix your 2.6.24.x kernel with "rmmod i2c-viapro"? If it's just 1 our of 1 try, it could be just luck? Did you try to rmmod any other driver?

I think it was 2 or 3 times, but as I already said, my notes say I
managed to shutdown 2.6.25-rc6-git8 once, but I can't replicate that.

Funnily enough, earlier today I was using what I thought was a
fixed 2.6.24.4 kernel (with the drm patches reverted) and gdm hung again. Maybe it is something else entirely. All I know for certain is that I didn't see the problem with vanilla 2.6.24.

Ken

Signature · 6 lines
das eine Mal als Tragödie, das andere Mal als Farce

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c
#3 lore raw
Quoted 17 lines · Ken Moffat
Quoted 11 lines · Jean Delvare

Hi Ken,

Quoted 7 lines · Ken Moffat

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.

Quoted 4 lines

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?

Quoted 6 lines

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.

Quoted 5 lines

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...)

Quoted 24 lines
Quoted 3 lines

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

Quoted 8 lines

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.)

Quoted 1 line

[ 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.

Quoted 7 lines

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

Quoted 8 lines

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,

Signature · 1 line
Jean Delvare
#4 lore raw
Quoted 3 lines · Jean Delvare

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.)

[...]

Quoted 4 lines

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.

Maybe the radeonfb driver is trying to talk to EDID EEPROMs on all I2C adapters it finds? When it tries to using the i2c-viapro adapter, it hangs.

_______________________________________________
i2c mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/i2c

#5 lore raw
Quoted 5 lines · Trent Piepho
Quoted 3 lines · Jean Delvare

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.)

[...]

Quoted 8 lines
Quoted 4 lines

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.

Maybe the radeonfb driver is trying to talk to EDID EEPROMs on all I2C adapters it finds? When it tries to using the i2c-viapro adapter, it hangs.

No, the radeonfb driver only probes for EEPROMs on (at most) its 4 own I2C buses. It doesn't even know about the other I2C buses on the system.

Note that I am using radeonfb and i2c-viapro myself, so if there was a conflict between both drivers, I think would know by now. I've not experienced the problem reported by Ken. But I don't use gdm.

Note that I am using the X.org radeon driver. Ken did not tell which X driver he was using, maybe it matters.

Signature · 1 line
Jean Delvare
author
#6 lore raw
Quoted 18 lines · Jean Delvare
Quoted 5 lines · Trent Piepho
Quoted 3 lines · Jean Delvare

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.)

[...]

Quoted 8 lines
Quoted 4 lines

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.

Maybe the radeonfb driver is trying to talk to EDID EEPROMs on all I2C adapters it finds? When it tries to using the i2c-viapro adapter, it hangs.

No, the radeonfb driver only probes for EEPROMs on (at most) its 4 own I2C buses. It doesn't even know about the other I2C buses on the system.

Quoted 7 lines

Note that I am using radeonfb and i2c-viapro myself, so if there was a conflict between both drivers, I think would know by now. I've not experienced the problem reported by Ken. But I don't use gdm.

Note that I am using the X.org radeon driver. Ken did not tell which X driver he was using, maybe it matters.

I was going to delay replying, because I had nothing to report -
tried changing the interesting differences in the 64-bit .config where it looked as if I had strayed from what is in the current defconfig, no change. Tried removing radeonfb (oh, the horrible screen size of 80x25!), no change. I haven't looked in detail at drivers.

For Trent: if I use the ('bad') system as normal, log out to gdm,
then log in again it is fine. That involves the screen going black and then gdm restarts X, paints the background and puts up a window. It's only attempts to shut down or restart (reboot) which dismiss the gdm dialog window but leave the background in place - on 'good' kernels, the screen goes black and then the console messages appear as soon as I click the confirm or ok or whatever button.

I'm on xorg-7.3 on this system with xorg-server-1.4.0.90 and
xf86-video-ati ('ati') - until yesterday evening I was still using 6.7.196, then I upgraded to 6.8.0 but that too changed nothing.

I'll try -rc7, just in case, then I'll see if I can change the
32-bit config to provoke the problem. I see debian users have been hitting a race with gdm, but this isn't debian (it's all compiled from source) and I do have dbus-1.1.2 and dbus-glib-0.74 installed.

Thanks for the suggestions.

Ken

Signature · 1 line
das eine Mal als Tragödie, das andere Mal als Farce
author
#7 lore raw
In reply to Jean Delvare
Quoted 6 lines · Jean Delvare

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.

I've been attending to more-urgent non-kernel problems.

In fact, i2c-viapro is not contributory, and drm may have nothing
to do with it - the problem seems to happen with any kernel > 2.6.24, but not always.

So, to be clear, 2.6.24.4 with the drm patch reverted, and
2.6.25-rc1, and 2.6.25-rc7 ALL intermittently fail. I'll start bisecting. Actually, I suppose I'd better try 2.6.24 itself a few more times, so that I have a little more confidence it was 'good' for this (fortunately, no other users on that box). Apologies for attributing possible blame to i2c.

Ken

Signature · 1 line
das eine Mal als Tragödie, das andere Mal als Farce

A message that is not in the archive (sent off-list or not yet received): [email protected]

author
#9 lore raw
Quoted 105 lines · Andrew Morton

Looks like another post-2.6.24 regression for the list.

Quoted 100 lines · On Tue, 25 Mar 2008 20:07:14 +0000 Ken Moffat <[email protected]> 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.

The same with 2.6.25-rc6-git8.

The only oddity in the logs is a large block of

Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message:
'GET_CONFIG greeter/SetPosition :0'
Mar 24 13:49:29 bluesbreaker gdmlogin[2995]:   Got response: 'OK
false'
Mar 24 13:49:29 bluesbreaker gdmlogin[2995]: Sending command:
'CLOSE'
Mar 24 13:49:29 bluesbreaker gdm[2554]: Handling user message:
'CLOSE'
Mar 24 13:49:29 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In
loop
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login:
end verify for ''
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: No
login/Bad login
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In
loop
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login:
end verify for ''
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: No
login/Bad login
Mar 24 13:49:35 bluesbreaker gdm[2562]: gdm_slave_wait_for_login: In

loop
... about 165 repeats of these 3 lines, it seems to stop the messages on its own, then I ran shutdown and got the normal

Mar 24 13:50:02 bluesbreaker shutdown[3000]: shutting down for
system halt
Mar 24 13:50:02 bluesbreaker init: Switching to runlevel: 0
Mar 24 13:50:08 bluesbreaker logger: /etc/rc.d/init.d/rc called with
arg 0
Mar 24 13:50:08 bluesbreaker logger: /etc/rc.d/rc0.d/K01cups called

with arg stop
and so forth.

Yes, I've got a lot of debugging in there, I used this box to find
out why gdm-2.20 gave me a messy shutdown, and left it in after I reverted to gdm-2.18.

This only happens with 64-bit kernels, I've been using it as i686
without any issues.

While trying to debug this, I reverted the two drm patches from
2.6.24.1 (in 2.6.24.4) and normal behaviour was restored. I forgot to change the extraversion, which meant my modules were overwritten. When I later went back to the "bad 2.6.24.4" it shut down correctly. Examination showed i2c_viapro was the key - if I rmmod it in 2.6.24.x, gdm works correctly. For the record, my 32-bit config is very different, but does include i2c_viapro as a module.

So, I started to think it might be an i2c problem. But with
2.6.25-rc6-git8 I can't get gdm to work correctly, neither by reverting the patches, nor with rmmod, so for the moment I'm in the dark. My notes say that I managed to fix it one time on -rc6-git8, by 'rmmod i2c_viapro' before logging out, but all subsequent attempts to repeat this have failed.

FWIW, the via ISA bridge is a 1106:3227 (VIA_8237, also
described as VT8237R in i2c-viapro).

Going back to 2.6.24.4 and reverting only the following patch,
normal behaviour is restored:

drivers/char/drm/drm_vm.c +1 -0
index e8d50af..ef5e6b1 100644
@@ -506,6 +506,7 @@ static int drm_mmap_dma(struct file *filp,
 struct vm_area_struct *vma)
        vma->vm_ops = &drm_vm_dma_ops;
 
        vma->vm_flags |= VM_RESERVED;   /* Don't swap */
+       vma->vm_flags |= VM_DONTEXPAND;
 
        vma->vm_file = filp;    /* Needed for drm_vm_open() */

        drm_vm_open_locked(vma);
drivers/char/drm/drm_vm.c +1 -0
@@ -655,6 +656,7 @@ static int drm_mmap_locked(struct file *filp,
 struct vm_area_struct *vma)
                return -EINVAL; /* This should never happen. */
        }
        vma->vm_flags |= VM_RESERVED;   /* Don't swap */
+       vma->vm_flags |= VM_DONTEXPAND;
 
        vma->vm_file = filp;    /* Needed for drm_vm_open() */

        drm_vm_open_locked(vma);

I haven't been following 2.6.25 closely, but I assume that what got
applied to 2.6.24-stable was only part of the change to 2.6.25, and perhaps some other part of it is affecting me ?

Quoted 6 lines
Quoted 6 lines

.config.gz for 2.6.25-rc6-git8 is attached.

Ken

Signature · 1 line
das eine Mal als Trag__die, das andere Mal als Farce

I'm back on this with very mixed results - looks as if what I
reverted against 2.6.24.4 might not be the problem. I've seen failure to shutdown/reboot from gdm on versions of 2.6.24.n (> 2.6.24, with the patch above reverted) and intermittent failures in 2.6.25-rc. Today's test results, with i2c-viapro removed from the config (separate thread, it's a red herring): (success means it rebooted or shut down, failure means gdm hung with just an X background) - after failure, I shutdown or reboot from a tty)

2.6.25-rc1 success
2.6.25-rc1 success (used it to build rc7) 2.6.25-rc7 failure
2.6.25-rc1 failure (rebooted from rc7, wanted to shutdown).

Looks like I'll have to bisect, and it may be nothing at all to do
with the patch above. All I know for certain is that I haven't seen the problem on vanilla 2.6.24, and it's intermittent.

Ken

Signature · 1 line
das eine Mal als Tragödie, das andere Mal als Farce