:
:Ah, excellent. If my tests of Luoqi's fix work, I'll commit it as
:part of my big VM commit to -4.x, and also commit this and a few
:other simple VM bug fixes to -3.x.
Oops, there is still something broken. I think getblk() needs to be
reorganized completely, there are s
:>...
:> having to check for B_DELWRI in bread(), breadn(), and nfs_bioread()
:> by forcing getblk() to handle the B_DELWRI condition.
:>
:> Cool. I'll replace my nfs_bioread() patch with this one and test it
:> before committing all this stuff to the -4.x branch ( which I will al
On Wednesday, 20 January 1999 at 23:00:34 -0800, Matthew Dillon wrote:
>> Sorry, Matt, the patch in my previous email was fatally flawed. Try this one
>> below. The two printf() messages don't necessarily come out in pairs and
>> it's not just NFS bufs' B_CACHE bits are cleared, so my comment about
:Sorry, Matt, the patch in my previous email was fatally flawed. Try this one
:below. The two printf() messages don't necessarily come out in pairs and
:it's not just NFS bufs' B_CACHE bits are cleared, so my comment about
:vm_page_is_valid() check in my previous message was wrong and the check is
On Thursday, 21 January 1999 at 7:19:39 +0100, Andreas Klemm wrote:
> On Thu, Jan 21, 1999 at 12:09:00PM +1030, Greg Lehey wrote:
>> On Wednesday, 20 January 1999 at 19:33:54 +0100, Andreas Klemm wrote:
>>> On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
Hmm. Interes
On Thu, Jan 21, 1999 at 12:09:00PM +1030, Greg Lehey wrote:
> On Wednesday, 20 January 1999 at 19:33:54 +0100, Andreas Klemm wrote:
> > On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
> >>
> >> Hmm. Interesting, it's dying trying to fsync an FFS vnode. Are you
> >> by any
On Wednesday, 20 January 1999 at 19:33:54 +0100, Andreas Klemm wrote:
> On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
>>
>> Hmm. Interesting, it's dying trying to fsync an FFS vnode. Are you
>> by any chance running NFS ( client *or* server ) on this box?
>
> No, no NFS
(This is mainly for Luoqi, John, or David, or anyone who understands
struct buf's and NFS).
I see some other weirdness in bread() relating to NFS as well.
int
bread(struct vnode * vp, daddr_t blkno, int size, struct ucred * cred,
struct buf ** bpp)
{
struct buf *bp;
Try this. In nfs_bioread(), nfs/nfs_bio.c:
Before, it was:
if (getpages && !(bp->b_flags & B_VMIO)) {
#ifdef DIAGNOSTIC
printf("nfs_bioread: non vmio buf found, discarding\n");
Try changin the if() to this:
if (
:ok, here are some instructions which -- I hope -- reproduce it
:(I haven't found a *nice* way; this is the ridiculous way):
:
:NFS server and client are completely 3.0-CURRENT
:(of CTM src-cur.3712.gz) with Luoqi's NFS fix. The server has all
:(physical) file systems mounted with softupdates exce
On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
>
> Hmm. Interesting, it's dying trying to fsync an FFS vnode. Are you
> by any chance running NFS ( client *or* server ) on this box?
No, no NFS compiled in and am not using it. See my kernel config.
> First, if eith
On Tue, Jan 19, 1999 at 11:00:55PM -0800, Matthew Dillon wrote:
[...]
> ::But there's still something wrong: When shutting down the server
> ::it still sometimes panics in vinvalbuf() complaining 'bout dirty
> ::pages. On the client side vi dies of SEGV (edited file and
> ::/var/tmp/vi.recover on n
:Hi !
:
:Since one or two weeks my system panics shortly before completely
:going down. Services like squid and inn take a little longer than
:usual to finish, I hear much disk activity.
:
:This happens usually if the system ran a day or so.
:
:What can I do to help ? Compile Kernel with debug inf
Hi !
Since one or two weeks my system panics shortly before completely
going down. Services like squid and inn take a little longer than
usual to finish, I hear much disk activity.
This happens usually if the system ran a day or so.
What can I do to help ? Compile Kernel with debug infos ?
BTW,
14 matches
Mail list logo
