Re: core's decision on modular kernels
On Wed, 21 Sep 2011, Martin S. Weber wrote: On Wed, Sep 21, 2011 at 07:55:38AM +0200, Alan Barrett wrote: - A port's MONOLITHIC kernel should include features that traditionally would have been present in a non-modular GENERIC kernel, and it may or may not include options MODULAR, at the portmaster's discretion. Huh? Would it be possible please to get a more detailed rationale behind allowing options MODULAR in a MONOLITHIC kernel, if all ports using modules already offer MODULAR and GENERIC? The main difference between MODULAR and MONOLITHIC would be that MONOLITHIC has built-in support for almost everything considered stable and useful, whereas MODULAR might expect to load a lot of modules at run time. MONOLITHIC might still not have absolutely everything built-in, and options MODULAR allows it to load additional modules at run time, if the portmaster decides that this would be useful. I use a MONOLITHIC kernel with options MODULAR to allow loading of a module that contains the root file system as an md(4) image. --apb (Alan Barrett)
Re: core's decision on modular kernels
On Thu, Sep 22, 2011 at 08:09:58AM +0200, Alan Barrett wrote: On Wed, 21 Sep 2011, Martin S. Weber wrote: On Wed, Sep 21, 2011 at 07:55:38AM +0200, Alan Barrett wrote: - A port's MONOLITHIC kernel should include features that traditionally would have been present in a non-modular GENERIC kernel, and it may or may not include options MODULAR, at the portmaster's discretion. Huh? Would it be possible please to get a more detailed rationale behind allowing options MODULAR in a MONOLITHIC kernel, if all ports using modules already offer MODULAR and GENERIC? The main difference between MODULAR and MONOLITHIC would be that MONOLITHIC has built-in support for almost everything considered stable and useful, whereas MODULAR might expect to load a lot of modules at run time. MONOLITHIC might still not have absolutely everything built-in, and options MODULAR allows it to load additional modules at run time, if the portmaster decides that this would be useful. I use a MONOLITHIC kernel with options MODULAR to allow loading of a module that contains the root file system as an md(4) image. What is the difference between MONOLITHIC and MODULAR with 'built-in' modules? And wouldn't the latter be a better aim?? David -- David Laight: da...@l8s.co.uk
Re: dom0 lockdebug panic
On 09/22/11 02:00, Jean-Yves Migeon wrote:
On 21.09.2011 17:47, Christoph Egger wrote:
Hi,
when I boot latest -current dom0 kernel I get this panic:
Mutex error: lockdebug_barrier: spin lock held
lock address : 0xa00023604790 type : spin
initialized : 0x803276c0
shared holds : 0 exclusive: 1
shares wanted: 0 exclusive: 0
current cpu : 0 last held: 0
current lwp : 0xa00025c5b1e0 last held: 0xa00025c5b1e0
last locked* : 0x8032aff4 unlocked : 0x8032b269
owner field : 0x00010600 wait/spin: 0/1
panic: LOCKDEBUG
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 80213515 cs e030 rflags 246 cr2
[snip]
last locked points to sys/dev/pci/if_bnx.c, line 4863.
Hmm, mixing a spin mutex with a workqueue working with an adaptive
one... does no good.
Could you try the patch below please?
Works for me. Thanks for the quick fix. Please commit.
Christoph
Index: sys/dev/pci/if_bnx.c
===
RCS file: /cvsroot/src/sys/dev/pci/if_bnx.c,v
retrieving revision 1.44
diff -u -p -r1.44 if_bnx.c
--- sys/dev/pci/if_bnx.c 15 Jul 2011 11:29:31 - 1.44
+++ sys/dev/pci/if_bnx.c 21 Sep 2011 21:02:32 -
@@ -707,7 +707,7 @@ bnx_attach(device_t parent, device_t sel
/* create workqueue to handle packet allocations */
if (workqueue_create(sc-bnx_wq, device_xname(self),
- bnx_alloc_pkts, sc, PRI_NONE, IPL_NONE, WQ_MPSAFE) != 0) {
+ bnx_alloc_pkts, sc, PRI_NONE, IPL_NET, WQ_MPSAFE) != 0) {
aprint_error_dev(self, failed to create workqueue\n);
goto bnx_attach_fail;
}
Re: core's decision on modular kernels
On Thu, Sep 22, 2011 at 08:53:53AM +0100, David Laight wrote: What is the difference between MONOLITHIC and MODULAR with 'built-in' modules? And wouldn't the latter be a better aim?? I think that by MODULAR with built-in modules, you mean a barebones kernel linked with some .kmod's? I would love to see that. What has to happen to make it so? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 344-0444 x24
wapbl module
It would appear that wapbl is only relevant for ffs file systems (and in particular, only for ffs filesystems with a V2 superblock format). Yet the current modularization of wapbl is not dependant on the ffs module. (wapbl's required-list is empty.) I realize that even though wapbl registers itself as a module, it is not built as a loadable module - ie, it must be built-in. I intend to try to change this, so I would like to know if wapbl is ever intended for non-ffs file systems. FWIW, I also intend to have the ffs code auto-load wapbl whenever it is needed. Thanks in advance for any comments. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: wapbl module
On Thu, Sep 22, 2011 at 08:24:48AM -0700, Paul Goyette wrote: I realize that even though wapbl registers itself as a module, it is not built as a loadable module - ie, it must be built-in. I intend to try to change this, so I would like to know if wapbl is ever intended for non-ffs file systems. The WAPBL option changes the buffer subsystem, that's why it can't easily be modularized. Joerg
Re: wapbl module
On Thu, 22 Sep 2011, Joerg Sonnenberger wrote: On Thu, Sep 22, 2011 at 08:24:48AM -0700, Paul Goyette wrote: I realize that even though wapbl registers itself as a module, it is not built as a loadable module - ie, it must be built-in. I intend to try to change this, so I would like to know if wapbl is ever intended for non-ffs file systems. The WAPBL option changes the buffer subsystem, that's why it can't easily be modularized. Ah, OK. Then I guess I'll not dive any further into this! Thanks. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: core's decision on modular kernels
On Thu, Sep 22, 2011 at 10:08:02AM -0500, David Young wrote: On Thu, Sep 22, 2011 at 08:53:53AM +0100, David Laight wrote: What is the difference between MONOLITHIC and MODULAR with 'built-in' modules? And wouldn't the latter be a better aim?? I think that by MODULAR with built-in modules, you mean a barebones kernel linked with some .kmod's? I would love to see that. What has to happen to make it so? Probably just some 'round tuits'. Mostly in the area of config() and the kernel makefile. First stage would be linking an existing kmod into the kernel and sorting out the required data area linkage to get it initialised. I've really not had enough time to play recently. Maybe some wet winter weekends ... David -- David Laight: da...@l8s.co.uk
