From: Chris Dearman <chris@algor.co.uk>
To: Zhang Fuxin <fxzhang@ict.ac.cn>
Cc: "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: 2.4.16 for algorithmics p6032
Date: Wed, 05 Dec 2001 14:25:56 +0000 [thread overview]
Message-ID: <3C0E2E74.C1E7DF9F@algor.co.uk> (raw)
In-Reply-To: 200112051354.fB5DstZ21095@oval.algor.co.uk
Zhang Fuxin wrote:
>
> hi,Chris£¬
> you can do anything you like to my code:)
> i have promised to release it months ago,but so busy I was the past
> months and i am shy to release ugly code. Sorry if it waste you time.
Thanks. We've followed very similar routes so there aren't so many
differences :-)
>
> Today I make some tests and get some fixes ,log is here
> (i was too sleepy last night,so most of them is stupy errors):
> 2001.12.05:
> arch/mips/defconfig-p6032:
> ide dma unstable,don't choose 'use dma by default when available'
Yes. I have had a look at this but haven't tracked it down yet. The
only thing I know is that the buffer heads get corrupted, so I assume
there is some interrupt locking problem somewhere. I know that DMA
works in the MIPS 2.4.3 port. Were you using DMA in your 2.4.8 kernel?
> you probably will be more able to deal with the dma and board cache
Do you use the IOBC? I had to make some changes to pci.h and the
ethernet driver to make them work properly.
> than me:). The spurious interrupt problem still there,i have added some
> code to work around it but don't know the reason.
The spurious interrupts are caused by posted writes to PCI devices.
The sequence is usually something like:
o write device to clear interrupt (write gets posted)
o enable CPU interrupts (interrupt is still pending)
o CPU enters interrupt handler and reads 8259 which causes posted
write
to be flushed and so now there is no interrupt...
The only fix is to do an explicit PCI (eg ISA port) before reenabling
interrupts. The 2.4.x kernel reenables interrupts more quickly than the
older kernel which is why it is more noticeable.
>
> I have made a quick test with ltp, most of them passed,but some of
> the fs test and the syscall test failed,i will look into them soon
> if you have interest,i can give you more detail results
I've not used ltp, but if you do find anything useful I would be
interested.
Regards
Chris
--
Algorithmics,The Fruit Farm,Ely Road,Chittering,CAMBS CB5 9PH,ENGLAND
P: +44 1223 706200 F: +44 1223 706250 W: http://www.algor.co.uk
parent reply other threads:[~2001-12-05 15:26 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <200112051354.fB5DstZ21095@oval.algor.co.uk>]
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=3C0E2E74.C1E7DF9F@algor.co.uk \
--to=chris@algor.co.uk \
--cc=fxzhang@ict.ac.cn \
--cc=linux-mips@oss.sgi.com \
/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.