:[General discussion of VM buffer corruption deleted]
:
:Matthew Dillon [EMAIL PROTECTED] wrote:
: Thor suggested adding the CACHETHEN bit back in the adaptec controller.
:
:To save anyone else the effort, this change only affects Adaptecs
:that identify as "aic7890/91" or "aic7896/97".
:
:Peter
[General discussion of VM buffer corruption deleted]
Matthew Dillon dil...@apollo.backplane.com wrote:
Thor suggested adding the CACHETHEN bit back in the adaptec controller.
To save anyone else the effort, this change only affects Adaptecs
that identify as aic7890/91 or aic7896/97.
Peter
To
:[General discussion of VM buffer corruption deleted]
:
:Matthew Dillon dil...@apollo.backplane.com wrote:
: Thor suggested adding the CACHETHEN bit back in the adaptec controller.
:
:To save anyone else the effort, this change only affects Adaptecs
:that identify as aic7890/91 or aic7896/97.
:
Matthew Dillon dil...@apollo.backplane.com wrote:
Oh my, did I really say Thor ? Sorry about that Tor!
Actually, no, I managed to insert that typo into Matt's quote. Sorry to
both Tor and Matt.
Peter
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in
Isn't all the work in CAM done at splsoftcam?
(or am I thinking of old code)
It starts off an ISR similar to the netisr doesn't it?
On Sat, 28 Aug 1999, Matthew Dillon wrote:
I'm trying to track down some VFS/BIO corruption on an NFS server
being tested under heavy loads and noticed
: Isn't all the work in CAM done at splsoftcam?
:
:Not all. There's completions done at splcam. I've had some worries and
:concerns about this, but (wince) I really have to admit that the ins and
:outs of the cam code often escape me, and they're documented only in the
:DNA of certain human
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
career on
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
Oh, Tor didn't Cc hackers. Tor suggested adding the CACHETHEN bit
back in the adaptec controller, undoing part of Justin's commit on
the 15th (see the commitlogs for sys and search for 'CACHETHEN').
This fixed the problem! Ah, sunshine here I come!
I'm trying to track down some VFS/BIO corruption on an NFS server
being tested under heavy loads and noticed that my SCSI interrupts
do not appear to be blocked by splbio().
(The adaptec's are on irq 5 and irq 12)
(kgdb) print bio_imask
$1 = 0x40080040
Isn't all the work in CAM done at splsoftcam?
(or am I thinking of old code)
It starts off an ISR similar to the netisr doesn't it?
On Sat, 28 Aug 1999, Matthew Dillon wrote:
I'm trying to track down some VFS/BIO corruption on an NFS server
being tested under heavy loads and noticed
Isn't all the work in CAM done at splsoftcam?
Not all. There's completions done at splcam. I've had some worries and
concerns about this, but (wince) I really have to admit that the ins and
outs of the cam code often escape me, and they're documented only in the
DNA of certain human subspecies
: Isn't all the work in CAM done at splsoftcam?
:
:Not all. There's completions done at splcam. I've had some worries and
:concerns about this, but (wince) I really have to admit that the ins and
:outs of the cam code often escape me, and they're documented only in the
:DNA of certain human
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
career on
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
:I strongly doubt that this is a CAM isr problem- the error pattern isn't
:entirely clear from what you said, but it looks more like a FIFO or CACHE
:LINE sized type of problem- it looks to be 16 bytes, but not a short
:count. Because this isn't one of the wacky systems I spent most of my
I strongly doubt that this is a CAM isr problem- the error pattern isn't
entirely clear from what you said, but it looks more like a FIFO or CACHE
LINE sized type of problem- it looks to be 16 bytes, but not a short
count. Because this isn't one of the wacky systems I spent most of my
Oh, Tor didn't Cc hackers. Tor suggested adding the CACHETHEN bit
back in the adaptec controller, undoing part of Justin's commit on
the 15th (see the commitlogs for sys and search for 'CACHETHEN').
This fixed the problem! Ah, sunshine here I come!
19 matches
Mail list logo
