On Fri, 3 Nov 2000 13:22:10 +0100 (CET),
Michael Schmitz [off-list ref] was rumoured to say:
quoted
pmud[333]: pmud [treshold = 420, margin = 15] started
modprobe: modprobe: Can't locate module char-major-56
pmud[333]: Couldn't open /dev/adb
pmud[333]: daemon stopped (Couldn't open /dev/adb)
Nope, /dev/adb remains unchanged, just ADB mice aren't necessarily read
via the adbmouse device anymore (but that was misc minor 10, the patch to
handle keyboard and mouse data as separate ADB devices in the ADB major
range never made it in).
Make sure you the core adb support is compiled in. It currently is, unless
CONFIG_MBX is set ... if CONFIG_ALL_PPC=y implies CONFIG_MBX=y, someone
better fix this.
I suspect it is somehow related to mouse and keyboard being handled by
the new input layer, in pmac-stable this seems to be handled quite
differently from pmac-benh (at least, there's an extra config menu).
Maybe someone forgot that pmu/adb is handling more than keyboard and mouse?
Did all your kernels that crash lack ADB support, or just the latest you
built with CONFIG_ALL_PPC=y ?
I think there is some misunderstanding here. pmac-stable kernels w/o adb
_cannot_ crash on wakeup, because they can't sleep. At least that's my
experience. The benh-kernels may crash, but this doesn't seem to be
consistent, also I don't think it is related to the device bay.
I just had 2.2.18pre17-benh1 running (and sleeping) for about a week on
my Lombard, this morning it simply powered down and reset pram when I
tried to wake it up (battery was 95% full).
I also noted some other problems with sleep, mostly irregularly:
xscreensaver tends to become somehow disconnected from the display, when
this happens, it will run in the background after wakeup and begin
to consume 90%+ cpu, but doesn't blank the screen. It can be
easily killed, however.
I added some lines to pwrctl-local to kill it before sleeping
and relaunch it afterwards, but even then it happenened once again
(before, it was about every other time, though)
power consumption during sleep is occasionally (not frequently) 5-10
times the normal rate, which will discharge the battery within
24-36 hours.
sometimes I don't get my usb mouse back after wakeup. I haven't found any
way to reset usb (unplugging doesn't help and it doesn't work with
gpm either). So far I could not get the mouse (or any input layer
device) to work as a module at all, so rmmod/insmod rules out
as well (this was where I started experimenting with
pmac-stable kernels in the first place).
I think I saw this first with 2.2.18pre15-benh1. It seems to
happen more frequently when I'm carrying the PB around during
sleep, but this can't be a power supply issue, since I'm
usually unplugging the AC when at home, too.
Sorry I can't give better statistics on these phenomena. I can live with
them, except for the crashes, though the usb failure is annoying, too.
Cheers,
Derek
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
quoted
Make sure you the core adb support is compiled in. It currently is, unless
CONFIG_MBX is set ... if CONFIG_ALL_PPC=y implies CONFIG_MBX=y, someone
better fix this.
I suspect it is somehow related to mouse and keyboard being handled by
the new input layer, in pmac-stable this seems to be handled quite
differently from pmac-benh (at least, there's an extra config menu).
Maybe someone forgot that pmu/adb is handling more than keyboard and mouse?
Stupid me. I missed the bit about linux-pmac-stable having that specific
problem. Look at a diff between the Makefiles in both versions.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I suspect it is somehow related to mouse and keyboard being handled by
the new input layer, in pmac-stable this seems to be handled quite
differently from pmac-benh (at least, there's an extra config menu).
Maybe someone forgot that pmu/adb is handling more than keyboard and mouse?
No. the input layer also needs the ADB core since it's the low level
code. I would bet for a config problem. I'll check that when I'm back,
this week-end.
I think there is some misunderstanding here. pmac-stable kernels w/o adb
_cannot_ crash on wakeup, because they can't sleep. At least that's my
experience. The benh-kernels may crash, but this doesn't seem to be
consistent, also I don't think it is related to the device bay.
I just had 2.2.18pre17-benh1 running (and sleeping) for about a week on
my Lombard, this morning it simply powered down and reset pram when I
tried to wake it up (battery was 95% full).
I though that was fixed for a long time... weird.
I also noted some other problems with sleep, mostly irregularly:
xscreensaver tends to become somehow disconnected from the display, when
this happens, it will run in the background after wakeup and begin
to consume 90%+ cpu, but doesn't blank the screen. It can be
easily killed, however.
Yup. Fortunately, even if you don't kill it, it tends to stop playing the
CPU hog after a few seconds (or minutes ?)
I added some lines to pwrctl-local to kill it before sleeping
and relaunch it afterwards, but even then it happenened once again
(before, it was about every other time, though)
power consumption during sleep is occasionally (not frequently) 5-10
times the normal rate, which will discharge the battery within
24-36 hours.
Bizarre... The new sleep code is supposed to be a lot less robust to
those various issues. Well, I suggest you try again with pmac-stable once
the ADB problem is ironed out. Both Paul and I did various fixes to the
sleep process.
sometimes I don't get my usb mouse back after wakeup. I haven't found any
way to reset usb (unplugging doesn't help and it doesn't work with
gpm either). So far I could not get the mouse (or any input layer
device) to work as a module at all, so rmmod/insmod rules out
as well (this was where I started experimenting with
pmac-stable kernels in the first place).
I think I saw this first with 2.2.18pre15-benh1. It seems to
happen more frequently when I'm carrying the PB around during
sleep, but this can't be a power supply issue, since I'm
usually unplugging the AC when at home, too.
Well, it can be a problem with sleep/wakeup code for the USB controller.
That code is not very clean in that sense that it should do more things
before putting the OHCI to sleep (like waiting for pending requests to
complete, etc...)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
On Fri, 3 Nov 2000, Benjamin Herrenschmidt wrote:
quoted
I just had 2.2.18pre17-benh1 running (and sleeping) for about a week on
my Lombard, this morning it simply powered down and reset pram when I
tried to wake it up (battery was 95% full).
I though that was fixed for a long time... weird.
Thought so, too. This was the only time this happened to me since then,
but Albrecht seems to have the same problem.
quoted
I also noted some other problems with sleep, mostly irregularly:
xscreensaver tends to become somehow disconnected from the display, when
this happens, it will run in the background after wakeup and begin
to consume 90%+ cpu, but doesn't blank the screen. It can be
easily killed, however.
Yup. Fortunately, even if you don't kill it, it tends to stop playing the
CPU hog after a few seconds (or minutes ?)
Rather minutes. I didn't remember it ever spinning down on its own
(before I killed it, that is), and I certainly sometimes only noticed it
after 15-30 minutes.
quoted
I added some lines to pwrctl-local to kill it before sleeping
and relaunch it afterwards, but even then it happenened once again
(before, it was about every other time, though)
power consumption during sleep is occasionally (not frequently) 5-10
times the normal rate, which will discharge the battery within
24-36 hours.
Bizarre... The new sleep code is supposed to be a lot less robust to
those various issues. Well, I suggest you try again with pmac-stable once
the ADB problem is ironed out. Both Paul and I did various fixes to the
sleep process.
Again, this only happened once with newer kernels.
Thanks,
Derek
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/