All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Soete <joel.soete@tiscali.be>
To: "M. Grabert" <xam@cs.ucc.ie>
Cc: parisc-linux@lists.parisc-linux.org
Subject: Re: [parisc-linux] compiler & kernel
Date: Sat, 31 May 2003 10:40:33 +0000	[thread overview]
Message-ID: <3ED886A1.10605@tiscali.be> (raw)
In-Reply-To: <Pine.LNX.4.44.0305301120390.11291-100000@sal.ucc.ie>

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), 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!
>
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..)?

OTC this w-e I still experiment such a scsi terminator pb: I recover a 
lvd 30gb 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 got scsi parity errors. And 
without terminator the controler do not see the disk at all?

>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,
>
Are you sure this is with hppa64-gcc (iirc canonicalize.., was just 
recently backport to 3.2)?

[...]

>  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.
>
>  
>
hmm I just reboot (just to exchange cards) some l-w firewall (so only 
ppp, ppoe, netfilter, just ipv4, no ipv6 , no bridging, no vlan)  
running since 79days a kernel 2.4.20-pa22 build with gcc-3.3 on a b180 
and do not presenting this kind of pb. Unfortuantely, I don't have all 
your hw available but can you send me your config file so that I can see 
if I can reproduce.

btw which gcc-3.3 release do you use?
hth,
    Joel

  reply	other threads:[~2003-05-31 10:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-30 12:10 [parisc-linux] compiler & kernel M. Grabert
2003-05-31 10:40 ` Joel Soete [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
2003-06-02 10:11 Joel Soete
2003-06-02 19:05 ` Matthias Klose
2003-06-02 20:20 ` M. Grabert
2003-06-02 21:58   ` Grant Grundler
2003-06-03 17:21 Joel Soete

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ED886A1.10605@tiscali.be \
    --to=joel.soete@tiscali.be \
    --cc=parisc-linux@lists.parisc-linux.org \
    --cc=xam@cs.ucc.ie \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.