2.4.24-rc1 does not boot on SGI

2.4.24-rc1 does not boot on SGI

[Giuseppe Sacco]

This is quick note about a problem with the latest kernel (yesterday
snapshot from linux-mips git repository).

The new kernel once again does not boot on SGI O2. What happens is that
arcboot write its messages and nothing more is displayed on the screen.
The last message is "Starting ELF64 kernel". The previous running kernel
were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.

Does anyone have a suggestion about what to look for? I will start
looking at all diffs in arch/mips/sgi-ip32.

Bye,
Giuseppe

2.6.24-rc1 does not boot on SGI [was: 2.4.24-rc1 does not boot on SGI]

[Giuseppe Sacco]

Il giorno sab, 27/10/2007 alle 09.07 +0200, Giuseppe Sacco ha scritto:
> This is quick note about a problem with the latest kernel (yesterday
> snapshot from linux-mips git repository).
[...]

Oops, of course I meant 2.6.24-rc1 and not to 2.4.24-rc1.

Re: 2.4.24-rc1 does not boot on SGI

[Atsushi Nemoto]

On Sat, 27 Oct 2007 09:07:05 +0200, Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> wrote:
> The new kernel once again does not boot on SGI O2. What happens is that
> arcboot write its messages and nothing more is displayed on the screen.
> The last message is "Starting ELF64 kernel". The previous running kernel
> were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.
> 
> Does anyone have a suggestion about what to look for? I will start
> looking at all diffs in arch/mips/sgi-ip32.

Could you try this one?

http://www.linux-mips.org/archives/linux-mips/2007-10/msg00431.html

I suppose currently all 64-bit platforms which use cevt-r4k.c are
broken.

---
Atsushi Nemoto

2.6.24-rc1 does not boot on SGI [was: Re: 2.4.24-rc1 does not boot on SGI]

[Giuseppe Sacco]

Il giorno lun, 29/10/2007 alle 00.07 +0900, Atsushi Nemoto ha scritto:
> On Sat, 27 Oct 2007 09:07:05 +0200, Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> wrote:
[...]
> > Does anyone have a suggestion about what to look for? I will start
> > looking at all diffs in arch/mips/sgi-ip32.
> 
> Could you try this one?
> 
> http://www.linux-mips.org/archives/linux-mips/2007-10/msg00431.html
> 
> I suppose currently all 64-bit platforms which use cevt-r4k.c are
> broken.

Nothing changed using this patch: the system does not boot. Currently I
suspect the reason is the change the IRQ handling because it is the main
change in arch/mips/sg-ip32.

Re: 2.6.24-rc1 does not boot on SGI [was: Re: 2.4.24-rc1 does not boot on SGI]

[Ralf Baechle]

On Sun, Oct 28, 2007 at 08:17:11PM +0100, Giuseppe Sacco wrote:

> Nothing changed using this patch: the system does not boot. Currently I
> suspect the reason is the change the IRQ handling because it is the main
> change in arch/mips/sg-ip32.

All the patch was meant to is to renumber interrupts so interrupts 0 ... 7
become available for use with cpu_irq.c.  Irq 7 is the cp0 compare interrupt
which on IP32 is used as the clockevent device that is the source of
timer interrupts.

  Ralf

Re: 2.6.24-rc1 does not boot on SGI

[Giuseppe Sacco]

Hi Ralf,

Il giorno lun, 29/10/2007 alle 15.06 +0000, Ralf Baechle ha scritto:
> On Sun, Oct 28, 2007 at 08:17:11PM +0100, Giuseppe Sacco wrote:
> 
> > Nothing changed using this patch: the system does not boot. Currently I
> > suspect the reason is the change the IRQ handling because it is the main
> > change in arch/mips/sg-ip32.
> 
> All the patch was meant to is to renumber interrupts so interrupts 0 ... 7
> become available for use with cpu_irq.c.  Irq 7 is the cp0 compare interrupt
> which on IP32 is used as the clockevent device that is the source of
> timer interrupts.

The latest git update, gave a bootable 2.6.24-rc1 but now, while
booting, the system start looping and calling function print_irq_desc()
from kernel/irq/internals.h. I can only read "...count:...unhandled:..."
since the text scroll too quickly, but I will try to connect a serial
console in order to send here the complete message.

Bye,
Giuseppe

Re: 2.6.24-rc1 does not boot on SGI

[Giuseppe Sacco]

Il giorno lun, 05/11/2007 alle 14.15 +0100, Giuseppe Sacco ha scritto:
[...]
> The latest git update, gave a bootable 2.6.24-rc1 but now, while
> booting, the system start looping and calling function print_irq_desc()
> from kernel/irq/internals.h. I can only read "...count:...unhandled:..."
[...]

Here it is:

sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 0:0:4:0: Attached scsi CD-ROM sr0
mice: PS/2 mouse device common for all mice
irq 13, desc: ffffffff804486e0, depth: 1, count: 0, unhandled: 0
->handle_irq():  ffffffff800663c0, handle_bad_irq+0x0/0x2c0
->chip(): ffffffff8043e320, 0xffffffff8043e320
->action(): 0000000000000000
  IRQ_DISABLED set
unexpected IRQ # 13
irq 13, desc: ffffffff804486e0, depth: 1, count: 0, unhandled: 0
->handle_irq():  ffffffff800663c0, handle_bad_irq+0x0/0x2c0
->chip(): ffffffff8043e320, 0xffffffff8043e320
->action(): 0000000000000000
  IRQ_DISABLED set
unexpected IRQ # 13


and keep printing about interrupt #13. The log from the start is
available here
http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-2.6.24-rc1-unexpted-irq13.log.bz

Bye,
Giuseppe

Re: 2.6.24-rc1 does not boot on SGI

[Giuseppe Sacco]

I reply to my own message, providing more details, hoping that anyone
here could give a hint or the solution.

During bootup on ip32, since 2.4.24-rc1, the system loop printing a
message about unexpected interrupt #13. (see transcript below.)

I enabled more debug in the kernel, and studied the code. What I
understood is that interrupt #13 from CRIME means that the system should
check on MACEISA for the real interrupt.

The interrupt start appearing just after executing the code
psmouse_init() that enable ps2 drivers for keyboard and mouse. Keyboard
interrupt #49 is enabled first and mouse interrupt #51 is enabled later.

When initialising the keyboard interrupt (it is a MACEISA interrupt),
the interrupt start appearing, so I am pretty sure that interrupt #13 is
related to the keyboard interrupt.

When the system receive interrupt #13, it correctly detect it is a
MACEISA interrupt, and check for mace->perif.ctrl.istat value. The
problem seems to be that this value is zero instead of having bit #9 on
(that would mean, interrupt #49, keyboard).

So, either the interrupt #49 is not correctly enabled, or maceisa
interrupt aren't correctly checked.

Does this description ring a bell to anyone?

Bye,
Giuseppe

Calling initcall 0xffffffff80496ca0: serport_init+0x0/0x48()
initcall 0xffffffff80496ca0: serport_init+0x0/0x48() returned 0.
initcall 0xffffffff80496ca0 ran for 0 msecs: serport_init+0x0/0x48()
Calling initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0()
initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() returned 0.
initcall 0xffffffff80496ce8 ran for 1 msecs: maceps2_init+0x0/0xe0()
Calling initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18()
initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() returned 0.
initcall 0xffffffff80496dc8 ran for 1 msecs: serio_raw_init+0x0/0x18()
Calling initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0()
mice: PS/2 mouse device common for all mice
initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() returned 0.
initcall 0xffffffff80496f40 ran for 16 msecs: mousedev_init+0x0/0xd0()
Calling initcall 0xffffffff80497010: atkbd_init+0x0/0x18()
initcall 0xffffffff80497010: atkbd_init+0x0/0x18() returned 0.
initcall 0xffffffff80497010 ran for 0 msecs: atkbd_init+0x0/0x18()
Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90()
maceisa enable: 49
crime_int 00000020 enabled
*irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
->handle_irq():  ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
->chip(): ffffffff8043e320, 0xffffffff8043e320
->action(): 0000000000000000
  IRQ_DISABLED set

Re: 2.6.24-rc1 does not boot on SGI

[Ricardo Mendoza]

Giuseppe Sacco wrote:
> I reply to my own message, providing more details, hoping that anyone
> here could give a hint or the solution.
> 
> During bootup on ip32, since 2.4.24-rc1, the system loop printing a
> message about unexpected interrupt #13. (see transcript below.)
> 
> I enabled more debug in the kernel, and studied the code. What I
> understood is that interrupt #13 from CRIME means that the system should
> check on MACEISA for the real interrupt.
> 
> The interrupt start appearing just after executing the code
> psmouse_init() that enable ps2 drivers for keyboard and mouse. Keyboard
> interrupt #49 is enabled first and mouse interrupt #51 is enabled later.
> 
> When initialising the keyboard interrupt (it is a MACEISA interrupt),
> the interrupt start appearing, so I am pretty sure that interrupt #13 is
> related to the keyboard interrupt.
> 
> When the system receive interrupt #13, it correctly detect it is a
> MACEISA interrupt, and check for mace->perif.ctrl.istat value. The
> problem seems to be that this value is zero instead of having bit #9 on
> (that would mean, interrupt #49, keyboard).
> 
> So, either the interrupt #49 is not correctly enabled, or maceisa
> interrupt aren't correctly checked.
> 
> Does this description ring a bell to anyone?
> 
> Bye,
> Giuseppe
> 
> Calling initcall 0xffffffff80496ca0: serport_init+0x0/0x48()
> initcall 0xffffffff80496ca0: serport_init+0x0/0x48() returned 0.
> initcall 0xffffffff80496ca0 ran for 0 msecs: serport_init+0x0/0x48()
> Calling initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0()
> initcall 0xffffffff80496ce8: maceps2_init+0x0/0xe0() returned 0.
> initcall 0xffffffff80496ce8 ran for 1 msecs: maceps2_init+0x0/0xe0()
> Calling initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18()
> initcall 0xffffffff80496dc8: serio_raw_init+0x0/0x18() returned 0.
> initcall 0xffffffff80496dc8 ran for 1 msecs: serio_raw_init+0x0/0x18()
> Calling initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0()
> mice: PS/2 mouse device common for all mice
> initcall 0xffffffff80496f40: mousedev_init+0x0/0xd0() returned 0.
> initcall 0xffffffff80496f40 ran for 16 msecs: mousedev_init+0x0/0xd0()
> Calling initcall 0xffffffff80497010: atkbd_init+0x0/0x18()
> initcall 0xffffffff80497010: atkbd_init+0x0/0x18() returned 0.
> initcall 0xffffffff80497010 ran for 0 msecs: atkbd_init+0x0/0x18()
> Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90()
> maceisa enable: 49
> crime_int 00000020 enabled
> *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
> irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
> ->handle_irq():  ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
> ->chip(): ffffffff8043e320, 0xffffffff8043e320
> ->action(): 0000000000000000
>   IRQ_DISABLED set

I recommend you pull latest git. Looks like some issue that Ralf and I
fixed a few weeks ago.


     Ricardo

Re: 2.6.24-rc1 does not boot on SGI

[Giuseppe Sacco]

Hi Ricardo,

Il giorno lun, 10/12/2007 alle 14.05 -0400, Ricardo Mendoza ha scritto:
[...]
> > maceisa enable: 49
> > crime_int 00000020 enabled
> > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
> > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
> > ->handle_irq():  ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
> > ->chip(): ffffffff8043e320, 0xffffffff8043e320
> > ->action(): 0000000000000000
> >   IRQ_DISABLED set
> 
> I recommend you pull latest git. Looks like some issue that Ralf and I
> fixed a few weeks ago.

I am using git (from linux-mips.org) of two or three days ago, but I
will try if anything is changed in the meantime.

Thanks,
Giuseppe

Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]

[Giuseppe Sacco]

Il giorno lun, 10/12/2007 alle 14.05 -0400, Ricardo Mendoza ha scritto:
[...]
> > Calling initcall 0xffffffff80497028: psmouse_init+0x0/0x90()
> > maceisa enable: 49
> > crime_int 00000020 enabled
> > *irq 13, crime_int=00002000, crime_mask=003003a0, mace_int=00000000*
> > irq 13, desc: ffffffff80448390, depth: 1, count: 0, unhandled: 0
> > ->handle_irq():  ffffffff80065eb0, handle_bad_irq+0x0/0x2c0
> > ->chip(): ffffffff8043e320, 0xffffffff8043e320
> > ->action(): 0000000000000000
> >   IRQ_DISABLED set
> 
> I recommend you pull latest git. Looks like some issue that Ralf and I
> fixed a few weeks ago.

I just checked that my repository is up to date, so my problem is still
there (thus I don't know if it is the same problem you fixed).

BTW, what was the problem you fixed? I would like to have a look to it,
to better understand what's going on there.

Thanks,
Giuseppe

Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]

[Ricardo Mendoza]

Giuseppe Sacco wrote:

> I just checked that my repository is up to date, so my problem is still
> there (thus I don't know if it is the same problem you fixed).
> 
> BTW, what was the problem you fixed? I would like to have a look to it,
> to better understand what's going on there.

Well I just updated to see if anything had broken in the past few days,
but I don't seem to be hitting that error of yours. Could you send your
config to see if I can reproduce it?


     Ricardo

Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]

[Giuseppe Sacco]

On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote:
> Giuseppe Sacco wrote:
> 
> > I just checked that my repository is up to date, so my problem is still
> > there (thus I don't know if it is the same problem you fixed).
> > 
> > BTW, what was the problem you fixed? I would like to have a look to it,
> > to better understand what's going on there.
> 
> Well I just updated to see if anything had broken in the past few days,
> but I don't seem to be hitting that error of yours. Could you send your
> config to see if I can reproduce it?

Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2
but please note that the problem is present in every kernel since 2.6.24-rc1

my boot stanza in arcboot is:

label=test
  image=/boot/vmlinux-2.6.24-rc4-gs1
  append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200"

bye,
Giuseppe

Re: Still no 2.6.24 on ip32 [was: Re: 2.6.24-rc1 does not boot on SGI]

[Ricardo Mendoza]

Giuseppe Sacco wrote:

> On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote:
>> Giuseppe Sacco wrote:
>>
>>> I just checked that my repository is up to date, so my problem is still
>>> there (thus I don't know if it is the same problem you fixed).
>>>
>>> BTW, what was the problem you fixed? I would like to have a look to it,
>>> to better understand what's going on there.
>> Well I just updated to see if anything had broken in the past few days,
>> but I don't seem to be hitting that error of yours. Could you send your
>> config to see if I can reproduce it?
> 
> Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2
> but please note that the problem is present in every kernel since 2.6.24-rc1
> 
> my boot stanza in arcboot is:
> 
> label=test
>   image=/boot/vmlinux-2.6.24-rc4-gs1
>   append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200"

Ran it without problems, can't get into much detail right now but I the
problem you are seeing is more than likely caused by your other patch to
serial_core.c.


     Ricardo

Re: Still no 2.6.24 on ip32

[Giuseppe Sacco]

Hi Ricardo,

On Tue, Dec 11, 2007 at 01:18:00PM -0400, Ricardo Mendoza wrote:
> Giuseppe Sacco wrote:
> > On Tue, Dec 11, 2007 at 09:26:42AM -0400, Ricardo Mendoza wrote:
> >> Giuseppe Sacco wrote:
> >>
> >>> I just checked that my repository is up to date, so my problem is still
> >>> there (thus I don't know if it is the same problem you fixed).
> >>>
> >>> BTW, what was the problem you fixed? I would like to have a look to it,
> >>> to better understand what's going on there.
> >> Well I just updated to see if anything had broken in the past few days,
> >> but I don't seem to be hitting that error of yours. Could you send your
> >> config to see if I can reproduce it?
> > 
> > Yes, sure: http://eppesuigoccas.homedns.org/~giuseppe/debian/config-2.6.24-rc4-ip32.bz2
> > but please note that the problem is present in every kernel since 2.6.24-rc1
> > 
> > my boot stanza in arcboot is:
> > 
> > label=test
> >   image=/boot/vmlinux-2.6.24-rc4-gs1
> >   append="root=/dev/sda1 ro video=gbefb:1024x768-16@60 debug initcall_debug console=tty0 console=ttyS1,115200"
> 
> Ran it without problems, can't get into much detail right now but I the
> problem you are seeing is more than likely caused by your other patch to
> serial_core.c.

I made a few run, recompiled everything from scratch, without my patch,
but I always had the system loop on IRQ #13 while booting.

Do you test on ip32? SGI O2 R5000@200? I would like to know any difference
between our test environments.

Thanks,
Gisueppe

Re: 2.4.24-rc1 does not boot on SGI

[Martin Michlmayr]

* Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-27 09:07]:
> The new kernel once again does not boot on SGI O2. What happens is that
> arcboot write its messages and nothing more is displayed on the screen.
> The last message is "Starting ELF64 kernel". The previous running kernel
> were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.

I can confirm that currnt git doesn't boot (no message on the serial
console at all).  However, I'm curious to know whether 2.6.23 is
working properly for you (and, if so, can you send me your .config).
For me, it stops after printing

Freeing unused kernel memory: 268k freed

but then I can still hear it doing something and after a minute or so
I see:

Adding 131064k swap on /dev/sda2.  Priority:-1 extents:1 across:131064k
EXT3 FS on sda1, internal journal

and later:

gbefb: wait for vpixen_off timed out

and then I gave up and went to bed. ;-)
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: 2.4.24-rc1 does not boot on SGI

[Giuseppe Sacco]

Il giorno mar, 30/10/2007 alle 09.31 +0100, Martin Michlmayr ha scritto:
> * Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-27 09:07]:
> > The new kernel once again does not boot on SGI O2. What happens is that
> > arcboot write its messages and nothing more is displayed on the screen.
> > The last message is "Starting ELF64 kernel". The previous running kernel
> > were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.
> 
> I can confirm that currnt git doesn't boot (no message on the serial
> console at all).  However, I'm curious to know whether 2.6.23 is
> working properly for you (and, if so, can you send me your .config).
[...]

my config file for 2.6.23.1 from kernel.org is
http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-mips-config-2.6.23.1-gs2.bz2

currently open points:

1. serial line does not work
2. cat /proc/self/cmdline ends in kernel oops
3. writing on USB block devices through a PCI-to-PCI does not work
4. XFS kernel module is missing 32bit ioctl and cannot talk with xfsdump
nor xfsrestore

I am currently investigating on 1. and 3.

Re: 2.4.24-rc1 does not boot on SGI

[Martin Michlmayr]

* Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-30 09:41]:
> 1. serial line does not work

What exactly is not working?  I see kernel messages but serial doesn't
work when I reach user land.  Do you see the same?
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: 2.4.24-rc1 does not boot on SGI

[Giuseppe Sacco]

Il giorno mar, 30/10/2007 alle 10.09 +0100, Martin Michlmayr ha scritto:
> * Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-30 09:41]:
> > 1. serial line does not work
> 
> What exactly is not working?  I see kernel messages but serial doesn't
> work when I reach user land.  Do you see the same?

Yes. I understood that the serial line is correctly setup at startup,
then when the serial8250 device is started, it scan all registered
drivers (including the "platform" one), it tries to assign the two uarts
registered from ip32-platform.c, but here it get lost because the first
line is correctly registered, but the second line overlap the first one.

What happens is that when registering the second uart, the serial device
look for an unused uart and it gets the one used by ttyS0. I think that
the device think the uart is free because our uarts are UPIO_MEM but
mapbase isn't used.

Beside this, there is an error in ip32-platform:uart8250_init() since
the two uart structures are initialised with the same
&mace->isa.serial1. (this has already been pointed out in a previous
message on this list.)

A solution would be to change the initialisation in
ip32-platform:uart8250_init() in order to use mapbase instead of
membase, but I don't know how to translate the two numbers to mapbase.
Infact, if you use mapbase, the serial device know how to translate it
to membase and will correctly find the uart as used.

Bye,
Giuseppe

Re: 2.4.24-rc1 does not boot on SGI

[J. Scott Kasten]

On Tue, 30 Oct 2007, Giuseppe Sacco wrote:

> my config file for 2.6.23.1 from kernel.org is
> http://eppesuigoccas.homedns.org/~giuseppe/debian/sgi-mips-config-2.6.23.1-gs2.bz2
>
> currently open points:
>
> 1. serial line does not work
>

You say the serial line does not work.  I'm running debian's 2.6.18 kernel 
on my daily use box.  I had an urgent need to communicate with a serial 
device and tried using my O2.  No dice.  I finally dug the laptop out of 
the closet and took care of it that way.  It sounds like the generic 
serial stuff was broken a ways back.

-S-

Re: 2.4.24-rc1 does not boot on SGI

[Giuseppe Sacco]

Il giorno mar, 30/10/2007 alle 07.20 -0400, J. Scott Kasten ha scritto:
[...]
> You say the serial line does not work.  I'm running debian's 2.6.18 kernel 
> on my daily use box.  I had an urgent need to communicate with a serial 
> device and tried using my O2.  No dice.  I finally dug the laptop out of 
> the closet and took care of it that way.  It sounds like the generic 
> serial stuff was broken a ways back.

Using 2.6.18 debian kernel I hadn't any problem: the machine used to be
a faxserver with hylafax (using a modem via the serial port).

What kind of problem do you had with 2.6.18?

Re: 2.4.24-rc1 does not boot on SGI

[J. Scott Kasten]

On Tue, 30 Oct 2007, Giuseppe Sacco wrote:

>> the closet and took care of it that way.  It sounds like the generic
>> serial stuff was broken a ways back.
>
> Using 2.6.18 debian kernel I hadn't any problem: the machine used to be
> a faxserver with hylafax (using a modem via the serial port).
>
> What kind of problem do you had with 2.6.18?
>

Well, hmm... That's good to know you had it working.  I'll check into it 
again.  I hooked the serial device up, fired up minicom and couldn't get 
any characters comming back.  Verified the line settings and all too. 
Finally tried the laptop, using the same cable, and all was fine.

To be honest, it wasn't entirely debian's kernel.  It was their source 
package, but I rebuilt with USB support.  When I get a chance, I'll look 
at this again.

-S-

Re: 2.4.24-rc1 does not boot on SGI

[Martin Michlmayr]

* Martin Michlmayr <tbm@cyrius.com> [2007-10-30 09:31]:
> Adding 131064k swap on /dev/sda2.  Priority:-1 extents:1 across:131064k
> EXT3 FS on sda1, internal journal
> 
> and later:
> 
> gbefb: wait for vpixen_off timed out
> 
> and then I gave up and went to bed. ;-)

Okay, so I can login via SSH but there's still no "login" prompt on
the serial console.  echo foo > /dev/ttyS0 also doesn't work, but
printk()s are shown on the serial console (e.g. when I load a module).
Any ideas, Ralf?
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: 2.4.24-rc1 does not boot on SGI

[Ralf Baechle]

On Tue, Oct 30, 2007 at 09:31:07AM +0100, Martin Michlmayr wrote:

> * Giuseppe Sacco <giuseppe@eppesuigoccas.homedns.org> [2007-10-27 09:07]:
> > The new kernel once again does not boot on SGI O2. What happens is that
> > arcboot write its messages and nothing more is displayed on the screen.
> > The last message is "Starting ELF64 kernel". The previous running kernel
> > were 2.6.23 from linux-mips.org and 2.6.23.1 from kernel.org.
> 
> I can confirm that currnt git doesn't boot (no message on the serial
> console at all).  However, I'm curious to know whether 2.6.23 is
> working properly for you (and, if so, can you send me your .config).
> For me, it stops after printing
> 
> Freeing unused kernel memory: 268k freed
> 
> but then I can still hear it doing something and after a minute or so
> I see:
> 
> Adding 131064k swap on /dev/sda2.  Priority:-1 extents:1 across:131064k
> EXT3 FS on sda1, internal journal
> 
> and later:
> 
> gbefb: wait for vpixen_off timed out
> 
> and then I gave up and went to bed. ;-)

There was bug in the timer code resuling in a hang on master.  Commit
5a8e84c525ee1ad17e0ccfbc0a81c19b6773837c fixes this issue.

Irritatingly there was also a bug in Qemu which when running a Malta
kernel will cancel the affect of the first bug and result in a working
Malta kernel.  But only on Qemu, not on actual hardware.  Ths is working
on a fix for this one.

With the help of ricmm I found a few more issues in the IP32 interrupt
code.  I have a preliminary fix but it either isn't all it takes to fix
IP32 or it is still broken itself.

  Ralf