Thor Lancelot Simon wrote:
I'm trying to make secmodel_overlay work in my netbsd-5 tree. It appears
to have never been adapted when secmodel_securelevel was split out of
secmodel_bsd44.
At some point I think I had a different idea about how to implement what
"overlay" was supposed to do, so it
Andrew Doran wrote:
> > This is concerning. As mentioned, bufio_cache is interrupt safe (marked
> > with IPL_BIO) and locks at pool_cache(9) layer, also deeper layers e.g.
> > UVM kva-cache, should use spin-locks at IPL_VM.
> >
> > There is one possibly related mysterious backtrace - PR/42611.
Masao Uebayashi wrote:
On Fri, Apr 9, 2010 at 1:16 AM, Thor Lancelot Simon wrote:
I just confused myself considerably because this config file fragment
didn't work:
no options SECMODEL_BSD44
options SECMODEL_OVERLAY
It turns out these kernel options (in sys/conf/std) have *lower
Thor Lancelot Simon wrote:
According to kauth(9):
Listeners might sleep, so no locks can be held when calling
an authorization wrapper.
According to uipc_socket.c:sobind():
solock(so);
error = (*so->so_proto->pr_usrreq)(so, PRU_BIND, NULL, na
According to kauth(9):
Listeners might sleep, so no locks can be held when calling
an authorization wrapper.
According to uipc_socket.c:sobind():
solock(so);
error = (*so->so_proto->pr_usrreq)(so, PRU_BIND, NULL, nam,
NULL
> Especially since the errors were preceeded by scsi allocation errors
> from the scsi controller.
I was told that "cannot allocate scsipi_xfer" was a mostly harmless temporary
memory starvation inside the kernel's SCSI system.
s...@cirr.com said:
> Unfortunately this older version of installboot does not support the
> "ioaddr" option. If I'm running into the weird problem you state, is
> there another work around?
If you can compile a bootloader from sources, you can set the address
using a CONSADDR definition. See
Hello. It's possible the problem is not memory. It could be one of
the controller chips as well. Especially since the errors were preceeded
by scsi allocation errors from the scsi controller. Unfortunately, such
errors can be hard to diagnose.
-Brian
On Apr 8, 6:57pm, Edgar =?iso-8859
jo...@britannica.bec.de said:
> The SoC project is about avoiding the system call overhead. It is not
> about a minor micro optimisation in the kernel. So please just go on.
...but read the thread starting at
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-March/028066.html
before
best r
> If it's been runing solidly for a while,
More or less, yes. At least, that's the first panic of that kind I've seen.
> I'd be suspicious of the hardware.
I'm unsure about that. At least, it's ECC memory.
> Especially if you've not made any changes recently.
No.
Hello. If it's been runing solidly for a while, I'd be suspicious of
the hardware. Especially if you've not made any changes recently.
-thanks
-Brian
I'm trying to make secmodel_overlay work in my netbsd-5 tree. It appears
to have never been adapted when secmodel_securelevel was split out of
secmodel_bsd44.
I cannot understand how secmodel_bsd44 arranges that secmodel_securelevel
will not see requests unless secmodel_bsd44 arranges to pass the
On Fri, Apr 9, 2010 at 1:16 AM, Thor Lancelot Simon wrote:
> I just confused myself considerably because this config file fragment
> didn't work:
>
> no options SECMODEL_BSD44
> options SECMODEL_OVERLAY
>
> It turns out these kernel options (in sys/conf/std) have *lowercase* names.
>
I just confused myself considerably because this config file fragment
didn't work:
no options SECMODEL_BSD44
options SECMODEL_OVERLAY
It turns out these kernel options (in sys/conf/std) have *lowercase* names.
Why? Shouldn't I change them?
--
Thor Lancelot Simon
On Thursday 08 April 2010 15:48:47 David Young wrote:
> On Thu, Apr 08, 2010 at 09:15:38AM +0200, Hans Petter Selasky wrote:
> > On Thursday 08 April 2010 02:10:28 David Young wrote:
> > > I would like for MI drivers to be able to override pci(9),
> > > bus_space(9), and bus_dma(9) behavior for the
On Thu, Apr 08, 2010 at 09:15:38AM +0200, Hans Petter Selasky wrote:
> On Thursday 08 April 2010 02:10:28 David Young wrote:
> > I would like for MI drivers to be able to override pci(9), bus_space(9),
> > and bus_dma(9) behavior for the purpose of handling exceptions, managing
> > bus resources, c
On Wed, Apr 07, 2010 at 04:00:36PM -0700, B Harder wrote:
>
> Hi Sverre -- I am interested... I've actually already got the 6000-4
> firmware, got the pcidevs setup, and worked w/ the existing driver
> code to get the device attached... at this point, it's failing w/
> eeprom errors (two of them,
On Wed, Apr 07, 2010 at 08:30:00PM -0600, Sverre Froyen wrote:
> > If you want memory you can DMA to/from, I think you need to use
> > bus_dmamem_alloc().
>
> Yes, reading the man page for bus_dmamap_load etc. I see that is required. Is
> this a requirement for NetBSD but not for OpenBSD? Look at
On Thu, Apr 08, 2010 at 07:16:10AM +1000, matthew green wrote:
>
>On Thu, Apr 01, 2010 at 09:52:07AM +0200, Nicolas Joly wrote:
>[...]
>> The attached patch introduce a new function clock_getres1() function
>> which has most of the corresponding syscall logic except for the
>>
On our 4.0/amd64 file server, I got several sdn(..): unable to allocate
scsipi_xfer followed some 20 minutes later by a panic: lockmgr: non-zero
exclusive count.
I managed to take a dump.
Where to go from here?
On Thursday 08 April 2010 02:10:28 David Young wrote:
> I would like for MI drivers to be able to override pci(9), bus_space(9),
> and bus_dma(9) behavior for the purpose of handling exceptions, managing
> bus resources, creating test harnesses, and counting events.
>
> Matt Thomas nudged me in so
On Thu Apr 08 2010 at 02:35:28 +0100, Jasper Wallace wrote:
>
> Hi,
>
> I'm trying to debug a problem with netbsd and a usb cdc acm device using
> rump and in the process I can only get rump to attach to ugen0. I can work
> around this by nailing down ugen0 to a particular usb port in my kernel
22 matches
Mail list logo
