NetBSD Problem Report #35448

From agrier@poofygoof.com  Sat Jan 20 03:54:28 2007
Return-Path: <agrier@poofygoof.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id D70A263B8CE
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 20 Jan 2007 03:54:28 +0000 (UTC)
Message-Id: <20070120035419.E991233143@arwen.poofy.goof.com>
Date: Fri, 19 Jan 2007 19:54:18 -0800 (PST)
From: agrier@poofygoof.com
Reply-To: agrier@poofygoof.com
To: gnats-bugs@NetBSD.org
Subject: memory management fault trap during heavy network I/O
X-Send-Pr-Version: 3.95

>Number:         35448
>Category:       port-alpha
>Synopsis:       memory management fault trap during heavy network I/O
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    mhitch
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 20 03:55:00 +0000 2007
>Closed-Date:    
>Last-Modified:  Tue Dec 18 16:00:06 +0000 2012
>Originator:     agrier@poofygoof.com
>Release:        NetBSD 4.99.8
>Organization:
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
>Environment:


System: NetBSD arwen.poofy.goof.com 4.99.8 NetBSD 4.99.8 (ARWEN) #0: Thu Jan 18 23:03:09 PST 2007 agrier@arwen.poofy.goof.com:/var/obj/ARWEN alpha
Architecture: alpha
Machine: alpha

ARWEN is an alphaserver 1000A 5/400.

the ARWEN kernel is GENERIC with hardcoded line to attach root at ld0.
>Description:

- the trap:

CPU 0: fatal kernel trap:

CPU 0    trap entry = 0x2 (memory management fault)
CPU 0    a0         = 0xfffffe0108266000
CPU 0    a1         = 0x1
CPU 0    a2         = 0x0
CPU 0    pc         = 0xfffffc00007ecde0
CPU 0    ra         = 0xfffffc000035f9ac
CPU 0    pv         = 0x0
CPU 0    curlwp    = 0xfffffc000fcd2660
CPU 0        pid = 335, comm = nfsio

panic: trap
Begin traceback...
alpha trace requires known PC =eject=
End traceback...
syncing disks... 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 5 5 5 5 5 5 giving up

- the backtrace:

(gdb) bt
#0  0xfffffc00007df888 in dumpsys ()
    at /projects/NetBSD/src/sys/arch/alpha/alpha/machdep.c:1229
#1  0xfffffc00007dfdb0 in cpu_reboot ()
    at /projects/NetBSD/src/sys/arch/alpha/alpha/machdep.c:1048
#2  0xfffffc0000644a50 in panic ()
    at /projects/NetBSD/src/sys/kern/subr_prf.c:246
#3  0xfffffc00007e7248 in trap ()
    at /projects/NetBSD/src/sys/arch/alpha/alpha/trap.c:601
#4  0xfffffc00003003e8 in XentMM ()
    at /projects/NetBSD/src/sys/arch/alpha/alpha/locore.s:492
#5  0xfffffc000035f9ac in in_delayed_cksum ()
    at /projects/NetBSD/src/sys/netinet/ip_output.c:1123
can not access 0xfffffffd, invalid translation (invalid L1 PTE)
can not access 0xfffffffd, invalid translation (invalid L1 PTE)
Cannot access memory at address 0xfffffffffffffffd

- some poking:

(gdb) frame 5
#5  0xfffffc000035f9ac in in_delayed_cksum ()
    at /projects/NetBSD/src/sys/netinet/ip_output.c:1123
1123            csum = in4_cksum(m, 0, offset, ntohs(ip->ip_len) - offset);
(gdb) proc 0xfffffc000fcd2660 # curlwp from the trap
(gdb) bt
#0  0xfffffc000062a730 in mi_switch ()
    at /projects/NetBSD/src/sys/kern/kern_synch.c:997
(gdb) list *0xfffffc00007ecde0 # pc from the trap
0xfffffc00007ecde0 is in in4_cksum
(/projects/NetBSD/src/sys/netinet/in4_cksum.c:175).

- dmesg

NetBSD 4.99.8 (ARWEN) #0: Thu Jan 18 23:03:09 PST 2007
	agrier@arwen.poofy.goof.com:/var/obj/ARWEN
AlphaServer 1000A 5/400, 400MHz, s/n 
8192 byte page size, 1 processor.
total memory = 256 MB
(2016 KB reserved for PROM, 254 MB used by NetBSD)
avail memory = 241 MB
mainbus0 (root)
cpu0 at mainbus0: ID 0 (primary), 21164A-2
cpu0: Architecture extensions: 1<BWX>
cia0 at mainbus0: DECchip 2117x Core Logic Chipset (ALCOR/ALCOR2), pass 3
cia0: extended capabilities: 21<DWEN,BWEN>
cia0: using BWX for PCI config access
pci0 at cia0 bus 0
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pceb0 at pci0 dev 7 function 0: Intel 82375EB/SB PCI-EISA Bridge (rev. 0x05)
ppb0 at pci0 dev 8 function 0: Digital Equipment DC21050 PCI-PCI Bridge (rev. 0x02)
pci1 at ppb0 bus 2
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
isp0 at pci1 dev 0 function 0: QLogic 1020 Fast Wide SCSI HBA
isp0: interrupting at dec_1000a irq 0
scsibus0 at isp0: 16 targets, 8 luns per target
tlp0 at pci0 dev 11 function 0: DECchip 21140 Ethernet, pass 1.2
tlp0: interrupting at dec_1000a irq 1
tlp0: DEC DE500-XA, Ethernet address 00:00:f8:02:06:a5
tlp0: 10baseT, 100baseTX, 100baseTX-FDX, 10baseT-FDX
mlx0 at pci0 dev 12 function 0: Mylex RAID (v2 interface)
mlx0: interrupting at dec_1000a irq 3
mlx0: DAC960P/PD, 3 channels, firmware 2.70-0-00, 32MB RAM
ld0 at mlx0 unit 0: RAID5, online
ld0: 16380 MB, 8320 cyl, 64 head, 63 sec, 512 bytes/sect x 33546240 sectors
ld1 at mlx0 unit 1: RAID5, online
ld1: 32768 MB, 8322 cyl, 128 head, 63 sec, 512 bytes/sect x 67108864 sectors
ld2 at mlx0 unit 2: RAID5, online
ld2: 32768 MB, 8322 cyl, 128 head, 63 sec, 512 bytes/sect x 67108864 sectors
ld3 at mlx0 unit 3: RAID5, online
ld3: 4536 MB, 2304 cyl, 64 head, 63 sec, 512 bytes/sect x 9289728 sectors
eisa0 at pceb0
eisa0: can't map I/O space for slot 9
isa0 at pceb0
lpt0 at isa0 port 0x3bc-0x3bf irq 7
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
pckbc0 at isa0 port 0x60-0x64
attimer0 at isa0 port 0x40-0x43: AT Timer
vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
wsdisplay0 at vga0 kbdmux 1
wsmux1: connecting to wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker (CPU-intensive output)
spkr0 at pcppi0
isabeep0 at pcppi0
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
mcclock0 at isa0 port 0x70-0x71: mc146818 or compatible
pcppi0: attached to attimer0
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
Kernelized RAIDframe activated
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 0 lun 0: <DEC, RZ28M    (C) DEC, 0568> disk fixed
sd0: async, 8-bit transfers
sd0: 2007 MB, 3045 cyl, 16 head, 84 sec, 512 bytes/sect x 4110480 sectors
sd0: sync (100.00ns offset 12), 8-bit (10.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 4 lun 0: <DEC, RRD45   (C) DEC, 1645> cdrom removable
cd0: async, 8-bit transfers
WARNING: can't figure what device matches "RAID 0 12 0 0 0 0 0"
root on ld0a dumps on sd0b

- other misc foo

ps won't grok the coredump:

arwen$ ps -N netbsd.gdb -M /var/crash/netbsd.0.core
ps: can't read proc credentials at 0xfffffc000ade3480: Undefined error: 0

>How-To-Repeat:
it seems to be triggered by syncing a remotely mounted mailbox from
within pine or mutt.
>Fix:
figure out what is causing the trap?  maybe a stack smash, based on
previous port-alpha mailing list entries.  perhaps

options KSTACK_CHECK_MAGIC

is in order?

>Release-Note:

>Audit-Trail:
From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: port-alpha/35448: memory management fault trap during heavy
 network I/O
Date: Mon, 22 Jan 2007 14:36:25 -0700 (MST)

 On Sat, 20 Jan 2007, agrier@poofygoof.com wrote:

 > - the trap:
 >
 > CPU 0: fatal kernel trap:
 >
 > CPU 0    trap entry = 0x2 (memory management fault)
 > CPU 0    a0         = 0xfffffe0108266000
 > CPU 0    a1         = 0x1
 > CPU 0    a2         = 0x0
 > CPU 0    pc         = 0xfffffc00007ecde0
 > CPU 0    ra         = 0xfffffc000035f9ac
 > CPU 0    pv         = 0x0
 > CPU 0    curlwp    = 0xfffffc000fcd2660
 > CPU 0        pid = 335, comm = nfsio
 ...
 > (gdb) list *0xfffffc00007ecde0 # pc from the trap
 > 0xfffffc00007ecde0 is in in4_cksum
 > (/projects/NetBSD/src/sys/netinet/in4_cksum.c:175).

    A preliminary analysis seems to indicate the trap occurred where 
 in4_cksum is summing 16 words in an unrolled loop.  If I understand the 
 trap registers correctly, it looks like the address causing the trap is 
 0xfffffe0108266000 (the contents of a0 above).  Running pmap(1) against 
 the coredump and kernel file seems to indicate that the address is not 
 within the current kernel's mapped address space.  The gdb backtrace 
 fails, so it's a little hard to figure out where it came from.  I'm going 
 to start groveling through the stack myself to see if I can dig out the 
 parameters to the in4_cksum() call, and if I can follow the traceback 
 manually.

    It might be helpful if a backtrace from ddb could be obtained (although 
 my recent experience with a 4.0_BETA [not 4.0_BETA2 yet] kernel was unable 
 to get a good backtrace on my own machine).

 > - other misc foo
 >
 > ps won't grok the coredump:
 >
 > arwen$ ps -N netbsd.gdb -M /var/crash/netbsd.0.core
 > ps: can't read proc credentials at 0xfffffc000ade3480: Undefined error: 0

    There's an xps gdb script in src/sys/gdbscripts that is able to display 
 some process information (and could be extended to show more process
 details).

 --
 Michael L. Hitch			mhitch@montana.edu
 Computer Consultant
 Information Technology Center
 Montana State University	Bozeman, MT	USA

From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: gnats-bugs@NetBSD.org
Cc: port-alpha-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, agrier@poofygoof.com
Subject: Re: port-alpha/35448: memory management fault trap during heavy
 network I/O
Date: Mon, 29 Jan 2007 11:09:01 -0700 (MST)

 On Mon, 22 Jan 2007, Michael L. Hitch wrote:

 > fails, so it's a little hard to figure out where it came from.  I'm going
 > to start groveling through the stack myself to see if I can dig out the
 > parameters to the in4_cksum() call, and if I can follow the traceback
 > manually.

    OK, I've dug out more information from the raw stack dump.  I located 
 the address of the mbuf and found that it has the same bad address in 
 mh_data:

 (gdb) print (struct mbuf)*0xfffffc000ef7be18
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 $2 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0,
      mh_data = 0xfffffe0108266000 <Address 0xfffffe0108266000 out of 
 bounds>,
      mh_owner = 0x4e4f5a414d412d58, mh_len = 4096, mh_flags = 67108865,
      mh_paddr = 251117080, mh_type = 1}, M_dat = {MH = {MH_pkthdr = {
          rcvif = 0xfffffe000005a080, tags = {slh_first = 0x0}, len = 188,
          csum_flags = 0, csum_data = 0, segsz = 0}, MH_dat = {MH_ext = {
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
 can not access 0x8266000, invalid translation (invalid L2 PTE)
            ext_buf = 0xfffffe0108266000 <Address 0xfffffe0108266000 out of 
 bounds>, ext_fr$
            ext_arg = 0xfffffe000c617cb8, ext_size = 4096,
            ext_type = 0xfffffc0000a62558, ext_nextref = 0xfffffc000ef7b118,
            ext_prevref = 0xfffffc000ef7a218, ext_un = {
              extun_paddr = 14733978372531027968, extun_pgs = {

    On a whim, I took a look at the data located at 0xfffffe0008266000 and 
 found what looks like data that might be expected, and Aaron confirmed 
 that the data was part of a mailbox file that was being synched.  So it 
 looked like something had corrupted the address used by the mbuf.  I 
 followed the stack back to nfs_writerpc, which can use the address of data 
 being sent as the external data address for the mbuf.  I dug out the 
 address of the uio and iovec structures used at that point and found:

 (gdb) print (struct uio)*0xfffffe000c617e70
 $8 = {uio_iov = 0xfffffe000c617e60, uio_iovcnt = 1, uio_offset = 102400,
    uio_resid = 18446744069414588416, uio_rw = UIO_WRITE,
    uio_vmspace = 0xfffffc0000abc018}
 (gdb) print (struct iovec)*0xfffffe000c617e60
 $9 = {iov_base = 0xfffffe0108267000, iov_len = 18446744069414588416}
 (gdb) x/2gx 0xfffffe000c617e60
 0xfffffe000c617e60:     0xfffffe0108267000      0xffffffff00001000

    The buffer address in iov_base is corrupt as well.  In addition, the 
 iov_len field appears corrupted.

    Following the stack back further, I get to nfs_doio and get the address 
 of the struct buf that was used to generate the uio/iovec data:

 (gdb) print (struct buf)*0xfffffc00052b8dc0
 $3 = {b_u = {u_actq = {tqe_next = 0xdeadbeef, tqe_prev = 
 0xfffffc00052b88b8},
      u_work = {wk_entry = {sqe_next = 0xdeadbeef}}}, b_interlock = {
      lock_data = 86745072}, b_flags = 85, b_error = 0, b_prio = 0,
    b_bufsize = 8192, b_bcount = 8192, b_resid = 8192, b_dev = 4294967295,
    b_un = {
      b_addr = 0xfffffe0008266000 "ntent-Transfer-Encoding:Message-ID;\n 
 b=T2nY8PninSOLy9W$
    b_iodone = 0xfffffc00005bd600 <uvm_aio_biodone>,
    b_proc = 0xfffffc0000abc4a0, b_vp = 0xfffffc000bea53c0, b_dep = {
      lh_first = 0x0}, b_saveaddr = 0x0, b_fspriv = {
      bf_private = 0xfffffc00052b95a8, bf_dcookie = -4397959768664}, b_hash 
 = {
      le_next = 0x16, le_prev = 0x0}, b_vnbufs = {le_next = 0x87654321,
      le_prev = 0x4}, b_freelist = {tqe_next = 0x0,
      tqe_prev = 0xfffffe0000263700}, b_lblkno = 0, b_freelistindex = 0}

    Lo and behold, it has the correct address of the data!  So somwhere 
 between nfs_doio() and nfs_writeprc(), the iov_base and iov_len values
 get clobbered (in an apparently fairly consistant way).

    Since the bad address was easy to check for, I inserted a number of 
 KASSERT() statements in nfs_doio(), nfs_doio_write, and nfs_writerpc().
 I was able to induce this failure on my own alpha at this point.  I found 
 that the address was good at the entry of nfs_writerpc(), but had been 
 corrupted at the start of the loop sending out the data.  This seemed odd,
 since there didn't appear to be anything that would cause the type of 
 corruption I was seeing.  While trying to figure out where some of the
 local variables in nfs_writerpc() were located on the stack, I noticed 
 there was a 'retry:' label before the output loop.  Finding where that 
 label was used shed some light on things.  Certain conditions (which I'm 
 not too clear on, since I don't understand NFS all that well) would cause 
 a resend of the entire data buffer, and if that clobbered the data address 
 and length, would result in what I was seeing.  Indeed, that was the case;
 a few more KASSERT() statements showed that the UIO_ADVANCE() at line 1547 
 of nfs_vnops.c was clobbering the iovec data.

    Closer examinination of what UIO_ADVANCE() was doing, and examination of 
 the generated code show what the problem was.

    The alpha has 64 bit pointers, and the iov_len values was also 64 bits. 
 The variable backup used to adjust the iovec data is an unsigned 32 bit 
 value.  The changes for version 1.225 appear to have intruduced a problem 
 that only showed up on the alpha.  Prior to that, the unsigned value of 
 'backup' was being subtracted from iov_base, and added to iov_len.  In 
 version 1.225, that was changed to use the macro UIO_ADVANCE() and passing 
 a negated value of 'backup' to the macro.  The compiler thus negated the 
 32 bit unsigned value of 'backup' and zero-extended the result to 64 bits 
 which was added to iov_base, and subtracted fro iov_len. resulting in the 
 clobbered values.

    Changing the UIO_ADVANCE() to a UIO_RETREAT() which passed 'backup' 
 directly and subtracted that from iov_base, and added it to iov_len gave 
 me a kernel which did not crash when nfs_writerpc() resent the data.  I've 
 also just verified that simply making 'backup' a signed 32 bit also works 
 using the UIO_ADVANCE() macro.

 ---
 Michael L. Hitch			mhitch@montana.edu
 Computer Consultant
 Information Technology Center
 Montana State University	Bozeman, MT	USA

Responsible-Changed-From-To: port-alpha-maintainer->mhitch
Responsible-Changed-By: mhitch@netbsd.org
Responsible-Changed-When: Mon, 29 Jan 2007 18:33:38 +0000
Responsible-Changed-Why:
I've analyzed it, so I'll take it.


State-Changed-From-To: open->analyzed
State-Changed-By: mhitch@netbsd.org
State-Changed-When: Mon, 29 Jan 2007 18:33:38 +0000
State-Changed-Why:
I've analyzed the problem.


From: Christian Biere <christianbiere@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-alpha/35448: memory management fault trap during heavy network I/O
Date: Thu, 1 Feb 2007 03:37:52 +0100

 Michael L. Hitch wrote:
 >     Changing the UIO_ADVANCE() to a UIO_RETREAT() which passed 'backup' 
 >  directly and subtracted that from iov_base, and added it to iov_len gave 
 >  me a kernel which did not crash when nfs_writerpc() resent the data.  I've 
 >  also just verified that simply making 'backup' a signed 32 bit also works 
 >  using the UIO_ADVANCE() macro.

 I'd prefer the former because it's cleaner. I take "advance" as a strong
 emphasis that it's meant to move forward. At least I've written a similar
 function before and decided against the more flexible term "add" for
 exactly this reason.


 --- sys/nfs/nfs_vnops.c.orig	2007-01-26 21:52:50.000000000 +0100
 +++ sys/nfs/nfs_vnops.c	2007-02-01 03:21:00.000000000 +0100
 @@ -251,10 +251,22 @@ extern const nfstype nfsv3_type[9];

  int nfs_numasync = 0;
  #define	DIRHDSIZ	_DIRENT_NAMEOFF(dp)
 -#define UIO_ADVANCE(uio, siz) \
 -    (void)((uio)->uio_resid -= (siz), \
 -    (uio)->uio_iov->iov_base = (char *)(uio)->uio_iov->iov_base + (siz), \
 -    (uio)->uio_iov->iov_len -= (siz))
 +
 +static __inline void
 +UIO_ADVANCE(struct uio *uio, size_t n)
 +{
 +	uio->uio_resid -= n;
 +	uio->uio_iov->iov_base = (char *)uio->uio_iov->iov_base + n;
 +    	uio->uio_iov->iov_len -= n;
 +}
 +
 +static __inline void
 +UIO_RETREAT(struct uio *uio, size_t n)
 +{
 +	uio->uio_resid += n;
 +	uio->uio_iov->iov_base = (char *)uio->uio_iov->iov_base - n;
 +    	uio->uio_iov->iov_len += n;
 +}

  static void nfs_cache_enter(struct vnode *, struct vnode *,
      struct componentname *);
 @@ -1420,7 +1432,7 @@ retry:
  					break;
  				} else if (rlen < len) {
  					backup = len - rlen;
 -					UIO_ADVANCE(uiop, -backup);
 +					UIO_RETREAT(uiop, backup);
  					uiop->uio_offset -= backup;
  					len = rlen;
  				}
 @@ -1482,7 +1494,7 @@ retry:
  				 * then, we should resend them to nfsd.
  				 */
  				backup = origresid - tsiz;
 -				UIO_ADVANCE(uiop, -backup);
 +				UIO_RETREAT(uiop, backup);
  				uiop->uio_offset -= backup;
  				tsiz = origresid;
  				goto retry;

From: "Aaron J. Grier" <agrier@poofygoof.com>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-alpha/35448: memory management fault trap during heavy network I/O
Date: Mon, 26 Mar 2007 22:43:52 -0700

 a modified version of the provided patch has kept my 1000A from
 panicing, and this PR can be closed.

 I'm now back where I started with netbsd-2, with NFS service
 dissapearing during the weekly cron, with no apparent retransmissions or
 recovery, but that's a different PR.

 hooray?

 -- 
   Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com
               "silly brewer, saaz are for pils!"  --  virt

From: "Aaron J. Grier" <agrier@poofygoof.com>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-alpha/35448
Date: Sun, 16 Dec 2012 16:28:08 -0800

 flogging a dead horse here, but figured it was time for an update.

 the RETREAT / ADVANCE patch in this PR definitely helped me with stability,
 although this problem itself may be alpha-specific.

 the underlying problem (which exacerbated this problem) was traced to a
 duplex mismatch in my network, heavily exercising the NFS retransmit
 code.  :)  it has since been addressed, and the system in question (with
 the patch above) has been running stably under constant low-level use.

  4:20PM  up 623 days, 23:26, 14 users, load averages: 0.05, 0.04, 0.00

 the only idea I have for flushing out further bugs with the NFS
 retransmit code would be pounding on a UDP mount over a lossy link, IE
 purposely set mismatched duplex, crappy hub or switch, or a packet loss
 simulator.

 since this patch does no harm and improves at least alpha, could it be
 applied to current and pulled-up to NetBSD-6?

From: "Michael L. Hitch" <mhitch@lightning.msu.montana.edu>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-alpha/35448
Date: Tue, 18 Dec 2012 08:54:58 -0700 (MST)

 On Mon, 17 Dec 2012, Aaron J. Grier wrote:

 > flogging a dead horse here, but figured it was time for an update.
 >
 > the RETREAT / ADVANCE patch in this PR definitely helped me with stability,
 > although this problem itself may be alpha-specific.

    As I remember, it only showed up with the alpha gcc, but did not seem to 
 be there for amd64 (I can't remember if I tried to check the sparc64 code 
 or not).

    I think the discussion about this change had someone not liking the 
 RETREAT/ADVANCE patch (or names) I had at the time.  I had thought about a 
 patch using a different macro name (ADJUSTUIO or something similar) so 
 that there was a single macro that would indicate the adjustment could go 
 either direction.  I've been a bit (!) negligent on following up on this.

 > the only idea I have for flushing out further bugs with the NFS
 > retransmit code would be pounding on a UDP mount over a lossy link, IE
 > purposely set mismatched duplex, crappy hub or switch, or a packet loss
 > simulator.

    I think (but it has been some time) I was able to replicate the problem 
 with just a cross-over link between my two CS20 machines.  Only one of 
 them is running at this time, so I'm not sure how easily I could 
 replicate it now.  Maybe that would be a good opportunity to power up my 
 1000A and update it.

 > since this patch does no harm and improves at least alpha, could it be
 > applied to current and pulled-up to NetBSD-6?

    I think NetBSD-6 has a newer version of gcc since then, and I would want 
 to verify that the patch is still needed before commiting anything.

 Mike


 --
 Michael L. Hitch			mhitch@montana.edu
 Computer Consultant
 Information Technology Center
 Montana State University	Bozeman, MT	USA

>Unformatted:


 sources CVSed 2007-01-18

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.