On Thu, 2009-07-30 at 17:37 -0600, Theo de Raadt wrote:
> Follow the flow of the code:
>
> again:
> ...
>
> if (cookies) {
> free((caddr_t)cookies, M_TEMP);
> cookies = NULL;
> }
>
> A kernel double free. I doubt it.
>
Holy shit that was
> >From NetBSD.
>
> Index: nfs_serv.c
> ===
> RCS file: /cvs/src/sys/nfs/nfs_serv.c,v
> retrieving revision 1.77
> diff -u -p -r1.77 nfs_serv.c
> --- nfs_serv.c20 Jul 2009 16:49:40 - 1.77
> +++ nfs_serv.c30 Ju
>From NetBSD.
Index: nfs_serv.c
===
RCS file: /cvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.77
diff -u -p -r1.77 nfs_serv.c
--- nfs_serv.c 20 Jul 2009 16:49:40 - 1.77
+++ nfs_serv.c 30 Jul 2009 23:11:33 -
@@ -2489
This diff changes the configuration format of the split-horizon option
of ripd. This involves no behavior change, only configuration.
The old way was to give choice among three possible variants:
split-horizon default
split-horizon poisoned
split-horizon none
And the default behavior was "split-hor
ok?
Index: filter.c
===
RCS file: /cvs/src/libexec/tftp-proxy/filter.c,v
retrieving revision 1.2
diff -u -p -r1.2 filter.c
--- filter.c23 Jun 2007 15:51:21 - 1.2
+++ filter.c30 Jul 2009 19:47:45 -
@@ -78,40 +78,6
hmm, on Thu, Jul 30, 2009 at 11:05:14AM -0500, Marco Peereboom said that
> But is that an interrupt issue or does the disk simply suck?
the interrupt issues i reported about this machine are gone (atm).
interrupts in top showed normal level as far as i can tell.
this disk is of course the highest
But is that an interrupt issue or does the disk simply suck?
On Thu, Jul 30, 2009 at 05:27:25PM +0200, frantisek holop wrote:
> hmm, on Thu, Jul 30, 2009 at 09:25:49AM -0500, Marco Peereboom said that
> > Performance ok/better with the fancy pci routing tables enabled?
>
> hard to say as the disk
hmm, on Thu, Jul 30, 2009 at 09:25:49AM -0500, Marco Peereboom said that
> Performance ok/better with the fancy pci routing tables enabled?
hard to say as the disk is pig slow. feels like the 486 times..
> > pciide1 at pci0 dev 9 function 0 "NVIDIA MCP77 AHCI" rev 0xa2: DMA
> > (unsupported), c
this changes output from
15:48:38.877024 10.15.5.75.53496 > 10.15.5.2.69: 28 ERROR EUNDEF Interrupted
system call"
to
15:48:38.877024 10.15.5.75.53496 > 10.15.5.2.69: 28 ERROR EUNDEF "Interrupted
system call"
ok?
Index: print-tftp.c
===
Performance ok/better with the fancy pci routing tables enabled?
On Thu, Jul 30, 2009 at 03:52:05PM +0200, frantisek holop wrote:
> hmm, on Wed, Jul 29, 2009 at 08:50:14PM -0500, Marco Peereboom said that
> > did you try disabling acpicpu only?
>
> i have tried this and here is the dmesg:
> (it i
hmm, on Wed, Jul 29, 2009 at 08:50:14PM -0500, Marco Peereboom said that
> did you try disabling acpicpu only?
i have tried this and here is the dmesg:
(it is also accessible under obiit.org/f/dmesg.bsd.sp.acpi)
OpenBSD 4.6-current (GENERIC) #85: Mon Jul 27 19:10:16 MDT 2009
dera...@i386.open
OK, thanks for the explanation.
It wasn't obvious from just reading the diff.
Damien
| On Thursday 30 July 2009 05:12:50 damien.bergam...@free.fr wrote:
| > Except "rewriting parts of the code", what does this diff do?
| > Does it fix an existing bug?
| > Or is it just rewriting for the sake of
Here is a diff to add support for the IC Plus IP1001 GigE PHY.
>From FreeBSD
Tested by jasper@ with a IP1000A PHY to make sure I didn't break anything.
Index: ipgphy.c
===
RCS file: /cvs/src/sys/dev/mii/ipgphy.c,v
retrieving revisi
On Thursday 30 July 2009 05:12:50 damien.bergam...@free.fr wrote:
> Except "rewriting parts of the code", what does this diff do?
> Does it fix an existing bug?
> Or is it just rewriting for the sake of rewriting?
The current ALLMULTI flag handling is a bug.
Drivers should now be checking ac->ac_
Except "rewriting parts of the code", what does this diff do?
Does it fix an existing bug?
Or is it just rewriting for the sake of rewriting?
Damien
| The following diff rewrites parts of the code for promiscuous mode
| and multicast handling for the nfe(4) driver. Please test promisc
| mode and
The following diff rewrites parts of the code for promiscuous mode
and multicast handling for the nfe(4) driver. Please test promisc
mode and multicast mode of operation with any nfe(4) adapters.
Please provide a dmesg.
Index: if_nfe.c
16 matches
Mail list logo