Re: 5.4 amd64 - Poor disk performance with Smart Array 6404

2013-12-09 Thread Kenneth R Westerback
On Mon, Dec 09, 2013 at 07:24:19PM -0500, Adam Jensen wrote: > I recently (last night) installed OpenBSD-5.4-amd64 on an > HP-Proliant ML370-G4 that has a Smart Array 6404 controller card in > a 64-bit, 133-MHz PCI-X slot. It has two Ultra320 SCSI channels and > 192MB of RAM cache. One SCSI channel

Re: handle < 1970 timestamps in tar

2013-12-09 Thread Philip Guenther
On Mon, Dec 9, 2013 at 12:57 PM, Philip Guenther wrote: > On Mon, Dec 9, 2013 at 12:10 PM, Miod Vallat wrote: >> Since the switch to 64-bit time_t, our tar(1) can not archive files >> which timestamp are before 1970. >> >> Assuming these files: >> $ ls -l *gz >> -rw-r--r-- 1 miod dmg 34827 Ju

Re: handle < 1970 timestamps in tar

2013-12-09 Thread Philip Guenther
On Mon, Dec 9, 2013 at 12:10 PM, Miod Vallat wrote: > Since the switch to 64-bit time_t, our tar(1) can not archive files > which timestamp are before 1970. > > Assuming these files: > $ ls -l *gz > -rw-r--r-- 1 miod dmg 34827 Jul 1 1904 comandr.mod.gz > -rw-r--r-- 1 miod dmg 119280 Dec

Re: dhclient support for /32 assignments

2013-12-09 Thread Matthew Dempsky
On Tue, Dec 3, 2013 at 4:15 PM, Matthew Dempsky wrote: > The patch below extends dhclient to mimic this logic from ISC DHCP's > linux script: > > if [ "x$new_subnet_mask" = "x255.255.255.255" ] ; then > route add -host $router dev $interface > fi > route add defau

lpd: remove printcap fc, fs, xc, xs capabilities

2013-12-09 Thread Christian Weisgerber
Bad news: That serial printer you hooked up 30 years ago, with magic numbers in a printcap file you haven't changed since, well, that configuration might stop working. This diff removes the printcap fc, fs, xc, xs capabilities from lpd. They allowed configuring a tty with magic numbers that were

handle < 1970 timestamps in tar

2013-12-09 Thread Miod Vallat
Since the switch to 64-bit time_t, our tar(1) can not archive files which timestamp are before 1970. Assuming these files: $ ls -l *gz -rw-r--r-- 1 miod dmg 34827 Jul 1 1904 comandr.mod.gz -rw-r--r-- 1 miod dmg 119280 Dec 3 1969 gbusa.mod.gz tar will fail to archive them: $ tar cf - *g

Re: PATCH: Allow shared semaphores to be really shared

2013-12-09 Thread Ted Unangst
On Mon, Dec 09, 2013 at 19:49, Vadim Zhukov wrote: > So what's the decision? > > Are there any objections still? If not, can I have a pair of okays? > KDE4 really needs a decision to be made: people already had apps > crashing without this diff, so I've put a dirty hack to stop KDE using > of proc

Re: TIMEOUT_INITIALIZER() for src/sys/dev.c to avoid timeout_initialized()

2013-12-09 Thread Theo de Raadt
> On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote: > > this is a demonstration of using TIMEOUT_INITIALIZED(). > > > > because we know the timeout is always set up correctly, we dont > > have to test for it all over the place. > > > > [a bit of snipping...] > > > - if (timeout_in

Re: PATCH: Allow shared semaphores to be really shared

2013-12-09 Thread Vadim Zhukov
2013/12/8 Philip Guenther : > On Sat, Dec 7, 2013 at 10:35 AM, Ted Unangst wrote: >> One of the hallmarks of the original libpthread was that all data >> structures were opaque, and hidden via pointers. That in turn made it >> possible to write a binary compatible librthread. I never would have >>

Re: inteldrm diff

2013-12-09 Thread janis
> Thanks to Stefan Wollny, I now have a GM45-based system. It seems to > work quite well. I'm still trying to figure out the (minor) screen > corruption that happens in gnome, but after the latest set of changes > I've not been able to make it hang in anyway. > > So that means the only generation

Re: TIMEOUT_INITIALIZER() for src/sys/dev.c to avoid timeout_initialized()

2013-12-09 Thread Bret Lambert
On Mon, Dec 09, 2013 at 10:18:06PM +1000, David Gwynne wrote: > > On 9 Dec 2013, at 10:01 pm, David Gwynne wrote: > > > > > On 9 Dec 2013, at 6:59 pm, Bret Lambert wrote: > > > >> On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote: > >>> this is a demonstration of using TIMEOUT_INIT

Re: TIMEOUT_INITIALIZER() for src/sys/dev.c to avoid timeout_initialized()

2013-12-09 Thread David Gwynne
On 9 Dec 2013, at 10:01 pm, David Gwynne wrote: > > On 9 Dec 2013, at 6:59 pm, Bret Lambert wrote: > >> On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote: >>> this is a demonstration of using TIMEOUT_INITIALIZED(). >>> >>> because we know the timeout is always set up correctly, we

Re: TIMEOUT_INITIALIZER() for src/sys/dev.c to avoid timeout_initialized()

2013-12-09 Thread David Gwynne
On 9 Dec 2013, at 6:59 pm, Bret Lambert wrote: > On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote: >> this is a demonstration of using TIMEOUT_INITIALIZED(). >> >> because we know the timeout is always set up correctly, we dont >> have to test for it all over the place. >> > > [a

timeout_pending is not the best

2013-12-09 Thread David Gwynne
timeout_pending followed by timeot_del is pointless, as timeout_del effectively does the pending check itself. now that timeout_del returns whether the timeout was actually removed, you can make decisions based on that rather than race with timeout_pending checking timeout_pending shortly after y

Re: TIMEOUT_INITIALIZER() for src/sys/dev.c to avoid timeout_initialized()

2013-12-09 Thread Bret Lambert
On Mon, Dec 09, 2013 at 01:55:53PM +1000, David Gwynne wrote: > this is a demonstration of using TIMEOUT_INITIALIZED(). > > because we know the timeout is always set up correctly, we dont > have to test for it all over the place. > [a bit of snipping...] > - if (timeout_initialized(&rnd_tim