Re: CVS commit: src/sys/kern
On Dec 29, 2012, at 10:56 PM, Christos Zoulas chris...@netbsd.org wrote: Always call brelse() on error. Otherwise a possible error from bread() will cause the buffer to stay lock and we end up blocking forever in VOP_CLOSE-spec_close-vinvalbuf-bbysy since the buffer is marked busy but there is no I/O pending. This caused my laptop to hang on boot_findwedge because: findroot: unable to read block 358331527 of dev dk0 (22) Thanks. Just applied the same to breadn(). -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
Re: CVS commit: src/sys/dev/pci
On Sun, 30 Dec 2012 09:45:05 + Michael Lorenz macal...@netbsd.org wrote: Module Name: src Committed By: macallan Date: Sun Dec 30 09:45:05 UTC 2012 Modified Files: src/sys/dev/pci: radeonfb.c radeonfbreg.h Log Message: Add support for R3xx. Whi EFATFINGERS, fixed in the repository. This should also wire up CRTCs, DACs and outputs in a (more) sane way ( and keep track of the way things are set up ) - DVI and VGA outputs should now work properly on all supported cards. I tested this on an iBook G4, XVR-100 and a generic, PCish RV350. have fun Michael
Re: CVS commit: src/sbin/ping
3. Always send ICMP_MINLEN packets; this is what everyone else does. Makes ping -s n where n 8 work. Shouldn't that be an error? Otherwise people will think that something is happening when it isn't. pgpsqNepA4SMC.pgp Description: PGP signature
Re: CVS commit: src/sys/kern
On Dec 30, 10:21am, hann...@eis.cs.tu-bs.de (J. Hannken-Illjes) wrote: -- Subject: Re: CVS commit: src/sys/kern | Thanks. Just applied the same to breadn(). Heh, I missed that! Thanks, christos
Re: CVS commit: src/sbin/ping
On Dec 30, 7:53am, g...@ir.bbn.com (Greg Troxel) wrote: -- Subject: Re: CVS commit: src/sbin/ping | 3. Always send ICMP_MINLEN packets; this is what everyone else does. Makes | ping -s n where n 8 work. | | Shouldn't that be an error? Otherwise people will think that something | is happening when it isn't. Currently we are doing approximately what other ping implementations are doing: ping -s 1 localhost linux: PING localhost (127.0.0.1) 1(29) bytes of data. 9 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 macosx PING localhost (127.0.0.1): 1 data bytes 9 bytes from 127.0.0.1: icmp_seq=0 ttl=64 netbsd-old PING localhost (127.0.0.1): 1 data bytes [no response] netbsd-current PING localhost (127.0.0.1): 1 data bytes 8 bytes from 127.0.0.1: icmp_seq=0 ttl=255 We can change it anyway we want... christos
Re: CVS commit: src/sbin/ping
On Sun, 30 Dec 2012 10:50:07 -0500 chris...@zoulas.com (Christos Zoulas) wrote: netbsd-old PING localhost (127.0.0.1): 1 data bytes [no response] Not that old, though; it has worked in the past: box2$ uname -r 5.1_STABLE box2$ ping -c 1 -s 1 localhost PING localhost (127.0.0.1): 1 data bytes 9 bytes from 127.0.0.1: icmp_seq=0 ttl=255 localhost PING Statistics 1 packets transmitted, 1 packets received, 0.0% packet loss netbsd-current PING localhost (127.0.0.1): 1 data bytes 8 bytes from 127.0.0.1: icmp_seq=0 ttl=255 We can change it anyway we want... christos
Re: CVS commit: src/sbin/ping
In article 20121230173516.ab058f88b94567154810b...@pandora.be, dieter roelants dieter.net...@pandora.be wrote: On Sun, 30 Dec 2012 10:50:07 -0500 chris...@zoulas.com (Christos Zoulas) wrote: netbsd-old PING localhost (127.0.0.1): 1 data bytes [no response] Not that old, though; it has worked in the past: box2$ uname -r 5.1_STABLE box2$ ping -c 1 -s 1 localhost PING localhost (127.0.0.1): 1 data bytes 9 bytes from 127.0.0.1: icmp_seq=0 ttl=255 localhost PING Statistics 1 packets transmitted, 1 packets received, 0.0% packet loss This broke when F_TIMING64 was introduced. christos
Re: CVS commit: src/lib/libutil
On Sun, Dec 30, 2012 at 05:36:00PM +, David A. Holland wrote: Module Name: src Committed By: dholland Date: Sun Dec 30 17:36:00 UTC 2012 Modified Files: src/lib/libutil: efun.c Log Message: If malloc, calloc, or realloc returns NULL when a size of 0 was requested, which is allowed by pertinent standards, honor it instead of bombing. Do not do this for calloc(x, y) where x != 0 y != 0 but x*y == 0; in that case bomb. The commit message is misleading. We expect calloc(x,y) to return NULL if x!=0 y!=0 x*y==0. Joerg
Re: CVS commit: src/external/gpl3/gcc/dist/gcc/config/i386
On Sun, Dec 30, 2012 at 08:16:59PM +, David Laight wrote: Module Name: src Committed By: dsl Date: Sun Dec 30 20:16:59 UTC 2012 Modified Files: src/external/gpl3/gcc/dist/gcc/config/i386: i386.c Log Message: No need to check both TARGET_64BIT and ix86_preferred_stack_boundary = 64, if the former is true the latter is also true. At least in terms of documentation, this is a regression. TARGET_64BIT implies the presence of SSE support and that's somewhat independent of the separate preferred stack boundary Joerg
Re: CVS commit: src/lib/libutil
On Mon, Dec 31, 2012 at 02:59:13AM +0100, Joerg Sonnenberger wrote: Modified Files: src/lib/libutil: efun.c Log Message: If malloc, calloc, or realloc returns NULL when a size of 0 was requested, which is allowed by pertinent standards, honor it instead of bombing. Do not do this for calloc(x, y) where x != 0 y != 0 but x*y == 0; in that case bomb. The commit message is misleading. We expect calloc(x,y) to return NULL if x!=0 y!=0 x*y==0. I don't understand. The logic I added is exactly what I described. -- David A. Holland dholl...@netbsd.org
Re: CVS commit: src/lib/libutil
On Mon, 31 Dec 2012, Joerg Sonnenberger wrote: Log Message: If malloc, calloc, or realloc returns NULL when a size of 0 was requested, which is allowed by pertinent standards, honor it instead of bombing. Do not do this for calloc(x, y) where x != 0 y != 0 but x*y == 0; in that case bomb. The commit message is misleading. We expect calloc(x,y) to return NULL if x!=0 y!=0 x*y==0. (x!=0 y!=0 x*y==0) can be true only if calculating x*y results in what would loosely be called integer overflow; since the types are unsigned, it's a well-defined kind of wraparound, not the undefined kind of overflow. I'd expect an error like EINVAL rather than an error like ENOMEM for this case. --apb (Alan Barrett)
