> [...]
> Since you have one of these beasts, could you maybe try changing
> the number of tagged command queue entries you permit to be used
> at one time?
Of course, I'll do it as soon as...
1) I'm at home again... ;-)
2) Someone tells me how to achive that. I looked at 'man 8 atacontrol'
a
Benno Rice <[EMAIL PROTECTED]> writes:
> I think des's commit that removed the _use_yp variable from
> usr.sbin/vipw/pw_util.c fixed it. I managed to get an unresolved symbol
> error for _use_yp out of pam with the attached patch.
I have a similar patch in my tree, but dlerror() keeps returning
In file included from
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.h:45,
from
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.c:91:
/.amd_mnt/freefall/host/d/home/des
Hi Terry and you all,
On Tuesday, 16. April 2002 01:48 you wrote:
> [...]
> As I said: it could be drive settings unrelated to the code
> itself being correct. I've given three suggestions to verify
> this, one way or the other:
>
> 1)Control the drive DMA speed down
>
> 2)Pretend the m
Two panic's in a row, on a desktop workstation, with -CURRENT
kernel and world as of Apr. 15.
I am keeping the cores for now, if any further forensics are desired.
Thomas.
# gdb -k /usr/obj/usr/src/sys/SHALMANESER/kernel.debug
3dc44d47eaf2fa5efca6d587da113787.core
GNU gdb 4.18
Copyright 1998 F
Julian,
thanks for the comments, as always i found them very useful :)
i have combined both e-mail into one and included my answers
inline.
> ng_btsocket.c: unmodified: line 674
> sbappendrecord(&pcb->so->so_snd, m);
> m = m_dup(m, M_TRYWAIT);
> if (m == NULL) {
>
On Tue, 16 Apr 2002, Maksim Yevmenkin wrote:
>
> initially all nodes were WRITERs to "release the stack", but then i
> changed my strategy and now i'm serializing data at the edge of graph.
> for example both "bt3c" and "h4" nodes will NG_HOOK_FORCE_WRITER on
> upstream hook. also i probably
[EMAIL PROTECTED] wrote:
> > As I said: it could be drive settings unrelated to the code
> > itself being correct. I've given three suggestions to verify
> > this, one way or the other:
> >
> > 1)Control the drive DMA speed down
>
> I *did* test with UDMA66 instead of UDMA100 and it was even
Matthias Schuendehuette wrote:
> On Tuesday, 16. April 2002 01:48 you wrote:
> > [...]
> > As I said: it could be drive settings unrelated to the code
> > itself being correct. I've given three suggestions to verify
> > this, one way or the other:
> >
> > 1)Control the drive DMA speed down
>
On 17-Apr-2002 Terry Lambert wrote:
>> What was consistent thru all test was, that the disk operates quite
>> some time until the error occures the first time. After that, it is not
>> possible to access the disk in UDMA-Mode any more, regardeless *which*
>> UDMA-Mode it is. 'Quite some time' mea
John Baldwin wrote:
> > My hunch, which is why I suggested decreasing the number of
> > tags seen by the driver, is that the tagged queues are over
> > used, and this locks the disk up. My best guess is an off-by-one
> > or an exceptional condition handler that was not an issue until
> > recently
Dag-Erling Smorgrav wrote:
> Benno Rice <[EMAIL PROTECTED]> writes:
> > I think des's commit that removed the _use_yp variable from
> > usr.sbin/vipw/pw_util.c fixed it. I managed to get an unresolved symbol
> > error for _use_yp out of pam with the attached patch.
>
> I have a similar patch in
In file included from
/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.h:45,
from
/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/stb.c:91:
/d/home/des/tinderbox/src/gnu/usr.bin/cc/f771/../../../../contrib/gcc.295/f/str.
Warning
Unable to process data:
multipart/mixed;boundary="=_NextPart_000_00A1_11D12G3I.I1343N65"
14 matches
Mail list logo
