Linux PARISC architecture development
 help / color / mirror / Atom feed
* Re: [parisc-linux] compiler & kernel
@ 2003-06-02 10:11 Joel Soete
  2003-06-02 19:05 ` Matthias Klose
  2003-06-02 20:20 ` M. Grabert
  0 siblings, 2 replies; 14+ messages in thread
From: Joel Soete @ 2003-06-02 10:11 UTC (permalink / raw)
  To: M. Grabert, Joel Soete; +Cc: parisc-linux

Hi Max,

>
>On Sat, 31 May 2003, Joel Soete wrote:

> M. Grabert wrote:
>
> >[...]
> >
> >Oh yes, one important issue:
> >I have this 'target suffers from tag starvation' problem as some others
> >seem to have aswell. I just have a 20GB SE
SCSI (50 pin), n
> other SCSI
> >devices (the original internal UW-SCSI drive is in my AlphaStation now).
> > [...]
>
> Which scsi driver do you used (I presume a Symbios one but version 1 or
> 2; version 2 is recommended now in 2.4.20-pa..)?


 have/had this pro
>lems with both (old/new) Symbios drivers!
The problems are fixed for any Symbios driver when I use an older version
of 53x700 driver. I did extensive testing (for kernel with driver version
1 and 2) for 2 days before I was convi
ed that this 'fix' a
>tually works.

Right now the kernel I currently use (with the longest uptime for months
so far) is using the Symbios v1 driver, but as I said v2 works now aswell!

Curious, last v2 I do not have any more pb (neither on b180 
or b2k, N).
(that doesn't mean that I don't trust you; just share info)

I just install a 36Gb lvd disk on my b2k (ST336704LC HP supply) on the built
in scsi-controler which is of model <895a>(,rev 0x1) and all seems to works
fine.

> OTC this w
e I still experiment such a scsi terminator pb: I recover a
> lvd 30g
> scsi-disk (sun); I find a converter sca2 80pins sca 64pins but
> a cable with terminator for hvd disk. The disk seems to works fine
> untill the terminator warm to much then I 
ot scsi parity errors. And
> without terminator the controler do not se
> the disk at all?

That's actually the first time that I hear of a SCSI terminator
overheating. Perhaps you shouldn't overclock your SCSI bus then ;))))

But seriously, I h
ve had lots of troubles with 80pins to 64pins
converters and UW to U-SCSI
>converters. Quite often they didn't work
for some harddisk and others worked fine. I don't trust these converters!

Hmm to say everything: the converter came from a interna
 UW-disk of a k360,
the cable and its terminator from a D380 and nothing was foreseen for new
lvd :(.
(but that was just a do-it-yourself test because no shop of scsi spare part
near home :O )

> >hppa64-gcc (3.2.3, from ftp.p-l.org unofficial-de
s)
> >  seems to work fine but obviously ipt_limit.o is miscompiled:
> >  I ca
> insmod it, but iptable wouldn't recognize the --limit* options.
> >  There are still some problems with some modules and canonicalize_funcptr,
> >
> Are you sure thi
 is with hppa64-gcc (iirc canonicalize.., was just
> recently backport to 3.2)?

>
> [...]

I thought so. The canonicalize_* stuff showed up when compiling with
gcc-3.3 (I forgot this to mention), but I thought they showed up in
3.2 (64bit). Ma
be I just can't remeber this one correctly.
But the iptable_limit error is definite
>y a hppa64-gcc-3.2.3 issue
(or a kernel issue with hppa64 ;)

Well gcc-hppa64 pkg is a bit out dated but that is all is available.
And I do not found courage to 
oolchain the last gcc-3.3 :(

>
> >  Man, gcc-3.3 is SLOW! it takes ages to compile the kernel!
> >
> >  Kernel compiled with 3.3 definitely have a bogomips problem (they report
> >  0.8 instead of about 470 on a C2
>0);

This might actually b
 PA8000 specific ...

> >  The kernel takes forever to boot up (it 'waits' for over one minute
> >  after palo loads the kernel (right after the 'switch to another console'
> >  message)), propably because of the bogomi
>s calculation.

...my PA
book with the same kernel & gcc-3.3 doesn't hang!

> >  Also the userspace programme 'bogomips' has the same issue.
> >

Sorry could not help (no clue of what bogomips is: just see on my i386 but
no trace in my hppa dmesg?)

> >  Apart to make 
rom this issues, gcc-3.3 produces a kernel that is at
> >  least as stable as th
>se compiled with 3.0 or 3.2

I'll send the config file as soon as I'm back home (tomorrow)

No problem (I curoius to compare on the hw I test here)

> btw which g
c-3.3 release do you use?

the latest in testing (no prerelease anymore)

Well I used last unstable, let see


Joel




---------------------------------
Découvrez les 6 clés et gagnez le Club Med à Vie avec Tiscali
http://www.tiscali.be/nl/subs/tiscali4life/default.asp?lang=fr

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [parisc-linux] compiler & kernel
@ 2003-06-03 17:21 Joel Soete
  0 siblings, 0 replies; 14+ messages in thread
From: Joel Soete @ 2003-06-03 17:21 UTC (permalink / raw)
  To: M. Grabert; +Cc: parisc-linux

Hi Max,

>
>Attachment: config-2.4.20-pa35-gcc-3.3
>
32-bits first;
I test this config with gcc-3.3-2 and binutils 2.13.90.0.18-7 but I encounter
following pb:

`gcc-3.3 -print-libgcc-file-name` /usr/src/linux-2.4.20-pa35/arch/parisc/lib/lib.a

/usr/src/linux-2.4.20-pa35/lib/lib.a  \
        --end-group \
        -o vmlinux
drivers/net/wireless/wireless_net.o(.init.text+0x78): In function `init_orinoco_cs':
: undefined reference to `CardServices'
drivers/net/wireless/wireless_net.o(.ini
.text+0xac): In function `init_orinoco_cs':
: undefined reference to `register_pccard_driver'
drivers/net/wireless/wireless_net.o(.exit.text+0x2c): In function `exit_orinoco_cs':
: undefined reference to `unregister_pccard_driver'
drivers/net/wirel
ss/wireless_net.o(.text.cs_error+0x18): In function `cs_error':
: undefined reference to `CardServices'
drivers/net/wireless/wireless_net.o(.text.orinoco_cs_cor_reset+0x48): In
function `orinoco_cs_cor_reset':
: undefined reference to `CardServices

drivers/net/wireless/wireless_net.o(.text.orinoco_cs_cor_reset+0x74): In
function `orinoco_cs_cor_reset':
: undefined reference to `CardServices'
drivers/net/wireless/wireless_net.o(.text.orinoco_cs_cor_reset+0xd4): In
function `orinoco_cs_cor_re
et':
: undefined reference to `CardServices'
drivers/net/wireless/wireless_net.o(.text.orinoco_cs_attach+0x108): In function
`orinoco_cs_attach':
: undefined reference to `CardServices'
drivers/net/wireless/wireless_net.o(.text.orinoco_cs_detach+0
90): more
undefined references to `CardServices' follow
make: *** [vmlinux] Error 1

And the very same with gcc-3.0.4-16 {(which also backport canonicalize_*
?)}

Any idea?

Now overall results:
[the two test made exactely the same number of 
cc (grep "^gcc" blabla |
wc -l == 968)]

gcc-3.3

start: k-2.4.20-pa35-cfg-gcc33:Tue Jun  3 18:22:57 CEST 2003
end:   k-2.4.20-pa35-cfg-gcc33:Tue Jun  3 18:41:31 CEST 2003
(About 19 min)

gcc-3.0
start: k-2.4.20-pa35-cfg-gcc30:Tue Jun  3 19:1
:44 CEST 2003
end:   k-2.4.20-pa35-cfg-gcc30:Tue Jun  3 19:30:46 CEST 2003
(about 17 min)

I am not enough happy because not yet reach to obtain a kernel; I will try
tomorrow :(

Cheers,
    Joel

PS: I run those draft test on a b2k running a
kernel compile with gcc-3.3
(32-bits) and the BogoMIPS in dmesg is 799.53 (about 2 * 400MHz of cpu).
On the other hand I will made same test on a N (ucp) running a 64-bit kernel
with BogoMIPS announced as 1097.72 (about 2 * 550 Mhz of cpu).

Well 
hat is only draft info, I am waiting to run your kernel on the two
machime to see?


>
>Attachment: config-2.4.20-pa35-64
>

(I hope tomorrow )




---------------------------------
Découvrez les 6 clés et gagnez le Club Med à Vie avec Tiscali
http://www.tiscali.be/nl/subs/tiscali4life/default.asp?lang=fr

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [parisc-linux] compiler & kernel
@ 2003-05-30 12:10 M. Grabert
  2003-05-31 10:40 ` Joel Soete
  0 siblings, 1 reply; 14+ messages in thread
From: M. Grabert @ 2003-05-30 12:10 UTC (permalink / raw)
  To: parisc-linux

Hi,

I just wanted to share the experience I made after experimenting with
different compilers and linux-2.4.20-pa35 on Debian/testing on a C240.
Maybe it's of some use for you or somebody has some remarks how to
solve an issue or whether it's just me who has problems ;)
This is not a request for fixing things, I'm just curious whether
developers/users had similar problems and/or are aware of them.


Some general problems:


I use quite a lot of additional non-HP hardware in my C240:

I'm using a 4port USB2.0-card, a IBM Token Ring card, (soon hopefully a
NetGEAR MA311 Wireless NIC) and a 8193too-compatible Network card)

So far I can only use USB1.1 drivers, since the EHCI code seems to
dislike parisc (kernel oops with any compiler).

Another general problem (which exists as far as I can remember):

It also seems that I can only use drivers for hardware if they are
directly compiled into the kernel, since otherwise 'lspci -v' will
show ioports/memory for devices marked as 'disabled' and trying to
modprobe h/w driver modules will fail.
Modules not accessing the hardware directly however work fine.



Oh yes, one important issue:
I have this 'target suffers from tag starvation' problem as some others
seem to have aswell. I just have a 20GB SE SCSI (50 pin), no other SCSI
devices (the original internal UW-SCSI drive is in my AlphaStation now).

I tried several configurations ... actually all configurations possible.
It is definitely NOT a SCSI termination issue, nor a faulty HD (it works
perfectly on my SUN and my Alpha). Moreover it works quite well with
older kernels, such as 2.4.19-pa2.

Newer kernels (starting with about 2.4.20) often report "target is
suffering from tag starvation" and after that the kernel will most likely
oops and hang. Most the time I even can't boot the kernel, since
mounting the root fs alone will most likely cause a kernel crash.
Older kernels either don't display the message at all, or
not very often (such as once a day if the disk is in HEAVY use), and the
kernel will never crash after displaying the message.

So I copied the /usr/src/linux-2.4.19-pa2/drivers/scsi/53c700.c driver
to the corresponding directory in the 2.4.20-pa35 kernel and now the
kernel is perfectly stable again!
I don't know what causes this trouble, but I really don't think it's my
SCSI hardware (I use SCSI devices for quite a long time. I should know by
know which cables to use and how to do proper SCSI termination etc.
Moreover I exchanged everything just to be sure it's not faulty
cables/terminators).
Maybe it's just the software driver, maybe it's a bug in the HP SCSI chip
when using SE disks ... I just know the older driver is much more stable!


And finally some issues I have found when using certain versions of gcc
to compile linux-2.4.20-pa35:

(for all different compilers I used the same configuration, except for
choosing 32/64bit kernels. I use the PA8000 CPU option by default)



hppa64-gcc (3.2.3, from ftp.p-l.org unofficial-debs)
  seems to work fine but obviously ipt_limit.o is miscompiled:
  I can insmod it, but iptable wouldn't recognize the --limit* options.
  There are still some problems with some modules and canonicalize_funcptr,
  (IIRC networking VLAN support, TUN/TAP, zlib_deflate), but when
  compiled into the kernel (not compiled as modules) they seems to work

  Also some stability issues:
  Ie. wmrack makes the kernel crash immeadiately (no kernel Oops output),
  xosview doesn't work (no windows opened)

gcc-3.0
  still propably the recommended compiler, no problems!
  IIRC I still used the PA7000 CPU setting when compiling with gcc-3.0
  at that time

gcc-3.2.3
  I don't recall having the same issues in ipt_limit.o that the 64bit
  version of gcc-3.2.3 has, everythink seems to work quite well. compiling
  the kernel is slower than gcc-3.0

gcc-3.3
  compiled fine after commenting out the references $mulU in parisc_ksyms.c
  and fixing drivers/net/tokenring/olympic.c (yes, some people still use
  tokenring!):
     - type cast error in the use of memcpy_fromio, casting the parameter
       to ulong works
     - one text string spread over two lines, but without a '\' at the end.

  Man, gcc-3.3 is SLOW! it takes ages to compile the kernel!

  Kernel compiled with 3.3 definitely have a bogomips problem (they report
  0.8 instead of about 470 on a C240);
  The kernel takes forever to boot up (it 'waits' for over one minute
  after palo loads the kernel (right after the 'switch to another console'
  message)), propably because of the bogomips calculation.
  Also the userspace programme 'bogomips' has the same issue.

  Apart to make from this issues, gcc-3.3 produces a kernel that is at
  least as stable as those compiled with 3.0 or 3.2


BTW, I've quite alot of networking stuff in the kernel:
IPv6, Bridging, VLan, PPP, PPPoE, Netfilter, Network devices etc.
Apart from that it is a pretty 'normal' configuration (I'll send the
.config and System.map if somebody wants it).


Right now I'm running linux-2.4.20-pa35 for over a week now, and the
machine is really stable. It's actively used as DHCP-server,
SMB-server, router/firewall and for several other stuff in our LAN.



Thanks, Max

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2003-06-04  5:47 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-06-02 10:11 [parisc-linux] compiler & kernel Joel Soete
2003-06-02 19:05 ` Matthias Klose
2003-06-02 20:20 ` M. Grabert
2003-06-02 21:58   ` Grant Grundler
  -- strict thread matches above, loose matches on Subject: below --
2003-06-03 17:21 Joel Soete
2003-05-30 12:10 M. Grabert
2003-05-31 10:40 ` Joel Soete
2003-06-02  8:10   ` M. Grabert
2003-06-02 17:32   ` John David Anglin
2003-06-03  7:14     ` Joel Soete
2003-06-03 14:18       ` John David Anglin
2003-06-03 15:35         ` Joel Soete
2003-06-03 23:59         ` Grant Grundler
2003-06-04  5:47           ` John David Anglin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox