headers
Jeremy Chadwick | 1 Oct 2010 01:19

Re: Problem running 8.1R on KVM with AMD hosts

On Thu, Sep 30, 2010 at 07:57:51PM +0100, Luke Marsden wrote:
> Hi FreeBSD-stable,
> 
> > > 1. Please, build your kernel with debug symbols.
> > > 2. Show kgdb output
> 
> I could not convince the kernel to dump (it was looping forever but not
> panicing), but I have managed to compiled a kernel with debugging
> symbols and DDB which immediately drops into the debugger when the
> problem occurs, see screenshot at:
> 
>         http://lukemarsden.net/kvm-panic.png
> 
> Progress, I sense.
> 
> I tried typing 'panic' on the understanding that this should force a
> panic and cause it would dump core to the configured swap device (I have
> set dump* in /etc/rc.conf) so that I could get you the kgdb output, but
> it just looped back into the debugger.

Try "call doadump" instead.

--

-- 
| Jeremy Chadwick                                   jdc <at> parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
Luke Marsden | 1 Oct 2010 02:22
Picon

Re: Problem running 8.1R on KVM with AMD hosts

On Thu, 2010-09-30 at 18:55 -0400, Jung-uk Kim wrote:
> It seems MCA capability is advertised by the CPUID translator but 
> writing to the MSRs causes GPF.  In other words, it seems like a CPU 
> emulator bug.  A simple workaround is 'set hw.mca.enabled=0' from the 
> loader prompt.  If it works, add hw.mca.enabled="0" 
> in /boot/loader.conf to make it permanent.  MCA does not make any 
> sense in emulation any way.

Awesome, this allows us to boot 8.1R on Linux KVM with AMD hardware!

Thank you very much. This has just doubled our number of availability
zones.

--

-- 
Best Regards,
Luke Marsden
Hybrid Logic Ltd.

Web: http://www.hybrid-cluster.com/
Hybrid Web Cluster - cloud web hosting based on FreeBSD and ZFS

Mobile: +447791750420

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 1 comment |
headers
Don Lewis | 1 Oct 2010 05:15
Picon
Favicon

Re: CPU time accounting broken on 8-STABLE machine after a few hours of uptime

On 30 Sep, Andriy Gapon wrote:
> on 30/09/2010 02:27 Don Lewis said the following:

>> I tried enabling apic and got worse results.  I saw ping RTTs as high as
>> 67 seconds.  Here's the timer info with apic enabled:
[snip]
>> Here's the verbose boot info with apic:
>> <http://people.freebsd.org/~truckman/AN-M2_HD-8.1-STABLE-apic-verbose.txt>
> 
> vmstat -i ?

Here's the vmstat -i output at the time the machine starts experiencing
freezes and ntp goes insane:

Thu Sep 30 11:38:57 PDT 2010
interrupt                          total       rate
irq1: atkbd0                           6          0
irq9: acpi0                           10          0
irq12: psm0                           18          0
irq14: ata0                         2845          1
irq17: ahc0                          310          0
irq19: fwohci0                         1          0
irq22: ehci0+                      74628         40
cpu0: timer                      3676399       1999
irq256: nfe0                        3915          2
Total                            3758132       2043
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*gw.catspoiler.o .GPS.            1 u  129  128  377    0.185   -0.307   0.020
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Braniss | 1 Oct 2010 09:26
Picon
Picon
Favicon

boot0cfg problems

In a not so distant past, boot0cfg -sn ... used to work, then it only
partialy worked, it would modify the data in boot but not the mbr, for
which 'gpart -s set active -in ...' modified the mbr. Now
# boot0cfg -s1 -v /dev/mfid0
boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
but:
# boot0cfg -v /dev/mfid0
#   flag     start chs   type       end chs       offset         size
1   0x80      0:  1: 1   0xa5   1023:212:63           63     41943006
2   0x00   1023:255:63   0xa5   1023:169:63     41943069     41943006
3   0x00   1023:255:63   0xa5   1023:126:63     83886075     41943006
4   0x00   1023:255:63   0xa5   1023:201:63    125829081   1046478825

version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
options=packet,update,nosetdrv
volume serial ID 9090-9090
default_selection=F2 (Slice 2)

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 5 comments |
headers
Dominic Fandrey | 1 Oct 2010 09:50
Picon
Favicon

pkg_version output does not match manual page

> pkg_version -IoL=
graphics/dri                        >
java/eclipse-eclemma                !
graphics/libGL                      >
graphics/libGLU                     >
graphics/libdrm                     >
graphics/libglut                    >
graphics/mesa-demos                 >
games/openarena                     >
games/openarena-data                !
games/openarena-oax                 !

The ports java/eclipse-eclemma, games/openarena-data and
games/openarena-oax are all ports of mine that await commit
(ports/144849 from March and ports/146818 from May).

The pkg_version(1) manual page states:
     !       The installed package exists in the index but for some reason,
             pkg_version was unable to compare the version number of the
             installed package with the corresponding entry in the index.

Well, these installed packages definitely do not exist in the
INDEX. I would expect ? instead:
     ?       The installed package does not appear in the index.  This could
             be due to an out of date index or a package taken from a PR that
             has not yet been committed.

Does anyone else have this problem?

Regards
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Webb | 1 Oct 2010 10:00
Favicon

Re: Problem running 8.1R on KVM with AMD hosts

Luke Marsden <luke <at> hybrid-logic.co.uk> writes:

> On Thu, 2010-09-30 at 18:55 -0400, Jung-uk Kim wrote:
> > It seems MCA capability is advertised by the CPUID translator but 
> > writing to the MSRs causes GPF.  In other words, it seems like a CPU 
> > emulator bug.  A simple workaround is 'set hw.mca.enabled=0' from the 
> > loader prompt.  If it works, add hw.mca.enabled="0" 
> > in /boot/loader.conf to make it permanent.  MCA does not make any 
> > sense in emulation any way.

Many thanks for tracking this one down for us!

> Awesome, this allows us to boot 8.1R on Linux KVM with AMD hardware!

I'll patch the system on lon-b not to advertise mca this morning Luke. It'll
be interesting to try again once I've done this to check if it fixes normal
booting without the extra hw.mca_enabled="0" flag.

Best wishes,

Chris.
_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"
Permalink | Reply | 0 comments |
headers
Jeremy Chadwick | 1 Oct 2010 11:01

Re: boot0cfg problems

On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> In a not so distant past, boot0cfg -sn ... used to work, then it only
> partialy worked, it would modify the data in boot but not the mbr, for
> which 'gpart -s set active -in ...' modified the mbr. Now
> # boot0cfg -s1 -v /dev/mfid0
> boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
> but:
> # boot0cfg -v /dev/mfid0
> #   flag     start chs   type       end chs       offset         size
> 1   0x80      0:  1: 1   0xa5   1023:212:63           63     41943006
> 2   0x00   1023:255:63   0xa5   1023:169:63     41943069     41943006
> 3   0x00   1023:255:63   0xa5   1023:126:63     83886075     41943006
> 4   0x00   1023:255:63   0xa5   1023:201:63    125829081   1046478825
> 
> version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
> options=packet,update,nosetdrv
> volume serial ID 9090-9090
> default_selection=F2 (Slice 2)

Can you try doing "sysctl kern.geom.debugflags=16" first?

--

-- 
| Jeremy Chadwick                                   jdc <at> parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
(Continue reading)

Permalink | Reply | 4 comments |
headers
Daniel Braniss | 1 Oct 2010 13:20
Picon
Picon
Favicon

Re: boot0cfg problems

> On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> > In a not so distant past, boot0cfg -sn ... used to work, then it only
> > partialy worked, it would modify the data in boot but not the mbr, for
> > which 'gpart -s set active -in ...' modified the mbr. Now
> > # boot0cfg -s1 -v /dev/mfid0
> > boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
> > but:
> > # boot0cfg -v /dev/mfid0
> > #   flag     start chs   type       end chs       offset         size
> > 1   0x80      0:  1: 1   0xa5   1023:212:63           63     41943006
> > 2   0x00   1023:255:63   0xa5   1023:169:63     41943069     41943006
> > 3   0x00   1023:255:63   0xa5   1023:126:63     83886075     41943006
> > 4   0x00   1023:255:63   0xa5   1023:201:63    125829081   1046478825
> > 
> > version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
> > options=packet,update,nosetdrv
> > volume serial ID 9090-9090
> > default_selection=F2 (Slice 2)
> 
> Can you try doing "sysctl kern.geom.debugflags=16" first?
>
this is not realy foot-shooting :-), but
- the error msg is gone,
- the slice info is updated,
- but the active bit in the mbr is not! - some bioses rely on it.
looking at changes done to boot0cfg.c there is now an err(...) call which
does an exit, before the boot is updated. I changed it to a warn(...) and the 
old
behaviour is back.
BTW,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jeremy Chadwick | 1 Oct 2010 13:34

Re: boot0cfg problems

On Fri, Oct 01, 2010 at 01:20:42PM +0200, Daniel Braniss wrote:
> > On Fri, Oct 01, 2010 at 09:26:41AM +0200, Daniel Braniss wrote:
> > > In a not so distant past, boot0cfg -sn ... used to work, then it only
> > > partialy worked, it would modify the data in boot but not the mbr, for
> > > which 'gpart -s set active -in ...' modified the mbr. Now
> > > # boot0cfg -s1 -v /dev/mfid0
> > > boot0cfg: write_mbr: /dev/mfid0: Operation not permitted
> > > but:
> > > # boot0cfg -v /dev/mfid0
> > > #   flag     start chs   type       end chs       offset         size
> > > 1   0x80      0:  1: 1   0xa5   1023:212:63           63     41943006
> > > 2   0x00   1023:255:63   0xa5   1023:169:63     41943069     41943006
> > > 3   0x00   1023:255:63   0xa5   1023:126:63     83886075     41943006
> > > 4   0x00   1023:255:63   0xa5   1023:201:63    125829081   1046478825
> > > 
> > > version=2.0  drive=0x80  mask=0x3  ticks=182  bell=# (0x23)
> > > options=packet,update,nosetdrv
> > > volume serial ID 9090-9090
> > > default_selection=F2 (Slice 2)
> > 
> > Can you try doing "sysctl kern.geom.debugflags=16" first?
> >
> this is not realy foot-shooting :-), but
> - the error msg is gone,
> - the slice info is updated,
> - but the active bit in the mbr is not! - some bioses rely on it.
> looking at changes done to boot0cfg.c there is now an err(...) call which
> does an exit, before the boot is updated. I changed it to a warn(...) and the 
> old
> behaviour is back.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jilles Tjoelker | 1 Oct 2010 14:55
Picon
Favicon

Re: mysqld_safe holding open a pty/tty on FreeBSD (7.x and 8.x)

On Thu, Sep 30, 2010 at 09:03:33AM +0200, Ed Schouten wrote:
> * Jeremy Chadwick <freebsd <at> jdc.parodius.com> wrote:
> > 1) "mysqld_safe > /dev/null 2>&1 &" never released the tty
> > 2) "nohup mysqld_safe > /dev/null 2>&1 &" did release the tty

> What happens if you run the following command?

> 	daemon -cf mysqld_safe

> The point is that FreeBSD's pts(4) driver only deallocates TTYs when
> it's really sure nothing uses it anymore. Even if there is not a single
> file descriptor referring to the slave device, it has to wait until
> there exist no processes which have the TTY as its controlling TTY.

In fact, POSIX allows dissociating the controlling terminal from the
session when all file descriptors for it (in any session) have been
closed. See SUSv4 XBD 11.1.3 The Controlling Terminal. Once the terminal
has been dissociated, it is no longer in use at all and can, in case of
a pty, be cleaned up. Implementing this may be an interesting idea. Of
course, this will cause opening /dev/tty to fail in some cases where it
previously succeeded, but it seems uncommon.

Somewhat unrelated, I think that starting daemons with daemon(8),
</dev/null >/dev/null 2>&1 or similar is inferior to implementing
daemonizing in the program itself. Think of the poor soul who needs to
install and start N daemons full of bugs and configuration errors: it is
better if such errors show up on the console instead of being hidden
away in a log file.

--

--
(Continue reading)

Permalink | Reply | 0 comments |

Gmane