daily CVS update output

[NetBSD source update]

Updating src tree:
P src/distrib/sets/lists/comp/mi
P src/lib/libc/string/strcasecmp.3
P src/lib/libc/sys/fork.2
P src/sbin/chown/chown.8
P src/share/man/man7/signal.7
P src/share/man/man9/Makefile
P src/share/man/man9/pci.9
P src/share/man/man9/pci_intr.9
P src/share/man/man9/pci_msi.9
P src/sys/arch/arc/arc/bus_space_sparse.c
P src/sys/arch/arc/include/param.h
P src/sys/arch/arm/arm32/pmap.c
P src/sys/arch/arm/marvell/pci_machdep.c
U src/sys/arch/evbarm/conf/KURONAS_X4
P src/sys/arch/evbarm/conf/README.evbarm
P src/sys/arch/evbarm/conf/VTC100
P src/sys/arch/mips/atheros/dev/ehci_arbus.c
P src/sys/arch/mips/cavium/octeon_intr.c
P src/sys/arch/mips/cavium/dev/octeon_dwctwo.c
P src/sys/arch/mips/include/cache_r4k.h
P src/sys/arch/mips/mips/bus_space_alignstride_chipdep.c
P src/sys/arch/mips/mips/mipsX_subr.S
cvs update: `src/sys/arch/mips/mips/pmap_segtab.c' is no longer in the 
repository
cvs update: `src/sys/arch/mips/mips/pmap_tlb.c' is no longer in the repository
P src/sys/dev/acpi/acpi_mcfg.c
P src/sys/dev/ic/rt2860.c
P src/sys/dev/microcode/ral/microcode.h
U src/sys/dev/microcode/ral/ral-license
U src/sys/dev/microcode/ral/ral-rt2860
U src/sys/dev/microcode/ral/ral-rt2870
U src/sys/dev/microcode/ral/ral-rt3070
U src/sys/dev/microcode/ral/ral-rt3071
U src/sys/dev/microcode/ral/ral-rt3090
U src/sys/dev/microcode/ral/ral-rt3290
U src/sys/dev/microcode/ral/ral-rt73
P src/sys/uvm/pmap/pmap_tlb.c

Updating xsrc tree:


Killing core files:

Running the SUP scanner:
SUP Scan for current starting at Wed Jul 13 03:01:40 2016
SUP Scan for current completed at Wed Jul 13 03:01:58 2016
SUP Scan for mirror starting at Wed Jul 13 03:01:58 2016
SUP Scan for mirror completed at Wed Jul 13 03:04:50 2016



Updating release-6 src tree (netbsd-6):

Updating release-6 xsrc tree (netbsd-6):

Running the SUP scanner:
SUP Scan for release-6 starting at Wed Jul 13 03:07:15 2016
SUP Scan for release-6 completed at Wed Jul 13 03:07:25 2016



Updating release-7 src tree (netbsd-7):
U doc/CHANGES-7.1
P sys/arch/evbmips/loongson/yeeloong_machdep.c
P sys/dev/pci/lynxfb.c

Updating release-7 xsrc tree (netbsd-7):
P external/mit/xf86-video-siliconmotion/dist/src/smi_driver.c
P external/mit/xorg-server/dist/hw/xfree86/vgahw/vgaHW.h

Running the SUP scanner:
SUP Scan for release-7 starting at Wed Jul 13 03:09:40 2016
SUP Scan for release-7 completed at Wed Jul 13 03:09:47 2016




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  54074016 Jul 13 03:11 ls-lRA.gz

Re: ahcisata and WDCTL_RST

[John Nemeth]

On Jul 12,  9:38pm, John Klos wrote:
} 
} I have an older MSi MS-7511 motherboard (it just happens to be the one 
} that the NetBSD Foundation gave to certain developers). It has run fine 
} for years, but with NetBSD-7 and -current, ahcisata will only recognize 
} SATA drives every tenth boot or so. There's no discernible pattern:
} 
} ahcisata0 at pci0 dev 9 function 0: vendor 0x10de product 0x0ad0 (rev. 0xa2)
} LSA0: Picked IRQ 21 with weight 1
} ahcisata0: interrupting at ioapic0 pin 21
} ahcisata0: 64-bit DMA
} ahcisata0: ignoring broken port multiplier support
} ahcisata0: AHCI revision 1.20, 6 ports, 32 slots, CAP 
0xe3209f05
} atabus0 at ahcisata0 channel 0

[trimming essentially duplicate lines]

} ...
} ahcisata0 port 1: device present, speed: 3.0Gb/s
} ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0
} 
} 
} With NetBSD 7.0.1 installation kernel, I get the same as above but:
} 
} ahcisata0 port 3: device present, speed: 3.0Gb/s
} atabus0: Unrecognized signature 0x0001 on port 0. Assuming it's a disk.

 [haven't seen this before]

} wd0 at atabus0 drive 0
} wd0: 
} wd0: drive supports 16-sector PIO transfers, LBA48 addressing
} wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
} wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
} wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 
(Ultra/133) (using DMA)
} ... (and other three disks)
} 
} However, booting a NetBSD 6.1.5 kernel, all drives are recognized and are 
} usable with no problems at all. The only difference is that the "ignoring 
} broken port multiplier support" message isn't reported by the 6.1.5 
} kernel.
} 
} While trying to figure out what was wrong, I tried completely different 
} drives, different SATA cables, a different power supply, et cetera, and 
} nothing mattered except changing the kernel.
} 
} Does anyone have ideas about what may've broken this?

 I don't know what it is happening, but it does appear to be
related to PRs 49448 and/or 50030.

}-- End of excerpt from John Klos

ahcisata and WDCTL_RST

[John Klos]

Hi,

I have an older MSi MS-7511 motherboard (it just happens to be the one 
that the NetBSD Foundation gave to certain developers). It has run fine 
for years, but with NetBSD-7 and -current, ahcisata will only recognize 
SATA drives every tenth boot or so. There's no discernible pattern:


ahcisata0 at pci0 dev 9 function 0: vendor 0x10de product 0x0ad0 (rev. 0xa2)
LSA0: Picked IRQ 21 with weight 1
ahcisata0: interrupting at ioapic0 pin 21
ahcisata0: 64-bit DMA
ahcisata0: ignoring broken port multiplier support
ahcisata0: AHCI revision 1.20, 6 ports, 32 slots, CAP 
0xe3209f05
atabus0 at ahcisata0 channel 0
atabus1 at ahcisata0 channel 1
atabus2 at ahcisata0 channel 2
atabus3 at ahcisata0 channel 3
atabus4 at ahcisata0 channel 4
atabus5 at ahcisata0 channel 5
...
ahcisata0 port 1: device present, speed: 3.0Gb/s
ahcisata0 port 2: device present, speed: 3.0Gb/s
ahcisata0 port 0: device present, speed: 3.0Gb/s
ahcisata0 port 3: device present, speed: 3.0Gb/s
ahcisata0 channel 0: clearing WDCTL_RST failed for drive 0
ahcisata0 channel 1: clearing WDCTL_RST failed for drive 0
ahcisata0 channel 2: clearing WDCTL_RST failed for drive 0
ahcisata0 channel 3: clearing WDCTL_RST failed for drive 0


With NetBSD 7.0.1 installation kernel, I get the same as above but:

ahcisata0 port 3: device present, speed: 3.0Gb/s
ahcisata0 port 1: device present, speed: 3.0Gb/s
ahcisata0 port 2: device present, speed: 3.0Gb/s
ahcisata0 port 0: device present, speed: 3.0Gb/s
atabus0: Unrecognized signature 0x0001 on port 0. Assuming it's a disk.
atabus3: Unrecognized signature 0x0001 on port 0. Assuming it's a disk.
atabus2: Unrecognized signature 0x0001 on port 0. Assuming it's a disk.
atabus1: Unrecognized signature 0x0001 on port 0. Assuming it's a disk.
wd0 at atabus0 drive 0
wd0: 
wd0: drive supports 16-sector PIO transfers, LBA48 addressing
wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) 
(using DMA)
... (and other three disks)

However, booting a NetBSD 6.1.5 kernel, all drives are recognized and are 
usable with no problems at all. The only difference is that the "ignoring 
broken port multiplier support" message isn't reported by the 6.1.5 
kernel.


While trying to figure out what was wrong, I tried completely different 
drives, different SATA cables, a different power supply, et cetera, and 
nothing mattered except changing the kernel.


Does anyone have ideas about what may've broken this?

Thanks,
John

Re: build failure for pmax

[coypu]

Nick fixed it here.
http://mail-index.netbsd.org/source-changes/2016/07/12/msg076007.html

Re: setrlimit(2) can set stack segement hard limit lower than soft limit ?

[Christos Zoulas]

In article <20160712095447.ga27...@issan.sis.pasteur.fr>,
Nicolas Joly   wrote:
>-=-=-=-=-=-
>
>
>Hi,
>
>Juste encountered a small case where setting stack segement limits
>made the hard limit smaller than the soft one, which seems problematic
>to me. Soft limit should never be larger than hard limit.
>
>The attached sample illustrate this small issue.
>
>njoly@issan [~]> cc -o setrlimit setrlimit.c 
>njoly@issan [~]> ./setrlimit 
>set RLIMIT_STACK: 4192256/4192256
>get RLIMIT_STACK: 4194304/4192256
>
>Cheching the corresponding code in dosetrlimit() show rlim_cur is page
>rounded ... but rlim_max is not :
>
>[...]
> * Since allocation is done in terms of page, roundup
> * "rlim_cur" (otherwise, contiguous regions
> * overlap).  If stack limit is going up make more
> * accessible, if going down make inaccessible.
> */
>limp->rlim_cur = round_page(limp->rlim_cur);
>if (limp->rlim_cur != alimp->rlim_cur) {
>[...]
>
>Do we need to call round_page() on limp->rlim_max too, or should we
>only raise it to limp->rlim_cur if needed ?

I think we should call round_page to it too...

christos

setrlimit(2) can set stack segement hard limit lower than soft limit ?

[Nicolas Joly]

Hi,

Juste encountered a small case where setting stack segement limits
made the hard limit smaller than the soft one, which seems problematic
to me. Soft limit should never be larger than hard limit.

The attached sample illustrate this small issue.

njoly@issan [~]> cc -o setrlimit setrlimit.c 
njoly@issan [~]> ./setrlimit 
set RLIMIT_STACK: 4192256/4192256
get RLIMIT_STACK: 4194304/4192256

Cheching the corresponding code in dosetrlimit() show rlim_cur is page
rounded ... but rlim_max is not :

[...]
 * Since allocation is done in terms of page, roundup
 * "rlim_cur" (otherwise, contiguous regions
 * overlap).  If stack limit is going up make more
 * accessible, if going down make inaccessible.
 */
limp->rlim_cur = round_page(limp->rlim_cur);
if (limp->rlim_cur != alimp->rlim_cur) {
[...]

Do we need to call round_page() on limp->rlim_max too, or should we
only raise it to limp->rlim_cur if needed ?

Thanks.

-- 
Nicolas Joly

Cluster & Computing Group
Biology IT Center
Institut Pasteur, Paris.

#include 

#include 
#include 

int main() {
  int res;
  struct rlimit lim, new;

  lim.rlim_cur = lim.rlim_max = 4192256;
  res = setrlimit(RLIMIT_STACK, );
  assert(res != -1);
  printf("set RLIMIT_STACK: %lu/%lu\n", lim.rlim_cur, lim.rlim_max);
  new.rlim_cur = new.rlim_max = 0;
  res = getrlimit(RLIMIT_STACK, );
  assert(res != -1);
  printf("get RLIMIT_STACK: %lu/%lu\n", new.rlim_cur, new.rlim_max);

  return 0; }

Re: build failure for pmax

[coypu]

I'm able to get around this issue (which is causing most MIPS builds to
fail right now) with the following change:

Index: sys/arch/pmax/conf/INSTALL
===
RCS file: /cvsroot/src/sys/arch/pmax/conf/INSTALL,v
retrieving revision 1.71
diff -u -r1.71 INSTALL
--- sys/arch/pmax/conf/INSTALL  20 Jul 2014 10:06:11 -  1.71
+++ sys/arch/pmax/conf/INSTALL  12 Jul 2016 08:21:55 -
@@ -12,7 +12,7 @@
 
 #options   INCLUDE_CONFIG_FILE # embed config file in kernel binary
 
-makeoptionsCOPTS="-Os -mmemcpy"# Optimise for space. Implies -O2
+#makeoptions   COPTS="-Os -mmemcpy"# Optimise for space. Implies -O2
 
 maxusers   8