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:
diff --git a/drivers/char/drm/drm_vm.c b/drivers/char/drm/drm_vm.c
index e8d50af..ef5e6b1 100644
--- a/drivers/char/drm/drm_vm.c
+++ b/drivers/char/drm/drm_vm.c
@@ -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
--
das eine Mal als Trag?die, das andere Mal als Farce
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.
>
> 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.
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.
>
> 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?
>
> 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:
>
> diff --git a/drivers/char/drm/drm_vm.c b/drivers/char/drm/drm_vm.c
> index e8d50af..ef5e6b1 100644
> --- a/drivers/char/drm/drm_vm.c
> +++ b/drivers/char/drm/drm_vm.c
> @@ -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
--
Jean Delvare
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).
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.
>
> 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: -- -- -- -- -- -- -- --
>
> 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.
[...]
>
> 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
--
das eine Mal als Trag?die, das andere Mal als Farce
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
On Wed, 26 Mar 2008, Jean Delvare wrote:
> 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.)
[...]
> 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.
On Wed, 26 Mar 2008 18:35:10 -0700 (PDT), Trent Piepho wrote:
> On Wed, 26 Mar 2008, Jean Delvare wrote:
> > 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.)
> [...]
> > 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.
--
Jean Delvare
On Thu, Mar 27, 2008 at 09:26:17AM +0100, Jean Delvare wrote:
> On Wed, 26 Mar 2008 18:35:10 -0700 (PDT), Trent Piepho wrote:
> > On Wed, 26 Mar 2008, Jean Delvare wrote:
> > > 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.)
> > [...]
> > > 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.
>
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
--
das eine Mal als Trag?die, das andere Mal als Farce