[parisc-linux] new gcc-default for hppa

[parisc-linux] new gcc-default for hppa

[jsoe0708]

Hi all,

I do notice that unstable debian for i386 switch (or will very soon) gcc-=
default
to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
kernel with this because of pb encounter with network connection)

Thanks in advance for advise,
    Joel
 

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> I do notice that unstable debian for i386 switch (or will very soon) gcc-default
> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
> kernel with this because of pb encounter with network connection)

yes:

tausq@auric:~$ madison gcc|grep unstable
       gcc |    2:3.1-1 |      unstable | hurd-i386
       gcc |  3:3.2.2-0 |      unstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc

randolph

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>> I do notice that unstable debian for i386 switch (or will very soon)
gcc-default
>> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling ne=
w
>> kernel with this because of pb encounter with network connection)
>
>yes:
>
>tausq@auric:~$ madison gcc|grep unstable
>       gcc |    2:3.1-1 |      unstable | hurd-i386
>       gcc |  3:3.2.2-0 |      unstable | alpha, arm, hppa, i386, ia64,
m68k,
>mips, mipsel, powerpc, s390, sparc
>
Thanks I will so wait before updating all my 2 test server (a b180 & a b2=
k)

Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>> I do notice that unstable debian for i386 switch (or will very soon)
gcc-default
>> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling ne=
w
>> kernel with this because of pb encounter with network connection)
>
>yes:
>
>tausq@auric:~$ madison gcc|grep unstable
>       gcc |    2:3.1-1 |      unstable | hurd-i386
>       gcc |  3:3.2.2-0 |      unstable | alpha, arm, hppa, i386, ia64,
m68k,
>mips, mipsel, powerpc, s390, sparc
>
Thanks I will so wait before updating all my 2 test server (a b180 & a b2=
k)

Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>> I do notice that unstable debian for i386 switch (or will very soon)
gcc-default
>> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling ne=
w
>> kernel with this because of pb encounter with network connection)
>
>yes:
>
>tausq@auric:~$ madison gcc|grep unstable
>       gcc |    2:3.1-1 |      unstable | hurd-i386
>       gcc |  3:3.2.2-0 |      unstable | alpha, arm, hppa, i386, ia64,
m68k,
>mips, mipsel, powerpc, s390, sparc
>

Well as mentionned in another mail, I just compile the 2.4.20-pa21 with
this new release and it always compile well, always boot well but also as=

soon as a network connection is tempted the system still crash.

And ? it just printout Stack Dump: (thousand time) but nothing more??
Do I do again something wrong?

never the less, Here I got the pim info:
PROCESSOR PIM INFORMATION

-----------------  Processor 0 HPMC Information ------------------

Timestamp =3D 
  Mon Jan  13 17:32:31 GMT 2003    (20:03:01:13:17:32:31)

HPMC Chassis Codes =3D 2cbf0  2500b  2cbfb  

General Registers 0 - 31
00-03   0000000000000000  0000000010340010  0000000010110850  00000000000=
000ff
04-07   0000000000000004  00000000000f4023  00000000103f7244  00000000103=
fa5c3
08-11   0000000000000060  0000000000000010  000000000000000e  00000000000=
00001
12-15   0000000010408010  000000000000000c  0000000000000005  00000000000=
69e0c
16-19   000000001ffb5cc0  0000000000069e0c  0000000000000004  fffffffffee=
00000
20-23   000000000000000e  00000000000003fd  0000000010111b84  00000000103=
43810
24-27   00000000000003fd  fffffffffee003fd  00000000100ba160  00000000103=
30010
28-31   0000000000000000  000000000001338a  000000001ffb6440  00000000101=
10850

Control Registers 0 - 31
00-03   0000000000000000  0000000000000000  0000000000000000  00000000000=
00000
04-07   0000000000000000  0000000000000000  0000000000000000  00000000000=
00000
08-11   00000000000005be  0000000000000000  00000000000000c0  00000000000=
0001a
12-15   0000000000000000  0000000000000000  0000000000108000  00000000000=
00000
16-19   000000311b8e25f8  0000000000000000  0000000010111b94  000000000f2=
0001c
20-23   00000000a607fffb  c0000000802003fd  000000ff0004fe0c  00000000c20=
00000
24-27   000000000034c000  000000000dfbc000  0000000000044021  00000000f04=
12000
28-31   0000000055555555  0000000055555555  000000001f93c000  00000000103=
e8000
Space Registers 0 - 7

00-03   00000000          000002df          00000000          000002df
04-07   00000000          00000000          00000000          00000000

IIA Space                    =3D 0x0000000000000000
IIA Offset                   =3D 0x0000000010111b98
Check Type                   =3D 0x20000000
CPU State                    =3D 0x9e000004
Cache Check                  =3D 0x00000000
TLB Check                    =3D 0x00000000
Bus Check                    =3D 0x0030103b
Assists Check                =3D 0x00000000
Assist State                 =3D 0x00000000
Path Info                    =3D 0x00000000
System Responder Address     =3D 0x000000fffee003fd
System Requestor Address     =3D 0xfffffffffffa0000

Floating-Point Registers 0 - 31
00-03   0000001f00000000  0000000000000000  0000000000000000  00000000000=
00000
04-07   00000001103e2000  f00000001014ec28  1032100000000000  00000000000=
00000
08-11   1034b02000000002  0000000200000002  0000000010343810  103e3810103=
40810
12-15   103e40001fffb000  0000000200000002  00000000100b0000  1034b5c0103=
e1e5c
16-19   103438100000000b  103f6e4b10343b48  0000000f103f6810  f0000000000=
0000f
20-23   00000001103e1000  f00000001013e3e4  cccccccda3d70c6e  00000000ccc=
ccccd
24-27   000007b11ff580a0  000099990000000a  0000000000000004  10330010102=
f5d54
28-31   1fffb000102f5800  000080011013ff24  102f580000008001  1fffb005000=
00005


'9000/785 B,C,J Workstation Unarchitected (per-CPU)', rev 1, 140 bytes:

Check Summary                =3D 0xcb81041008000000
Available Memory             =3D 0x0000000010000000
CPU Diagnose Register 2      =3D 0x0301000000000004
CPU Status Register 0        =3D 0x2420c20000000000
CPU Status Register 1        =3D 0x8002000000000000
SADD LOG                     =3D 0x10d8bb0180311000
Read Short LOG               =3D 0xc18040fffee003fd
ERROR_STATUS                 =3D 0x0000000000100010
MEM_ADDR                     =3D 0x000001ff3fffffff
MEM_SYND                     =3D 0x0000000000000000
MEM_ADDR_CORR                =3D 0x000001ff3fffffff
MEM_SYND_CORR                =3D 0x0000000000000000
RUN_DATA_HIGH                =3D 0xc1bff0fffed08040
RUN_DATA_LOW                 =3D 0xc1bff0fffed08040
RUN_CTRL                     =3D 0x0000021c00001418
RUN_ADDR                     =3D 0xc1bff0fffed08040
System Responder Path        =3D 0x00ffff0a000e0101


HPMC PIM Analysis Information:

Timestamp =3D 
  Mon Jan  13 17:32:31 GMT 2003    (20:03:01:13:17:32:31)


'9000/785 B,C,J Workstation HPMC PIM Analysis (per-CPU)', rev 0, 1304 byt=
es:

A Data I/O Fetch Timeout occurred while CPU 0 was
requesting information from a device at the path 10/0/14/1/1 (built-in PC=
I
device).


Memory/IO Controller Error Analysis Information:

The Memory/IO Controller only observed the Broadcast Error.  It did not
log
any additional information about the HPMC.

<Press any key to continue (q to quit)> 

-----------------  Processor 0 LPMC Information ------------------

Check Type                   =3D 0x00000000
I/D Cache Parity Info        =3D 0x00000000
Cache Check                  =3D 0x00000000
TLB Check                    =3D 0x00000000
Bus Check                    =3D 0x00000000
Assists Check                =3D 0x00000000
Assist State                 =3D 0x00000000
Path Info                    =3D 0x00000000
System Responder Address     =3D 0x0000000000000000
System Requestor Address     =3D 0x0000000000000000


 Rope     Word1        Word2            Word3
------ ------------ ------------
   0    0x00000000   0x0e0cc2a9   0x00000000fed30048
   1    0x00000000   0x1e0cc009   0x00000000fed32048
   2    ----------   0x2e0cc009   ------------------
   3    ----------   0x3e0cc009   ------------------
   4    ----------   0x4e0cc009   ------------------
   5    ----------   0x5e0cc009   ------------------
   6    ----------   0x6e0cc009   ------------------
   7    ----------   0x7e0cc009   ------------------

And then dump_analyser.sh got me:

IAOQ =3D 

Func: , Off: fffdf5ee, Addr: 0x0
objdump: --start-address: bad number: 0x

GR0 =3D 0000000000000000
0000000000000000
00000000
0000001f00000000

GR1 =3D 0000000010340010
0000000000000000
000002df
0000000000000000
Func: processor_tbl, Off: c, Addr: 0x10340010

GR2 =3D 0000000010110850
0000000000000000
00000000
0000000000000000
Func: inb, Off: 7c, Addr: 0x10110850
101107f4:	87 20 20 b8 	cmpib,=3D 0,r25,10110858 <inb+0x84>
10110850:	c8 7c 9f a5 	movb,tr ret0,r3,10110828 <inb+0x54>
10110854:	08 03 02 5c 	copy r3,ret0
10110858:	e8 57 0f 45 	b,l 10100000 <_text>,rp
1011085c:	34 42 3f 91 	ldo -38(rp),rp

GR3 =3D 00000000000000ff
0000000000000000
000002df
0000000000000000

GR4 =3D 0000000000000004
0000000000000000
00000000
00000001103e2000

GR5 =3D 00000000000f4023
0000000000000000
00000000
f00000001014ec28

GR6 =3D 00000000103f7244
0000000000000000
00000000
1032100000000000
Func: log_buf, Off: 0, Addr: 0x103f7244

GR7 =3D 00000000103fa5c3
0000000000000000
00000000
0000000000000000
Func: log_buf, Off: 337f, Addr: 0x103fa5c3

GR8 =3D 0000000000000060
00000000000005be
1034b02000000002

GR9 =3D 0000000000000010
0000000000000000
0000000200000002

GR10 =3D 000000000000000e
00000000000000c0
0000000010343810

GR11 =3D 0000000000000001
000000000000001a
103e381010340810

GR12 =3D 0000000010408010
0000000000000000
103e40001fffb000
Func: IRQ_timeout, Off: 2f4, Addr: 0x10408010

GR13 =3D 000000000000000c
0000000000000000
0000000200000002

GR14 =3D 0000000000000005
0000000000108000
00000000100b0000

GR15 =3D 0000000000069e0c
0000000000000000
1034b5c0103e1e5c

GR16 =3D 000000001ffb5cc0
000000311b8e25f8
103438100000000b

GR17 =3D 0000000000069e0c
0000000000000000
103f6e4b10343b48

GR18 =3D 0000000000000004
0000000010111b94
0000000f103f6810

GR19 =3D fffffffffee00000
000000000f20001c
f00000000000000f

GR20 =3D 000000000000000e
00000000a607fffb
00000001103e1000

GR21 =3D 00000000000003fd
c0000000802003fd
f00000001013e3e4

GR22 =3D 0000000010111b84
000000ff0004fe0c
cccccccda3d70c6e
Func: lba_astro_in8, Off: 0, Addr: 0x10111b84
10111b80:	0e 80 12 90 	stw r0,8(sr0,r20)
10111b84 <lba_astro_in8>:
10111b84:	22 60 0f dd 	ldil -1200000,r19
10111b88:	d3 39 1b f0 	extrw,u r25,31,16,r25
10111b8c:	0a 79 0a 19 	add,l r25,r19,r25

GR23 =3D 0000000010343810
00000000c2000000
00000000cccccccd
Func: pidhash, Off: f60, Addr: 0x10343810

GR24 =3D 00000000000003fd
000000000034c000
000007b11ff580a0

GR25 =3D fffffffffee003fd
000000000dfbc000
000099990000000a

GR26 =3D 00000000100ba160
0000000000044021
0000000000000004

GR27 =3D 0000000010330010
00000000f0412000
10330010102f5d54
Func: $global$, Off: 0, Addr: 0x10330010

GR28 =3D 0000000000000000
0000000055555555
1fffb000102f5800

GR29 =3D 000000000001338a
0000000055555555
000080011013ff24

GR30 =3D 000000001ffb6440
000000001f93c000
102f580000008001

GR31 =3D 0000000010110850
00000000103e8000
1fffb00500000005
Func: inb, Off: 7c, Addr: 0x10110850
101107f4:	87 20 20 b8 	cmpib,=3D 0,r25,10110858 <inb+0x84>
10110850:	c8 7c 9f a5 	movb,tr ret0,r3,10110828 <inb+0x54>
10110854:	08 03 02 5c 	copy r3,ret0
10110858:	e8 57 0f 45 	b,l 10100000 <_text>,rp
1011085c:	34 42 3f 91 	ldo -38(rp),rp

Done.


I do not know if it is relevant but HTH (me no :( )

Joel

PS: Tommorrow I will try either snapshot or gcc-3.0?

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Mon, Jan 13, 2003 at 07:36:03PM +0100, jsoe0708@tiscali.be wrote:
> Well as mentionned in another mail, I just compile the 2.4.20-pa21 with
> this new release and it always compile well, always boot well but also as
> soon as a network connection is tempted the system still crash.
> 
> And ? it just printout Stack Dump: (thousand time) but nothing more??
> Do I do again something wrong?

probably not. the stack dump is something I sometimes comment out
since it interfers with the register dump (which is more interesting).


> never the less, Here I got the pim info:
> PROCESSOR PIM INFORMATION

> GR2 = 0000000010110850
> Func: inb, Off: 7c, Addr: 0x10110850

> I do not know if it is relevant but HTH (me no :( )

Knowing it's inb() helps a bit. But we really need to know
who called inb. Unless we get a nice stack unwind, we just
have to guess based on activity that caused the crash and
last dmesg output from the console.

Sounds like the networking card you are attempting to
use isn't enabled properly by the driver.
Can you remind me which type of machine this is running
on and which type of NIC you are using?

thanks,
grant

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>On Mon, Jan 13, 2003 at 07:36:03PM +0100, jsoe0708@tiscali.be wrote:
>> Well as mentionned in another mail, I just compile the 2.4.20-pa21 wit=
h
>> this new release and it always compile well, always boot well but also=

>as
>> soon as a network connection is tempted the system still crash.
>> 
>> And ? it just printout Stack Dump: (thousand time) but nothing more??
>> Do I do again something wrong?
>
>probably not. the stack dump is something I sometimes comment out
>since it interfers with the register dump (which is more interesting).
>
Allright...
>
>> never the less, Here I got the pim info:
>> PROCESSOR PIM INFORMATION
>
>> GR2 =3D 0000000010110850
>> Func: inb, Off: 7c, Addr: 0x10110850
>
>> I do not know if it is relevant but HTH (me no :( )
>
>Knowing it's inb() helps a bit. But we really need to know
>who called inb. Unless we get a nice stack unwind, we just
>have to guess based on activity that caused the crash and
>last dmesg output from the console.
>
>Sounds like the networking card you are attempting to
>use isn't enabled properly by the driver.
>Can you remind me which type of machine this is running
>on and which type of NIC you are using?
>
The system on which I test it is a b2k with
...
Searching for devices...
Found devices:
1. Astro BC Runway Port (12) at 0xfed00000 [10], versions 0x582, 0x0, 0xb=

2. Elroy PCI Bridge (13) at 0xfed30000 [10/0], versions 0x782, 0x0, 0xa
3. Elroy PCI Bridge (13) at 0xfed32000 [10/1], versions 0x782, 0x0, 0xa
4. Kazoo W+ (0) at 0xfffa0000 [32], versions 0x5d0, 0x0, 0x4
5. Memory (1) at 0xfed10200 [49], versions 0x9d, 0x0, 0x9
CPU(s): 1 x PA8600 (PCX-W+) at 400.000000 MHz
SBA found Astro 2.1 at 0xfed00000
lba version TR4.0 (0x5) found at 0xfed30000
WARNING: Ignoring enabled ELMMIO BASE 0xf8000000  SIZE 0xfc000000
PCI: Ignoring BAR0-3 of IDE controller 00:0e.0
lba version TR4.0 (0x5) found at 0xfed32000
WARNING: Ignoring enabled ELMMIO BASE 0xf8000000  SIZE 0xfc000000
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch enabled, polling @ 0xf0400804.
SuperIO: Found NS87560 Legacy I/O device at 00:0e.1 (IRQ 64) 
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
parport0: PC-style at 0x378, irq 101 [PCSPP(,...)]
Starting kswapd
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
STI GSC/PCI graphics driver version 0.9
STI PCI graphic ROM found at f4940000 (128 kB), fb at fb000000 (16 MB)
STI word mode ROM at f4940044, hpa at fb000000
STI id 35acda16-9a02587, conforms to spec rev. 8.0c
STI device: HPA4982A
stifb: Unsupported gfx card id 0x35acda16
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL=
_PCI
enabled
ttyS00 at port 0x03f8 (irq =3D 99) is a 16550A
ttyS01 at port 0x02f8 (irq =3D 100) is a 16550A
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize
loop: loaded (max 8 devices)
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ 66.
tulip1:  EEPROM default media type Autosense.
tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) bloc=
k.
tulip_mii_recover: 100 ms
tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ 130=
.
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=3D=
xx
....

No chance, as you can see, the two interfaces are of the same time.
(I also have a b180 but the buildin NIC is also "Digital DS21143 Tulip re=
v
65" :( )

Thanks to your attention,
        Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>On Mon, Jan 13, 2003 at 07:36:03PM +0100, jsoe0708@tiscali.be wrote:
>> Well as mentionned in another mail, I just compile the 2.4.20-pa21 wit=
h
>> this new release and it always compile well, always boot well but also=

>as
>> soon as a network connection is tempted the system still crash.
>> 
>> And ? it just printout Stack Dump: (thousand time) but nothing more??
>> Do I do again something wrong?
>
>probably not. the stack dump is something I sometimes comment out
>since it interfers with the register dump (which is more interesting).
>
Allright...
>
>> never the less, Here I got the pim info:
>> PROCESSOR PIM INFORMATION
>
>> GR2 =3D 0000000010110850
>> Func: inb, Off: 7c, Addr: 0x10110850
>
>> I do not know if it is relevant but HTH (me no :( )
>
>Knowing it's inb() helps a bit. But we really need to know
>who called inb. Unless we get a nice stack unwind, we just
>have to guess based on activity that caused the crash and
>last dmesg output from the console.
>
>Sounds like the networking card you are attempting to
>use isn't enabled properly by the driver.
>Can you remind me which type of machine this is running
>on and which type of NIC you are using?
>
The system on which I test it is a b2k with
...
Searching for devices...
Found devices:
1. Astro BC Runway Port (12) at 0xfed00000 [10], versions 0x582, 0x0, 0xb=

2. Elroy PCI Bridge (13) at 0xfed30000 [10/0], versions 0x782, 0x0, 0xa
3. Elroy PCI Bridge (13) at 0xfed32000 [10/1], versions 0x782, 0x0, 0xa
4. Kazoo W+ (0) at 0xfffa0000 [32], versions 0x5d0, 0x0, 0x4
5. Memory (1) at 0xfed10200 [49], versions 0x9d, 0x0, 0x9
CPU(s): 1 x PA8600 (PCX-W+) at 400.000000 MHz
SBA found Astro 2.1 at 0xfed00000
lba version TR4.0 (0x5) found at 0xfed30000
WARNING: Ignoring enabled ELMMIO BASE 0xf8000000  SIZE 0xfc000000
PCI: Ignoring BAR0-3 of IDE controller 00:0e.0
lba version TR4.0 (0x5) found at 0xfed32000
WARNING: Ignoring enabled ELMMIO BASE 0xf8000000  SIZE 0xfc000000
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Soft power switch enabled, polling @ 0xf0400804.
SuperIO: Found NS87560 Legacy I/O device at 00:0e.1 (IRQ 64) 
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
parport0: PC-style at 0x378, irq 101 [PCSPP(,...)]
Starting kswapd
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
STI GSC/PCI graphics driver version 0.9
STI PCI graphic ROM found at f4940000 (128 kB), fb at fb000000 (16 MB)
STI word mode ROM at f4940044, hpa at fb000000
STI id 35acda16-9a02587, conforms to spec rev. 8.0c
STI device: HPA4982A
stifb: Unsupported gfx card id 0x35acda16
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL=
_PCI
enabled
ttyS00 at port 0x03f8 (irq =3D 99) is a 16550A
ttyS01 at port 0x02f8 (irq =3D 100) is a 16550A
lp0: using parport0 (interrupt-driven).
Generic RTC Driver v1.02 05/27/1999 Sam Creasey (sammy@oh.verio.com)
RAMDISK driver initialized: 16 RAM disks of 6144K size 1024 blocksize
loop: loaded (max 8 devices)
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
tulip0: no phy info, aborting mtable build
tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ 66.
tulip1:  EEPROM default media type Autosense.
tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) bloc=
k.
tulip_mii_recover: 100 ms
tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ 130=
.
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=3D=
xx
....

No chance, as you can see, the two interfaces are of the same time.
(I also have a b180 but the buildin NIC is also "Digital DS21143 Tulip re=
v
65" :( )

Thanks to your attention,
        Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Tue, Jan 14, 2003 at 07:57:01AM +0100, jsoe0708@tiscali.be wrote:
> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
> tulip0: no phy info, aborting mtable build
> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
> eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ 66.
> tulip1:  EEPROM default media type Autosense.
> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
> tulip_mii_recover: 100 ms
> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
> tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
> eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ 130.
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ....
> 
> No chance, as you can see, the two interfaces are of the same time.

I'll assume you meant same "type". They only happen to be the same rev
of the same device - mounted on different boards and wired
up to the PHY differently. ie they excercise slighly different code
paths in the tulip media init code path. This sounds more like a
bug in tulip driver than a compiler bug.

I've not tried add-on tulip's in my c3k (only minor differences to b2k).
I believe (but am not 100% sure right now) that gcc-3.2 built kernels
worked on that box.  I am sure gcc-3.2 built 2.4 kernels worked on a500.

Also, can you compare your .config with the one in 2.4.20-pa14.tgz
(ftp.p-l.o/kernels/c3000) or a default .config if that's closer?

BTW, one can safely enable MMIO on the b2k and perhaps either
(a) avoid the crash or (b) get an accurate IP on where in the code
it's crashing. "inb" has too many levels of indirection to see
exactly where in tulip it's crashing.

> (I also have a b180 but the buildin NIC is also "Digital DS21143 Tulip rev
> 65" :( )

Interesting. My b180 has:
grundler@debian:~$ lspci
00:01.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 14)
00:01.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 14)
00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 01)
00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 04)
00:14.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 30)

For the record, 21143 is the eth0. I use the eepro100 card for
local private subnet.

hth,
grant

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Tue, Jan 14, 2003 at 07:57:01AM +0100, jsoe0708@tiscali.be wrote:
> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
> tulip0: no phy info, aborting mtable build
> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
> eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ 66.
> tulip1:  EEPROM default media type Autosense.
> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
> tulip_mii_recover: 100 ms
> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
> tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
> eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ 130.
> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
> ....
> 
> No chance, as you can see, the two interfaces are of the same time.

I'll assume you meant same "type". They only happen to be the same rev
of the same device - mounted on different boards and wired
up to the PHY differently. ie they excercise slighly different code
paths in the tulip media init code path. This sounds more like a
bug in tulip driver than a compiler bug.

I've not tried add-on tulip's in my c3k (only minor differences to b2k).
I believe (but am not 100% sure right now) that gcc-3.2 built kernels
worked on that box.  I am sure gcc-3.2 built 2.4 kernels worked on a500.

Also, can you compare your .config with the one in 2.4.20-pa14.tgz
(ftp.p-l.o/kernels/c3000) or a default .config if that's closer?

BTW, one can safely enable MMIO on the b2k and perhaps either
(a) avoid the crash or (b) get an accurate IP on where in the code
it's crashing. "inb" has too many levels of indirection to see
exactly where in tulip it's crashing.

> (I also have a b180 but the buildin NIC is also "Digital DS21143 Tulip rev
> 65" :( )

Interesting. My b180 has:
grundler@debian:~$ lspci
00:01.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 14)
00:01.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 14)
00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 01)
00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c875 (rev 04)
00:14.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 30)

For the record, 21143 is the eth0. I use the eepro100 card for
local private subnet.

hth,
grant

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>-- Original Message --
>Date: Tue, 14 Jan 2003 09:52:03 -0700
>To: jsoe0708@tiscali.be
>Cc: Randolph Chung <tausq@debian.org>,
>	parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Subject: Re: [parisc-linux] new gcc-default for hppa
>From: grundler@dsl2.external.hp.com (Grant Grundler)
>
>
>On Tue, Jan 14, 2003 at 07:57:01AM +0100, jsoe0708@tiscali.be wrote:
>> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
>> tulip0: no phy info, aborting mtable build
>> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
>> eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ 66=
.
>> tulip1:  EEPROM default media type Autosense.
>> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
block.
>> tulip_mii_recover: 100 ms
>> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
>> tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
>> eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ
130.
>> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>> ide: Assuming 33MHz system bus speed for PIO modes; override with ideb=
us=3Dxx
>> ....
>> 
>> No chance, as you can see, the two interfaces are of the same time.
>
>I'll assume you meant same "type".

Yes, Sorry:

b2000:/var/logs# lspci
00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/=
43
(rev 41)
00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip
00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 IDE=

(rev 03)
00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev
01)
00:0e.2 USB Controller: National Semiconductor Corporation USB Controller=

(rev 02)
00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a (rev
01)
01:00.0 3D controller: Hewlett-Packard Company Visualize FXe (rev 03)
01:02.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/=
43
(rev 41)
01:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26=
)
01:04.0 Network controller: Eicon Technology Corporation EiconCard P92


b180:/var/logs# lspci
00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR)=

53c875 (rev 04)
00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/=
43
(rev 41)

> They only happen to be the same rev
>of the same device - mounted on different boards and wired
>up to the PHY differently. ie they excercise slighly different code
>paths in the tulip media init code path. This sounds more like a
>bug in tulip driver than a compiler bug.
>
>I've not tried add-on tulip's in my c3k (only minor differences to b2k).=

>I believe (but am not 100% sure right now) that gcc-3.2 built kernels
>worked on that box.  I am sure gcc-3.2 built 2.4 kernels worked on a500.=

>
>Also, can you compare your .config with the one in 2.4.20-pa14.tgz
>(ftp.p-l.o/kernels/c3000)

There are a lot of differences (do you want it I do not think it will be
usefull)

> or a default .config if that's closer?

It will have to wait tommorrow (sorry)

>
>BTW, one can safely enable MMIO on the b2k and perhaps either

I assume you speek about:# CONFIG_TULIP_MMIO is not set (on my config?)

>(a) avoid the crash or (b) get an accurate IP on where in the code
>it's crashing. "inb" has too many levels of indirection to see
>exactly where in tulip it's crashing.
>
>> (I also have a b180 but the buildin NIC is also "Digital DS21143 Tulip=

>rev
>> 65" :( )
>
>Interesting. My b180 has:
>grundler@debian:~$ lspci
>00:01.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
>NCR) 53c875 (rev 14)
>00:01.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
>NCR) 53c875 (rev 14)
>00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
>(rev 01)
>00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
>NCR) 53c875 (rev 04)
>00:14.0 Ethernet controller: Digital Equipment Corporation DECchip
>21142/43 (rev 30)
>
>For the record, 21143 is the eth0. I use the eepro100 card for
>local private subnet.
>
Thanks for advises,
    Joel

PS: Sorry to be short but I have to leave, I inform you of progress

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>-- Original Message --
>Date: Tue, 14 Jan 2003 09:52:03 -0700
>To: jsoe0708@tiscali.be
>Cc: Randolph Chung <tausq@debian.org>,
>	parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Subject: Re: [parisc-linux] new gcc-default for hppa
>From: grundler@dsl2.external.hp.com (Grant Grundler)
>
>
>On Tue, Jan 14, 2003 at 07:57:01AM +0100, jsoe0708@tiscali.be wrote:
>> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
>> tulip0: no phy info, aborting mtable build
>> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.
>> eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ 66=
.
>> tulip1:  EEPROM default media type Autosense.
>> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
block.
>> tulip_mii_recover: 100 ms
>> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.
>> tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
>> eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ
130.
>> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>> ide: Assuming 33MHz system bus speed for PIO modes; override with ideb=
us=3Dxx
>> ....
>> 
>> No chance, as you can see, the two interfaces are of the same time.
>
>I'll assume you meant same "type".

Yes, Sorry:

b2000:/var/logs# lspci
00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/=
43
(rev 41)
00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip
00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 IDE=

(rev 03)
00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev
01)
00:0e.2 USB Controller: National Semiconductor Corporation USB Controller=

(rev 02)
00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a (rev
01)
01:00.0 3D controller: Hewlett-Packard Company Visualize FXe (rev 03)
01:02.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/=
43
(rev 41)
01:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 26=
)
01:04.0 Network controller: Eicon Technology Corporation EiconCard P92


b180:/var/logs# lspci
00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR)=

53c875 (rev 04)
00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/=
43
(rev 41)

> They only happen to be the same rev
>of the same device - mounted on different boards and wired
>up to the PHY differently. ie they excercise slighly different code
>paths in the tulip media init code path. This sounds more like a
>bug in tulip driver than a compiler bug.
>
>I've not tried add-on tulip's in my c3k (only minor differences to b2k).=

>I believe (but am not 100% sure right now) that gcc-3.2 built kernels
>worked on that box.  I am sure gcc-3.2 built 2.4 kernels worked on a500.=

>
>Also, can you compare your .config with the one in 2.4.20-pa14.tgz
>(ftp.p-l.o/kernels/c3000)

There are a lot of differences (do you want it I do not think it will be
usefull)

> or a default .config if that's closer?

It will have to wait tommorrow (sorry)

>
>BTW, one can safely enable MMIO on the b2k and perhaps either

I assume you speek about:# CONFIG_TULIP_MMIO is not set (on my config?)

>(a) avoid the crash or (b) get an accurate IP on where in the code
>it's crashing. "inb" has too many levels of indirection to see
>exactly where in tulip it's crashing.
>
>> (I also have a b180 but the buildin NIC is also "Digital DS21143 Tulip=

>rev
>> 65" :( )
>
>Interesting. My b180 has:
>grundler@debian:~$ lspci
>00:01.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
>NCR) 53c875 (rev 14)
>00:01.1 SCSI storage controller: LSI Logic / Symbios Logic (formerly
>NCR) 53c875 (rev 14)
>00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
>(rev 01)
>00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
>NCR) 53c875 (rev 04)
>00:14.0 Ethernet controller: Digital Equipment Corporation DECchip
>21142/43 (rev 30)
>
>For the record, 21143 is the eth0. I use the eepro100 card for
>local private subnet.
>
Thanks for advises,
    Joel

PS: Sorry to be short but I have to leave, I inform you of progress

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

Hi Grant and Randolph,

>-- Original Message --
>From: jsoe0708@tiscali.be
>Subject: Re: [parisc-linux] new gcc-default for hppa
>To: grundler@dsl2.external.hp.com
>Cc: "Randolph Chung" <tausq@debian.org>,
>	parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Date: Tue, 14 Jan 2003 18:49:46 +0100
>
>
>>-- Original Message --
>>Date: Tue, 14 Jan 2003 09:52:03 -0700
>>To: jsoe0708@tiscali.be
>>Cc: Randolph Chung <tausq@debian.org>,
>>	parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>>Subject: Re: [parisc-linux] new gcc-default for hppa
>>From: grundler@dsl2.external.hp.com (Grant Grundler)
>>
>>
>>On Tue, Jan 14, 2003 at 07:57:01AM +0100, jsoe0708@tiscali.be wrote:
>>> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
>>> tulip0: no phy info, aborting mtable build
>>> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.=

>>> eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ
66.
>>> tulip1:  EEPROM default media type Autosense.
>>> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
>block.
>>> tulip_mii_recover: 100 ms
>>> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.=

>>> tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
>>> eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ=

>130.
>>> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>>> ide: Assuming 33MHz system bus speed for PIO modes; override with ide=
bus=3Dxx
>>> ....
>>>
>>> No chance, as you can see, the two interfaces are of the same time.
>>
>>I'll assume you meant same "type".
>
>Yes, Sorry:
>
>b2000:/var/logs# lspci
>00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142=
/43
>(rev 41)
>00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip
>00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 ID=
E
>(rev 03)
>00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev=

>01)
>00:0e.2 USB Controller: National Semiconductor Corporation USB Controlle=
r
>(rev 02)
>00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a (rev
>01)
>01:00.0 3D controller: Hewlett-Packard Company Visualize FXe (rev 03)
>01:02.0 Ethernet controller: Digital Equipment Corporation DECchip 21142=
/43
>(rev 41)
>01:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev
26)
>01:04.0 Network controller: Eicon Technology Corporation EiconCard P92
>
>
>b180:/var/logs# lspci
>00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR=
)
>53c875 (rev 04)
>00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142=
/43
>(rev 41)
>
>> They only happen to be the same rev
>>of the same device - mounted on different boards and wired
>>up to the PHY differently. ie they excercise slighly different code
>>paths in the tulip media init code path. This sounds more like a
>>bug in tulip driver than a compiler bug.
>>
>>I've not tried add-on tulip's in my c3k (only minor differences to b2k)=
.
>>I believe (but am not 100% sure right now) that gcc-3.2 built kernels
>>worked on that box.  I am sure gcc-3.2 built 2.4 kernels worked on a500=
.
>>
>>Also, can you compare your .config with the one in 2.4.20-pa14.tgz
>>(ftp.p-l.o/kernels/c3000)
>
>There are a lot of differences (do you want it I do not think it will be=

>usefull)
>
>> or a default .config if that's closer?
>
>It will have to wait tommorrow (sorry)
>
>>
>>BTW, one can safely enable MMIO on the b2k and perhaps either
>
>I assume you speek about:# CONFIG_TULIP_MMIO is not set (on my config?)

I now add CONFIG_TULIP_MMIO=3Dyes

and I got this time actual stack dump:
 for buildin NIC:
Stack Dump:
 1ebd4780:  0004ff0f 54203230 38204345 35343a30 
 1ebd4770:  2031343a 101e0e7c 64204a61 31205765 
 1ebd4760:  2e0a2023 6d61696c 61766520 6f752068 
 1ebd4750:  75780a59 2f4c696e 20474e55 00075f10 
 1ebd4740:  0000001b 00069e0c 00069e0c 00000008 
 1ebd4730:  1ebd4588 101e27e4 1fe3ac80 00000000 

Kernel addresses on the stack:
 [<101e0e7c>]  [<101e27e4>]  [<101e25f8>]  [<101e0bec>] 
 [<1014b828>]  [<101de398>]  [<10104a6c>]  [<1013f4ac>] 
 [<10109f90>]  [<10109084>]  [<10109d4c>]  [<1013ff24>] 
 [<1013e3e4>]  [<1014ec28>]  [<101213f0>] 

Kernel Fault: Code=3D26 regs=3D1ebd4780 (Addr=3D00000082)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 1039d010 101e27e4 0000000a
r04-07  0000001b 0000000a 1ed034e0 00010004
r08-11  00000000 0000006e 00000000 00075ec0
r12-15  1ebea96c 00069e0c 00069e0c 00069e0c
r16-19  00000004 00069e0c 00000004 0000006e
r20-23  00000001 00000000 101e11c8 0000000a
r24-27  1ebd4748 0000000a 0000000a 10330010
r28-31  00000000 00000031 1ebd4780 101e1098
sr0-3   00000000 000002d8 00000000 000002d8
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101e0dcc 101e0dd0
 IIR: 4b3600f0    ISR: 00000000  IOR: 00000082
 CPU:        0   CR30: 1ebd4000 CR31: 103e8000
 ORIG_R28: 78110466

  AND FOR External Nic:


Stack Dump:
 1ec3e080:  0004ff0f 00000000 00000000 00000000 
 1ec3e070:  00000000 701e49c4 70707070 70707070 
 1ec3e060:  70707070 70707070 70707070 70707070 
 1ec3e050:  70707070 70707070 70707070 70707070 
 1ec3e040:  70707070 70707070 70707070 70707070 
 1ec3e030:  70707070 70707070 70707070 70707070 

Kernel addresses on the stack:
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>] 

Kernel Fault: Code=3D6 regs=3D1ec3e080 (Addr=3D701e49c4)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 1039d010 701e49c4 1ec60000
r04-07  1ec61000 00000001 1ec3dfc8 1ec60000
r08-11  00000001 00000000 00000000 00039750
r12-15  1ec6096c 00000000 0000b71b 00035054
r16-19  00029054 faf00208 000020a8 0000007f
r20-23  00000f92 00000001 00000000 00000001
r24-27  1fea9a60 00000000 1ec61000 10330010
r28-31  00001000 00000031 1ec3e080 101e07d8
sr0-3   00000000 000002c2 00000000 000002c2
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 701e49c4 701e49c8
 IIR: 43ffff80    ISR: 00000000  IOR: 00000000
 CPU:        0   CR30: 1ebf0000 CR31: 103e8000
 ORIG_R28: 00000000

Completly deferent as you predict.

(Randolph: Do you want I send you those new material: kernel, system.map,=

...?)

I also forget to recall: this only occurs for incoming ethernet trafic(ie=

ssh, telnet, ftp, coming from an external server). The outgoing traffic
works fine (I just do a telnet and a ftp from this server to an external
one without crash).

HTH,
    Joel



*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Wed, Jan 15, 2003 at 05:14:47PM +0100, jsoe0708@tiscali.be wrote:
> >There are a lot of differences (do you want it I do not think it will be
> >usefull)
> >
> >> or a default .config if that's closer?
> >
> >It will have to wait tommorrow (sorry)

np. I also want you to look at something that is known
to work before going too far.

> I now add CONFIG_TULIP_MMIO=yes

yes. that's what I meant.

> (Randolph: Do you want I send you those new material: kernel, system.map,
> ...?)

Or make them available via http or ftp.
Otherwise, posting what symbols the IAOQ/GR02 values point at
is even better.

> I also forget to recall: this only occurs for incoming ethernet trafic(ie
> ssh, telnet, ftp, coming from an external server). The outgoing traffic
> works fine (I just do a telnet and a ftp from this server to an external
> one without crash)

Interesting. "outgoing" has both inbound and outbound data.
That doesn't sound like a tulip driver bug though it's certainly
possible.

Have you tried sending UDP (not TCP) traffic?
(Not sure how to do that...suggestions?)

You have any iptables (firewall) filtering enabled?

Maybe an issue with opening a new connection in the interrupt context?
My weak understanding of the network stack is that a TCP packet comes
in with SYN (on the interrupt stack) and gets queued for the bottom
half. The bottom half is invoked with interrupts re-enabled but
on the kernel stack in the "interrupt context". Did I get that right?

hth,
grant

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Wed, Jan 15, 2003 at 05:14:47PM +0100, jsoe0708@tiscali.be wrote:
> >There are a lot of differences (do you want it I do not think it will be
> >usefull)
> >
> >> or a default .config if that's closer?
> >
> >It will have to wait tommorrow (sorry)

np. I also want you to look at something that is known
to work before going too far.

> I now add CONFIG_TULIP_MMIO=yes

yes. that's what I meant.

> (Randolph: Do you want I send you those new material: kernel, system.map,
> ...?)

Or make them available via http or ftp.
Otherwise, posting what symbols the IAOQ/GR02 values point at
is even better.

> I also forget to recall: this only occurs for incoming ethernet trafic(ie
> ssh, telnet, ftp, coming from an external server). The outgoing traffic
> works fine (I just do a telnet and a ftp from this server to an external
> one without crash)

Interesting. "outgoing" has both inbound and outbound data.
That doesn't sound like a tulip driver bug though it's certainly
possible.

Have you tried sending UDP (not TCP) traffic?
(Not sure how to do that...suggestions?)

You have any iptables (firewall) filtering enabled?

Maybe an issue with opening a new connection in the interrupt context?
My weak understanding of the network stack is that a TCP packet comes
in with SYN (on the interrupt stack) and gets queued for the bottom
half. The bottom half is invoked with interrupts re-enabled but
on the kernel stack in the "interrupt context". Did I get that right?

hth,
grant

Re: [parisc-linux] new gcc-default for hppa

[Jeremy Drake]

On Wed, 15 Jan 2003, Grant Grundler wrote:

> Have you tried sending UDP (not TCP) traffic?
> (Not sure how to do that...suggestions?)
> 
netcat: cat /something | nc -u host port

-- 
You were s'posed to laugh!

Re: [parisc-linux] new gcc-default for hppa

[Jeremy Drake]

On Wed, 15 Jan 2003, Grant Grundler wrote:

> Have you tried sending UDP (not TCP) traffic?
> (Not sure how to do that...suggestions?)
> 
netcat: cat /something | nc -u host port

-- 
You were s'posed to laugh!

Re: [parisc-linux] new gcc-default for hppa

[M. Grabert]

On Wed, 15 Jan 2003, Grant Grundler wrote:

> On Wed, Jan 15, 2003 at 05:14:47PM +0100, jsoe0708@tiscali.be wrote:
> > >There are a lot of differences (do you want it I do not think it will be
> > >usefull)
> > >
> > >> or a default .config if that's closer?
> > >
> > >It will have to wait tommorrow (sorry)
>
> np. I also want you to look at something that is known
> to work before going too far.
>
> > I now add CONFIG_TULIP_MMIO=yes
>
> yes. that's what I meant.
>
> > (Randolph: Do you want I send you those new material: kernel, system.map,
> > ...?)
>
> Or make them available via http or ftp.
> Otherwise, posting what symbols the IAOQ/GR02 values point at
> is even better.
>
> > I also forget to recall: this only occurs for incoming ethernet trafic(ie
> > ssh, telnet, ftp, coming from an external server). The outgoing traffic
> > works fine (I just do a telnet and a ftp from this server to an external
> > one without crash)
>
> Interesting. "outgoing" has both inbound and outbound data.
> That doesn't sound like a tulip driver bug though it's certainly
> possible.

This is EXACTLY what happened to me when I conpiled a kernel for my C240
(just using the built-in network card) with a (buggy) gcc-3.2. Incoming
network traffic will crash the system, outgoing will work.

gcc-3.2 obviously miscompiles parts of the network code of the kernel,
whereas gcc-3.0 (with the very same kernel, same config) produced a
working kernel. I can't remember exactly what kernel/config and compiler,
but I sent the details to the list some months ago (I cann look them up
if somebody is interested).

Perhaps this helps to narrow down which part (driver or networking code)
of the kernel is affected by the miscompilation.

Re: [parisc-linux] new gcc-default for hppa

[M. Grabert]

On Wed, 15 Jan 2003, Grant Grundler wrote:

> On Wed, Jan 15, 2003 at 05:14:47PM +0100, jsoe0708@tiscali.be wrote:
> > >There are a lot of differences (do you want it I do not think it will be
> > >usefull)
> > >
> > >> or a default .config if that's closer?
> > >
> > >It will have to wait tommorrow (sorry)
>
> np. I also want you to look at something that is known
> to work before going too far.
>
> > I now add CONFIG_TULIP_MMIO=yes
>
> yes. that's what I meant.
>
> > (Randolph: Do you want I send you those new material: kernel, system.map,
> > ...?)
>
> Or make them available via http or ftp.
> Otherwise, posting what symbols the IAOQ/GR02 values point at
> is even better.
>
> > I also forget to recall: this only occurs for incoming ethernet trafic(ie
> > ssh, telnet, ftp, coming from an external server). The outgoing traffic
> > works fine (I just do a telnet and a ftp from this server to an external
> > one without crash)
>
> Interesting. "outgoing" has both inbound and outbound data.
> That doesn't sound like a tulip driver bug though it's certainly
> possible.

This is EXACTLY what happened to me when I conpiled a kernel for my C240
(just using the built-in network card) with a (buggy) gcc-3.2. Incoming
network traffic will crash the system, outgoing will work.

gcc-3.2 obviously miscompiles parts of the network code of the kernel,
whereas gcc-3.0 (with the very same kernel, same config) produced a
working kernel. I can't remember exactly what kernel/config and compiler,
but I sent the details to the list some months ago (I cann look them up
if somebody is interested).

Perhaps this helps to narrow down which part (driver or networking code)
of the kernel is affected by the miscompilation.

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

Hi,
>
>This is EXACTLY what happened to me when I conpiled a kernel for my C240=

>(just using the built-in network card) with a (buggy) gcc-3.2. Incoming
>network traffic will crash the system, outgoing will work.
>
>gcc-3.2 obviously miscompiles parts of the network code of the kernel,
>whereas gcc-3.0 (with the very same kernel, same config) produced a
>working kernel. I can't remember exactly what kernel/config and compiler=
,
>but I sent the details to the list some months ago (I cann look them up
>if somebody is interested).
>
>Perhaps this helps to narrow down which part (driver or networking code)=

>of the kernel is affected by the miscompilation.
>
May be still have to do a test: recompile the kernel with config file men=
tioned
my Grant earlier (the 2.4.20-pa14 for c3k). Do not know if it can help us=

more? I will try and let inform.

Thanks,
    Joel

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

Hi,
>
>This is EXACTLY what happened to me when I conpiled a kernel for my C240=

>(just using the built-in network card) with a (buggy) gcc-3.2. Incoming
>network traffic will crash the system, outgoing will work.
>
>gcc-3.2 obviously miscompiles parts of the network code of the kernel,
>whereas gcc-3.0 (with the very same kernel, same config) produced a
>working kernel. I can't remember exactly what kernel/config and compiler=
,
>but I sent the details to the list some months ago (I cann look them up
>if somebody is interested).
>
>Perhaps this helps to narrow down which part (driver or networking code)=

>of the kernel is affected by the miscompilation.
>
May be still have to do a test: recompile the kernel with config file men=
tioned
my Grant earlier (the 2.4.20-pa14 for c3k). Do not know if it can help us=

more? I will try and let inform.

Thanks,
    Joel

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>May be still have to do a test: recompile the kernel with config file me=
ntioned
>my Grant earlier (the 2.4.20-pa14 for c3k). Do not know if it can help
us
>more? I will try and let inform.
>
:^(( Also crash.

(I do not have any other supported NIC to test more :( )

Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>May be still have to do a test: recompile the kernel with config file me=
ntioned
>my Grant earlier (the 2.4.20-pa14 for c3k). Do not know if it can help
us
>more? I will try and let inform.
>
:^(( Also crash.

(I do not have any other supported NIC to test more :( )

Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Wed, Jan 15, 2003 at 05:14:47PM +0100, jsoe0708@tiscali.be wrote:
> and I got this time actual stack dump:
>  for builtin NIC:
> Stack Dump:
>  1ebd4780:  0004ff0f 54203230 38204345 35343a30
>  1ebd4770:  2031343a 101e0e7c 64204a61 31205765
>  1ebd4760:  2e0a2023 6d61696c 61766520 6f752068
>  1ebd4750:  75780a59 2f4c696e 20474e55 00075f10
>  1ebd4740:  0000001b 00069e0c 00069e0c 00000008
>  1ebd4730:  1ebd4588 101e27e4 1fe3ac80 00000000
> 
> Kernel addresses on the stack:
>  [<101e0e7c>]  [<101e27e4>]  [<101e25f8>]  [<101e0bec>]
>  [<1014b828>]  [<101de398>]  [<10104a6c>]  [<1013f4ac>]
>  [<10109f90>]  [<10109084>]  [<10109d4c>]  [<1013ff24>]
>  [<1013e3e4>]  [<1014ec28>]  [<101213f0>]

Randolph made the matching config/System.map available to me.

> Kernel Fault: Code=26 regs=1ebd4780 (Addr=00000082)

data page fault. looks like a null ptr dereference.
Above Kernel addresses point to:
0x101e0e7c opost+c8
0x101e27e4 write_chan+1ec
0x101e25f8 write_chan+0
0x101e0bec do_tty_write+134
0x1014b828 path_walk+14
0x101de398 tty_write+30
0x10104a6c handle_interruption+150
0x1013f4ac sys_write+a4
0x10109f90 syscall_exit+0
0x10109084 intr_check_sig+0
0x10109d4c child_return+0
0x1013ff24 chrdev_open+64
0x1013e3e4 dentry_open+f4
0x1014ec28 locate_fd+70
0x101213f0 it_real_fn+0

Seems like a jumble of stack traces.
Start with IOAQ (0x101e0dcc opost+18) and GR02 (rp, 0x101e27e4
write_chan+1ec) and look at source code to see which
kernel stack addresses are valid.

In any case, doesn't look like a problem with tulip driver.
I'll let someone else keep poking at this.

>   AND FOR External Nic:

> Kernel Fault: Code=6 regs=1ec3e080 (Addr=701e49c4)

This is bad. The kernel branched off into the weeds
or something. Could be the same problem though.

grant

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Wed, Jan 15, 2003 at 05:14:47PM +0100, jsoe0708@tiscali.be wrote:
> and I got this time actual stack dump:
>  for builtin NIC:
> Stack Dump:
>  1ebd4780:  0004ff0f 54203230 38204345 35343a30
>  1ebd4770:  2031343a 101e0e7c 64204a61 31205765
>  1ebd4760:  2e0a2023 6d61696c 61766520 6f752068
>  1ebd4750:  75780a59 2f4c696e 20474e55 00075f10
>  1ebd4740:  0000001b 00069e0c 00069e0c 00000008
>  1ebd4730:  1ebd4588 101e27e4 1fe3ac80 00000000
> 
> Kernel addresses on the stack:
>  [<101e0e7c>]  [<101e27e4>]  [<101e25f8>]  [<101e0bec>]
>  [<1014b828>]  [<101de398>]  [<10104a6c>]  [<1013f4ac>]
>  [<10109f90>]  [<10109084>]  [<10109d4c>]  [<1013ff24>]
>  [<1013e3e4>]  [<1014ec28>]  [<101213f0>]

Randolph made the matching config/System.map available to me.

> Kernel Fault: Code=26 regs=1ebd4780 (Addr=00000082)

data page fault. looks like a null ptr dereference.
Above Kernel addresses point to:
0x101e0e7c opost+c8
0x101e27e4 write_chan+1ec
0x101e25f8 write_chan+0
0x101e0bec do_tty_write+134
0x1014b828 path_walk+14
0x101de398 tty_write+30
0x10104a6c handle_interruption+150
0x1013f4ac sys_write+a4
0x10109f90 syscall_exit+0
0x10109084 intr_check_sig+0
0x10109d4c child_return+0
0x1013ff24 chrdev_open+64
0x1013e3e4 dentry_open+f4
0x1014ec28 locate_fd+70
0x101213f0 it_real_fn+0

Seems like a jumble of stack traces.
Start with IOAQ (0x101e0dcc opost+18) and GR02 (rp, 0x101e27e4
write_chan+1ec) and look at source code to see which
kernel stack addresses are valid.

In any case, doesn't look like a problem with tulip driver.
I'll let someone else keep poking at this.

>   AND FOR External Nic:

> Kernel Fault: Code=6 regs=1ec3e080 (Addr=701e49c4)

This is bad. The kernel branched off into the weeds
or something. Could be the same problem though.

grant

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Wed, Jan 15, 2003 at 06:41:45PM -0700, Grant Grundler wrote:
> In any case, doesn't look like a problem with tulip driver.
> I'll let someone else keep poking at this.

I retried this again last night on the c3k.
But this time I used an eepro100 driver and cross-over cable.
Several interesting differences:
o HPMCs instead of panic
o attempting to ssh to the c3k as "root" results in "permission denied"
  and no HPMC or panic
o GR02/IOAQ points at pty data struct not getting setup correctly.
  (I've got some of the data written down at home, just not here)
o iptables based firewall running on tulip NIC was showing packets
  getting LOGd and DROPd. ie ethernet traffic was coming in on the NIC.

Given that pty code works for X11, something must not be getting
initialized correctly for tcp connections.  And since all of the
TCP code and mid-level pty mgt is arch independent, I'm starting
to believe this is a toolchain bug.

Stephan Eranian had a good idea - replace .o's in the gcc 3.2
built kernel tree with .o's built using gcc-3.0. Then maybe we
can narrow down where the issue is.

grant

Re: [parisc-linux] new gcc-default for hppa

[Joel Soete]

Hi Grant,
...
>  And since all of the
>TCP code and mid-level pty mgt is arch independent, I'm starting
>to believe this is a toolchain bug.
>
>Stephan Eranian had a good idea - replace .o's in the gcc 3.2
>built kernel tree with .o's built using gcc-3.0. Then maybe we
>can narrow down where the issue is.
>
Following this idea I do the following test:

on a b2k unstable debian install with toolchain pkg:

ii  gcc            3.2.2-0        The GNU C compiler.
ii  gcc-3.0        3.0.4-14       The GNU C compiler
ii  gcc-3.0-base   3.0.4-14       The GNU Compiler Collection (base package)
ii  gcc-3.2        3.2.2-0pre5    The GNU C compiler
ii  gcc-3.2-base   3.2.2-0pre5    The GNU Compiler Collection (base package)
ii  gcc-snapshot   20030118-1     A SNAPSHOT of the The GNU Compiler Collectio
ii  libc6          2.3.1-10       GNU C Library: Shared libraries and Timezone
ii  libc6-dev      2.3.1-10       GNU C Library: Development Libraries and
Hea
ii  binutils       2.13.90.0.16-1 The GNU assembler, linker and binary utiliti
ii  binutils-dev   2.13.90.0.16-1 The GNU binary utilities (BFD development
fi

I build first kernel-2.4.20-pa22 with default gcc (ie gcc-3.2); without surprise
it crashed on the first incomming ip connection.

I then 'make distclean', replaced gcc by gcc-3.0 into Makefile and rebuild
so the same sources with the same .config. The result is an operational kernel.

Trust me, in this test the only variable is gcc release. Does it help?

That said, always in the continuity of this idea, I also notice that ld is
used to build some kernel parts. Is it  possible (even manually just for
test) to use gcc in place of ld? (if yes, howto?)

hth,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Joel Soete]

Hi Grant,
...
>  And since all of the
>TCP code and mid-level pty mgt is arch independent, I'm starting
>to believe this is a toolchain bug.
>
>Stephan Eranian had a good idea - replace .o's in the gcc 3.2
>built kernel tree with .o's built using gcc-3.0. Then maybe we
>can narrow down where the issue is.
>
Following this idea I do the following test:

on a b2k unstable debian install with toolchain pkg:

ii  gcc            3.2.2-0        The GNU C compiler.
ii  gcc-3.0        3.0.4-14       The GNU C compiler
ii  gcc-3.0-base   3.0.4-14       The GNU Compiler Collection (base package)
ii  gcc-3.2        3.2.2-0pre5    The GNU C compiler
ii  gcc-3.2-base   3.2.2-0pre5    The GNU Compiler Collection (base package)
ii  gcc-snapshot   20030118-1     A SNAPSHOT of the The GNU Compiler Collectio
ii  libc6          2.3.1-10       GNU C Library: Shared libraries and Timezone
ii  libc6-dev      2.3.1-10       GNU C Library: Development Libraries and
Hea
ii  binutils       2.13.90.0.16-1 The GNU assembler, linker and binary utiliti
ii  binutils-dev   2.13.90.0.16-1 The GNU binary utilities (BFD development
fi

I build first kernel-2.4.20-pa22 with default gcc (ie gcc-3.2); without surprise
it crashed on the first incomming ip connection.

I then 'make distclean', replaced gcc by gcc-3.0 into Makefile and rebuild
so the same sources with the same .config. The result is an operational kernel.

Trust me, in this test the only variable is gcc release. Does it help?

That said, always in the continuity of this idea, I also notice that ld is
used to build some kernel parts. Is it  possible (even manually just for
test) to use gcc in place of ld? (if yes, howto?)

hth,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Fri, Jan 24, 2003 at 12:02:25PM +0100, Joel Soete wrote:
> Trust me, in this test the only variable is gcc release. Does it help?

not alot. We need to narrow down *what* is broken and then show that
to the compiler/toolchain experts. They need either a test case or
shown broken asm output.

> That said, always in the continuity of this idea, I also notice that ld is
> used to build some kernel parts. Is it  possible (even manually just for
> test) to use gcc in place of ld? (if yes, howto?)

hmm...offhand I don't know.

grant

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Fri, Jan 24, 2003 at 12:02:25PM +0100, Joel Soete wrote:
> Trust me, in this test the only variable is gcc release. Does it help?

not alot. We need to narrow down *what* is broken and then show that
to the compiler/toolchain experts. They need either a test case or
shown broken asm output.

> That said, always in the continuity of this idea, I also notice that ld is
> used to build some kernel parts. Is it  possible (even manually just for
> test) to use gcc in place of ld? (if yes, howto?)

hmm...offhand I don't know.

grant

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> That said, always in the continuity of this idea, I also notice that ld is
> used to build some kernel parts. Is it  possible (even manually just for
> test) to use gcc in place of ld? (if yes, howto?)

When linking, gcc is just a front end for ld.  You can see what happens
with "-v", "-Wl,-v", "-Wl,-debug", etc.  You can pass any option that
you want to ld using the gcc "-Wl" option.  Gcc doesn't doing any linking
itself.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[Joel Soete]

John David Anglin wrote:
>>That said, always in the continuity of this idea, I also notice that ld is
>>used to build some kernel parts. Is it  possible (even manually just for
>>test) to use gcc in place of ld? (if yes, howto?)
> 
> 
> When linking, gcc is just a front end for ld.  You can see what happens
> with "-v", "-Wl,-v", "-Wl,-debug", etc.  You can pass any option that
> you want to ld using the gcc "-Wl" option.  Gcc doesn't doing any linking
> itself.
> 

Ha Ok.

My confusion came from Helge Deller mail:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018970.html>

But he spook about g++ (which I presume is different of gcc)?

Thanks,
	Joel

Re: [parisc-linux] new gcc-default for hppa

[Joel Soete]

John David Anglin wrote:
>>That said, always in the continuity of this idea, I also notice that ld is
>>used to build some kernel parts. Is it  possible (even manually just for
>>test) to use gcc in place of ld? (if yes, howto?)
> 
> 
> When linking, gcc is just a front end for ld.  You can see what happens
> with "-v", "-Wl,-v", "-Wl,-debug", etc.  You can pass any option that
> you want to ld using the gcc "-Wl" option.  Gcc doesn't doing any linking
> itself.
> 

Ha Ok.

My confusion came from Helge Deller mail:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018970.html>

But he spook about g++ (which I presume is different of gcc)?

Thanks,
	Joel

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> My confusion came from Helge Deller mail:
> <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018970.html>
> 
> But he spook about g++ (which I presume is different of gcc)?

No, it also uses ld.  However, its defaults with respect to libgcc linking
and exception support differ (ie, it sets defaults suitable to C++).  You
can link C++ code using gcc if you provide the correct options.  The
libtool package now uses gcc for linking as its options are more standardized
than those for ld.  I should note that it isn't possible to link g++ and
some gcc code directly with ld unless the system doesn't require collect2.
Collect2 is used to determine and link in code needed for the running of
initializers and finalizers.  The gcc/g++ drivers run collect2, and it
runs ld.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> My confusion came from Helge Deller mail:
> <http://lists.parisc-linux.org/pipermail/parisc-linux/2003-January/018970.html>
> 
> But he spook about g++ (which I presume is different of gcc)?

No, it also uses ld.  However, its defaults with respect to libgcc linking
and exception support differ (ie, it sets defaults suitable to C++).  You
can link C++ code using gcc if you provide the correct options.  The
libtool package now uses gcc for linking as its options are more standardized
than those for ld.  I should note that it isn't possible to link g++ and
some gcc code directly with ld unless the system doesn't require collect2.
Collect2 is used to determine and link in code needed for the running of
initializers and finalizers.  The gcc/g++ drivers run collect2, and it
runs ld.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> That said, always in the continuity of this idea, I also notice that ld is
> used to build some kernel parts. Is it  possible (even manually just for
> test) to use gcc in place of ld? (if yes, howto?)

When linking, gcc is just a front end for ld.  You can see what happens
with "-v", "-Wl,-v", "-Wl,-debug", etc.  You can pass any option that
you want to ld using the gcc "-Wl" option.  Gcc doesn't doing any linking
itself.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Tue, Jan 21, 2003 at 04:57:16PM -0700, Grant Grundler wrote:
> Stephan Eranian had a good idea - replace .o's in the gcc 3.2
> built kernel tree with .o's built using gcc-3.0. Then maybe we
> can narrow down where the issue is.

this worked. replacing drivers/char/pty.o with one built using
gcc-3.0 resulted in a kernel that ssh logins wouldn't crash.

Any advice on comparing .o's? or rather compare .S files?

I can probably also narrow down the code path a bit more.
I'm suspecting the initialization before calling tty_register_driver().

thanks,
grant

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Tue, Jan 21, 2003 at 04:57:16PM -0700, Grant Grundler wrote:
> Stephan Eranian had a good idea - replace .o's in the gcc 3.2
> built kernel tree with .o's built using gcc-3.0. Then maybe we
> can narrow down where the issue is.

this worked. replacing drivers/char/pty.o with one built using
gcc-3.0 resulted in a kernel that ssh logins wouldn't crash.

Any advice on comparing .o's? or rather compare .S files?

I can probably also narrow down the code path a bit more.
I'm suspecting the initialization before calling tty_register_driver().

thanks,
grant

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> Any advice on comparing .o's? or rather compare .S files?

You could try using "objdump -d" on the .o's, then diff'ing.  However
the diff might be large.  Probably, comparing .S files would be
best.  Don't use "-g".  However, if you find a difference that looks
suspicious, "-g" will help you locate the source line.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> Any advice on comparing .o's? or rather compare .S files?

You could try using "objdump -d" on the .o's, then diff'ing.  However
the diff might be large.  Probably, comparing .S files would be
best.  Don't use "-g".  However, if you find a difference that looks
suspicious, "-g" will help you locate the source line.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> You could try using "objdump -d" on the .o's, then diff'ing.  However
> the diff might be large.  Probably, comparing .S files would be
> best.  Don't use "-g".  However, if you find a difference that looks
> suspicious, "-g" will help you locate the source line.

well.... Grant and I did some more debugging on this.... here's what
we've tried so far:

- pty.c compiled completely with 3.2.2 => crash
- pty.c compiled completely with 3.0.4 => ok
- all the functions except pty_init compiled with 3.2.2, and with
pty_init compiled with 3.0 => ok
- pty.c compiled with 3.2.2 with only one of -fno-schedule-insns
  or -fno-schedule-insns2 => crash
- pty.c compiled with 3.2.2 with both -fno-schedule-insns and
  -fno-schedule-insns2 => ok

For reference, this is the original compile line:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa-linux/3.2.2/include -DKBUILD_BASENAME=pty  -DEXPORT_SYMTAB -c pty.c

here are the corresponding assembly files:
without -fno-schedule-insns -fno-schedule-insns2
    http://www.parisc-linux.org/~tausq/pty.s-opt
with -fno-schedule-insns -fno-schedule-insns2
    http://www.parisc-linux.org/~tausq/pty.s-noopt
diff -ywb output
    http://www.parisc-linux.org/~tausq/pty.s.diff

still need to look at the asm output a bit more carefully....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> You could try using "objdump -d" on the .o's, then diff'ing.  However
> the diff might be large.  Probably, comparing .S files would be
> best.  Don't use "-g".  However, if you find a difference that looks
> suspicious, "-g" will help you locate the source line.

well.... Grant and I did some more debugging on this.... here's what
we've tried so far:

- pty.c compiled completely with 3.2.2 => crash
- pty.c compiled completely with 3.0.4 => ok
- all the functions except pty_init compiled with 3.2.2, and with
pty_init compiled with 3.0 => ok
- pty.c compiled with 3.2.2 with only one of -fno-schedule-insns
  or -fno-schedule-insns2 => crash
- pty.c compiled with 3.2.2 with both -fno-schedule-insns and
  -fno-schedule-insns2 => ok

For reference, this is the original compile line:
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections -march=2.0 -mschedule=8000   -nostdinc -I /usr/lib/gcc-lib/hppa-linux/3.2.2/include -DKBUILD_BASENAME=pty  -DEXPORT_SYMTAB -c pty.c

here are the corresponding assembly files:
without -fno-schedule-insns -fno-schedule-insns2
    http://www.parisc-linux.org/~tausq/pty.s-opt
with -fno-schedule-insns -fno-schedule-insns2
    http://www.parisc-linux.org/~tausq/pty.s-noopt
diff -ywb output
    http://www.parisc-linux.org/~tausq/pty.s.diff

still need to look at the asm output a bit more carefully....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> well.... Grant and I did some more debugging on this.... here's what
> we've tried so far:

ok, here's what's happening apparently.... (with many thanks to Grant 
for a sharp eye :)

The pty_init() function does a number of structure copies. e.g.

init_termios is a 36-byte structure.

	pty_driver.init_termios = tty_std_termios;
	pty_driver.init_termios.c_iflag = 0;
	pty_driver.init_termios.c_oflag = 0;
	pty_driver.init_termios.c_cflag = B38400 | CS8 | CREAD;
	pty_driver.init_termios.c_lflag = 0;

gcc translates this to something like this:
    /* %r4 is &pty_driver */
    ldo 28(%r4),%r23
    ldi 28,%r21
    ldw,ma 4(%r22),%r20
    ldw,ma 4(%r22),%r19
    stw,ma %r20,4(%r23)
    addib,>= -8,%r21,.-12
    stw,ma %r19,4(%r23)
    /* ... */
    stw %r0,28(%r4)
    stw %r0,32(%r4)
    stw %r10,36(%r4)
    stw %r0,40(%r4)

When optimizations are turned on, gcc reschedules some of those final 
stw insns above the structure copy loop. When the structure copy 
happens, the values get overwritten. ick.

this was kind of interesting to debug :) but i have no idea how to fix
it. Dave? :)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> well.... Grant and I did some more debugging on this.... here's what
> we've tried so far:

ok, here's what's happening apparently.... (with many thanks to Grant 
for a sharp eye :)

The pty_init() function does a number of structure copies. e.g.

init_termios is a 36-byte structure.

	pty_driver.init_termios = tty_std_termios;
	pty_driver.init_termios.c_iflag = 0;
	pty_driver.init_termios.c_oflag = 0;
	pty_driver.init_termios.c_cflag = B38400 | CS8 | CREAD;
	pty_driver.init_termios.c_lflag = 0;

gcc translates this to something like this:
    /* %r4 is &pty_driver */
    ldo 28(%r4),%r23
    ldi 28,%r21
    ldw,ma 4(%r22),%r20
    ldw,ma 4(%r22),%r19
    stw,ma %r20,4(%r23)
    addib,>= -8,%r21,.-12
    stw,ma %r19,4(%r23)
    /* ... */
    stw %r0,28(%r4)
    stw %r0,32(%r4)
    stw %r10,36(%r4)
    stw %r0,40(%r4)

When optimizations are turned on, gcc reschedules some of those final 
stw insns above the structure copy loop. When the structure copy 
happens, the values get overwritten. ick.

this was kind of interesting to debug :) but i have no idea how to fix
it. Dave? :)

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

In reference to a message from Randolph Chung, dated Jan 27:
> > well.... Grant and I did some more debugging on this.... here's what
> > we've tried so far:
> 
> ok, here's what's happening apparently.... (with many thanks to Grant 
> for a sharp eye :)

there's a temporary workaround in cvs now (2.4.20-pa23). For people
who have seen the crash with gcc-3.2, please give it a try and let us 
know how it goes.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

In reference to a message from Randolph Chung, dated Jan 27:
> > well.... Grant and I did some more debugging on this.... here's what
> > we've tried so far:
> 
> ok, here's what's happening apparently.... (with many thanks to Grant 
> for a sharp eye :)

there's a temporary workaround in cvs now (2.4.20-pa23). For people
who have seen the crash with gcc-3.2, please give it a try and let us 
know how it goes.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] new gcc-default for hppa

[Patrick Caulfield]

On Mon, Jan 27, 2003 at 11:46:07PM -0800, Randolph Chung wrote:
> In reference to a message from Randolph Chung, dated Jan 27:
> > > well.... Grant and I did some more debugging on this.... here's what
> > > we've tried so far:
> > 
> > ok, here's what's happening apparently.... (with many thanks to Grant 
> > for a sharp eye :)
> 
> there's a temporary workaround in cvs now (2.4.20-pa23). For people
> who have seen the crash with gcc-3.2, please give it a try and let us 
> know how it goes.

Works fine for me. 

Thanks VERY much :-)

-- 

patrick

Re: [parisc-linux] new gcc-default for hppa

[Joel Soete]

Hi all,

>
>On Mon, Jan 27, 2003 at 11:46:07PM -0800, Randolph Chung wrote:
>> In reference to a message from Randolph Chung, dated Jan 27:
>> > > well.... Grant and I did some more debugging on this.... here's what
>> > > we've tried so far:
>> > 
>> > ok, here's what's happening apparently.... (with many thanks to Grant
>
>> > for a sharp eye :)
>> 
>> there's a temporary workaround in cvs now (2.4.20-pa23). For people
>> who have seen the crash with gcc-3.2, please give it a try and let us

>> know how it goes.
>
>Works fine for me. 
>
>Thanks VERY much :-)
>
>-- 
>

Seems to works fine also on my b180.

Great,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Joel Soete]

Hi again,
>
>>
>>On Mon, Jan 27, 2003 at 11:46:07PM -0800, Randolph Chung wrote:
>>> In reference to a message from Randolph Chung, dated Jan 27:
>>> > > well.... Grant and I did some more debugging on this.... here's what
>>> > > we've tried so far:
>>> > 
>>> > ok, here's what's happening apparently.... (with many thanks to Grant
>>
>>> > for a sharp eye :)
>>> 
>>> there's a temporary workaround in cvs now (2.4.20-pa23). For people
>>> who have seen the crash with gcc-3.2, please give it a try and let us
>
>>> know how it goes.
>>
>>Works fine for me. 
>>
>>Thanks VERY much :-)
>>
>>-- 
>>
>
>Seems to works fine also on my b180.
>
Also works on the b2k and more test with ssh, telnet and ftp (do some small
transfer in both in-out).

Thanks again,
    Joel

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Michael Wood]

On Mon, Jan 27, 2003 at 11:46:07PM -0800, Randolph Chung wrote:
> In reference to a message from Randolph Chung, dated Jan 27:
> > > well.... Grant and I did some more debugging on this.... here's what
> > > we've tried so far:
> > 
> > ok, here's what's happening apparently.... (with many thanks to Grant 
> > for a sharp eye :)
> 
> there's a temporary workaround in cvs now (2.4.20-pa23). For people
> who have seen the crash with gcc-3.2, please give it a try and let us 
> know how it goes.
[snip]

Since you seem to have found the problem, this is probably not relevant,
but I found this on Kernel Traffic:

	Alan remarked, "2.5.x crashes erratically and randomly under
	high tty/pty load.  At the moment I'm assuming this is the tty
	code. That means we can't decide not to fix it since its already
	fatally broken." Close by, Linus Torvalds said he didn't think
	the TTY code was in such bad shape. He guessed there were just a
	few locking problems that had crept in, coupled with the
	preemption patches' tendency to expose existing locking bugs.

It sounds vaguely related, except maybe for the "high load" bit.

-- 
Michael Wood <mwood@its.uct.ac.za>

Re: [parisc-linux] new gcc-default for hppa

[Michael Wood]

On Mon, Jan 27, 2003 at 11:46:07PM -0800, Randolph Chung wrote:
> In reference to a message from Randolph Chung, dated Jan 27:
> > > well.... Grant and I did some more debugging on this.... here's what
> > > we've tried so far:
> > 
> > ok, here's what's happening apparently.... (with many thanks to Grant 
> > for a sharp eye :)
> 
> there's a temporary workaround in cvs now (2.4.20-pa23). For people
> who have seen the crash with gcc-3.2, please give it a try and let us 
> know how it goes.
[snip]

Since you seem to have found the problem, this is probably not relevant,
but I found this on Kernel Traffic:

	Alan remarked, "2.5.x crashes erratically and randomly under
	high tty/pty load.  At the moment I'm assuming this is the tty
	code. That means we can't decide not to fix it since its already
	fatally broken." Close by, Linus Torvalds said he didn't think
	the TTY code was in such bad shape. He guessed there were just a
	few locking problems that had crept in, coupled with the
	preemption patches' tendency to expose existing locking bugs.

It sounds vaguely related, except maybe for the "high load" bit.

-- 
Michael Wood <mwood@its.uct.ac.za>

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> Since you seem to have found the problem, this is probably not relevant,
> but I found this on Kernel Traffic:
> 
> 	Alan remarked, "2.5.x crashes erratically and randomly under
> 	high tty/pty load.  At the moment I'm assuming this is the tty
> 	code. That means we can't decide not to fix it since its already
> 	fatally broken." Close by, Linus Torvalds said he didn't think
> 	the TTY code was in such bad shape. He guessed there were just a
> 	few locking problems that had crept in, coupled with the
> 	preemption patches' tendency to expose existing locking bugs.
> 
> It sounds vaguely related, except maybe for the "high load" bit.

i think this is a completely different problem. the one Grant and I
found is very parisc and compiler specific.

randolph

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> Since you seem to have found the problem, this is probably not relevant,
> but I found this on Kernel Traffic:
> 
> 	Alan remarked, "2.5.x crashes erratically and randomly under
> 	high tty/pty load.  At the moment I'm assuming this is the tty
> 	code. That means we can't decide not to fix it since its already
> 	fatally broken." Close by, Linus Torvalds said he didn't think
> 	the TTY code was in such bad shape. He guessed there were just a
> 	few locking problems that had crept in, coupled with the
> 	preemption patches' tendency to expose existing locking bugs.
> 
> It sounds vaguely related, except maybe for the "high load" bit.

i think this is a completely different problem. the one Grant and I
found is very parisc and compiler specific.

randolph

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> gcc translates this to something like this:
>     /* %r4 is &pty_driver */
>     ldo 28(%r4),%r23
>     ldi 28,%r21
>     ldw,ma 4(%r22),%r20
>     ldw,ma 4(%r22),%r19
>     stw,ma %r20,4(%r23)
>     addib,>= -8,%r21,.-12
>     stw,ma %r19,4(%r23)
>     /* ... */
>     stw %r0,28(%r4)
>     stw %r0,32(%r4)
>     stw %r10,36(%r4)
>     stw %r0,40(%r4)
> 
> When optimizations are turned on, gcc reschedules some of those final 
> stw insns above the structure copy loop. When the structure copy 
> happens, the values get overwritten. ick.
> 
> this was kind of interesting to debug :) but i have no idea how to fix
> it. Dave? :)

I don't either at the moment.  It's memory aliasing problem.  It's
most likely not a problem in the backend.

Can you strip the above down to a simple testcase and file a GCC PR?
I will bump it to high-priority as it is a regression.

-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[John David Anglin]

> gcc translates this to something like this:
>     /* %r4 is &pty_driver */
>     ldo 28(%r4),%r23
>     ldi 28,%r21
>     ldw,ma 4(%r22),%r20
>     ldw,ma 4(%r22),%r19
>     stw,ma %r20,4(%r23)
>     addib,>= -8,%r21,.-12
>     stw,ma %r19,4(%r23)
>     /* ... */
>     stw %r0,28(%r4)
>     stw %r0,32(%r4)
>     stw %r10,36(%r4)
>     stw %r0,40(%r4)
> 
> When optimizations are turned on, gcc reschedules some of those final 
> stw insns above the structure copy loop. When the structure copy 
> happens, the values get overwritten. ick.
> 
> this was kind of interesting to debug :) but i have no idea how to fix
> it. Dave? :)

I don't either at the moment.  It's memory aliasing problem.  It's
most likely not a problem in the backend.

Can you strip the above down to a simple testcase and file a GCC PR?
I will bump it to high-priority as it is a regression.

-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Wed, Jan 15, 2003 at 06:41:45PM -0700, Grant Grundler wrote:
> In any case, doesn't look like a problem with tulip driver.
> I'll let someone else keep poking at this.

I retried this again last night on the c3k.
But this time I used an eepro100 driver and cross-over cable.
Several interesting differences:
o HPMCs instead of panic
o attempting to ssh to the c3k as "root" results in "permission denied"
  and no HPMC or panic
o GR02/IOAQ points at pty data struct not getting setup correctly.
  (I've got some of the data written down at home, just not here)
o iptables based firewall running on tulip NIC was showing packets
  getting LOGd and DROPd. ie ethernet traffic was coming in on the NIC.

Given that pty code works for X11, something must not be getting
initialized correctly for tcp connections.  And since all of the
TCP code and mid-level pty mgt is arch independent, I'm starting
to believe this is a toolchain bug.

Stephan Eranian had a good idea - replace .o's in the gcc 3.2
built kernel tree with .o's built using gcc-3.0. Then maybe we
can narrow down where the issue is.

grant

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

Hi Grant and Randolph,

>-- Original Message --
>From: jsoe0708@tiscali.be
>Subject: Re: [parisc-linux] new gcc-default for hppa
>To: grundler@dsl2.external.hp.com
>Cc: "Randolph Chung" <tausq@debian.org>,
>	parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>Date: Tue, 14 Jan 2003 18:49:46 +0100
>
>
>>-- Original Message --
>>Date: Tue, 14 Jan 2003 09:52:03 -0700
>>To: jsoe0708@tiscali.be
>>Cc: Randolph Chung <tausq@debian.org>,
>>	parisc-linux@lists.parisc-linux.org, debian-hppa@lists.debian.org
>>Subject: Re: [parisc-linux] new gcc-default for hppa
>>From: grundler@dsl2.external.hp.com (Grant Grundler)
>>
>>
>>On Tue, Jan 14, 2003 at 07:57:01AM +0100, jsoe0708@tiscali.be wrote:
>>> Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
>>> tulip0: no phy info, aborting mtable build
>>> tulip0:  MII transceiver #1 config 1000 status 782d advertising 01e1.=

>>> eth0: Digital DS21143 Tulip rev 65 at 0xf00, 00:30:D3:01:5A:3B, IRQ
66.
>>> tulip1:  EEPROM default media type Autosense.
>>> tulip1:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3)
>block.
>>> tulip_mii_recover: 100 ms
>>> tulip1:  MII transceiver #1 config 3100 status 7849 advertising 0101.=

>>> tulip1:  Advertising 01e1 on PHY 1, previously advertising 0101.
>>> eth1: Digital DS21143 Tulip rev 65 at 0x12100, 00:30:6E:06:23:D0, IRQ=

>130.
>>> Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
>>> ide: Assuming 33MHz system bus speed for PIO modes; override with ide=
bus=3Dxx
>>> ....
>>>
>>> No chance, as you can see, the two interfaces are of the same time.
>>
>>I'll assume you meant same "type".
>
>Yes, Sorry:
>
>b2000:/var/logs# lspci
>00:0c.0 Ethernet controller: Digital Equipment Corporation DECchip 21142=
/43
>(rev 41)
>00:0d.0 Multimedia audio controller: Analog Devices AD1889 sound chip
>00:0e.0 IDE interface: National Semiconductor Corporation 87415/87560 ID=
E
>(rev 03)
>00:0e.1 Bridge: National Semiconductor Corporation 87560 Legacy I/O (rev=

>01)
>00:0e.2 USB Controller: National Semiconductor Corporation USB Controlle=
r
>(rev 02)
>00:0f.0 SCSI storage controller: LSI Logic / Symbios Logic 53c895a (rev
>01)
>01:00.0 3D controller: Hewlett-Packard Company Visualize FXe (rev 03)
>01:02.0 Ethernet controller: Digital Equipment Corporation DECchip 21142=
/43
>(rev 41)
>01:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev
26)
>01:04.0 Network controller: Eicon Technology Corporation EiconCard P92
>
>
>b180:/var/logs# lspci
>00:13.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly NCR=
)
>53c875 (rev 04)
>00:14.0 Ethernet controller: Digital Equipment Corporation DECchip 21142=
/43
>(rev 41)
>
>> They only happen to be the same rev
>>of the same device - mounted on different boards and wired
>>up to the PHY differently. ie they excercise slighly different code
>>paths in the tulip media init code path. This sounds more like a
>>bug in tulip driver than a compiler bug.
>>
>>I've not tried add-on tulip's in my c3k (only minor differences to b2k)=
.
>>I believe (but am not 100% sure right now) that gcc-3.2 built kernels
>>worked on that box.  I am sure gcc-3.2 built 2.4 kernels worked on a500=
.
>>
>>Also, can you compare your .config with the one in 2.4.20-pa14.tgz
>>(ftp.p-l.o/kernels/c3000)
>
>There are a lot of differences (do you want it I do not think it will be=

>usefull)
>
>> or a default .config if that's closer?
>
>It will have to wait tommorrow (sorry)
>
>>
>>BTW, one can safely enable MMIO on the b2k and perhaps either
>
>I assume you speek about:# CONFIG_TULIP_MMIO is not set (on my config?)

I now add CONFIG_TULIP_MMIO=3Dyes

and I got this time actual stack dump:
 for buildin NIC:
Stack Dump:
 1ebd4780:  0004ff0f 54203230 38204345 35343a30 
 1ebd4770:  2031343a 101e0e7c 64204a61 31205765 
 1ebd4760:  2e0a2023 6d61696c 61766520 6f752068 
 1ebd4750:  75780a59 2f4c696e 20474e55 00075f10 
 1ebd4740:  0000001b 00069e0c 00069e0c 00000008 
 1ebd4730:  1ebd4588 101e27e4 1fe3ac80 00000000 

Kernel addresses on the stack:
 [<101e0e7c>]  [<101e27e4>]  [<101e25f8>]  [<101e0bec>] 
 [<1014b828>]  [<101de398>]  [<10104a6c>]  [<1013f4ac>] 
 [<10109f90>]  [<10109084>]  [<10109d4c>]  [<1013ff24>] 
 [<1013e3e4>]  [<1014ec28>]  [<101213f0>] 

Kernel Fault: Code=3D26 regs=3D1ebd4780 (Addr=3D00000082)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 1039d010 101e27e4 0000000a
r04-07  0000001b 0000000a 1ed034e0 00010004
r08-11  00000000 0000006e 00000000 00075ec0
r12-15  1ebea96c 00069e0c 00069e0c 00069e0c
r16-19  00000004 00069e0c 00000004 0000006e
r20-23  00000001 00000000 101e11c8 0000000a
r24-27  1ebd4748 0000000a 0000000a 10330010
r28-31  00000000 00000031 1ebd4780 101e1098
sr0-3   00000000 000002d8 00000000 000002d8
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 101e0dcc 101e0dd0
 IIR: 4b3600f0    ISR: 00000000  IOR: 00000082
 CPU:        0   CR30: 1ebd4000 CR31: 103e8000
 ORIG_R28: 78110466

  AND FOR External Nic:


Stack Dump:
 1ec3e080:  0004ff0f 00000000 00000000 00000000 
 1ec3e070:  00000000 701e49c4 70707070 70707070 
 1ec3e060:  70707070 70707070 70707070 70707070 
 1ec3e050:  70707070 70707070 70707070 70707070 
 1ec3e040:  70707070 70707070 70707070 70707070 
 1ec3e030:  70707070 70707070 70707070 70707070 

Kernel addresses on the stack:
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>]  [<101e49c4>]  [<101e07d8>]  [<101e0e7c>] 
 [<101e11c8>]  [<101e2b28>]  [<101e1710>]  [<101e49c4>] 
 [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]  [<101e2b28>] 
 [<101e1710>] 

Kernel Fault: Code=3D6 regs=3D1ec3e080 (Addr=3D701e49c4)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111 Not tainted
r00-03  00000000 1039d010 701e49c4 1ec60000
r04-07  1ec61000 00000001 1ec3dfc8 1ec60000
r08-11  00000001 00000000 00000000 00039750
r12-15  1ec6096c 00000000 0000b71b 00035054
r16-19  00029054 faf00208 000020a8 0000007f
r20-23  00000f92 00000001 00000000 00000001
r24-27  1fea9a60 00000000 1ec61000 10330010
r28-31  00001000 00000031 1ec3e080 101e07d8
sr0-3   00000000 000002c2 00000000 000002c2
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 701e49c4 701e49c8
 IIR: 43ffff80    ISR: 00000000  IOR: 00000000
 CPU:        0   CR30: 1ebf0000 CR31: 103e8000
 ORIG_R28: 00000000

Completly deferent as you predict.

(Randolph: Do you want I send you those new material: kernel, system.map,=

...?)

I also forget to recall: this only occurs for incoming ethernet trafic(ie=

ssh, telnet, ftp, coming from an external server). The outgoing traffic
works fine (I just do a telnet and a ftp from this server to an external
one without crash).

HTH,
    Joel



*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Patrick Caulfield]

On Mon, Jan 13, 2003 at 12:38:26PM -0700, Grant Grundler wrote:
> On Mon, Jan 13, 2003 at 07:36:03PM +0100, jsoe0708@tiscali.be wrote:
> > Well as mentionned in another mail, I just compile the 2.4.20-pa21 with
> > this new release and it always compile well, always boot well but also as
> > soon as a network connection is tempted the system still crash.
> > 
> > And ? it just printout Stack Dump: (thousand time) but nothing more??
> > Do I do again something wrong?
> 
> probably not. the stack dump is something I sometimes comment out
> since it interfers with the register dump (which is more interesting).
> 
> 
> > never the less, Here I got the pim info:
> > PROCESSOR PIM INFORMATION
> 
> > GR2 = 0000000010110850
> > Func: inb, Off: 7c, Addr: 0x10110850
> 
> > I do not know if it is relevant but HTH (me no :( )
> 
> Knowing it's inb() helps a bit. But we really need to know
> who called inb. Unless we get a nice stack unwind, we just
> have to guess based on activity that caused the crash and
> last dmesg output from the console.
> 
> Sounds like the networking card you are attempting to
> use isn't enabled properly by the driver.
> Can you remind me which type of machine this is running
> on and which type of NIC you are using?

I doubt this is exactly the case. I have the same problem with my C110 in that
connecting to the box over ssh will kill it (with a gcc 3.2 compiled kernel) but
DECnet works fine with that kernel.

Oddly, DECnet does /not/ work with a gcc 3.0.4 compiled kernel (it doesn't crash,
just produces bogus packets), though ssh does - as we know.

patrick

Re: [parisc-linux] new gcc-default for hppa

[Grant Grundler]

On Mon, Jan 13, 2003 at 07:36:03PM +0100, jsoe0708@tiscali.be wrote:
> Well as mentionned in another mail, I just compile the 2.4.20-pa21 with
> this new release and it always compile well, always boot well but also as
> soon as a network connection is tempted the system still crash.
> 
> And ? it just printout Stack Dump: (thousand time) but nothing more??
> Do I do again something wrong?

probably not. the stack dump is something I sometimes comment out
since it interfers with the register dump (which is more interesting).


> never the less, Here I got the pim info:
> PROCESSOR PIM INFORMATION

> GR2 = 0000000010110850
> Func: inb, Off: 7c, Addr: 0x10110850

> I do not know if it is relevant but HTH (me no :( )

Knowing it's inb() helps a bit. But we really need to know
who called inb. Unless we get a nice stack unwind, we just
have to guess based on activity that caused the crash and
last dmesg output from the console.

Sounds like the networking card you are attempting to
use isn't enabled properly by the driver.
Can you remind me which type of machine this is running
on and which type of NIC you are using?

thanks,
grant

[parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[jsoe0708]

>PS: Tommorrow I will try either snapshot or gcc-3.0?
>
I so try snapshot (named 20030105-1) and so set LD_LIBRARY_PATH and PATH
as documented but compiling the kernel 2.4.20 failled with:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-pa21/include -Wall -Wstrict-prot=
otypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-ca=
lls
-mdisable-fpregs -ffunction-sections -march=3D1.1 -mschedule=3D7100   -no=
stdinc
-I /usr/lib/gcc-snapshot/lib/gcc-lib/hppa-linux/3.3/include -DKBUILD_BASE=
NAME=3Dide_cd
 -c -o ide-cd.o ide-cd.c
In file included from /usr/src/linux-2.4.20-pa21/include/linux/ide.h:301,=

                 from ide-cd.c:309:
/usr/src/linux-2.4.20-pa21/include/asm/ide.h: In function `ide_fix_drivei=
d':
/usr/src/linux-2.4.20-pa21/include/asm/ide.h:150: warning: comparison bet=
ween
signed and unsigned
In file included from /usr/src/linux-2.4.20-pa21/include/linux/highmem.h:=
5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/pagemap.h:=
16,
                 from /usr/src/linux-2.4.20-pa21/include/linux/locks.h:8,=

                 from /usr/src/linux-2.4.20-pa21/include/linux/blk.h:5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/ide.h:771,=

                 from ide-cd.c:309:
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h: In function `flush_cach=
e_range':
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h:83: warning: comparison
between signed and unsigned
In file included from /usr/src/linux-2.4.20-pa21/include/linux/highmem.h:=
5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/pagemap.h:=
16,
                 from /usr/src/linux-2.4.20-pa21/include/linux/locks.h:8,=

                 from /usr/src/linux-2.4.20-pa21/include/linux/blk.h:5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/ide.h:771,=

                 from ide-cd.c:309:
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h: In function `flush_cach=
e_page':
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h:102: warning: comparison=

between signed and unsigned
In file included from ide-cd.c:318:
ide-cd.h: At top level:
ide-cd.h:440: error: long, short, signed or unsigned used invalidly for
`slot_tablelen'
ide-cd.c: In function `cdrom_analyze_sense_data':
ide-cd.c:468: warning: comparison between signed and unsigned
ide-cd.c: In function `cdrom_buffer_sectors':
ide-cd.c:816: warning: comparison between signed and unsigned
ide-cd.c:816: warning: signed and unsigned type in conditional expression=

ide-cd.c: In function `cdrom_read_intr':
ide-cd.c:994: warning: comparison between signed and unsigned
ide-cd.c:994: warning: signed and unsigned type in conditional expression=

ide-cd.c: In function `cdrom_read_from_buffer':
ide-cd.c:1061: warning: comparison between signed and unsigned
ide-cd.c: In function `cdrom_start_read_continuation':
ide-cd.c:1100: warning: comparison between signed and unsigned
ide-cd.c: In function `cdrom_write_intr':
ide-cd.c:1607: warning: comparison between signed and unsigned
ide-cd.c:1607: warning: signed and unsigned type in conditional expressio=
n
make[3]: *** [ide-cd.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.20-pa21/drivers/ide'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.20-pa21/drivers/ide'
make[1]: *** [_subdir_ide] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.20-pa21/drivers'
make: *** [_dir_drivers] Error 2

I have a look and in drivers/ide/ide-cd.h line 440 I found well:
    __u8 short slot_tabelen;

Any idea?

Thanks,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

[parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[jsoe0708]

>PS: Tommorrow I will try either snapshot or gcc-3.0?
>
I so try snapshot (named 20030105-1) and so set LD_LIBRARY_PATH and PATH
as documented but compiling the kernel 2.4.20 failled with:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-pa21/include -Wall -Wstrict-prot=
otypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-D__linux__ -pipe -fno-strength-reduce -mno-space-regs -mfast-indirect-ca=
lls
-mdisable-fpregs -ffunction-sections -march=3D1.1 -mschedule=3D7100   -no=
stdinc
-I /usr/lib/gcc-snapshot/lib/gcc-lib/hppa-linux/3.3/include -DKBUILD_BASE=
NAME=3Dide_cd
 -c -o ide-cd.o ide-cd.c
In file included from /usr/src/linux-2.4.20-pa21/include/linux/ide.h:301,=

                 from ide-cd.c:309:
/usr/src/linux-2.4.20-pa21/include/asm/ide.h: In function `ide_fix_drivei=
d':
/usr/src/linux-2.4.20-pa21/include/asm/ide.h:150: warning: comparison bet=
ween
signed and unsigned
In file included from /usr/src/linux-2.4.20-pa21/include/linux/highmem.h:=
5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/pagemap.h:=
16,
                 from /usr/src/linux-2.4.20-pa21/include/linux/locks.h:8,=

                 from /usr/src/linux-2.4.20-pa21/include/linux/blk.h:5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/ide.h:771,=

                 from ide-cd.c:309:
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h: In function `flush_cach=
e_range':
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h:83: warning: comparison
between signed and unsigned
In file included from /usr/src/linux-2.4.20-pa21/include/linux/highmem.h:=
5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/pagemap.h:=
16,
                 from /usr/src/linux-2.4.20-pa21/include/linux/locks.h:8,=

                 from /usr/src/linux-2.4.20-pa21/include/linux/blk.h:5,
                 from /usr/src/linux-2.4.20-pa21/include/linux/ide.h:771,=

                 from ide-cd.c:309:
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h: In function `flush_cach=
e_page':
/usr/src/linux-2.4.20-pa21/include/asm/pgalloc.h:102: warning: comparison=

between signed and unsigned
In file included from ide-cd.c:318:
ide-cd.h: At top level:
ide-cd.h:440: error: long, short, signed or unsigned used invalidly for
`slot_tablelen'
ide-cd.c: In function `cdrom_analyze_sense_data':
ide-cd.c:468: warning: comparison between signed and unsigned
ide-cd.c: In function `cdrom_buffer_sectors':
ide-cd.c:816: warning: comparison between signed and unsigned
ide-cd.c:816: warning: signed and unsigned type in conditional expression=

ide-cd.c: In function `cdrom_read_intr':
ide-cd.c:994: warning: comparison between signed and unsigned
ide-cd.c:994: warning: signed and unsigned type in conditional expression=

ide-cd.c: In function `cdrom_read_from_buffer':
ide-cd.c:1061: warning: comparison between signed and unsigned
ide-cd.c: In function `cdrom_start_read_continuation':
ide-cd.c:1100: warning: comparison between signed and unsigned
ide-cd.c: In function `cdrom_write_intr':
ide-cd.c:1607: warning: comparison between signed and unsigned
ide-cd.c:1607: warning: signed and unsigned type in conditional expressio=
n
make[3]: *** [ide-cd.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.20-pa21/drivers/ide'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.20-pa21/drivers/ide'
make[1]: *** [_subdir_ide] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.20-pa21/drivers'
make: *** [_dir_drivers] Error 2

I have a look and in drivers/ide/ide-cd.h line 440 I found well:
    __u8 short slot_tabelen;

Any idea?

Thanks,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[John David Anglin]

> I have a look and in drivers/ide/ide-cd.h line 440 I found well:
>     __u8 short slot_tabelen;
> 
> Any idea?

Look at the code after preprocessing with "-E" option.  This will
show you the actual code where the fault occurs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[Matthew Wilcox]

On Tue, Jan 14, 2003 at 08:54:22AM -0500, John David Anglin wrote:
> > I have a look and in drivers/ide/ide-cd.h line 440 I found well:
> >     __u8 short slot_tabelen;
> > 
> > Any idea?
> 
> Look at the code after preprocessing with "-E" option.  This will
> show you the actual code where the fault occurs.

well, yeah, but the actual error's pretty clear.  you can't specify
two types for the same variable (__u8 is typedeffed to unsigned char).
unfortunately, gcc used to not even warn about this ;-(

the question is, what size is really wanted here?  i dunno, ask the
maintainer of that file.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[Matthew Wilcox]

On Tue, Jan 14, 2003 at 08:54:22AM -0500, John David Anglin wrote:
> > I have a look and in drivers/ide/ide-cd.h line 440 I found well:
> >     __u8 short slot_tabelen;
> > 
> > Any idea?
> 
> Look at the code after preprocessing with "-E" option.  This will
> show you the actual code where the fault occurs.

well, yeah, but the actual error's pretty clear.  you can't specify
two types for the same variable (__u8 is typedeffed to unsigned char).
unfortunately, gcc used to not even warn about this ;-(

the question is, what size is really wanted here?  i dunno, ask the
maintainer of that file.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[jsoe0708]

>
>> I have a look and in drivers/ide/ide-cd.h line 440 I found well:
>>     __u8 short slot_tabelen;
>> 
>> Any idea?
>
>Look at the code after preprocessing with "-E" option.  This will
>show you the actual code where the fault occurs.
>
Hi Dave,

Good idea and I do so for tree compiler still install:
gcc-3.0 -E

struct atapi_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
# 427 "ide-cd.h"
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 438 "ide-cd.h" 
        byte curlba[3];
        byte nslots;
        __u8 short slot_tablelen;
};

gcc-3.2 -E

struct atapi_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
# 427 "ide-cd.h"
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 438 "ide-cd.h"
        byte curlba[3];
        byte nslots;
        __u8 short slot_tablelen;
};

gcc-3.3 -E

struct atapi_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
# 427 "ide-cd.h"
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 438 "ide-cd.h"
        byte curlba[3];
        byte nslots;
        __u8 short slot_tablelen;
};

Do you notice any difference OTC above I encounter another use of slot_ta=
blelen
as:

struct cdrom_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 927 "/usr/src/linux-2.4.20-pa21/include/linux/cdrom.h"
        __u8 curlba[3];
        __u8 nslots;
        __u16 slot_tablelen;
};

hmm could this be a typo at one moment "unsigned short" would be changed
"__u8 short" ???

More over what could be the actual patch:
__u8 slot_tablelen;

or as in the 2d structure

__u16 slot_tablelen;

Cheers,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[jsoe0708]

>
>> I have a look and in drivers/ide/ide-cd.h line 440 I found well:
>>     __u8 short slot_tabelen;
>> 
>> Any idea?
>
>Look at the code after preprocessing with "-E" option.  This will
>show you the actual code where the fault occurs.
>
Hi Dave,

Good idea and I do so for tree compiler still install:
gcc-3.0 -E

struct atapi_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
# 427 "ide-cd.h"
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 438 "ide-cd.h" 
        byte curlba[3];
        byte nslots;
        __u8 short slot_tablelen;
};

gcc-3.2 -E

struct atapi_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
# 427 "ide-cd.h"
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 438 "ide-cd.h"
        byte curlba[3];
        byte nslots;
        __u8 short slot_tablelen;
};

gcc-3.3 -E

struct atapi_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
# 427 "ide-cd.h"
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 438 "ide-cd.h"
        byte curlba[3];
        byte nslots;
        __u8 short slot_tablelen;
};

Do you notice any difference OTC above I encounter another use of slot_ta=
blelen
as:

struct cdrom_mechstat_header {

        __u8 fault : 1;
        __u8 changer_state : 2;
        __u8 curslot : 5;
        __u8 mech_state : 3;
        __u8 door_open : 1;
        __u8 reserved1 : 4;
# 927 "/usr/src/linux-2.4.20-pa21/include/linux/cdrom.h"
        __u8 curlba[3];
        __u8 nslots;
        __u16 slot_tablelen;
};

hmm could this be a typo at one moment "unsigned short" would be changed
"__u8 short" ???

More over what could be the actual patch:
__u8 slot_tablelen;

or as in the 2d structure

__u16 slot_tablelen;

Cheers,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[John David Anglin]

>         byte nslots;
>         __u8 short slot_tablelen;
          ^^^^ ^^^^^

As Willi said, the error is above and you will have to figure out or
ask the maintainer what the intended type for slot_tablelen was in
this struct.  Look to see if there is a maximum size defined somewhere.

>         __u8 nslots;
>         __u16 slot_tablelen;
> };
> 
> hmm could this be a typo at one moment "unsigned short" would be changed
> "__u8 short" ???

Could be a typo.  However, this is a different struct from the one above,
so the types could be different to accomodate different table sizes.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[jsoe0708]

>-- Original Message --
>Subject: Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-defau=
lt
>for hppa]
>To: jsoe0708@tiscali.be
>From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>Cc: tausq@debian.org, parisc-linux@lists.parisc-linux.org,
>	debian-hppa@lists.debian.org
>Date: Tue, 14 Jan 2003 10:04:14 -0500 (EST)
>
>
>>         byte nslots;
>>         __u8 short slot_tablelen;
>          ^^^^ ^^^^^
>
>As Willi said, the error is above and you will have to figure out or
>ask the maintainer what the intended type for slot_tablelen was in
>this struct.  Look to see if there is a maximum size defined somewhere.
>
>>         __u8 nslots;
>>         __u16 slot_tablelen;
>> };
>> 
Ha the solution stand in 2.4.21: __u16

Thanks,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[jsoe0708]

>-- Original Message --
>Subject: Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-defau=
lt
>for hppa]
>To: jsoe0708@tiscali.be
>From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>Cc: tausq@debian.org, parisc-linux@lists.parisc-linux.org,
>	debian-hppa@lists.debian.org
>Date: Tue, 14 Jan 2003 10:04:14 -0500 (EST)
>
>
>>         byte nslots;
>>         __u8 short slot_tablelen;
>          ^^^^ ^^^^^
>
>As Willi said, the error is above and you will have to figure out or
>ask the maintainer what the intended type for slot_tablelen was in
>this struct.  Look to see if there is a maximum size defined somewhere.
>
>>         __u8 nslots;
>>         __u16 slot_tablelen;
>> };
>> 
Ha the solution stand in 2.4.21: __u16

Thanks,
    Joel


*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[John David Anglin]

>         byte nslots;
>         __u8 short slot_tablelen;
          ^^^^ ^^^^^

As Willi said, the error is above and you will have to figure out or
ask the maintainer what the intended type for slot_tablelen was in
this struct.  Look to see if there is a maximum size defined somewhere.

>         __u8 nslots;
>         __u16 slot_tablelen;
> };
> 
> hmm could this be a typo at one moment "unsigned short" would be changed
> "__u8 short" ???

Could be a typo.  However, this is a different struct from the one above,
so the types could be different to accomodate different table sizes.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-snapshot problem [was: new gcc-default for hppa]

[John David Anglin]

> I have a look and in drivers/ide/ide-cd.h line 440 I found well:
>     __u8 short slot_tabelen;
> 
> Any idea?

Look at the code after preprocessing with "-E" option.  This will
show you the actual code where the fault occurs.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

>> I do notice that unstable debian for i386 switch (or will very soon)
gcc-default
>> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling ne=
w
>> kernel with this because of pb encounter with network connection)
>
>yes:
>
>tausq@auric:~$ madison gcc|grep unstable
>       gcc |    2:3.1-1 |      unstable | hurd-i386
>       gcc |  3:3.2.2-0 |      unstable | alpha, arm, hppa, i386, ia64,
m68k,
>mips, mipsel, powerpc, s390, sparc
>

Well as mentionned in another mail, I just compile the 2.4.20-pa21 with
this new release and it always compile well, always boot well but also as=

soon as a network connection is tempted the system still crash.

And ? it just printout Stack Dump: (thousand time) but nothing more??
Do I do again something wrong?

never the less, Here I got the pim info:
PROCESSOR PIM INFORMATION

-----------------  Processor 0 HPMC Information ------------------

Timestamp =3D 
  Mon Jan  13 17:32:31 GMT 2003    (20:03:01:13:17:32:31)

HPMC Chassis Codes =3D 2cbf0  2500b  2cbfb  

General Registers 0 - 31
00-03   0000000000000000  0000000010340010  0000000010110850  00000000000=
000ff
04-07   0000000000000004  00000000000f4023  00000000103f7244  00000000103=
fa5c3
08-11   0000000000000060  0000000000000010  000000000000000e  00000000000=
00001
12-15   0000000010408010  000000000000000c  0000000000000005  00000000000=
69e0c
16-19   000000001ffb5cc0  0000000000069e0c  0000000000000004  fffffffffee=
00000
20-23   000000000000000e  00000000000003fd  0000000010111b84  00000000103=
43810
24-27   00000000000003fd  fffffffffee003fd  00000000100ba160  00000000103=
30010
28-31   0000000000000000  000000000001338a  000000001ffb6440  00000000101=
10850

Control Registers 0 - 31
00-03   0000000000000000  0000000000000000  0000000000000000  00000000000=
00000
04-07   0000000000000000  0000000000000000  0000000000000000  00000000000=
00000
08-11   00000000000005be  0000000000000000  00000000000000c0  00000000000=
0001a
12-15   0000000000000000  0000000000000000  0000000000108000  00000000000=
00000
16-19   000000311b8e25f8  0000000000000000  0000000010111b94  000000000f2=
0001c
20-23   00000000a607fffb  c0000000802003fd  000000ff0004fe0c  00000000c20=
00000
24-27   000000000034c000  000000000dfbc000  0000000000044021  00000000f04=
12000
28-31   0000000055555555  0000000055555555  000000001f93c000  00000000103=
e8000
Space Registers 0 - 7

00-03   00000000          000002df          00000000          000002df
04-07   00000000          00000000          00000000          00000000

IIA Space                    =3D 0x0000000000000000
IIA Offset                   =3D 0x0000000010111b98
Check Type                   =3D 0x20000000
CPU State                    =3D 0x9e000004
Cache Check                  =3D 0x00000000
TLB Check                    =3D 0x00000000
Bus Check                    =3D 0x0030103b
Assists Check                =3D 0x00000000
Assist State                 =3D 0x00000000
Path Info                    =3D 0x00000000
System Responder Address     =3D 0x000000fffee003fd
System Requestor Address     =3D 0xfffffffffffa0000

Floating-Point Registers 0 - 31
00-03   0000001f00000000  0000000000000000  0000000000000000  00000000000=
00000
04-07   00000001103e2000  f00000001014ec28  1032100000000000  00000000000=
00000
08-11   1034b02000000002  0000000200000002  0000000010343810  103e3810103=
40810
12-15   103e40001fffb000  0000000200000002  00000000100b0000  1034b5c0103=
e1e5c
16-19   103438100000000b  103f6e4b10343b48  0000000f103f6810  f0000000000=
0000f
20-23   00000001103e1000  f00000001013e3e4  cccccccda3d70c6e  00000000ccc=
ccccd
24-27   000007b11ff580a0  000099990000000a  0000000000000004  10330010102=
f5d54
28-31   1fffb000102f5800  000080011013ff24  102f580000008001  1fffb005000=
00005


'9000/785 B,C,J Workstation Unarchitected (per-CPU)', rev 1, 140 bytes:

Check Summary                =3D 0xcb81041008000000
Available Memory             =3D 0x0000000010000000
CPU Diagnose Register 2      =3D 0x0301000000000004
CPU Status Register 0        =3D 0x2420c20000000000
CPU Status Register 1        =3D 0x8002000000000000
SADD LOG                     =3D 0x10d8bb0180311000
Read Short LOG               =3D 0xc18040fffee003fd
ERROR_STATUS                 =3D 0x0000000000100010
MEM_ADDR                     =3D 0x000001ff3fffffff
MEM_SYND                     =3D 0x0000000000000000
MEM_ADDR_CORR                =3D 0x000001ff3fffffff
MEM_SYND_CORR                =3D 0x0000000000000000
RUN_DATA_HIGH                =3D 0xc1bff0fffed08040
RUN_DATA_LOW                 =3D 0xc1bff0fffed08040
RUN_CTRL                     =3D 0x0000021c00001418
RUN_ADDR                     =3D 0xc1bff0fffed08040
System Responder Path        =3D 0x00ffff0a000e0101


HPMC PIM Analysis Information:

Timestamp =3D 
  Mon Jan  13 17:32:31 GMT 2003    (20:03:01:13:17:32:31)


'9000/785 B,C,J Workstation HPMC PIM Analysis (per-CPU)', rev 0, 1304 byt=
es:

A Data I/O Fetch Timeout occurred while CPU 0 was
requesting information from a device at the path 10/0/14/1/1 (built-in PC=
I
device).


Memory/IO Controller Error Analysis Information:

The Memory/IO Controller only observed the Broadcast Error.  It did not
log
any additional information about the HPMC.

<Press any key to continue (q to quit)> 

-----------------  Processor 0 LPMC Information ------------------

Check Type                   =3D 0x00000000
I/D Cache Parity Info        =3D 0x00000000
Cache Check                  =3D 0x00000000
TLB Check                    =3D 0x00000000
Bus Check                    =3D 0x00000000
Assists Check                =3D 0x00000000
Assist State                 =3D 0x00000000
Path Info                    =3D 0x00000000
System Responder Address     =3D 0x0000000000000000
System Requestor Address     =3D 0x0000000000000000


 Rope     Word1        Word2            Word3
------ ------------ ------------
   0    0x00000000   0x0e0cc2a9   0x00000000fed30048
   1    0x00000000   0x1e0cc009   0x00000000fed32048
   2    ----------   0x2e0cc009   ------------------
   3    ----------   0x3e0cc009   ------------------
   4    ----------   0x4e0cc009   ------------------
   5    ----------   0x5e0cc009   ------------------
   6    ----------   0x6e0cc009   ------------------
   7    ----------   0x7e0cc009   ------------------

And then dump_analyser.sh got me:

IAOQ =3D 

Func: , Off: fffdf5ee, Addr: 0x0
objdump: --start-address: bad number: 0x

GR0 =3D 0000000000000000
0000000000000000
00000000
0000001f00000000

GR1 =3D 0000000010340010
0000000000000000
000002df
0000000000000000
Func: processor_tbl, Off: c, Addr: 0x10340010

GR2 =3D 0000000010110850
0000000000000000
00000000
0000000000000000
Func: inb, Off: 7c, Addr: 0x10110850
101107f4:	87 20 20 b8 	cmpib,=3D 0,r25,10110858 <inb+0x84>
10110850:	c8 7c 9f a5 	movb,tr ret0,r3,10110828 <inb+0x54>
10110854:	08 03 02 5c 	copy r3,ret0
10110858:	e8 57 0f 45 	b,l 10100000 <_text>,rp
1011085c:	34 42 3f 91 	ldo -38(rp),rp

GR3 =3D 00000000000000ff
0000000000000000
000002df
0000000000000000

GR4 =3D 0000000000000004
0000000000000000
00000000
00000001103e2000

GR5 =3D 00000000000f4023
0000000000000000
00000000
f00000001014ec28

GR6 =3D 00000000103f7244
0000000000000000
00000000
1032100000000000
Func: log_buf, Off: 0, Addr: 0x103f7244

GR7 =3D 00000000103fa5c3
0000000000000000
00000000
0000000000000000
Func: log_buf, Off: 337f, Addr: 0x103fa5c3

GR8 =3D 0000000000000060
00000000000005be
1034b02000000002

GR9 =3D 0000000000000010
0000000000000000
0000000200000002

GR10 =3D 000000000000000e
00000000000000c0
0000000010343810

GR11 =3D 0000000000000001
000000000000001a
103e381010340810

GR12 =3D 0000000010408010
0000000000000000
103e40001fffb000
Func: IRQ_timeout, Off: 2f4, Addr: 0x10408010

GR13 =3D 000000000000000c
0000000000000000
0000000200000002

GR14 =3D 0000000000000005
0000000000108000
00000000100b0000

GR15 =3D 0000000000069e0c
0000000000000000
1034b5c0103e1e5c

GR16 =3D 000000001ffb5cc0
000000311b8e25f8
103438100000000b

GR17 =3D 0000000000069e0c
0000000000000000
103f6e4b10343b48

GR18 =3D 0000000000000004
0000000010111b94
0000000f103f6810

GR19 =3D fffffffffee00000
000000000f20001c
f00000000000000f

GR20 =3D 000000000000000e
00000000a607fffb
00000001103e1000

GR21 =3D 00000000000003fd
c0000000802003fd
f00000001013e3e4

GR22 =3D 0000000010111b84
000000ff0004fe0c
cccccccda3d70c6e
Func: lba_astro_in8, Off: 0, Addr: 0x10111b84
10111b80:	0e 80 12 90 	stw r0,8(sr0,r20)
10111b84 <lba_astro_in8>:
10111b84:	22 60 0f dd 	ldil -1200000,r19
10111b88:	d3 39 1b f0 	extrw,u r25,31,16,r25
10111b8c:	0a 79 0a 19 	add,l r25,r19,r25

GR23 =3D 0000000010343810
00000000c2000000
00000000cccccccd
Func: pidhash, Off: f60, Addr: 0x10343810

GR24 =3D 00000000000003fd
000000000034c000
000007b11ff580a0

GR25 =3D fffffffffee003fd
000000000dfbc000
000099990000000a

GR26 =3D 00000000100ba160
0000000000044021
0000000000000004

GR27 =3D 0000000010330010
00000000f0412000
10330010102f5d54
Func: $global$, Off: 0, Addr: 0x10330010

GR28 =3D 0000000000000000
0000000055555555
1fffb000102f5800

GR29 =3D 000000000001338a
0000000055555555
000080011013ff24

GR30 =3D 000000001ffb6440
000000001f93c000
102f580000008001

GR31 =3D 0000000010110850
00000000103e8000
1fffb00500000005
Func: inb, Off: 7c, Addr: 0x10110850
101107f4:	87 20 20 b8 	cmpib,=3D 0,r25,10110858 <inb+0x84>
10110850:	c8 7c 9f a5 	movb,tr ret0,r3,10110828 <inb+0x54>
10110854:	08 03 02 5c 	copy r3,ret0
10110858:	e8 57 0f 45 	b,l 10100000 <_text>,rp
1011085c:	34 42 3f 91 	ldo -38(rp),rp

Done.


I do not know if it is relevant but HTH (me no :( )

Joel

PS: Tommorrow I will try either snapshot or gcc-3.0?

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[Randolph Chung]

> I do notice that unstable debian for i386 switch (or will very soon) gcc-default
> to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
> kernel with this because of pb encounter with network connection)

yes:

tausq@auric:~$ madison gcc|grep unstable
       gcc |    2:3.1-1 |      unstable | hurd-i386
       gcc |  3:3.2.2-0 |      unstable | alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc

randolph

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

...
>
>Or make them available via http or ftp.

The best idea I had, was to put those stuff on a testdrive server but Ran=
dolph
do not have access.

>Otherwise, posting what symbols the IAOQ/GR02 values point at
>is even better.
>
>> I also forget to recall: this only occurs for incoming ethernet trafic=
(ie
>> ssh, telnet, ftp, coming from an external server). The outgoing traffi=
c
>> works fine (I just do a telnet and a ftp from this server to an extern=
al
>> one without crash)
>
>Interesting. "outgoing" has both inbound and outbound data.
>That doesn't sound like a tulip driver bug though it's certainly
>possible.
>
>Have you tried sending UDP (not TCP) traffic?
>(Not sure how to do that...suggestions?)

Well as per Jeremy suggestion I do some following test and obtain strange=

results:

from the 'server' runing gcc32 kernel
cat /something | nc -u host 23
# no problem
cat /samething | nc host 23
# no problem
telnet host
...
# no problem

OTC from an external server to this gcc32 kernel server (which I call pal=
x)

cat /something | nc -u palx 23
# no problem

cat /samething | nc palx 23
# ??? no problem and that is strange because I well address the same 'tel=
net'
port

telnet palx

immediate crash?

so I try to strace telnetd and make it leasen on a port 6800
nohup /usr/sbin/in.telnetd -debug 6800 &

palx2000:~# strace -p  324
poll([{fd=3D3, events=3DPOLLIN, revents=3DPOLLIN}], 1, -1) =3D 1
accept(3, 0, NULL)                      =3D 4
dup2(4, 0)                              =3D 0
close(4)                                =3D 0
close(3)                                =3D 0
lock(0, {sa_family=3DAF_INET, sin_port=3Dhtons(1187), sin_addr=3Dinet_add=
r("172.16.248.169")},
[16]) =3D 0
setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, [1], 4) =3D 0
setsockopt(0, SOL_IP, IP_TOS, [16], 4)  =3D 0
open("/dev/ptmx", O_RDWR)               =3D 3
statfs("/dev/pts", {f_type=3D"DEVPTS_SUPER_MAGIC", f_bsize=3D1024, f_bloc=
ks=3D0,
f_bfree=3D0, f_files=3D0, f_ffree=3D0, f_namelen=3D255}) =3D 0
ioctl(3, 0x40245410, {B38400 opost isig icanon echo ...}) =3D 0
ioctl(3, 0x40045430, [0])               =3D 0
stat64("/dev/pts/0", {st_mode=3D0, st_size=3D5, ...}) =3D 0
statfs("/dev/pts/0", {f_type=3D"DEVPTS_SUPER_MAGIC", f_bsize=3D1024, f_bl=
ocks=3D0,
f_bfree=3D0, f_files=3D0, f_ffree=3D0, f_namelen=3D255}) =3D 0
ioctl(3, 0x80045431, [0])               =3D 0
ioctl(3, 0x40245410, {B38400 opost isig icanon echo ...}) =3D 0
ioctl(3, 0x40045430, [0])               =3D 0
stat64("/dev/pts/0", {st_mode=3D0, st_size=3D5, ...}) =3D 0
open("/dev/pts/0", O_RDWR|O_NOCTTY)     =3D 4
ioctl(4, 0x40245410, {B38400 opost isig icanon echo ...}) =3D 0
readlink("/proc/self/fd/4", "/dev/pts/0", 4095) =3D 10
socket(PF_UNIX, SOCK_STREAM, 0)         =3D 5
connect(5, {sa_family=3DAF_UNIX, path=3D"/var/run/.nscd_socket"}, 110) =3D=
 -1
ENOENT (No such file or directory)
close(5)                                =3D 0
open("/etc/nsswitch.conf", O_RDONLY)    =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) =3D 465
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/ld.so.cache", O_RDONLY)      =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 25974, PROT_READ, MAP_PRIVATE, 5, 0) =3D 0x40017000
close(5)                                =3D 0
open("/lib/libnss_files.so.2", O_RDONLY) =3D 5
read(5, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0(\234"...,
1024) =3D 1024
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 116188, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =3D 0x40196000=

mprotect(0x401a2000, 67036, PROT_NONE)  =3D 0
mmap(0x401b1000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FI=
XED,
5, 0xb000) =3D 0x401b1000
close(5)                                =3D 0
munmap(0x40017000, 25974)               =3D 0
gettimeofday({1042712090, 356267}, NULL) =3D 0
getpid()                                =3D 324
open("/etc/resolv.conf", O_RDONLY)      =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
newuname({sys=3D"Linux", node=3D"palx2000", ...}) =3D 0
open("/etc/host.conf", O_RDONLY)        =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "order hosts,bind\nmulti on\n", 4096) =3D 26
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
newuname({sys=3D"Linux", node=3D"palx2000", ...}) =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
socket(PF_UNIX, SOCK_STREAM, 0)         =3D 5
connect(5, {sa_family=3DAF_UNIX, path=3D"/var/run/.nscd_socket"}, 110) =3D=
 -1
ENOENT (No such file or directory)
close(5)                                =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
writev(0, [{"\377\375\30", 3}, {"\377\375 ", 3}, {"\377\375#", 3}, {"\377=
\375\'",
3}], 4) =3D 12
read(0, "#!/usr/bin/env ruby \n\nrequire \'g"..., 8192) =3D 4236
read(0, "", 8192)                       =3D 0
brk(0)                                  =3D 0x35000
brk(0x37000)                            =3D 0x37000
time([1042712118])                      =3D 1042712118
brk(0)                                  =3D 0x37000
brk(0x38000)                            =3D 0x38000
open("/etc/localtime", O_RDONLY)        =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40019000
read(5, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\n\0\0\0\n\0"..., 4096=
)
=3D 1067
close(5)                                =3D 0
munmap(0x40019000, 4096)                =3D 0
getpid()                                =3D 324
rt_sigaction(SIGPIPE, {0x4018fa3a, [], 0}, {SIG_DFL}, 8) =3D 0
socket(PF_UNIX, SOCK_DGRAM, 0)          =3D 5
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
connect(5, {sa_family=3DAF_UNIX, path=3D"/dev/log"}, 16) =3D 0
send(5, "<30>Jan 16 11:15:18 telnetd[324]"..., 57, 0) =3D 57
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) =3D 0
munmap(0x40017000, 8192)                =3D 0
exit(1)                                 =3D ?


palx2000:~# strace -p  324 palx2000:~# ps -ef | grep telnetdpalx2000:~#
lrt   nohup /usr/sbin/in.telnetd -debug 6800 &
[1] 332
palx2000:~# nohup: appending output to `nohup.out'
nohup /usr/sbin/in.telnetd -debug 6800 &palx2000:~# more nohup.out palx20=
00:~#
strace -p  324 palx2000:~# ps -ef | grep telnetd
root       332   285  0 11:15 ttyS0    00:00:00 /usr/sbin/in.telnetd -deb=
ug
6800
root       336   285  0 11:15 ttyS0    00:00:00 grep telnetd
palx2000:~# ps -ef | grep telnetdpalx2000:~# nohup /usr/sbin/in.telnetd
-debug 6800 &palx2000:~# more nohup.out palx2000:~# strace -p  324
       332 2>&1 | tee /var/logs/StraceTelnetdDebug.doc
poll([{fd=3D3, events=3DPOLLIN, revents=3DPOLLIN}], 1, -1) =3D 1
accept(3, 0, NULL)                      =3D 4
dup2(4, 0)                              =3D 0
close(4)                                =3D 0
close(3)                                =3D 0
lock(0, {sa_family=3DAF_INET, sin_port=3Dhtons(1188), sin_addr=3Dinet_add=
r("172.16.248.169")},
[16]) =3D 0
setsockopt(0, SOL_S
Stack Dump:
 1c6a1b80:  0004ff0e 00000000 00000000 00000000
 1c6a1b70:  00000000 00000000 00000000 00000000
 1c6a1b60:  00000000 00000000 00000000 00000001
 1c6a1b50:  143133fc 00000001 00000003 14313340
 1c6a1b40:  5455509e 00000000 00000000 00000000
 1c6a1b30:  00000000 102bc794 00000000 1811fb60

Kernel addresses on the stack:
 [<102bc794>]  [<10299a38>]  [<102bf3fc>]  [<102c6b90>]
 [<102c38dc>]  [<10126298>]  [<10125cf4>]  [<1012256c>]
 [<1012241c>]  [<10122154>]  [<10109078>]  [<101e2a10>]
 [<101e2a0c>]  [<1013ff24>]  [<1013e3e4>]  [<1014ec28>]
 [<101e49c4>]  [<101e1678>]  [<101e1710>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]

Kernel Fault: Code=3D26 regs=3D1c6a1b80 (Addr=3D00000001)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110 Not tainted
r00-03  00000000 10340810 10299a38 1c6a1b00
r04-07  19ba8810 103a58b4 1f37586c 00000001
r08-11  10340bc0 00000001 0000000f 10342810
r12-15  103fc010 00000000 0000b71b 00035054
r16-19  1c6a1600 faf00208 000020a8 19ba8810
r20-23  00000000 00000001 10299a08 00000005
r24-27  00000001 00000001 1f37586c 10330010
r28-31  00000000 00000000 1c6a1b80 102bf3fc
sr0-3   00000000 00000383 00000000 00000383
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 1011a73c 1011a740
 IIR: 0ea01093    ISR: 00000000  IOR: 00000001
 CPU:        0   CR30: 19a90000 CR31: 103e8000
 ORIG_R28: 00000000

For which crash dump_analyser.sh give me:
IAOQ =3D 1011a73c
Func: __wake_up, Off: 64, Addr: 0x1011a73c
1011a730:	34 28 07 60 	ldo 3b0(r1),r8
1011a734:	0c 99 10 95 	ldw -4(sr0,r4),r21
1011a738:	34 14 00 00 	ldi 0,r20
1011a73c:	0e a0 10 93 	ldw 0(sr0,r21),r19
1011a77c:	88 86 3f 6f 	cmpb,<>,n r6,r4,1011a738 <__wake_up+0x60>

GR0 =3D 00000000

GR1 =3D 10340810
Func: syscall_names, Off: 39c, Addr: 0x10340810

GR2 =3D 10299a38
Func: sock_def_readable, Off: 30, Addr: 0x10299a38
10299a14:	86 80 20 38 	cmpib,=3D 0,r20,10299a38 <sock_def_readable+0x30>
10299a28:	82 74 20 10 	cmpb,=3D r20,r19,10299a38 <sock_def_readable+0x30>=

10299a30:	e8 4f 04 e8 	b,l 102b7cac <tcp_recvmsg+0xa3c>,rp
10299a34:	08 00 02 40 	nop
10299a38:	48 73 05 a8 	ldw 2d4(r3),r19
10299a3c:	86 60 20 2a 	cmpib,=3D,n 0,r19,10299a58 <sock_def_readable+0x50=
>

GR3 =3D 1c6a1b00

GR4 =3D 19ba8810

GR5 =3D 103a58b4
Func: identify_ramdisk_image, Off: 78, Addr: 0x103a58b4
103a58b0:	08 04 02 58 	copy r4,r24
103a58b4:	0c 60 10 14 	ldb 0(sr0,r3),r20
103a58b8:	34 13 00 3e 	ldi 1f,r19
103a58bc:	82 93 22 58 	cmpb,=3D r19,r20,103a59f0 <identify_ramdisk_image+=
0x1b4>

GR6 =3D 1f37586c

GR7 =3D 00000001

GR8 =3D 10340bc0
Func: runqueue_head, Off: 0, Addr: 0x10340bc0

GR9 =3D 00000001

GR10 =3D 0000000f

GR11 =3D 10342810
Func: kstat, Off: 1bf8, Addr: 0x10342810

GR12 =3D 103fc010
Func: tv1, Off: 358, Addr: 0x103fc010

GR13 =3D 00000000

GR14 =3D 0000b71b

GR15 =3D 00035054

GR16 =3D 1c6a1600

GR17 =3D faf00208

GR18 =3D 000020a8

GR19 =3D 19ba8810

GR20 =3D 00000000

GR21 =3D 00000001

GR22 =3D 10299a08
Func: sock_def_readable, Off: 0, Addr: 0x10299a08
10299a00:	34 42 3f d9 	ldo -14(rp),rp
10299a04:	08 00 02 40 	nop
10299a08 <sock_def_readable>:
10299a08:	6b c2 3f d9 	stw rp,-14(sp)
10299a0c:	6f c3 00 80 	stw,ma r3,40(sp)

GR23 =3D 00000005

GR24 =3D 00000001

GR25 =3D 00000001

GR26 =3D 1f37586c

GR27 =3D 10330010
Func: $global$, Off: 0, Addr: 0x10330010

GR28 =3D 00000000

GR29 =3D 00000000

GR30 =3D 1c6a1b80

GR31 =3D 102bf3fc
Func: tcp_rcv_established, Off: 6bc, Addr: 0x102bf3fc
102bf3f0:	34 19 00 00 	ldi 0,r25
102bf3f4:	e6 c0 20 00 	be,l 0(sr4,r22),%sr0,%r31
102bf3f8:	08 1f 02 42 	copy r31,rp
102bf3fc:	e8 1f 15 55 	b,l 102beeac <tcp_rcv_established+0x16c>,r0

(nothing change for kernel)

That does not help me more but may be somebody else?



>
>You have any iptables (firewall) filtering enabled?
>

I check and there well iptables foreseen as module bu not loaded?

>Maybe an issue with opening a new connection in the interrupt context?
>My weak understanding of the network stack is that a TCP packet comes
>in with SYN (on the interrupt stack) and gets queued for the bottom
>half. The bottom half is invoked with interrupts re-enabled but
>on the kernel stack in the "interrupt context". Did I get that right?
>
IIRC Carlos suspect a tty problem?

hth,
Joel



*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

Re: [parisc-linux] new gcc-default for hppa

[jsoe0708]

...
>
>Or make them available via http or ftp.

The best idea I had, was to put those stuff on a testdrive server but Ran=
dolph
do not have access.

>Otherwise, posting what symbols the IAOQ/GR02 values point at
>is even better.
>
>> I also forget to recall: this only occurs for incoming ethernet trafic=
(ie
>> ssh, telnet, ftp, coming from an external server). The outgoing traffi=
c
>> works fine (I just do a telnet and a ftp from this server to an extern=
al
>> one without crash)
>
>Interesting. "outgoing" has both inbound and outbound data.
>That doesn't sound like a tulip driver bug though it's certainly
>possible.
>
>Have you tried sending UDP (not TCP) traffic?
>(Not sure how to do that...suggestions?)

Well as per Jeremy suggestion I do some following test and obtain strange=

results:

from the 'server' runing gcc32 kernel
cat /something | nc -u host 23
# no problem
cat /samething | nc host 23
# no problem
telnet host
...
# no problem

OTC from an external server to this gcc32 kernel server (which I call pal=
x)

cat /something | nc -u palx 23
# no problem

cat /samething | nc palx 23
# ??? no problem and that is strange because I well address the same 'tel=
net'
port

telnet palx

immediate crash?

so I try to strace telnetd and make it leasen on a port 6800
nohup /usr/sbin/in.telnetd -debug 6800 &

palx2000:~# strace -p  324
poll([{fd=3D3, events=3DPOLLIN, revents=3DPOLLIN}], 1, -1) =3D 1
accept(3, 0, NULL)                      =3D 4
dup2(4, 0)                              =3D 0
close(4)                                =3D 0
close(3)                                =3D 0
lock(0, {sa_family=3DAF_INET, sin_port=3Dhtons(1187), sin_addr=3Dinet_add=
r("172.16.248.169")},
[16]) =3D 0
setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, [1], 4) =3D 0
setsockopt(0, SOL_IP, IP_TOS, [16], 4)  =3D 0
open("/dev/ptmx", O_RDWR)               =3D 3
statfs("/dev/pts", {f_type=3D"DEVPTS_SUPER_MAGIC", f_bsize=3D1024, f_bloc=
ks=3D0,
f_bfree=3D0, f_files=3D0, f_ffree=3D0, f_namelen=3D255}) =3D 0
ioctl(3, 0x40245410, {B38400 opost isig icanon echo ...}) =3D 0
ioctl(3, 0x40045430, [0])               =3D 0
stat64("/dev/pts/0", {st_mode=3D0, st_size=3D5, ...}) =3D 0
statfs("/dev/pts/0", {f_type=3D"DEVPTS_SUPER_MAGIC", f_bsize=3D1024, f_bl=
ocks=3D0,
f_bfree=3D0, f_files=3D0, f_ffree=3D0, f_namelen=3D255}) =3D 0
ioctl(3, 0x80045431, [0])               =3D 0
ioctl(3, 0x40245410, {B38400 opost isig icanon echo ...}) =3D 0
ioctl(3, 0x40045430, [0])               =3D 0
stat64("/dev/pts/0", {st_mode=3D0, st_size=3D5, ...}) =3D 0
open("/dev/pts/0", O_RDWR|O_NOCTTY)     =3D 4
ioctl(4, 0x40245410, {B38400 opost isig icanon echo ...}) =3D 0
readlink("/proc/self/fd/4", "/dev/pts/0", 4095) =3D 10
socket(PF_UNIX, SOCK_STREAM, 0)         =3D 5
connect(5, {sa_family=3DAF_UNIX, path=3D"/var/run/.nscd_socket"}, 110) =3D=
 -1
ENOENT (No such file or directory)
close(5)                                =3D 0
open("/etc/nsswitch.conf", O_RDONLY)    =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "# /etc/nsswitch.conf\n#\n# Example"..., 4096) =3D 465
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/ld.so.cache", O_RDONLY)      =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 25974, PROT_READ, MAP_PRIVATE, 5, 0) =3D 0x40017000
close(5)                                =3D 0
open("/lib/libnss_files.so.2", O_RDONLY) =3D 5
read(5, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0(\234"...,
1024) =3D 1024
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 116188, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) =3D 0x40196000=

mprotect(0x401a2000, 67036, PROT_NONE)  =3D 0
mmap(0x401b1000, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FI=
XED,
5, 0xb000) =3D 0x401b1000
close(5)                                =3D 0
munmap(0x40017000, 25974)               =3D 0
gettimeofday({1042712090, 356267}, NULL) =3D 0
getpid()                                =3D 324
open("/etc/resolv.conf", O_RDONLY)      =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
newuname({sys=3D"Linux", node=3D"palx2000", ...}) =3D 0
open("/etc/host.conf", O_RDONLY)        =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "order hosts,bind\nmulti on\n", 4096) =3D 26
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
newuname({sys=3D"Linux", node=3D"palx2000", ...}) =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
read(5, "", 4096)                       =3D 0
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
socket(PF_UNIX, SOCK_STREAM, 0)         =3D 5
connect(5, {sa_family=3DAF_UNIX, path=3D"/var/run/.nscd_socket"}, 110) =3D=
 -1
ENOENT (No such file or directory)
close(5)                                =3D 0
open("/etc/hosts", O_RDONLY)            =3D 5
fcntl64(5, F_GETFD)                     =3D 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
read(5, "127.0.0.1\tlocalhost\n172.16.248.1"..., 4096) =3D 484
close(5)                                =3D 0
munmap(0x40017000, 4096)                =3D 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40017000
writev(0, [{"\377\375\30", 3}, {"\377\375 ", 3}, {"\377\375#", 3}, {"\377=
\375\'",
3}], 4) =3D 12
read(0, "#!/usr/bin/env ruby \n\nrequire \'g"..., 8192) =3D 4236
read(0, "", 8192)                       =3D 0
brk(0)                                  =3D 0x35000
brk(0x37000)                            =3D 0x37000
time([1042712118])                      =3D 1042712118
brk(0)                                  =3D 0x37000
brk(0x38000)                            =3D 0x38000
open("/etc/localtime", O_RDONLY)        =3D 5
fstat64(5, {st_mode=3D0, st_size=3D0, ...}) =3D 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
=3D 0x40019000
read(5, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\n\0\0\0\n\0"..., 4096=
)
=3D 1067
close(5)                                =3D 0
munmap(0x40019000, 4096)                =3D 0
getpid()                                =3D 324
rt_sigaction(SIGPIPE, {0x4018fa3a, [], 0}, {SIG_DFL}, 8) =3D 0
socket(PF_UNIX, SOCK_DGRAM, 0)          =3D 5
fcntl64(5, F_SETFD, FD_CLOEXEC)         =3D 0
connect(5, {sa_family=3DAF_UNIX, path=3D"/dev/log"}, 16) =3D 0
send(5, "<30>Jan 16 11:15:18 telnetd[324]"..., 57, 0) =3D 57
rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) =3D 0
munmap(0x40017000, 8192)                =3D 0
exit(1)                                 =3D ?


palx2000:~# strace -p  324 palx2000:~# ps -ef | grep telnetdpalx2000:~#
lrt   nohup /usr/sbin/in.telnetd -debug 6800 &
[1] 332
palx2000:~# nohup: appending output to `nohup.out'
nohup /usr/sbin/in.telnetd -debug 6800 &palx2000:~# more nohup.out palx20=
00:~#
strace -p  324 palx2000:~# ps -ef | grep telnetd
root       332   285  0 11:15 ttyS0    00:00:00 /usr/sbin/in.telnetd -deb=
ug
6800
root       336   285  0 11:15 ttyS0    00:00:00 grep telnetd
palx2000:~# ps -ef | grep telnetdpalx2000:~# nohup /usr/sbin/in.telnetd
-debug 6800 &palx2000:~# more nohup.out palx2000:~# strace -p  324
       332 2>&1 | tee /var/logs/StraceTelnetdDebug.doc
poll([{fd=3D3, events=3DPOLLIN, revents=3DPOLLIN}], 1, -1) =3D 1
accept(3, 0, NULL)                      =3D 4
dup2(4, 0)                              =3D 0
close(4)                                =3D 0
close(3)                                =3D 0
lock(0, {sa_family=3DAF_INET, sin_port=3Dhtons(1188), sin_addr=3Dinet_add=
r("172.16.248.169")},
[16]) =3D 0
setsockopt(0, SOL_S
Stack Dump:
 1c6a1b80:  0004ff0e 00000000 00000000 00000000
 1c6a1b70:  00000000 00000000 00000000 00000000
 1c6a1b60:  00000000 00000000 00000000 00000001
 1c6a1b50:  143133fc 00000001 00000003 14313340
 1c6a1b40:  5455509e 00000000 00000000 00000000
 1c6a1b30:  00000000 102bc794 00000000 1811fb60

Kernel addresses on the stack:
 [<102bc794>]  [<10299a38>]  [<102bf3fc>]  [<102c6b90>]
 [<102c38dc>]  [<10126298>]  [<10125cf4>]  [<1012256c>]
 [<1012241c>]  [<10122154>]  [<10109078>]  [<101e2a10>]
 [<101e2a0c>]  [<1013ff24>]  [<1013e3e4>]  [<1014ec28>]
 [<101e49c4>]  [<101e1678>]  [<101e1710>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]  [<101e11c8>]
 [<101e2b28>]  [<101e1710>]  [<101e49c4>]  [<101e07d8>]
 [<101e0e7c>]  [<101e11c8>]  [<101e2b28>]  [<101e1710>]
 [<101e49c4>]  [<101e07d8>]  [<101e0e7c>]

Kernel Fault: Code=3D26 regs=3D1c6a1b80 (Addr=3D00000001)

     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001110 Not tainted
r00-03  00000000 10340810 10299a38 1c6a1b00
r04-07  19ba8810 103a58b4 1f37586c 00000001
r08-11  10340bc0 00000001 0000000f 10342810
r12-15  103fc010 00000000 0000b71b 00035054
r16-19  1c6a1600 faf00208 000020a8 19ba8810
r20-23  00000000 00000001 10299a08 00000005
r24-27  00000001 00000001 1f37586c 10330010
r28-31  00000000 00000000 1c6a1b80 102bf3fc
sr0-3   00000000 00000383 00000000 00000383
sr4-7   00000000 00000000 00000000 00000000

IASQ: 00000000 00000000 IAOQ: 1011a73c 1011a740
 IIR: 0ea01093    ISR: 00000000  IOR: 00000001
 CPU:        0   CR30: 19a90000 CR31: 103e8000
 ORIG_R28: 00000000

For which crash dump_analyser.sh give me:
IAOQ =3D 1011a73c
Func: __wake_up, Off: 64, Addr: 0x1011a73c
1011a730:	34 28 07 60 	ldo 3b0(r1),r8
1011a734:	0c 99 10 95 	ldw -4(sr0,r4),r21
1011a738:	34 14 00 00 	ldi 0,r20
1011a73c:	0e a0 10 93 	ldw 0(sr0,r21),r19
1011a77c:	88 86 3f 6f 	cmpb,<>,n r6,r4,1011a738 <__wake_up+0x60>

GR0 =3D 00000000

GR1 =3D 10340810
Func: syscall_names, Off: 39c, Addr: 0x10340810

GR2 =3D 10299a38
Func: sock_def_readable, Off: 30, Addr: 0x10299a38
10299a14:	86 80 20 38 	cmpib,=3D 0,r20,10299a38 <sock_def_readable+0x30>
10299a28:	82 74 20 10 	cmpb,=3D r20,r19,10299a38 <sock_def_readable+0x30>=

10299a30:	e8 4f 04 e8 	b,l 102b7cac <tcp_recvmsg+0xa3c>,rp
10299a34:	08 00 02 40 	nop
10299a38:	48 73 05 a8 	ldw 2d4(r3),r19
10299a3c:	86 60 20 2a 	cmpib,=3D,n 0,r19,10299a58 <sock_def_readable+0x50=
>

GR3 =3D 1c6a1b00

GR4 =3D 19ba8810

GR5 =3D 103a58b4
Func: identify_ramdisk_image, Off: 78, Addr: 0x103a58b4
103a58b0:	08 04 02 58 	copy r4,r24
103a58b4:	0c 60 10 14 	ldb 0(sr0,r3),r20
103a58b8:	34 13 00 3e 	ldi 1f,r19
103a58bc:	82 93 22 58 	cmpb,=3D r19,r20,103a59f0 <identify_ramdisk_image+=
0x1b4>

GR6 =3D 1f37586c

GR7 =3D 00000001

GR8 =3D 10340bc0
Func: runqueue_head, Off: 0, Addr: 0x10340bc0

GR9 =3D 00000001

GR10 =3D 0000000f

GR11 =3D 10342810
Func: kstat, Off: 1bf8, Addr: 0x10342810

GR12 =3D 103fc010
Func: tv1, Off: 358, Addr: 0x103fc010

GR13 =3D 00000000

GR14 =3D 0000b71b

GR15 =3D 00035054

GR16 =3D 1c6a1600

GR17 =3D faf00208

GR18 =3D 000020a8

GR19 =3D 19ba8810

GR20 =3D 00000000

GR21 =3D 00000001

GR22 =3D 10299a08
Func: sock_def_readable, Off: 0, Addr: 0x10299a08
10299a00:	34 42 3f d9 	ldo -14(rp),rp
10299a04:	08 00 02 40 	nop
10299a08 <sock_def_readable>:
10299a08:	6b c2 3f d9 	stw rp,-14(sp)
10299a0c:	6f c3 00 80 	stw,ma r3,40(sp)

GR23 =3D 00000005

GR24 =3D 00000001

GR25 =3D 00000001

GR26 =3D 1f37586c

GR27 =3D 10330010
Func: $global$, Off: 0, Addr: 0x10330010

GR28 =3D 00000000

GR29 =3D 00000000

GR30 =3D 1c6a1b80

GR31 =3D 102bf3fc
Func: tcp_rcv_established, Off: 6bc, Addr: 0x102bf3fc
102bf3f0:	34 19 00 00 	ldi 0,r25
102bf3f4:	e6 c0 20 00 	be,l 0(sr4,r22),%sr0,%r31
102bf3f8:	08 1f 02 42 	copy r31,rp
102bf3fc:	e8 1f 15 55 	b,l 102beeac <tcp_rcv_established+0x16c>,r0

(nothing change for kernel)

That does not help me more but may be somebody else?



>
>You have any iptables (firewall) filtering enabled?
>

I check and there well iptables foreseen as module bu not loaded?

>Maybe an issue with opening a new connection in the interrupt context?
>My weak understanding of the network stack is that a TCP packet comes
>in with SYN (on the interrupt stack) and gets queued for the bottom
>half. The bottom half is invoked with interrupts re-enabled but
>on the kernel stack in the "interrupt context". Did I get that right?
>
IIRC Carlos suspect a tty problem?

hth,
Joel



*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be

[parisc-linux] new gcc-default for hppa

[jsoe0708]

Hi all,

I do notice that unstable debian for i386 switch (or will very soon) gcc-=
default
to gcc-3.2. Is it also true for hppa? (am I anxious about compiling new
kernel with this because of pb encounter with network connection)

Thanks in advance for advise,
    Joel
 

*********************************************
Vous surfez toujours avec une ligne classique ?
Faites des economies avec Tiscali Complete...
Plus d'info sur ... http://complete.tiscali.be