Matthew Dillon | 1 Sep 22:58 2008

HEAD users - buildworld/installworld needed before next buildkernel/installkernel

    The kernel & modules are now being installed in /boot/kernel and
    /boot/modules instead of /kernel and /modules.

    Because of this change installkernel will refuse to install if you
    have not installed a new world and upgraded to the latest HEAD.
    A new world install is needed so the loader properly checks both
    places and the make upgrade is needed to move the existing
    kernel & modules from / to /boot.  Otherwise / can wind up with four
    copies and run out of space.

					-Matt
					Matthew Dillon 
					<dillon <at> backplane.com>

Damian Lubosch | 8 Sep 15:50 2008
Picon

hammer does cache_lock

Hello!

I am using Hammer since it came out in the 2.0 release in a "prepare for
production" system.
I have a setup with the postfix mailserver, dovecot and dspam. The
user's mail-directories /home/mail/* are on my hammer-home-partition
(/home size ~ 150GB) At the moment about 70GB are used.

I prepared the subdirectory for the mail service using the master-slave pfs.

#hammer pfs-status /home/mail  gives:
/home/mail      PFS #3 {
    sync-beg-tid=0x0000000000000001
    sync-end-tid=0x000000034a1bea60
    shared-uuid=9c8aed31-59b9-11dd-abcc-0102b31f83bf
    unique-uuid=9c8aed7c-59b9-11dd-abcc-0102b31f83bf
    label=""
    operating as a MASTER
}

the home itself reports:
hammer pfs-status /home
/home   PFS #0 {
    sync-beg-tid=0x0000000000000000
    sync-end-tid=0x000000034a1bea60
    shared-uuid=dcc842aa-59b6-11dd-abcc-0102b31f83bf
    unique-uuid=dcc842aa-59b6-11dd-abcc-0102b31f83bf
    label="home"
    operating as a MASTER
}
(Continue reading)

Damian Lubosch | 8 Sep 16:19 2008
Picon

Re: hammer does cache_lock

Damian Lubosch schrieb:
> Hello!
>
> I am using Hammer since it came out in the 2.0 release in a "prepare for
> production" system.
> I have a setup with the postfix mailserver, dovecot and dspam. The
> user's mail-directories /home/mail/* are on my hammer-home-partition
> (/home size ~ 150GB) At the moment about 70GB are used.
>
> I prepared the subdirectory for the mail service using the master-slave pfs.
>
> #hammer pfs-status /home/mail  gives:
> /home/mail      PFS #3 {
>     sync-beg-tid=0x0000000000000001
>     sync-end-tid=0x000000034a1bea60
>     shared-uuid=9c8aed31-59b9-11dd-abcc-0102b31f83bf
>     unique-uuid=9c8aed7c-59b9-11dd-abcc-0102b31f83bf
>     label=""
>     operating as a MASTER
> }
>
> the home itself reports:
> hammer pfs-status /home
> /home   PFS #0 {
>     sync-beg-tid=0x0000000000000000
>     sync-end-tid=0x000000034a1bea60
>     shared-uuid=dcc842aa-59b6-11dd-abcc-0102b31f83bf
>     unique-uuid=dcc842aa-59b6-11dd-abcc-0102b31f83bf
>     label="home"
>     operating as a MASTER
(Continue reading)

Matthew Dillon | 9 Sep 00:00 2008

Re: hammer does cache_lock

:> I prepared the subdirectory for the mail service using the master-slave pfs.
:...
:> Ok, the problem is now, that (for the second  time) some files are
:> blocked, I get following messages in my logs:
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7b9d3c8 "group"
:> [diagnostic] cache_lock: blocked on 0xd7b9d3c8 "group"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:> [diagnostic] cache_lock: blocked on 0xd7cce058 "dovecot.index.log"
:>
:> The email-account containing this file isn't usable anymore when this
:> file is locked. When I try to access e.g. the group file (from dspam) my
:> console freezes.

    Hi Damian.  This looks like a bug in HAMMER.  The namecache must
    be deadlocking.

:Addition:
:The reboot solved the problem for now but it kernel-panicked with
:following message:
:
:Waiting (max 60 seconds) for system thread syncer to stop...stopped
:syncing disks... 932 932 932 932 932 932 932 932 932 932 932 932 932 932
:932 932 932 932
:giving up on 1 buffers
:Debugger("busy buffer problem")
(Continue reading)

Matthew Dillon | 13 Sep 23:29 2008

Re: cvs commit: src/sys/net route.c src/sys/netinet ip_output.c ip_var.h udp_usrreq.c

   Sephe, what do you think about putting a port pointer in the 
   socket structure directly and then only calling pr_mport() on socket
   creation or when the protocol stack decides it needs to be changed?

   I think it might make some of these issues easier to deal with.  Amoung
   other things we could trivially forward messages sent to the wrong port.

   We could also similarly tag the route table entry, perhaps with a cpuid
   or globaldata pointer, to detect issues there.

						-Matt

Sepherosa Ziehau | 14 Sep 03:39 2008
Picon

Re: cvs commit: src/sys/net route.c src/sys/netinet ip_output.c ip_var.h udp_usrreq.c

On Sun, Sep 14, 2008 at 5:29 AM, Matthew Dillon
<dillon <at> apollo.backplane.com> wrote:
>   Sephe, what do you think about putting a port pointer in the
>   socket structure directly and then only calling pr_mport() on socket
>   creation or when the protocol stack decides it needs to be changed?
>
>   I think it might make some of these issues easier to deal with.  Amoung
>   other things we could trivially forward messages sent to the wrong port.

I see, you mean push the mport into proto threads.  However, I don't
think we afford to do that with udp currently, especially with
unconnected udp; the probability that a packet is sent to the wrong
port is proportional to #cpu :)

Or we may add a flag to tell ip_output whether it should check port
and forward accordingly?  This flag could be used on packet forward
path (the port is always correct).

>
>   We could also similarly tag the route table entry, perhaps with a cpuid
>   or globaldata pointer, to detect issues there.

I had added cpuid in the route entry.  On output path, if it is
detected that the passed route entry's cpuid is not the same as
mycpuid, packet is not forwarded as you have mentioned, actually the
port is correct, e.g. in the callgraph like:
ip_input->tcp_input->tcp_respond->ip_output on a tcp server socket.
The port is always correct but the route entry passed to ip_output may
be allocated on different cpu, since we only duplicated tcp server
socket's inp pointer (i.e. inp's route cache is actually shared).
(Continue reading)

Hasso Tepper | 16 Sep 08:38 2008
Picon

Signal codes?

We don't have support for signal codes (si_code values at [1]) at all?

[1] - http://www.opengroup.org/onlinepubs/009695399/basedefs/signal.h.html

--

-- 
Hasso Tepper

Matthias Schmidt | 17 Sep 18:05 2008

DragonFly 2.1 on an Intel Mac mini

Hi,

I recently tried to install HEAD on my Mac Mini Core Solo (a decent
router for SOHO use, just consumes about 35W running full power).

I tried a HEAD snapshot CD with and without an ACPI kernel.  The kernel
boots and passes by the boot menu but stops when probing ISA PnP
devices.  The last message on the screen is:

isa_probe_children: probing PnP devices

The machine hangs forever ... 

I tested FreeBSD 7, which works fine.  A verbose dmesg of the boot
process is attached.

Any ideas? :)

Regards

	Matthias

Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 7.1-BETA #0: Sun Sep  7 13:49:18 UTC 2008
    root <at> logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
(Continue reading)

Matthew Dillon | 18 Sep 02:27 2008

Testing needed - HAMMER PFS exports via NFS

    It should now be possible in HEAD only to export nullfs mounts of
    HAMMER PFS's.

    This needs testing.

					-Matt
					Matthew Dillon 
					<dillon <at> backplane.com>

Matthew Dillon | 18 Sep 07:12 2008

Re: DragonFly 2.1 on an Intel Mac mini

:Hi,
:
:I recently tried to install HEAD on my Mac Mini Core Solo (a decent
:router for SOHO use, just consumes about 35W running full power).
:
:I tried a HEAD snapshot CD with and without an ACPI kernel.  The kernel
:boots and passes by the boot menu but stops when probing ISA PnP
:devices.  The last message on the screen is:
:
:isa_probe_children: probing PnP devices
:
:The machine hangs forever ... 
:
:I tested FreeBSD 7, which works fine.  A verbose dmesg of the boot
:process is attached.
:
:Any ideas? :)
:
:Regards
:
:	Matthias

    None right off the bat.  If it is getting that far though it sounds
    like it may be trying to probe an ISA serial port or something like
    that. 

    You may be able to add kprintf()'s to track down what it's actually
    hanging on.  Before doing that, perhaps try a bare-bones kernel config
    with as few devices as possible.

(Continue reading)


Gmane