Recently I added a module dependency, so compat_netbsd32 will autoload
mqueue module.
Well, it seems that something during a pkgsrc build-from-source will
trigger this. A little bit later, when the module auto-unload thread
tries to unload mqueue, I got a panic, with backtrace
pool_des
On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote:
> On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote:
> > Do you really need that mounted twice like that, and if not, can you try
> > with one of them missing and see if the problem remains ?
>
> Good idea, I'll try that later!
"Interestin
On 16 Oct 2015, at 13:44, Rhialto wrote:
> On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote:
>> On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote:
>>> Do you really need that mounted twice like that, and if not, can you try
>>> with one of them missing and see if the problem remains ?
>>
On 15 Oct 2015, at 00:21, Rhialto wrote:
> On Wed 14 Oct 2015 at 09:39:40 +0200, J. Hannken-Illjes wrote:
>> Looks like a deadlock, two threads in tstile.
>>
>> Please take a backtrace (with arguments) of these threads.
>
> I've got a whole lot more in tstile, and that is even just from running
On Fri 16 Oct 2015 at 16:31:18 +0200, J. Hannken-Illjes wrote:
> On 16 Oct 2015, at 13:44, Rhialto wrote:
>
> > On Thu 15 Oct 2015 at 20:12:44 +0200, Rhialto wrote:
> >> On Thu 15 Oct 2015 at 06:57:42 +0700, Robert Elz wrote:
> >>> Do you really need that mounted twice like that, and if not, can
On Fri 16 Oct 2015 at 16:29:55 +0200, J. Hannken-Illjes wrote:
> Looks like we are waiting for a NFS operation to complete.
>
> Did the machine hang here?
No, but I didn't try specifically to access the nfs volumes.
Interestingly enough, after the reboot (which used the stock 7.0 GENERIC
kernel)
Obviously "ifconfig -l" gets the info but I was wondering if I could
depend on the order that is returned.
Here's my problem and my proposed solution. I have a bunch of servers
all running NetBSD running various services. While I tend to run
Proliant servers for everything, there is more than on
da...@netbsd.org ("D'Arcy J.M. Cain") writes:
>I also have to figure out how to deal with hard drive differences in
>fstab but I don't have a clue how to proceed with that problem.
Use named wedges.
--
--
Michael van Elst
Internet: mlel...@serpens.de
On Fri, 16 Oct 2015 17:48:29 + (UTC)
mlel...@serpens.de (Michael van Elst) wrote:
> da...@netbsd.org ("D'Arcy J.M. Cain") writes:
>
> >I also have to figure out how to deal with hard drive differences in
> >fstab but I don't have a clue how to proceed with that problem.
>
> Use named wedges.
On Fri, Oct 16, 2015 at 02:02:45PM -0400, D'Arcy J.M. Cain wrote:
>
> Not sure that that helps. Won't wedges on different servers still have
> different names? The goal is to use exactly the same fstab file on
> disparate hardware.
With gpt yes, you could just use the same naming scheme.
With
Updating src tree:
P src/etc/rc.d/dhcpcd
P src/lib/libcurses/toucholap.c
P src/sbin/newfs_msdos/mkfs_msdos.h
P src/sys/arch/arm/allwinner/awin_mmc.c
P src/usr.sbin/makefs/msdos.c
P src/usr.sbin/makefs/msdos.h
Updating xsrc tree:
Killing core files:
Updating tar files:
src/top-level: collectin
11 matches
Mail list logo
