2.2.18pre17 again

2.2.18pre17 again

[Paul Mackerras]

I have updated my rsync trees with some more changes to my current
2.2.18pre17 source, mostly to allow a range of configs to compile
successfully.  I have also checked in the changes to the linuxppc_2_2
bk tree.  Prep-only configs should compile ok now and as a bonus they
no longer include all the pmac and chrp code that they used to.

If anyone gets compile errors with my 2.2.18pre17 tree, or the current
bk tree, please send me your .config.  I'm making a collection. :)

My primary rsync tree for the 2.2 kernel source is now at
ppc.linuxcare.com::linux-pmac-stable.  There is also a copy at
penguinppc.org::linux-pmac-stable.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Gabriel Paubert]

On Thu, 26 Oct 2000, Paul Mackerras wrote:

>
> I have updated my rsync trees with some more changes to my current
> 2.2.18pre17 source, mostly to allow a range of configs to compile
> successfully.  I have also checked in the changes to the linuxppc_2_2
> bk tree.  Prep-only configs should compile ok now and as a bonus they
> no longer include all the pmac and chrp code that they used to.
>
> If anyone gets compile errors with my 2.2.18pre17 tree, or the current
> bk tree, please send me your .config.  I'm making a collection. :)

Are you truly interested in my configs with VME support for MVME boards, a
different bootloader and many many other details ? Plus the negative
patches for the stupid things that are in the official kernel and which
will never, ever, make it to my own tree.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Paul Mackerras]

I just fixed a very silly mistake in _set_L2CR in my 2.2.18pre17
tree.  If you tried it on a G3 or G4 and it crashed on boot, please
try again.  The updated source is on ppc.linuxcare.com and
penguinppc.org as usual.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Martin Costabel]

Paul Mackerras wrote:

> If anyone gets compile errors with my 2.2.18pre17 tree, or the current
> bk tree, please send me your .config.  I'm making a collection. :)

I am sorry, but it still doesn't compile with CONFIG_MAGIC_SYSRQ=y. You
would need to patch

--- mac_hid.c   Mon Oct 23 13:13:08 2000
+++ drivers/macintosh/mac_hid.c Thu Oct 26 23:24:13 2000
@@ -295,11 +295,11 @@
 #ifdef CONFIG_MAGIC_SYSRQ
-                       ppc_md.ppc_kbd_sysrq_xlate   =
mac_hid_kbd_sysrq_xlate;
+                       kbd_sysrq_xlate   = mac_hid_kbd_sysrq_xlate;
                        SYSRQ_KEY                = 0x69;
 #endif
                        memcpy(pc_key_maps_save, key_maps,
sizeof(key_maps));
                        memcpy(key_maps, mac_key_maps_save,
sizeof(key_maps));
                } else {
 #ifdef CONFIG_MAGIC_SYSRQ
-                       ppc_md.ppc_kbd_sysrq_xlate   =
pckbd_sysrq_xlate;
+                       kbd_sysrq_xlate   = pckbd_sysrq_xlate;
                        SYSRQ_KEY                = 0x54;
 #endif

BTW, why didn't you adopt the names from the bk-linuxppc_2_3 tree for
the kbd_sysrq_xlate stuff? IMHO the circular macro definitions

#define kbd_sysrq_xlate (ppc_md.kbd_sysrq_xlate)
#define SYSRQ_KEY (ppc_md.SYSRQ_KEY)

in include/asm-ppc/keyboard.h are asking for trouble. They give you an
error  (" parse error before `(' ") if you want to say

ppc_md.kbd_sysrq_xlate   = pckbd_sysrq_xlate;

for example. If one day you should decide to #include <asm/keyboard.h>
into arch/ppc/kernel/pmac_setup.c, it won't compile any more.

Another problem I am having must be due to some bug in the screen
blanking code: The X server (Franz's XF-4.0.1) kills itself (and
everything that is running in an X window) after 10 minutes of idling.
This does not happen with 2.4.0-test kernels. It bit me hard, because it
happened while netscape was updating itself inside MOL inside an X
window. Now the MacOS boot partition is severely damaged.

If only MOL would run on 2.4.0 kernels on 603 machines, I would never go
back to 2.2.x kernels.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Albrecht Dre_]

The rsync'ed 2.2.18pre17 kernel hangs if I try to wake up my Lombard after a
sleep. Sleeping seems to work (the LED binks), but upon wakeup it just stops
blinking, and nothing else. No reports in /var/log/messages, I just have to
reboot.

I had somewhat similar problems with Ben's 2.2.17pre20-ben3 kernel (however,
this one reported a panic in /var/log/messages), but 2.2.18pre15-ben1 (from
http://penguinppc.org/~olaf/) works fine.

Any ideas?

Thanks in advance, Albrecht.

--

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Olaf Hering]

On Fri, Oct 27, Albrecht Dreß wrote:


> Any ideas?

Try current linux-pmac-benh.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 377 bytes --]

Olaf Hering wrote:
> Try current linux-pmac-benh.

O.K., I rsynced linux-pmac-benh from penguinppc.org (which is version
2.2.18pre17-ben1), built it, and now I get a kernel panic upon wakeup. My pmud
version is still 0.7.1.

I attach the kernel .config and the relevant part from /var/log/messages, and as
always, any help is _really_ welcome!

Thanks in advance, Albrecht.

--

[-- Attachment #2: panic_upon_wakeup.gz --]
[-- Type: application/octet-stream, Size: 910 bytes --]

[-- Attachment #3: kernel-config.gz --]
[-- Type: application/octet-stream, Size: 3261 bytes --]

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Claus]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]


 >: 
 >: I attach the kernel .config and the relevant part from /var/log/messages, and as
 >: always, any help is _really_ welcome!
 
if you panic'ed with the CD module inserted, would you try to snooze without it?

or try this one:

/* wakebay.c - wakes a powerbook mediabay so the system doesnt crash on accessing
 * a disk mounted before sleeping.  great for CD drives.
 *
 * Joseph Palani Garcia <jpgarcia@execpc.com>
 *
 * fairly simple.  IOCTL the mediabay to tell it the media changed.  (it only forgot
 * it in sleep.  we remind it.)
 *
 * 3 cases:
 *   nothing in drive      : does nothing, exits normally
 *   in drive, not mounted : acts, no effect (?)
 *   in drive, is mounted  : drive regains status, door locked, etc.
 *
 * this is useful for PMUD.  add it to the wakeup script to prevent crashes.
 *
 */
#include <stdio.h>
#include <fcntl.h>
#include <linux/cdrom.h>

int
main(int argc, char **argv)
{
  int fd, arg=0;

  if(argc<2){
    fprintf(stderr,"Usage:\n\t%s <device>\n",argv[0]);
    return 1;
  }

  fd = open(argv[1], O_RDONLY);

  if (fd < 0) {
    fprintf(stderr,"%s cannot be opened.  exiting.\n",argv[1]);
    return 0;
  }

  if (ioctl(fd, CDROM_MEDIA_CHANGED, &arg) < 0)
    perror("CDROM_MEDIA_CHANGED ioctl");

  close(fd);
  return 0;
}



Regards

		Claus

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Albrecht Dre_]

Claus wrote:
> if you panic'ed with the CD module inserted, would you try to snooze without it?

Got it. Without the cd drive module inserted, it does not panic. Apparently, it
is enough that there is a CD drive at all, because there was no CD inserted or
mounted. IMHO, this is a serious kernel bug. Anyone out there to fix this?

BTW, in an other approach, I rsync'ed Paul's linux-pmac-stable, but with this
one the pmud does not start at all as it can not open /dev/adb...

> or try this one:
[c code snipped]

Again, I _really_ think this should go into the kernel...

Thanks a lot, Albrecht.

--

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

>Claus wrote:
>> if you panic'ed with the CD module inserted, would you try to snooze
>without it?
>
>Got it. Without the cd drive module inserted, it does not panic.
>Apparently, it
>is enough that there is a CD drive at all, because there was no CD
inserted or
>mounted. IMHO, this is a serious kernel bug. Anyone out there to fix this?
>
>BTW, in an other approach, I rsync'ed Paul's linux-pmac-stable, but with this
>one the pmud does not start at all as it can not open /dev/adb...

Can you lookup the panic PC, LR and backtrace in your System.map ? Also,
if you could try to figure out what's up with /dev/adb... I suggest
enabling the CONFIG_ALL_PPC (Prep/chrp/pmac). I beleive the problem could
be there. I'll give it a look as soon as I find some time with my linux box.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Albrecht Dre_]

Benjamin Herrenschmidt wrote:
> Can you lookup the panic PC, LR and backtrace in your System.map ? Also,
> if you could try to figure out what's up with /dev/adb... I suggest
> enabling the CONFIG_ALL_PPC (Prep/chrp/pmac). I beleive the problem could

PC=c00d11f4 		 -> c00d11dc t idepmac_wake_device
LR=c00d19d0 		 -> c00d1648 t idepmac_notify_sleep
Backtrace:	C01A99C8 -> c01a99a0 t pmac_unmask_irq
		C00D19D0 -> c00d1648 t idepmac_notify_sleep
		C0111AFC -> c0111ac0 t broadcast_wak
		C01B4904 -> c01b450c T powerbook_sleep_G3
		C011208C -> c0111fd8 t pmu_ioctl
		C003C49C -> c003c200 T sys_ioctl
		C000392C -> c000392c T syscall_ret_1

I recompiled with CONFIG_ALL_PPC=y in .config, but this did not change anything.
Was there a change of the major device number for /dev/adb? In
/var/log/messages, the startup of results in the following:

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)

Thanks, Albrecht.

--

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> PC=c00d11f4 		 -> c00d11dc t idepmac_wake_device

Can you disassemble the kernel and look up where approximately in
idepmac_wake_device the panic happens?

> I recompiled with CONFIG_ALL_PPC=y in .config, but this did not change anything.
> Was there a change of the major device number for /dev/adb? In
> /var/log/messages, the startup of results in the following:
>
> 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.

Did all your kernels that crash lack ADB support, or just the latest you
built with CONFIG_ALL_PPC=y ?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Albrecht Dre_]

Michael Schmitz wrote:
> 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.

from .config:
# CONFIG_MBX is not set

> Did all your kernels that crash lack ADB support, or just the latest you
> built with CONFIG_ALL_PPC=y ?

Just the latest rsync'ed linux-pmac-stable from penguinppc.org. Before, I always
used Ben's (rsync'ed) kernels, and configured them for PowerMac's only. No
problems with starting pmud. Now, both configuring for PowerMac only and for
ALL_PPC have no /dev/adb. I'm afraid I have to dig into the sources...SIGH!

Thanks, Albrecht.

--

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> > Did all your kernels that crash lack ADB support, or just the latest you
> > built with CONFIG_ALL_PPC=y ?
>
> Just the latest rsync'ed linux-pmac-stable from penguinppc.org. Before, I always

When did you last rsync? I got my latest source yesterday afternoon, and
have no problems whatsoever...

You didn't accidentially delete /dev/adb?

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Albrecht Dre_]

Michael Schmitz wrote:
> When did you last rsync? I got my latest source yesterday afternoon, and
> have no problems whatsoever...

I rsync'ed again AND compiled the kernel with the original, unmodified .config.
Again, /dev/adb could not be opened, and modprobe complains about the missing
module for char-major-56. So I am totally lost...

> You didn't accidentially delete /dev/adb?

Nope:
crw-r--r--    1 root     root      56,   0 Apr 30  1999 /dev/adb

Albrecht.


--

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> > When did you last rsync? I got my latest source yesterday afternoon, and
> > have no problems whatsoever...
>
> I rsync'ed again AND compiled the kernel with the original, unmodified .config.
> Again, /dev/adb could not be opened, and modprobe complains about the missing
> module for char-major-56. So I am totally lost...

Is there a file adb.o in drivers/macintosh/ ?? Do you find adb_init and
adb_open in System.map?

I don't see any differences between my working .config and BenH's that
would accunt for this. I don't see any differences between pre14 and pre17
that count, for that matter. (There's some change to the low level sleep
code but that should affect both your and my Lombard alike.)

Now all this assumes you're not using BootX - I haven't tried pre17 with
BootX yet.

> > You didn't accidentially delete /dev/adb?
>
> Nope:
> crw-r--r--    1 root     root      56,   0 Apr 30  1999 /dev/adb

Just checking the obvious :-)

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> > Did all your kernels that crash lack ADB support, or just the latest you
> > built with CONFIG_ALL_PPC=y ?
>
> Just the latest rsync'ed linux-pmac-stable from penguinppc.org. Before, I always
> used Ben's (rsync'ed) kernels, and configured them for PowerMac's only. No
> problems with starting pmud. Now, both configuring for PowerMac only and for
> ALL_PPC have no /dev/adb. I'm afraid I have to dig into the sources...SIGH!

The reason is simple: adbdev_init() is now declared as module_init, and no
longer called from drivers/char/mem.c (which used to call all chardev init
functions). However, the adbdev code is not built as a module, rather
compiled in. What were you trying to achieve here, Paul?

I guess just adding back the adbdev_init() call to mem.c should restore
pmud to function. Or try forcing a build of adb.o as module.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

> >:
> >: I attach the kernel .config and the relevant part from /var/log/
>messages, and as
> >: always, any help is _really_ welcome!
>
>if you panic'ed with the CD module inserted, would you try to snooze
>without it?
>
>or try this one:

Well, the kernel sleep code is supposed to take care of that, but
apparently, that code is also causing the panic...

Michael, any clue ?

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

>
> Well, the kernel sleep code is supposed to take care of that, but
> apparently, that code is also causing the panic...
>
> Michael, any clue ?

Not at this time. My 2.2.18pre14 behaves as expected (CD inserted but not
mounted). I'll yet have to try pre17.

Side note: the ide revalidate patch is in Alan's pre18 now, so you can
start feeding him the related wakeup patches...

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

>> Well, the kernel sleep code is supposed to take care of that, but
>> apparently, that code is also causing the panic...
>>
>> Michael, any clue ?
>
>Not at this time. My 2.2.18pre14 behaves as expected (CD inserted but not
>mounted). I'll yet have to try pre17.
>
>Side note: the ide revalidate patch is in Alan's pre18 now, so you can
>start feeding him the related wakeup patches...

Yup, I know. Paul has all the patches and will probably take care of
feeding Alan


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> Well, the kernel sleep code is supposed to take care of that, but
> apparently, that code is also causing the panic...
>
> Michael, any clue ?

Can't reproduce the panic - both with and without the wakebay app, my
2.2.18pre17-ben1 fails to hang. No bad things happen with the CD mounted,
either.

So what should have happened? Crash (panic message), or plain hang?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Claus]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]


 >: 
 >: So what should have happened? Crash (panic message), or plain hang?

hi,
just for the record:

I've got the same crash as Albrecht in Sept. with 2.2.18pre4-ben1
and linuxppc2k on my PB3400 without the wakebay app.

Sep 18 00:35:03 apple kernel: Kernel panic: kernel access of bad area pc c00cf34c lr c00cfa88 address 24 tsk
+pmud/297

System.map-2.2.18pre4-ben1:
c00cf218 t idepmac_sleep_device
c00cf334 t idepmac_wake_device
c00cf400 t idepmac_sleep_interface
c00cf4e4 t idepmac_wake_interface
c00cf728 t idepmac_notify_sleep
c00cfab0 T ide_dma_intr
c00cfb8c T ide_build_dmatable

My only solution was to snooze without the cd module.

In the meantime I switched to potato; with the current

15:28@pts/2 ~ > uname -a
Linux apple 2.2.18pre17-ben1 #38 Wed Oct 25 18:51:51 CEST 2000 ppc unknown

now it's something special, that I realized today. A snooze and prompt
wakeup with the cd module inserted seems to hang the entire machine,
but it waits for dma'ing /dev/hdc.
This can last up to _four_ minutes, and I have to wait 'cause nothing
can be written to hda. 
The message 'system awake again' appears after hdc knows
and reports its dma status. 

15:29@pts/2 ~ > cat /var/log/messages
<snip>
Nov  3 15:06:28 apple pppd[299]: Exit.
Nov  3 15:07:08 apple kernel: media bay 0 contains a CD-ROM drive
Nov  3 15:07:08 apple kernel: keybdev.c: Removing keyboard: input1
Nov  3 15:07:08 apple kernel: ADB keyboard at 2, handler 1
Nov  3 15:07:08 apple kernel: Detected ADB keyboard, type ISO, swapping keys.
Nov  3 15:07:08 apple kernel: keybdev.c: Adding keyboard: input1
Nov  3 15:07:08 apple kernel: event0: Event device for input1
Nov  3 15:07:08 apple kernel: input1: ADB HID on ID 2:2.14
Nov  3 15:07:08 apple kernel: ADB mouse at 3, handler set to 4 (trackpad)
Nov  3 15:07:08 apple kernel: mouse0: PS/2 mouse device for input2
Nov  3 15:07:08 apple kernel: event1: Event device for input2
Nov  3 15:07:08 apple kernel: input2: ADB HID on ID 3:3.01
Nov  3 15:07:08 apple kernel: hda: Enabling MultiWord DMA 2
Nov  3 15:10:48 apple kernel: hdc: Enabling MultiWord DMA 2


15:29@pts/2 ~ > cat /var/log/daemon.log
<snip>
Nov  3 15:07:07 apple pmud[130]: initiating user requested sleep
Nov  3 15:07:07 apple pmud[130]: running /etc/power/pwrctl sleep ac
Nov  3 15:07:07 apple pmud[130]: going to sleep
Nov  3 15:10:48 apple pmud[130]: system awake again
Nov  3 15:10:48 apple pmud[130]: running /etc/power/pwrctl wakeup ac



Regards



		Claus

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

>just for the record:
>
>I've got the same crash as Albrecht in Sept. with 2.2.18pre4-ben1
>and linuxppc2k on my PB3400 without the wakebay app.
>
>Sep 18 00:35:03 apple kernel: Kernel panic: kernel access of bad area pc
>c00cf34c lr c00cfa88 address 24 tsk
>+pmud/297
>
>System.map-2.2.18pre4-ben1:
>c00cf218 t idepmac_sleep_device
>c00cf334 t idepmac_wake_device
>c00cf400 t idepmac_sleep_interface
>c00cf4e4 t idepmac_wake_interface
>c00cf728 t idepmac_notify_sleep
>c00cfab0 T ide_dma_intr
>c00cfb8c T ide_build_dmatable

Please, try to disassemble idepmac_sleep_device with objdump and see
where exactly it crashes. Looks like there may be some bad pointer going
on there...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

Seems I've seen that message before ???

> >Sep 18 00:35:03 apple kernel: Kernel panic: kernel access of bad area pc
> >c00cf34c lr c00cfa88 address 24 tsk
> >+pmud/297
> >
> >System.map-2.2.18pre4-ben1:
> >c00cf218 t idepmac_sleep_device
> >c00cf334 t idepmac_wake_device
>
> Please, try to disassemble idepmac_sleep_device with objdump and see
> where exactly it crashes. Looks like there may be some bad pointer going
> on there...

Rather disassemble idepmac_wake_device (that's where tha PC falls IMHO).

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Claus]

Moin Michael!

 >:
 >: Seems I've seen that message before ???
 >:
 >: > >Sep 18 00:35:03 apple kernel: Kernel panic: kernel access of bad area pc
 >: > >c00cf34c lr c00cfa88 address 24 tsk
 >: > >+pmud/297
 >: > >
 >: > >System.map-2.2.18pre4-ben1:
 >: > >c00cf218 t idepmac_sleep_device
 >: > >c00cf334 t idepmac_wake_device
 >: >
 >: > Please, try to disassemble idepmac_sleep_device with objdump and see
 >: > where exactly it crashes. Looks like there may be some bad pointer going
 >: > on there...
 >:
 >: Rather disassemble idepmac_wake_device (that's where tha PC falls IMHO).
 >:
 >: 	Michael


I've just had a snooze-pmud-cd_module crash, sorry it's not in log/messages.
I wrote this from the screen: pc c00d82cc lr c00d8aa8

2:02@pts/1 ~ > uname -a
Linux apple 2.2.18pre17-ben1 #38 Wed Oct 25 18:51:51 CEST 2000 ppc unknown

c00d82b4 <idepmac_wake_device>:
c00d82b4:       94 21 ff d0     stwu    r1,-48(r1)
c00d82b8:       7c 08 02 a6     mflr    r0
c00d82bc:       bf a1 00 24     stmw    r29,36(r1)
c00d82c0:       90 01 00 34     stw     r0,52(r1)
c00d82c4:       7c 7f 1b 78     mr      r31,r3
c00d82c8:       81 3f 00 54     lwz     r9,84(r31)
c00d82cc:       80 09 00 24     lwz     r0,36(r9)
^^^^^^^^
<snip>
c00d8720 <idepmac_notify_sleep>:
c00d8720:       94 21 ff c0     stwu    r1,-64(r1)
c00d8724:       7c 08 02 a6     mflr    r0
<snip>
c00d8970:       7f d9 00 2e     lwzx    r30,r25,r0
c00d8974:       3b 5d 00 01     addi    r26,r29,1
c00d8978:       2c 1e 00 00     cmpwi   r30,0
c00d897c:       41 82 01 2c     beq     c00d8aa8 <idepmac_notify_sleep+0x388>
<snip>
c00d8a98:       40 80 00 10     bge     c00d8aa8 <idepmac_notify_sleep+0x388>
c00d8a9c:       7f e3 fb 78     mr      r3,r31
c00d8aa0:       7f c4 f3 78     mr      r4,r30
c00d8aa4:       4b ff f8 11     bl      c00d82b4 <idepmac_wake_device>
c00d8aa8:       80 18 e3 d8     lwz     r0,-7208(r24)
^^^^^^^^
c00d8aac:       7f 5d d3 78     mr      r29,r26
c00d8ab0:       7c 1d 00 00     cmpw    r29,r0
c00d8ab4:       41 80 fe ac     blt     c00d8960 <idepmac_notify_sleep+0x240>
c00d8ab8:       38 60 00 00     li      r3,0
c00d8abc:       80 01 00 44     lwz     r0,68(r1)
c00d8ac0:       7c 08 03 a6     mtlr    r0
c00d8ac4:       ba c1 00 18     lmw     r22,24(r1)
c00d8ac8:       38 21 00 40     addi    r1,r1,64
c00d8acc:       4e 80 00 20     blr

c00d8ad0 <ide_dma_intr>:
c00d8ad0:       94 21 ff e0     stwu    r1,-32(r1)
<snip>


Regards



			Claus

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> I've just had a snooze-pmud-cd_module crash, sorry it's not in log/messages.
> I wrote this from the screen: pc c00d82cc lr c00d8aa8
>
> 2:02@pts/1 ~ > uname -a
> Linux apple 2.2.18pre17-ben1 #38 Wed Oct 25 18:51:51 CEST 2000 ppc unknown
>
> c00d82b4 <idepmac_wake_device>:
> c00d82b4:       94 21 ff d0     stwu    r1,-48(r1)
> c00d82b8:       7c 08 02 a6     mflr    r0
> c00d82bc:       bf a1 00 24     stmw    r29,36(r1)
> c00d82c0:       90 01 00 34     stw     r0,52(r1)
> c00d82c4:       7c 7f 1b 78     mr      r31,r3
> c00d82c8:       81 3f 00 54     lwz     r9,84(r31)
> c00d82cc:       80 09 00 24     lwz     r0,36(r9)
> ^^^^^^^^

That would be around

	DRIVER(drive)->media_change(drive);

and indicates that the driver part of the ide_drive struct is hosed, if I
interpret the assembly above right (r9 is loaded from *r31+84, r0 then
loaded from *r9+36).

Something scribbling over kernel memory?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Joseph P. Garcia]

Benjamin Herrenschmidt wrote:
> >if you panic'ed with the CD module inserted, would you try to snooze
> >without it?
> >
> >or try this one:
>
> Well, the kernel sleep code is supposed to take care of that, but
> apparently, that code is also causing the panic...

any possibility that the VFS layer causing more serious problems here?  Comments
before cdrom.c:media_changed() seem to hint at a potential race condition, and
if the pmac-ide sleep code tries doing the VFS-sync itself, it might aggrivate
matters.  Should/Is VFS being kicked automagically by the cdrom code, or might
we need some syncing or buffering code in ide-pmac.c to prevent a panic?

Could also be that the wakebay app/hack runs on the drive after DMA was
re-enabled.  I assume there is no problem with the media change acting on a
non-mediabay disk, which it appears to me it would be doing.

BTW, pmud 0.7.1 uses wakebay by default.  my PDQ doesnt have the panic problem
either.

--
Joseph P. Garcia      jpgarcia@execpc.com      jpgarcia@lidar.ssec.wisc.edu
CS Undergraduate                      Student Employee - Systems Programmer
University of Wisconsin - Madison                            UW Lidar Group

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

>> Well, the kernel sleep code is supposed to take care of that, but
>> apparently, that code is also causing the panic...
>
>any possibility that the VFS layer causing more serious problems here?
>Comments
>before cdrom.c:media_changed() seem to hint at a potential race
condition, and
>if the pmac-ide sleep code tries doing the VFS-sync itself, it might
aggrivate
>matters.  Should/Is VFS being kicked automagically by the cdrom code, or
might
>we need some syncing or buffering code in ide-pmac.c to prevent a panic?

The sleep code in via-pmu.c does a sync, and the sleep code ide-pmac.c
locks the IDE request queue preventing any other request from coming in
until it's unlocked on wakeup. I did this part. Michael did the VFS
stuffs, I must admit I didn't look at the VFS layer in depth myself.

>Could also be that the wakebay app/hack runs on the drive after DMA was
>re-enabled.  I assume there is no problem with the media change acting on a
>non-mediabay disk, which it appears to me it would be doing.

Well, the devices beeing powered down, it can't harm to send them a media
change.

>BTW, pmud 0.7.1 uses wakebay by default.  my PDQ doesnt have the panic
problem
>either.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> The sleep code in via-pmu.c does a sync, and the sleep code ide-pmac.c
> locks the IDE request queue preventing any other request from coming in
> until it's unlocked on wakeup. I did this part. Michael did the VFS
> stuffs, I must admit I didn't look at the VFS layer in depth myself.

I've looked at other uses of check_disk_change and there are no special
precautions (the function is called at mount or open time and doesn't seem
critical). I don't interpret the comment before media_changed() to
indicate a race, rather the unit attention signaling a media change isn't
persistent and the CD driver must keep track of the change condition
separately. Unit attention not being persistent is the reason why the
DRIVER(drive)->media_change(drive) call has to be the first command the
drive sees after wakeup. Otherwise the drive status gets reset and the IDE
driver never really checks for sense info...

First causing the low level media change check, and then kicking the VFS
check_disk_change() is what we do now, and we do indeed need both in order
to avoid a panic and later error messages from VFS (leaving out the
check_disk_change() call still requires you to issue that call later via
ioctl before you can access the disk again).

> >Could also be that the wakebay app/hack runs on the drive after DMA was
> >re-enabled.  I assume there is no problem with the media change acting on a
> >non-mediabay disk, which it appears to me it would be doing.
>
> Well, the devices beeing powered down, it can't harm to send them a media
> change.

The wakebay app runs on the drive only after all kernel based wakeup
(including the revalidate kicked by check_disk_change()). If the drive
wasn't a mediabay device we would need separate code to wake it, if it was
never powered down there would be no disk change status pending.

With the full revalidate done in the kernel we don't really need the
wakebay app anymore.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Olaf Hering]

On Thu, Nov 02, Albrecht Dreß wrote:

> Olaf Hering wrote:
> > Try current linux-pmac-benh.
>
> O.K., I rsynced linux-pmac-benh from penguinppc.org (which is version
> 2.2.18pre17-ben1), built it, and now I get a kernel panic upon wakeup. My pmud
> version is still 0.7.1.
>
> I attach the kernel .config and the relevant part from /var/log/messages, and as
> always, any help is _really_ welcome!

Hmm, I can provide diffs between 2.2.18pre15-ben1 and the current tree,
if someone needs that.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> The rsync'ed 2.2.18pre17 kernel hangs if I try to wake up my Lombard after a
> sleep. Sleeping seems to work (the LED binks), but upon wakeup it just stops
> blinking, and nothing else. No reports in /var/log/messages, I just have to
> reboot.

To follow up on this: 2.2.18pre18 does not freeze on sleep or wakeup on my
Lombard (no CD in drive, CD in drive, CD mounted, regardless).

It does freeze, however, when I snooze the machine while using software
cursor. Seems the software cursor interrupt needs to be stopped before
turning off the display :-) Question: is software cursor support worth the
hassle?

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

>To follow up on this: 2.2.18pre18 does not freeze on sleep or wakeup on my
>Lombard (no CD in drive, CD in drive, CD mounted, regardless).
>
>It does freeze, however, when I snooze the machine while using software
>cursor. Seems the software cursor interrupt needs to be stopped before
>turning off the display :-) Question: is software cursor support worth the
>hassle?

well, it's probably not difficult to fix. I'll give it a look.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> >It does freeze, however, when I snooze the machine while using software
> >cursor. Seems the software cursor interrupt needs to be stopped before
> >turning off the display :-) Question: is software cursor support worth the
> >hassle?
>
> well, it's probably not difficult to fix. I'll give it a look.

Right now, there's no hook in the fbcon code for this AFAIK. On second
thought, all it should take is to clear cursor_on in fbcon.c before sleep
(i.e. by fbcon_cursor(CM_ERASE), but that won't tell you if the cursor was
already erased). Adding new hooks to the consw struct is a no-no, perhaps.
Adding a CM_PAUSE / CM_RESUME feature to fbcon_cursor might be sufficient.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Olaf Hering]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On Thu, Oct 26, Paul Mackerras wrote:

>
> I have updated my rsync trees with some more changes to my current
> 2.2.18pre17 source, mostly to allow a range of configs to compile
> successfully.  I have also checked in the changes to the linuxppc_2_2
> bk tree.  Prep-only configs should compile ok now and as a bonus they
> no longer include all the pmac and chrp code that they used to.
>
> If anyone gets compile errors with my 2.2.18pre17 tree, or the current
> bk tree, please send me your .config.  I'm making a collection. :)
>
> My primary rsync tree for the 2.2 kernel source is now at
> ppc.linuxcare.com::linux-pmac-stable.  There is also a copy at
> penguinppc.org::linux-pmac-stable.

I synced that morning.
There is still some unresolved stuff for prep or chrp only, a common
config compiles fine.
The attached patch makes it compile, it works on a 43p 133, the TP850. A
MTX+ machine hangs with scsi resets, I will try a newer symbios logic
driver.
A B50 doesnt boot at all, it hangs after "Booting...", could be some asm
stuff.

The prep config is basicly that what I sent you a few days ago, I just
disabled the OF stuff.


Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

[-- Attachment #2: pmac_stable_2.2.18pre17.dif --]
[-- Type: text/plain, Size: 8631 bytes --]

diff -urN tmp/linux-pmac-stable.orig/arch/ppc/kernel/prep_pci.c linux-pmac-stable.chrp/arch/ppc/kernel/prep_pci.c
--- tmp/linux-pmac-stable.orig/arch/ppc/kernel/prep_pci.c	Wed Sep 13 01:06:23 2000
+++ linux-pmac-stable.chrp/arch/ppc/kernel/prep_pci.c	Fri Oct 27 17:01:16 2000
@@ -436,8 +436,8 @@

 static char ibm8xx_pci_IRQ_routes[] __prepdata = {
         0,      /* Line 0 - unused */
-        13,     /* Line 1 */
-        10,     /* Line 2 */
+        15,     /* Line 1 */
+        15,     /* Line 2 */
         15,     /* Line 3 */
         15,     /* Line 4 */
 };
diff -urN tmp/linux-pmac-stable.orig/arch/ppc/kernel/prep_setup.c linux-pmac-stable.chrp/arch/ppc/kernel/prep_setup.c
--- tmp/linux-pmac-stable.orig/arch/ppc/kernel/prep_setup.c	Thu Oct 26 04:56:13 2000
+++ linux-pmac-stable.chrp/arch/ppc/kernel/prep_setup.c	Fri Oct 27 17:01:16 2000
@@ -355,6 +355,8 @@
 	vgacon_remap_base = 0xf0000000;
 	/*vgacon_remap_base = ioremap(0xc0000000, 0xba000);*/
         conswitchp = &vga_con;
+#elif defined(CONFIG_DUMMY_CONSOLE)
+	conswitchp = &dummy_con;
 #endif
 }

@@ -834,7 +836,7 @@
 	else if (_prep_type == _PREP_IBM) {
 		ppc_md.set_rtc_time   = mc146818_set_rtc_time;
 		ppc_md.get_rtc_time   = mc146818_get_rtc_time;
-		ppc_md.calibrate_decr = prep_calibrate_decr;
+		ppc_md.calibrate_decr = prep_res_calibrate_decr;
 	}
 	else {
 		ppc_md.set_rtc_time   = mk48t59_set_rtc_time;
diff -urN tmp/linux-pmac-stable.orig/arch/ppc/kernel/prom.c linux-pmac-stable.chrp/arch/ppc/kernel/prom.c
--- tmp/linux-pmac-stable.orig/arch/ppc/kernel/prom.c	Wed Sep 13 01:08:58 2000
+++ linux-pmac-stable.chrp/arch/ppc/kernel/prom.c	Fri Oct 27 15:26:57 2000
@@ -2095,8 +2095,10 @@
 						(bi->dispDeviceDepth >> 3)) >> 2;
 	int i,j;

+#ifdef CONFIG_PMAC
 	pmu_suspend();
-
+#endif
+
 	for (i=0; i<(bi->dispDeviceRect[3] - bi->dispDeviceRect[1] - 16); i++)
 	{
 		unsigned long *src_ptr = src;
@@ -2114,7 +2116,9 @@
 		dst += (bi->dispDeviceRowBytes >> 2);
 	}

+#ifdef CONFIG_PMAC
 	pmu_resume();
+#endif
 }

 __pmac
diff -urN tmp/linux-pmac-stable.orig/drivers/char/mem.c linux-pmac-stable.chrp/drivers/char/mem.c
--- tmp/linux-pmac-stable.orig/drivers/char/mem.c	Thu Oct 26 07:40:21 2000
+++ linux-pmac-stable.chrp/drivers/char/mem.c	Fri Oct 27 15:32:39 2000
@@ -52,7 +52,7 @@
 #ifdef CONFIG_MDA_CONSOLE
 extern void mda_console_init(void);
 #endif
-#if defined(CONFIG_PPC) || defined(CONFIG_MAC)
+#if defined(CONFIG_PMAC) || defined(CONFIG_MAC)
 extern void adbdev_init(void);
 #endif
 #ifdef CONFIG_USB
@@ -665,7 +665,7 @@
 #ifdef CONFIG_VIDEO_BT848
 	i2c_init();
 #endif
-#if defined(CONFIG_PPC) || defined(CONFIG_MAC)
+#if defined(CONFIG_PMAC) || defined(CONFIG_MAC)
 	adbdev_init();
 #endif
 #ifdef CONFIG_VIDEO_DEV
diff -urN tmp/linux-pmac-stable.orig/drivers/char/misc.c linux-pmac-stable.chrp/drivers/char/misc.c
--- tmp/linux-pmac-stable.orig/drivers/char/misc.c	Sun Sep 24 20:37:54 2000
+++ linux-pmac-stable.chrp/drivers/char/misc.c	Fri Oct 27 15:33:46 2000
@@ -78,11 +78,15 @@
 extern int rtc_DP8570A_init(void);
 extern int rtc_MK48T08_init(void);
 extern int dsp56k_init(void);
+#ifdef CONFIG_PMAC
 extern int nvram_init(void);
+#endif
 extern int radio_init(void);
 extern void hfmodem_init(void);
 extern int pc110pad_init(void);
+#ifdef CONFIG_PMAC
 extern int pmu_device_init(void);
+#endif
 extern int tosh_init(void);
 extern int rng_init(void);

@@ -257,7 +261,7 @@
 #ifdef CONFIG_HFMODEM
 	hfmodem_init();
 #endif
-#ifdef CONFIG_NVRAM
+#if defined(CONFIG_NVRAM) && defined(CONFIG_PMAC)
 	nvram_init();
 #endif
 #ifdef CONFIG_MISC_RADIO
diff -urN tmp/linux-pmac-stable.orig/drivers/video/aty128fb.c linux-pmac-stable.chrp/drivers/video/aty128fb.c
--- tmp/linux-pmac-stable.orig/drivers/video/aty128fb.c	Wed Oct 11 23:26:41 2000
+++ linux-pmac-stable.chrp/drivers/video/aty128fb.c	Fri Oct 27 15:26:58 2000
@@ -51,11 +51,12 @@
 #include <asm/pci-bridge.h>
 #include <linux/nvram.h>
 #include <video/macmodes.h>
+#ifdef CONFIG_PMAC
 #include <asm/adb.h>
 #include <asm/pmu.h>
 #include <asm/backlight.h>
 #endif
-
+#endif
 #ifdef CONFIG_FB_COMPAT_XPMAC
 #include <asm/vc_ioctl.h>
 #endif
@@ -419,7 +420,7 @@
     aty128fb_set_cmap, aty128fb_pan_display, aty128fb_ioctl
 };

-#ifdef CONFIG_PPC
+#ifdef CONFIG_PMAC
 static int aty128_set_backlight_enable(int on, int level, void* data);
 static int aty128_set_backlight_level(int level, void* data);

@@ -427,7 +428,7 @@
 	aty128_set_backlight_enable,
 	aty128_set_backlight_level
 };
-#endif
+#endif /* CONFIG_PMAC */

     /*
      * Functions to read from/write to the mmio registers
@@ -1802,13 +1803,13 @@
     if (register_framebuffer(&info->fb_info) < 0)
 	return 0;

-#ifdef CONFIG_PPC
+#ifdef CONFIG_PMAC
     if (info->chip_gen == rage_M3)
     	register_backlight_controller(&aty128_backlight_controller, info, "ati");
-#endif
 #ifdef CONFIG_PMAC_PBOOK
     pmu_register_sleep_notifier(&aty128_sleep_notifier);
 #endif
+#endif

     printk(KERN_INFO "fb%d: %s frame buffer device on %s\n",
 	   GET_FB_IDX(info->fb_info.node), aty128fb_name, name);
@@ -2257,7 +2258,7 @@
     struct fb_info_aty128 *info = (struct fb_info_aty128 *)fb;
     u8 state = 0;

-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PMAC)
     if ((_machine == _MACH_Pmac) && blank)
     	set_backlight_enable(0);
 #endif
@@ -2271,7 +2272,7 @@

     aty_st_8(CRTC_EXT_CNTL+1, state);

-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PMAC)
     if ((_machine == _MACH_Pmac) && !blank)
     	set_backlight_enable(1);
 #endif
@@ -2412,7 +2413,7 @@
     }
 }

-#ifdef CONFIG_PPC
+#ifdef CONFIG_PMAC

 static int backlight_conv[] = {
 	0xff, 0xc0, 0xb5, 0xaa, 0x9f, 0x94, 0x89, 0x7e,
@@ -2447,7 +2448,7 @@
 	return aty128_set_backlight_enable(1, level, data);
 }

-#endif
+#endif /* CONFIG_PMAC */

     /*
      *  Accelerated functions
diff -urN tmp/linux-pmac-stable.orig/drivers/video/atyfb.c linux-pmac-stable.chrp/drivers/video/atyfb.c
--- tmp/linux-pmac-stable.orig/drivers/video/atyfb.c	Sun Sep 10 20:47:40 2000
+++ linux-pmac-stable.chrp/drivers/video/atyfb.c	Fri Oct 27 15:26:58 2000
@@ -68,10 +68,12 @@
 #include <asm/prom.h>
 #include <asm/pci-bridge.h>
 #include <video/macmodes.h>
+#if defined(CONFIG_PMAC)
 #include <asm/adb.h>
 #include <asm/pmu.h>
 #include <asm/backlight.h>
-#endif
+#endif /* CONFIG_PMAC */
+#endif /* CONFIG_PPC */
 #ifdef __sparc__
 #include <asm/pbm.h>
 #include <asm/fbio.h>
@@ -412,7 +414,7 @@
 #endif
 };

-#ifdef CONFIG_PPC
+#ifdef CONFIG_PMAC
 static int aty_set_backlight_enable(int on, int level, void* data);
 static int aty_set_backlight_level(int level, void* data);

@@ -2787,7 +2789,7 @@
 	    info->total_vram -= GUI_RESERVE;
 	}

-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PMAC)
     if (Gx == LI_CHIP_ID && machine_is_compatible("PowerBook1,1")) {
 	/* these bits let the 101 powerbook wake up from sleep -- paulus */
 	aty_st_lcd(LCD_POWER_MANAGEMENT, aty_ld_lcd(LCD_POWER_MANAGEMENT, info)
@@ -2831,9 +2833,9 @@
 	default_cmode = CMODE_8;
     if (mac_vmode_to_var(default_vmode, default_cmode, &var))
 	var = default_var;
-#else /* !CONFIG_PPC */
+#else /* !CONFIG_PMAC */
     var = default_var;
-#endif /* !CONFIG_PPC */
+#endif /* !CONFIG_PMAC */
     if (noaccel)
         var.accel_flags &= ~FB_ACCELF_TEXT;
     else
@@ -3504,7 +3506,7 @@
     struct fb_info_aty *info = (struct fb_info_aty *)fb;
     u8 gen_cntl;

-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PMAC)
     if ((_machine == _MACH_Pmac) && blank)
     	set_backlight_enable(0);
 #endif
@@ -3529,7 +3531,7 @@
 	gen_cntl &= ~(0x4c);
     aty_st_8(CRTC_GEN_CNTL, gen_cntl, info);

-#if defined(CONFIG_PPC)
+#if defined(CONFIG_PMAC)
     if ((_machine == _MACH_Pmac) && !blank)
     	set_backlight_enable(1);
 #endif
@@ -4227,7 +4229,7 @@
 }
 #endif /* CONFIG_PMAC_PBOOK */

-#ifdef CONFIG_PPC
+#ifdef CONFIG_PMAC
 static int backlight_conv[] = {
 	0x00, 0x3f, 0x4c, 0x59, 0x66, 0x73, 0x80, 0x8d,
 	0x9a, 0xa7, 0xb4, 0xc1, 0xcf, 0xdc, 0xe9, 0xff
@@ -4256,7 +4258,7 @@
 {
 	return aty_set_backlight_enable(1, level, data);
 }
-#endif /* CONFIG_PPC */
+#endif /* CONFIG_PMAC */


  #ifdef MODULE
diff -urN tmp/linux-pmac-stable.orig/include/asm-ppc/vga.h linux-pmac-stable.chrp/include/asm-ppc/vga.h
--- tmp/linux-pmac-stable.orig/include/asm-ppc/vga.h	Thu Oct 26 06:42:25 2000
+++ linux-pmac-stable.chrp/include/asm-ppc/vga.h	Fri Oct 27 19:11:43 2000
@@ -46,8 +46,12 @@
 #define scr_memcpyw_from memcpy
 #define scr_memcpyw_to memcpy

+#ifdef CONFIG_PREP
 extern unsigned long vgacon_remap_base;
 #define VGA_MAP_MEM(x) (x + vgacon_remap_base)
+#else
+#define VGA_MAP_MEM(x) (x)
+#endif /* CONFIG_PREP */
 #define vga_readb(x) (*(x))
 #define vga_writeb(x,y) (*(y) = (x))

Re: 2.2.18pre17 again

[Olaf Hering]

On Fri, Oct 27, Olaf Hering wrote:

> A B50 doesnt boot at all, it hangs after "Booting...", could be some asm
> stuff.

I tried some 18pre versions, but I didn't find the real trigger.
When I boot our 2.2.16 kernel and then the 2.2.18pre11 the machine comes
back. Rebooting again in that 2.2.18pre11 and it hangs. Same with a
pre10. The plain pre17 doesnt boot at all.



Gruss Olaf

--
 $ man clone

BUGS
       Main feature not yet implemented...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Michel Lanners]

Hi Paul.

On  26 Oct, this message from Paul Mackerras echoed through cyberspace:
> I have updated my rsync trees with some more changes to my current
> 2.2.18pre17 source

There are a few patches on sourceforge that you might consider for the
2.2.18 kernel release:

- per-fb mmap for controlfb: this one has worked well for everybody who
tested it, and gives a decent speed increase:

https://sourceforge.net/patch/?func=detailpatch&patch_id=101236&group_id=8234

- better processor configuration in head.S. This is basicallz a copz of
  what is already done in 2.4:

https://sourceforge.net/patch/?func=detailpatch&patch_id=101403&group_id=8234

- macserial proc additions and cleanups:

https://sourceforge.net/patch/?func=detailpatch&patch_id=101410&group_id=8234

- ICTC support in the sysctl interface:

https://sourceforge.net/patch/?func=detailpatch&patch_id=101484&group_id=8234

- kernel compilation independant of the /usr/src/linux path (however,
  this patches the top-level Makefile as well...):

https://sourceforge.net/patch/?func=detailpatch&patch_id=101549&group_id=8234

I have one or two other things (not of any particular importance); if I
get around to making a patch in the next days, I'll send them along.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Benjamin Herrenschmidt]

>- ICTC support in the sysctl interface:

Won't this require recalibrating the loops_per_jiffy for udelay() ?

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Gabriel Paubert]

On Tue, 31 Oct 2000, Benjamin Herrenschmidt wrote:

>
> >- ICTC support in the sysctl interface:
>
> Won't this require recalibrating the loops_per_jiffy for udelay() ?

Why isn't udelay based on the timebase then ? Easy to scale
microseconds to timebase.

There is a multiplier for mulhwu somewhere in a global variable, I should
remember the name since I wrote the code, tb_to_us if I'm not messing up.

It needs some care for 601 because of the different registers (RTC) that
has the bad habit of jumping from 1e9 to 0. It is trivial to implement as
a subroutine and check for CPU inside the subroutine. After all it's a
delay, so performance should not be critical.

udelay:
	lis	r4,tb_to_us@ha
	mfpvr	r5
	lwz	r4,tb_to_us@l(r4)
	srwi	r5,r5,16
	mulhwu	r4,r3,r4
	cmpwi	cr0,r5,1
	beq	2f
	mftbl	r5
1:	mftbl	r3
	sub	r3,r3,r5
	cmplw	cr0,r3,r4	# works for delays of up to almost 2^32 tb ticks
	blt	cr0,1b
	blr

2:	mfrtcl	r5
3:	mfrtcl	r3
	sub.	r3,r3,r5	# if wraparound has occurred
	bnl+	4f		# bump elapsed time by one second
	addis	r3,r3,1000000000@ha
	addi	r3,r3,1000000000@l
4:	cmplw	r3,r3,r4	# works for delays of up to almost 1 second
	blt	cr0,3b
	blr

Caution, untested... BTW, that's the kind of routine in which I'd like to
tell the compiler that it only uses r3/r4/r5/cr0 so that it can keep more
variables in the registers of the caller.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Benjamin Herrenschmidt]

>
>Why isn't udelay based on the timebase then ? Easy to scale
>microseconds to timebase.

Because you didn't implement it yet ? :)

>There is a multiplier for mulhwu somewhere in a global variable, I should
>remember the name since I wrote the code, tb_to_us if I'm not messing up.

Do we have that code in 2.2 ? Your time management patches are in 2.4
only AFAIK (nice code BTW).

>It needs some care for 601 because of the different registers (RTC) that
>has the bad habit of jumping from 1e9 to 0. It is trivial to implement as
>a subroutine and check for CPU inside the subroutine. After all it's a
>delay, so performance should not be critical.
>
>udelay:
>	lis	r4,tb_to_us@ha
>	mfpvr	r5
>	lwz	r4,tb_to_us@l(r4)
>	srwi	r5,r5,16
>	mulhwu	r4,r3,r4
>	cmpwi	cr0,r5,1
>	beq	2f
>	mftbl	r5
>1:	mftbl	r3
>	sub	r3,r3,r5
>	cmplw	cr0,r3,r4	# works for delays of up to almost 2^32 tb ticks
>	blt	cr0,1b
>	blr
>
>2:	mfrtcl	r5
>3:	mfrtcl	r3
>	sub.	r3,r3,r5	# if wraparound has occurred
>	bnl+	4f		# bump elapsed time by one second
>	addis	r3,r3,1000000000@ha
>	addi	r3,r3,1000000000@l
>4:	cmplw	r3,r3,r4	# works for delays of up to almost 1 second
>	blt	cr0,3b
>	blr
>
>Caution, untested... BTW, that's the kind of routine in which I'd like to
>tell the compiler that it only uses r3/r4/r5/cr0 so that it can keep more
>variables in the registers of the caller.

What is the max delay supported ? I beleive we should implement it as
__udelay and keept the macro mecanism to catch too high delays.

>	Gabriel.
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Gabriel Paubert]

On Tue, 31 Oct 2000, Benjamin Herrenschmidt wrote:

> >
> >Why isn't udelay based on the timebase then ? Easy to scale
> >microseconds to timebase.
>
> Because you didn't implement it yet ? :)

Perhaps...

>
> >There is a multiplier for mulhwu somewhere in a global variable, I should
> >remember the name since I wrote the code, tb_to_us if I'm not messing up.
>
> Do we have that code in 2.2 ? Your time management patches are in 2.4
> only AFAIK (nice code BTW).

Well, maybe. I'm sure they are in my local 2.2 tree, which is still at
2.2.12, because I absolutely needed them for production: otherwise clocks
were drifting randomly by up to several milliseconds even when controlled
by NTP. In my case a clock off by 5 milliseconds is basically the same as
no clock ;-)

> >It needs some care for 601 because of the different registers (RTC) that
> >has the bad habit of jumping from 1e9 to 0. It is trivial to implement as
> >a subroutine and check for CPU inside the subroutine. After all it's a
> >delay, so performance should not be critical.
> >
> >udelay:
> >	lis	r4,tb_to_us@ha
> >	mfpvr	r5
> >	lwz	r4,tb_to_us@l(r4)
> >	srwi	r5,r5,16
> >	mulhwu	r4,r3,r4
> >	cmpwi	cr0,r5,1
> >	beq	2f
> >	mftbl	r5
> >1:	mftbl	r3
> >	sub	r3,r3,r5
> >	cmplw	cr0,r3,r4	# works for delays of up to almost 2^32 tb ticks
> >	blt	cr0,1b
> >	blr
> >
> >2:	mfrtcl	r5
> >3:	mfrtcl	r3
> >	sub.	r3,r3,r5	# if wraparound has occurred
> >	bnl+	4f		# bump elapsed time by one second
> >	addis	r3,r3,1000000000@ha
> >	addi	r3,r3,1000000000@l
> >4:	cmplw	cr0,r3,r4	# works for delays of up to almost 1 second
> >	blt	cr0,3b
> >	blr
> >
>
> What is the max delay supported ? I beleive we should implement it as
> __udelay and keept the macro mecanism to catch too high delays.

It's in the comments: 1 second for 601, 2^32 timebase ticks for the other
(minus maximum interrupt + bh running time if interrupts are enabled).

Catching too long delays in the macros is ok, but the code can also catch
it at runtime since it's only a few instructions in the subroutine:

	andis. r0,r3,0xfffe; bne- what_are_you_smoking

will limit the udelay constant to about 0.13 second (131072 microseconds
to be exact). Of course at what_are_you_smoking the kernel starts a
complex process to find the author of the offending code and fulminate
him/her ;-): udelay values above a few hundred are almost always the
result of laziness or careless programming.

Even with a 33 MHz timebase (keep dreaming), the maximal delay for non
601 CPUs is over 100 seconds. However, there is one problem if we start
having preemptible kernels, especially for 601: a preempted udelay
could be lengthened by multiples of 1 second. There is a solution to this
problem, but it requires reading the rtcu and doing all the math on every
iteration. I just did not feel like writing it, especially since I
can't test it. Put a big warning in a comment if necessary. It should also
be properly ifdefed so that when CONFIG_6XX is off, the 601 check and code
is removed.

	Gabriel.

BTW: is anybody interested in high resolution timers ? (Higher resolution
than one jiffy I mean). It should be relatively easy now that timing code
is cleaned up. But I won't have time to look at it for a few weeks...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Dan Malek]

Gabriel Paubert wrote:
>
> On Tue, 31 Oct 2000, Benjamin Herrenschmidt wrote:
>


> > Because you didn't implement it yet ? :)
>
> Perhaps...

Make sure you look at the code in the "boot" directories.  I think
all of them have udelay functions that use the timebase.  At least,
it would be a starting point.

> Even with a 33 MHz timebase (keep dreaming), the maximal delay for non
> 601 CPUs is over 100 seconds.

I thought at one time we had mdelay/udelay that were smart enough
to loop and call the lower level delay to ensure this maximum
delay wasn't exceeded.....maybe I was smoking something :-).


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: 2.2.18pre17 again

[Michel Lanners]

On  31 Oct, this message from Benjamin Herrenschmidt echoed through cyberspace:
>>- ICTC support in the sysctl interface:
>
> Won't this require recalibrating the loops_per_jiffy for udelay() ?

In a perfect world, yes. But I have seen no ill effects of a (limited)
loops_per_jiffy mismatch.

But I agree, if you want to heavily use ICTC we'd better fix this part.
But the solution has followed ;-)

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Derek Homeier]

On Fri, 3 Nov 2000 13:22:10 +0100 (CET),
Michael Schmitz <schmitz@opal.biophys.uni-duesseldorf.de> was rumoured to say:

>
> > 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/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Michael Schmitz]

> > 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/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Benjamin Herrenschmidt]

>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/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[Derek Homeier]

On Fri, 3 Nov 2000, Benjamin Herrenschmidt wrote:

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

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

> >	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/

Re: Lombard Sleep Crash (Was: 2.2.18pre17 again)

[nicola cabibbo]

First of all I'm a normal user, not a developper, so please excuse my
intervention on this list!

I have noticed that wakeup succeeds normally if executed within a short
time,
e.g. closing the lid, then reopening it after ten or twnty minutes.

On the contrary it fails after a longer sleep, e.g. overnight.

Does this suggest something?

Thanks,

    Nicola Cabibbo

PS I use a Lombard 400, with precompiled benh kernel, 2.2.17pre20-ben3,
        and pmud 0.7.1.
        The same behaviour was observed with the previous pmud (0.6 ?)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/