Re: Stability of 2.3.47 (G4)

Re: Stability of 2.3.47 (G4)

[Jack Howarth]

Deti,
   I am surprised you are able to boot your G4 at all under 2.3.47.
Is this 2.3.47 from the linuxcare.com.au linux-pmac-devel cvs?
Current on the Sawtooth machines which use the newer lucent
chipset these kernels hang on boot unless all usb devices are
removed. Attaching the usb devices after booting eventually
results in a crash as well.
                     Jack

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

Re: Stability of 2.3.47 (G4)

[Detlef Fliegl]

Hi Jack

> Deti,
>    I am surprised you are able to boot your G4 at all under 2.3.47.
> Is this 2.3.47 from the linuxcare.com.au linux-pmac-devel cvs?
It´s a kernel from Cort Dougan´s server. He was really a big aid in
setting up my machine (as I am not familiar with open firmware and Mac
hardware).

> Current on the Sawtooth machines which use the newer lucent
> chipset these kernels hang on boot unless all usb devices are
> removed. Attaching the usb devices after booting eventually
> results in a crash as well.
Yes I know - it seems to be a memory consistency problem. Roman
Weissgaerber (the author of the OHCI driver) is already informed and he
has access to our G4 for further testing.


Deti
--
Detlef Fliegl, LRR, Technische Universitaet Muenchen
Phone: +49 89 289-25770, Fax +49 89 289-28232, Room S3240

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

Re: Stability of 2.3.47 (G4)

[Gabriel Paubert]

On Mon, 28 Feb 2000, Detlef Fliegl wrote:

> Yes I know - it seems to be a memory consistency problem. Roman
> Weissgaerber (the author of the OHCI driver) is already informed and he
> has access to our G4 for further testing.

I have some doubts about memory consistency with smart PCI bridges if you
don't set the global bit in the PTE. What happens if you use the SMP
definition of _PAGE_BASE in asm/pgtable.h ? Write gathering in the CPU may
simply bypass all coherency mechanisms by allocating a cache line which is
being written to without signalling it on the bus, I don't see anything in
the PCI specifications preventing a bridge from actually prefetching
memory contents and caching them.

#define _PAGE_BASE      _PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT

I also have a strange problems on my 750 based MVME2400, the system boots
perfectly from power off, but a reboot leads to strange problems with
messages like (2.3.45):

*ap++ == 0x55
Report this to bash-maintainers@prep.ai.mit.edu

Setting clock  (utc): Sun Feb 27 16:25:52 /etc/localtime 2000
/etc/rc.d/rc.sysin
it: line 2:    68 Segmentation fault      initlog -n $0 -s "$1" -e 1

Last login: Sun Feb 27 17:24:33 on ttyS0
[: too many arguments

In other cases I had illegal instructions or ld.so bug messages, ld.so
would enter an apparently infinite loop when trying to load the init code
(system hang just after Freeing unused memory which I traced with a few
printk; it depends on your definition of infinity but not a single page
fault in one night and still responsive to interrupts). But this only
happens at the second (and following) reboots after power up.

It works perfectly on a 603e, and 2.2.12 also works on both
kinds of machines without problems. I added a zeroing of all free memory
in the bootloader and the problems have disappeared, this is the only clue
I have right now, has anybody had a similar experience ?

I suspected L2 cache coherency lost during early boot but this looks weird
since uncompressing the kernel should completely thrash the 1Mb
L2 cache (compressed + uncompressed kernel > 2Mb).

	Gabriel.


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

Re: Stability of 2.3.47 (G4)

[Deti Fliegl]

Gabriel Paubert wrote:
>
> On Mon, 28 Feb 2000, Detlef Fliegl wrote:
>
> > Yes I know - it seems to be a memory consistency problem. Roman
> > Weissgaerber (the author of the OHCI driver) is already informed and he
> > has access to our G4 for further testing.
>
> I have some doubts about memory consistency with smart PCI bridges if you
> don't set the global bit in the PTE. What happens if you use the SMP
> definition of _PAGE_BASE in asm/pgtable.h ? Write gathering in the CPU may
> simply bypass all coherency mechanisms by allocating a cache line which is
> being written to without signalling it on the bus, I don't see anything in
> the PCI specifications preventing a bridge from actually prefetching
> memory contents and caching them.
>
> #define _PAGE_BASE      _PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_COHERENT
>
> I also have a strange problems on my 750 based MVME2400, the system boots
> perfectly from power off, but a reboot leads to strange problems with
> messages like (2.3.45):
>
> *ap++ == 0x55
> Report this to bash-maintainers@prep.ai.mit.edu
>
> Setting clock  (utc): Sun Feb 27 16:25:52 /etc/localtime 2000
> /etc/rc.d/rc.sysin
> it: line 2:    68 Segmentation fault      initlog -n $0 -s "$1" -e 1
>
> Last login: Sun Feb 27 17:24:33 on ttyS0
> [: too many arguments
>
> In other cases I had illegal instructions or ld.so bug messages, ld.so
> would enter an apparently infinite loop when trying to load the init code
> (system hang just after Freeing unused memory which I traced with a few
> printk; it depends on your definition of infinity but not a single page
> fault in one night and still responsive to interrupts). But this only
> happens at the second (and following) reboots after power up.
>
> It works perfectly on a 603e, and 2.2.12 also works on both
> kinds of machines without problems. I added a zeroing of all free memory
> in the bootloader and the problems have disappeared, this is the only clue
> I have right now, has anybody had a similar experience ?
>
> I suspected L2 cache coherency lost during early boot but this looks weird
> since uncompressing the kernel should completely thrash the 1Mb
> L2 cache (compressed + uncompressed kernel > 2Mb).
>
>         Gabriel.
I can reproduce the same behavior: After the second reboot the system
becomes instable and often the init process cannot be started. If I
start MacOS in between the next Linux reboot is successful. Maybe there
is something not initialized fully.
If there is a corelation with the OHCI-USB controller problems is not
easy to see. My next try is plugging a PCI Analyzer into the machine to
see whats happening on the bus when the USB error occures.
On my Athlon Board (with AMD OHCI onboard controller) similar problems
with the OHCI driver occur. Often the registers cannot be read properly
and other weird things happen (including crashes). Roman Weissgaerber,
the author of the OHCI driver is currently busy but he promised helping
us in the next two weeks.


Deti
--
Deti Fliegl
Phone: +49 179 2198419 Fax: +49 89 74141105
e-mailto:deti@fliegl.de http://www.fliegl.de

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

RE: Stability of 2.3.47 (G4)

[Patrick Lerda]

I try linux 2.3.47 on an other kind of PowerPC box, a 740 with a PCI bus.
The kernel start, but my NE2000 or my tulip board don't work in an
nfs mode. The IDE driver crash, and The adaptec driver don't work too.
Otherwise USB seems to work, and my framebuffer works...

I don't know who sync beta PowerPC linux, but I suspect a lot of
little-endian to big-endian problems...


	Patrick L.ERDA


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

RE: Stability of 2.3.47 (G4)

[Tom Rini]

On Mon, 28 Feb 2000, Patrick Lerda wrote:

> I try linux 2.3.47 on an other kind of PowerPC box, a 740 with a PCI bus.
> The kernel start, but my NE2000 or my tulip board don't work in an
> nfs mode. The IDE driver crash, and The adaptec driver don't work too.
> Otherwise USB seems to work, and my framebuffer works...

Well, the ne2k-pci driver may or may not have been fixed finally (yes, it
is/was an endian issue and was patched.  I think the patch stuck tho).  As
for the tulip board, do not use the tulip driver, use de4x5.  I've tried 3
tulip cards with tulip.c 0.91g-ppc and none of them have worked. (a real
tulip, a lite-on and a maxtronic or something wierd like that).

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/


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