Re: silly libusbhid question

[Hans Petter Selasky]

On Wednesday 08 September 2010 20:57:50 Maksim Yevmenkin wrote:
> hello,
> 
> [trying current@ first to get wider audience :)]
> 
> so, i have a somewhat silly question about libusbhid. please consider
> the following code
> 
> hid_data_t  d;
> hid_item_t  h;
> 
> for (d = hid_start_parse(desc, 1 << hid_input, -1); hid_get_item(d, &h) >
> 0; ) { ...
> }
> hid_end_parse(d);
> 
> the idea is/was to parse and iterate over hid descriptor desc in a
> such a way that only "hid_input" items are returned. as it turns out,
> this code will also pick up "hid_collection" items as well, i.e.
> "h.kind" is set to "hid_collection". is this a bug or a feature?
> 
> thanks,
> max

In kernel and userspace this is currently a feature in the HID libraries.

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: silly libusbhid question

[Hans Petter Selasky]

> In kernel and userspace this is currently a feature in the HID libraries.

And I agree that maybe this should be changed. Before changing anything please 
grep the kernel sources for this function and check that no callers are using 
this feature, or add this missing 1 << hid_collection mask.

--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: silly libusbhid question

[Maksim Yevmenkin]

On Wed, Sep 8, 2010 at 11:59 PM, Hans Petter Selasky  wrote:
>
>> In kernel and userspace this is currently a feature in the HID libraries.
>
> And I agree that maybe this should be changed. Before changing anything please
> grep the kernel sources for this function and check that no callers are using
> this feature, or add this missing 1 << hid_collection mask.

thanks for the answer! i was not going to change anything, not
immediately at least :) someone pointed me at a bluetooth mouse with a
somewhat "interesting" hid descriptor, i.e.

hid descriptor = {
   0x05 0x01 0x09 0x02 0xa1 0x01 0x85 0x03
   0x09 0x01 0xa1 0x00 0x05 0x09 0x19 0x01
   0x29 0x05 0x15 0x00 0x25 0x01 0x75 0x01
   0x95 0x05 0x81 0x02 0x75 0x03 0x95 0x01
   0x81 0x01 0x05 0x01 0x09 0x30 0x09 0x31
   0x16 0x00 0x80 0x26 0xff 0x7f 0x75 0x10
   0x95 0x02 0x81 0x06 0xa1 0x02 0x85 0x03
   0x05 0x01 0x09 0x38 0x15 0x81 0x25 0x7f
   0x75 0x08 0x95 0x01 0x81 0x06 0xc0 0xa1
   0x02 0x85 0x03 0x05 0x0c 0x0a 0x38 0x02
   0x15 0x81 0x25 0x7f 0x75 0x08 0x95 0x01
   0x81 0x06 0xc0 0xc0 0xc0
}

which (if i did everything right) decodes to

Collection page=Generic_Desktop usage=Mouse
Collection page=Generic_Desktop usage=Pointer
Input   id=3 size=1 count=1 page=Button usage=Button_1 Variable,
logical range 0..1
Input   id=3 size=1 count=1 page=Button usage=Button_2 Variable,
logical range 0..1
Input   id=3 size=1 count=1 page=Button usage=Button_3 Variable,
logical range 0..1
Input   id=3 size=1 count=1 page=Button usage=Button_4 Variable,
logical range 0..1
Input   id=3 size=1 count=1 page=Button usage=Button_5 Variable,
logical range 0..1
Input   id=3 size=16 count=1 page=Generic_Desktop usage=X Variable
Relative, logical range -32768..32767
Input   id=3 size=16 count=1 page=Generic_Desktop usage=Y Variable
Relative, logical range -32768..32767
Collection page=Generic_Desktop usage=Y
Input   id=3 size=8 count=1 page=Generic_Desktop usage=Wheel Variable
Relative, logical range -127..127
End collection
Collection page=Generic_Desktop usage=Wheel
Input   id=3 size=8 count=1 page=Consumer usage=AC_Pan Variable
Relative, logical range -127..127
End collection
End collection
End collection

please notice two nested collections one with usage "Y" and another
with usage "Wheel". the problem is that when

for (d = hid_start_parse(desc, 1 << hid_input, -1); hid_get_item(d,
&h) >  0; ) {
  switch(page) {
case Generic_Desktop:
  switch(usage) {
case X: break;
case Y: break;
case Wheel: break;
  }
  break;
  }
}
hid_end_parse(d);

code used to parse the descriptor and extract data from input reports,
"page" and "usage" on collection items override data from real input
items :( so it looks like we are getting two "X" and two "Wheel"
values -- one from real input item (which comes first) and then one
from collection item (which comes after and has garbage value in it).

in any case, workaround is quite simple (please see my latest commit
to bthidd(8)), i.e. just check h.kind and make sure it set to
hid_input.

thanks,
max
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: about in_multi_mtx @ netinet/in_mcast.c:1095

[John Baldwin]

On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote:
> Hello,
> 
> I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag
> when it's initialized so I always encounters the following LOR
> 
> lock order reversal: (sleepable after non-sleepable)
>  1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ 
netinet/in_mcast.c:1095
>  2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ 
/usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at _witness_debugger+0x2e
> witness_checkorder() at witness_checkorder+0x807
> _sx_xlock() at _sx_xlock+0x55
> usbd_do_request_flags() at usbd_do_request_flags+0xe5
> axe_cmd() at axe_cmd+0xc7
> axe_setmulti_locked() at axe_setmulti_locked+0x70
> axe_setmulti() at axe_setmulti+0x3e
> axe_ioctl() at axe_ioctl+0x132
> if_addmulti() at if_addmulti+0x19b
> in_joingroup_locked() at in_joingroup_locked+0x1bc
> in_joingroup() at in_joingroup+0x52
> in_control() at in_control+0x1144
> ifioctl() at ifioctl+0x1118
> kern_ioctl() at kern_ioctl+0xbe
> ioctl() at ioctl+0xfd
> syscallenter() at syscallenter+0x1aa
> syscall() at syscall+0x4c
> Xfast_syscall() at Xfast_syscall+0xe2
> 
> when I uses the following code at driver's ioctl routine:
> 
>   case SIOCADDMULTI:
>   case SIOCDELMULTI:
>   axe_setmulti(sc, 0);
>   break;
> 
> It means that USB driver always should defer SIOCADDMULTI /
> SIOCDELMULTI handling to the other process context to avoid LOR.
> 
> My question is that is it safe if the multicasting operations for USB
> device happens without IN_MULTI_LOCK?  Or is there any race cases if the
> task is deferred?

Why is USB using an sx lock instead of a mutex?

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Gordon Tetlow]

On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:

> All,
>
> I sat down and rewrote the man tools from a relatively old codebase to a
> single shell script. My original motivation was to allow multiple
> configuration files so port installations did not have to mess with
> /etc/manpath.config (like perl for example) when needing to manipulate the
> manpath. After looking at the existing code, I figured I could rewrite it as
> a shell script relatively easily.
>
> Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> /usr/bin/whatis)
> http://people.freebsd.org/~gordon/man.sh
>
> Features of the new code:
>
> 1. BSD licensed (old code is GPL).
> 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> (purposefully changed the manpath.config file since it is a different
> syntax).
> 3. Allows ports to override the toolset used to display the manpage based
> on language. This was done to try to merge the functionality of the
> japanese/man port into the base system as much as possible.
>
> I've tried to make this mirror the functionality, directory search order,
> and arguments as the current base implementation.
>
> This brings me to my next point. I need some testers willing to try this
> out. It would be particularly great if I could get some foreign language
> testers with localized manpage installations. If something doesn't work the
> way you expect, please contact me and I can help debug it (using man -ddd
>  will generally give me the debug information I need).
>

I have a new set for testing:
http://people.freebsd.org/~gordon/man.shar

This is going to be my final set before I commit it into the tree, barring
any showstoppers. Now includes manpage documentation for the various parts
of the new utilities. To install:
# sh man.shar
# make
# make -DBINDIR=/usr/bin install

Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages
would be appreciated. I'm new to manpage authoring and could use a review.

Please let me know if you have any questions.

Thanks,
Gordon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: about in_multi_mtx @ netinet/in_mcast.c:1095

[Weongyo Jeong]

On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote:
> On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote:
> > Hello,
> > 
> > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag
> > when it's initialized so I always encounters the following LOR
> > 
> > lock order reversal: (sleepable after non-sleepable)
> >  1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ 
> netinet/in_mcast.c:1095
> >  2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ 
> /usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > _witness_debugger() at _witness_debugger+0x2e
> > witness_checkorder() at witness_checkorder+0x807
> > _sx_xlock() at _sx_xlock+0x55
> > usbd_do_request_flags() at usbd_do_request_flags+0xe5
> > axe_cmd() at axe_cmd+0xc7
> > axe_setmulti_locked() at axe_setmulti_locked+0x70
> > axe_setmulti() at axe_setmulti+0x3e
> > axe_ioctl() at axe_ioctl+0x132
> > if_addmulti() at if_addmulti+0x19b
> > in_joingroup_locked() at in_joingroup_locked+0x1bc
> > in_joingroup() at in_joingroup+0x52
> > in_control() at in_control+0x1144
> > ifioctl() at ifioctl+0x1118
> > kern_ioctl() at kern_ioctl+0xbe
> > ioctl() at ioctl+0xfd
> > syscallenter() at syscallenter+0x1aa
> > syscall() at syscall+0x4c
> > Xfast_syscall() at Xfast_syscall+0xe2
> > 
> > when I uses the following code at driver's ioctl routine:
> > 
> > case SIOCADDMULTI:
> > case SIOCDELMULTI:
> > axe_setmulti(sc, 0);
> > break;
> > 
> > It means that USB driver always should defer SIOCADDMULTI /
> > SIOCDELMULTI handling to the other process context to avoid LOR.
> > 
> > My question is that is it safe if the multicasting operations for USB
> > device happens without IN_MULTI_LOCK?  Or is there any race cases if the
> > task is deferred?
> 
> Why is USB using an sx lock instead of a mutex?

Frankly speaking I also don't know why hps@ uses sx lock.  That is one
of things I'd like to change it.

Just looking the comment at usb_reques...@441:

/*
 * Grab the default sx-lock so that serialisation
 * is achieved when multiple threads are involved:
 */
sx_xlock(&udev->ctrl_sx);

I think he might want to hold the lock even if the thread is going into
sleep. It might be for serialization.

However even if we succeed to change the lock from sx to mutex, it's
hard to avoid the requests going into the sleep.  It means USB stack
should call like below:

mtx_sleep(chan, IN_MULTI_LOCK, ...);

to avoid the kernel's complain (would be `sleep with holding
non-sleepable lock').

What I'd like to say is that the sleeping is big problem if mutex is
used that it'd be worse when multiple mutex locks are used.

So I'm looking for a fundamental solution to solve this problem.
Welcomes any ideas.

regards,
Weongyo Jeong

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

{arch}/conf/DEFAULTS and uart

[Alexander Best]

hi there,

except for arm most archs seem to enforce uart support in conf/DEFAULTS. is
this really necessary? shouldn't DEFAULTS only contain vital devices/options
without a kernel on a specific arch won't function at all?

cheers.
alex

-- 
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: {arch}/conf/DEFAULTS and uart

[Alexander Best]

On Thu Sep  9 10, Alexander Best wrote:
> hi there,
> 
> except for arm most archs seem to enforce uart support in conf/DEFAULTS. is
> this really necessary? shouldn't DEFAULTS only contain vital devices/options
> without a kernel on a specific arch won't function at all?

jhb just explained to me, that the uart entry in DEFAULTS is not a controller
or something like that, but the uart backend to use *if* uart gets defined in
the kernel config.

sorry for the noise folks.

cheers.
alex

> 
> cheers.
> alex
> 
> -- 
> a13x

-- 
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: {arch}/conf/DEFAULTS and uart

[Alexander Best]

On Thu Sep  9 10, Alexander Best wrote:
> On Thu Sep  9 10, Alexander Best wrote:
> > hi there,
> > 
> > except for arm most archs seem to enforce uart support in conf/DEFAULTS. is
> > this really necessary? shouldn't DEFAULTS only contain vital devices/options
> > without a kernel on a specific arch won't function at all?
> 
> jhb just explained to me, that the uart entry in DEFAULTS is not a controller
> or something like that, but the uart backend to use *if* uart gets defined in
> the kernel config.
> 
> sorry for the noise folks.

however i found some missing comments and incorrect syntax which i fixed.

see the attached patch.

cheers.
alex

> 
> cheers.
> alex
> 
> > 
> > cheers.
> > alex
> > 
> > -- 
> > a13x
> 
> -- 
> a13x

-- 
a13x
diff --git a/sys/amd64/conf/DEFAULTS b/sys/amd64/conf/DEFAULTS
index 1fb52b3..e942c1a 100644
--- a/sys/amd64/conf/DEFAULTS
+++ b/sys/amd64/conf/DEFAULTS
@@ -5,10 +5,10 @@
 
 machineamd64
 
-# Bus support.
+# Bus support
 device isa
 
-# Pseudo devices.
+# Pseudo devices
 device mem # Memory and kernel memory devices
 device io  # I/O device
 
diff --git a/sys/arm/conf/DEFAULTS b/sys/arm/conf/DEFAULTS
index 591a0a1..5e1512f 100644
--- a/sys/arm/conf/DEFAULTS
+++ b/sys/arm/conf/DEFAULTS
@@ -5,7 +5,9 @@
 
 machinearm
 
-device mem
+# Pseudo devices
+device mem # Memory and kernel memory devices
 
+# Default partitioning schemes
 optionsGEOM_PART_BSD
 optionsGEOM_PART_MBR
diff --git a/sys/i386/conf/DEFAULTS b/sys/i386/conf/DEFAULTS
index 32e77e4..b780472 100644
--- a/sys/i386/conf/DEFAULTS
+++ b/sys/i386/conf/DEFAULTS
@@ -5,14 +5,14 @@
 
 machinei386
 
-# Bus support.
+# Bus support
 device isa
 optionsISAPNP
 
-# Floating point support.
+# Floating point support
 device npx
 
-# Pseudo devices.
+# Pseudo devices
 device mem # Memory and kernel memory devices
 device io  # I/O device
 
diff --git a/sys/ia64/conf/DEFAULTS b/sys/ia64/conf/DEFAULTS
index 2cb2330..88119b0 100644
--- a/sys/ia64/conf/DEFAULTS
+++ b/sys/ia64/conf/DEFAULTS
@@ -5,16 +5,17 @@
 
 machineia64
 
-# Bus support.
+# Bus support
 device acpi# ACPI support
 
-# Pseudo devices.
-device io  # I/O & EFI runtime device
+# Pseudo devices
 device mem # Memory and kernel memory devices
+device io  # I/O & EFI runtime device
 
 # UART chips on this platform
 device uart_ns8250
 
+# Default partitioning schemes
 optionsGEOM_PART_BSD
 optionsGEOM_PART_GPT
 optionsGEOM_PART_MBR
diff --git a/sys/mips/conf/DEFAULTS b/sys/mips/conf/DEFAULTS
index dc480ce..59e4442 100644
--- a/sys/mips/conf/DEFAULTS
+++ b/sys/mips/conf/DEFAULTS
@@ -5,9 +5,12 @@
 
 machinemips
 
-device mem
+# Pseudo devices
+device mem # Memory and kernel memory devices
 
+# UART chips on this platform
 device uart_ns8250
 
+# Default partitioning schemes
 optionsGEOM_PART_BSD
 optionsGEOM_PART_MBR
diff --git a/sys/pc98/conf/DEFAULTS b/sys/pc98/conf/DEFAULTS
index f30501e..527b861 100644
--- a/sys/pc98/conf/DEFAULTS
+++ b/sys/pc98/conf/DEFAULTS
@@ -6,14 +6,14 @@
 machinepc98 i386
 optionsPC98
 
-# Bus support.
+# Bus support
 device isa
 optionsISAPNP
 
-# Floating point support.
+# Floating point support
 device npx
 
-# Pseudo devices.
+# Pseudo devices
 device mem # Memory and kernel memory devices
 device io  # I/O device
 
diff --git a/sys/powerpc/conf/DEFAULTS b/sys/powerpc/conf/DEFAULTS
index 658c221..195a78f 100644
--- a/sys/powerpc/conf/DEFAULTS
+++ b/sys/powerpc/conf/DEFAULTS
@@ -3,12 +3,15 @@
 #
 # $FreeBSD$
 
-# Pseudo devices.
+machinepowerpc powerpc
+
+# Pseudo devices
 device mem # Memory and kernel memory devices
 
 # UART chips on this platform
 device uart_ns8250
 device uart_z8530
 
+# Default partitioning schemes
 optionsGEOM_PART_APM
 optionsGEOM_PART_MBR
diff --git a/sys/powerpc/conf/GENERIC b/sys/powerpc/conf/GENERIC
index 891d9aa..36f3d66 100644
--- a/sys/powerpc/conf/GENERIC
+++ b/sys/powerpc/conf/GENERIC
@@ -21,8 +21,6 @@
 cpuAIM
 ident  GENERIC
 
-machinepowerpc powerpc
-
 makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols
 
 # Platform support
diff --git a/sys/sparc64/conf/DEFAULTS b/sys/sparc64/conf/DEFAULTS
index 38b2408..2e60c94 100644
--- a/sys/sparc64/conf/DEFAULTS
+++ b/sys/sparc64/conf/DEFAULTS
@@ -5,7 +5,7 @@
 
 machinesparc64
 
-# Pseudo devices.
+# Pseudo devices
 device mem # Memory and kernel memory devices
 
 # UART chips on this platform
@@ -17,5 +17,5 @@ deviceuart_z8

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Anonymous]

Gordon Tetlow  writes:
> Gordon Tetlow  writes:
>> Anonymous  writes:
>>> It doesn't search in bin/../man nor in bin/.man. For example,
>>> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/
>>> manpath.config
>>> is default one and contains /usr/local/man which does not
>>> exist here.
>>
>> Guess I missed that pretty badly in my port. I'll go back and
>> retool the logic for this but that'll take a bit of time.
>
> Added. Latest version at http://people.freebsd.org/~gordon/man.sh

The order is still bogus compared to gnu man. If I don't like our
ancient GNU tools and altered PATH in order to prefer ones from ports
then I certainly don't want to view old manpages, too. The base manpath
should be appended *after* any PATH substitutions.

  $ man -aw gperf # man.sh
  /usr/share/man/en.UTF-8/man1/gperf.1.gz
  /usr/share/man/man1/gperf.1.gz
  LOCALBASE/man/man1/gperf.1.gz

  $ man -aw gperf # gnu man
  LOCALBASE/man/man1/gperf.1.gz
  /usr/share/man/en.UTF-8/man1/gperf.1.gz

  > $ echo $PATH
  > 
LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin

And it doesn't show anything when there are no arguments, not even
returning with exit code > 0.

  $ man # man.sh

  $ man # gnu man
  What manual page do you want?
  zsh: exit 1 man

> It's a slightly different heuristic than the existing man
> implementation since I don't support the notion of MANPATH_MAP.
> Here's the order:
>
> Default manpaths (/usr/share/man:/usr/share/openssl/man:/usr/local/
> man)
> Parse $PATH (path/man:path/MAN:(if ending in /bin)path/../man)
> Parse config files
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Jilles Tjoelker]

On Thu, Sep 09, 2010 at 11:48:37PM +0400, Anonymous wrote:
> Gordon Tetlow  writes:
> > Gordon Tetlow  writes:
> >> Anonymous  writes:
> >>> It doesn't search in bin/../man nor in bin/.man. For example,
> >>> my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/
> >>> manpath.config
> >>> is default one and contains /usr/local/man which does not
> >>> exist here.

> >> Guess I missed that pretty badly in my port. I'll go back and
> >> retool the logic for this but that'll take a bit of time.

> > Added. Latest version at http://people.freebsd.org/~gordon/man.sh

> The order is still bogus compared to gnu man. If I don't like our
> ancient GNU tools and altered PATH in order to prefer ones from ports
> then I certainly don't want to view old manpages, too. The base manpath
> should be appended *after* any PATH substitutions.

That is appropriate, but to avoid breaking the more common setup with
/usr/bin before /usr/local/bin, search_path needs to map the PATH
directories /bin and /usr/bin to the man directory /usr/share/man. GNU
man does the same, but it is written into /etc/manpath.config.

-- 
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

System reboots building mysql51-client with ZFS v28

[Rob Farmer]

I am running a fairly recent current with the new ZFS patches:

FreeBSD topaz.predatorlabs.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0
r212312M: Wed Sep  8 02:03:34 PDT 2010
rfar...@topaz.predatorlabs.net:/usr/obj/usr/src/sys/TOPAZ  amd64

When I try to build databases/mysql51-client from ports, the configure
script runs for a while then prints:
WARNING: Adding fix for interrupted reads

Then the system reboots. The kernel doesn't panic or anything - the
screen goes blank for about 5 seconds and the BIOS starts again. I
have WITNESS and all the standard debugging stuff for current, plus
the DUBUG_LOCKS and DEBUG_VFS_LOCKS options recommended in the ZFS
patch posting. Hardware is a Lenovo Thinkpad T61 with a Core 2 Duo,
4GB of RAM, ahci is being used for the hard drive. There is a 1 GB ufs
/boot, everything else is zfs (one drive, no mirroring, no snapshots,
nothing complex).

Port is up to date:
# $FreeBSD: ports/databases/mysql51-client/Makefile,v 1.100 2010/08/25
09:07:27 ale Exp $

Not sure if this is ZFS related or not. What can I do to collect some
useful information here? This can be reproduced reliably.

Thanks,
-- 
Rob Farmer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/09/09 14:51, Rob Farmer wrote:
> I am running a fairly recent current with the new ZFS patches:
> 
> FreeBSD topaz.predatorlabs.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0
> r212312M: Wed Sep  8 02:03:34 PDT 2010
> rfar...@topaz.predatorlabs.net:/usr/obj/usr/src/sys/TOPAZ  amd64
> 
> When I try to build databases/mysql51-client from ports, the configure
> script runs for a while then prints:
> WARNING: Adding fix for interrupted reads
> 
> Then the system reboots. The kernel doesn't panic or anything - the
> screen goes blank for about 5 seconds and the BIOS starts again. I
> have WITNESS and all the standard debugging stuff for current, plus
> the DUBUG_LOCKS and DEBUG_VFS_LOCKS options recommended in the ZFS
> patch posting. Hardware is a Lenovo Thinkpad T61 with a Core 2 Duo,
> 4GB of RAM, ahci is being used for the hard drive. There is a 1 GB ufs
> /boot, everything else is zfs (one drive, no mirroring, no snapshots,
> nothing complex).
> 
> Port is up to date:
> # $FreeBSD: ports/databases/mysql51-client/Makefile,v 1.100 2010/08/25
> 09:07:27 ale Exp $
> 
> Not sure if this is ZFS related or not. What can I do to collect some
> useful information here? This can be reproduced reliably.

Just a guess - are you compiling under X?  If so what about if you
compile under text mode?

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMiVf1AAoJEATO+BI/yjfB3pEH+wfej2GHUwBj3F4yPZjnUiTZ
B1X0FwzeWQWyRfl/FxF3X0LSH6s5Dc2y+QUd5e22yVfwUDV449+R53deCZesCtxm
IWabVgQKFJQF3rgdnC+fAy2kY5kaMGH/s/Ifq2GJcx8YnVLBPKQRcKHgHKAJ05l6
0G/Mr8YfGBXS7UvQJvSGqnfhLJjufBEe6dk/NTl2zguPAgWeo2z9e0xud9LYXBbH
RYGtFHzIxsvzTau4q8JVyvl6Uc5gNxvutNpOxwtWhX2lwbeqv2U+w1O9JjDCXP+e
5zLH3hffk0wKysEXPVx+ltkFzjCUCuNYIYDuvBX3V8QsYE7s4PT/J3Rmc2gX6fE=
=mnSc
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Rob Farmer]

On Thu, Sep 9, 2010 at 14:56, Xin LI  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2010/09/09 14:51, Rob Farmer wrote:
>> I am running a fairly recent current with the new ZFS patches:
>>
>> FreeBSD topaz.predatorlabs.net 9.0-CURRENT FreeBSD 9.0-CURRENT #0
>> r212312M: Wed Sep  8 02:03:34 PDT 2010
>> rfar...@topaz.predatorlabs.net:/usr/obj/usr/src/sys/TOPAZ  amd64
>>
>> When I try to build databases/mysql51-client from ports, the configure
>> script runs for a while then prints:
>> WARNING: Adding fix for interrupted reads
>>
>> Then the system reboots. The kernel doesn't panic or anything - the
>> screen goes blank for about 5 seconds and the BIOS starts again. I
>> have WITNESS and all the standard debugging stuff for current, plus
>> the DUBUG_LOCKS and DEBUG_VFS_LOCKS options recommended in the ZFS
>> patch posting. Hardware is a Lenovo Thinkpad T61 with a Core 2 Duo,
>> 4GB of RAM, ahci is being used for the hard drive. There is a 1 GB ufs
>> /boot, everything else is zfs (one drive, no mirroring, no snapshots,
>> nothing complex).
>>
>> Port is up to date:
>> # $FreeBSD: ports/databases/mysql51-client/Makefile,v 1.100 2010/08/25
>> 09:07:27 ale Exp $
>>
>> Not sure if this is ZFS related or not. What can I do to collect some
>> useful information here? This can be reproduced reliably.
>
> Just a guess - are you compiling under X?  If so what about if you
> compile under text mode?

Nope - this is a new install and X isn't running yet. It is installed,
but not started yet. I ran across this building dependencies for KDE
(why a desktop requires MySQL server is beyond me, but anyways).

-- 
Rob Farmer

>
> Cheers,
> - --
> Xin LI     http://www.delphij.net/
> FreeBSD - The Power to Serve!          Live free or die
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.16 (FreeBSD)
>
> iQEcBAEBCAAGBQJMiVf1AAoJEATO+BI/yjfB3pEH+wfej2GHUwBj3F4yPZjnUiTZ
> B1X0FwzeWQWyRfl/FxF3X0LSH6s5Dc2y+QUd5e22yVfwUDV449+R53deCZesCtxm
> IWabVgQKFJQF3rgdnC+fAy2kY5kaMGH/s/Ifq2GJcx8YnVLBPKQRcKHgHKAJ05l6
> 0G/Mr8YfGBXS7UvQJvSGqnfhLJjufBEe6dk/NTl2zguPAgWeo2z9e0xud9LYXBbH
> RYGtFHzIxsvzTau4q8JVyvl6Uc5gNxvutNpOxwtWhX2lwbeqv2U+w1O9JjDCXP+e
> 5zLH3hffk0wKysEXPVx+ltkFzjCUCuNYIYDuvBX3V8QsYE7s4PT/J3Rmc2gX6fE=
> =mnSc
> -END PGP SIGNATURE-
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SU+J deadlock

[Steve Kargl]

My system locked up without panicking.  Neither access from
the console nor via ssh from another terminal worked.  The
only recourse was a power cycle.

% uname -a
FreeBSD troutmask.apl.washington.edu 9.0-CURRENT
r211766M: Tue Aug 24 14:52:25 PDT 2010
ka...@troutmask.apl.washington.edu:/usr/obj/usr/src/sys/SPEW  amd64

Upon rebooting, I entered single user mode.  The hand
transcribed session is

# fsck -y

** SU+J Recovering /dev/ad6s1f
** Reading 33554422 byte journal from inode 4

RECOVER? yes

** Building recovery table
** Resolving unreferenced inode list
** Processing journal entries
Bad cg number 6296367
UNEXPECTED SU+J INCONSISTENCY

FALLBACK TO FULL FSCK? yes

** Skipping journal, falling through to full fsck

** Last Mounted on /usr
** Phase 1 - Check Block and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=38437143 OWNER=sgk MODE=100600
SIZE=536576 MTIME=Sep 9 14:30 2010
RECONNECT? yes

No lost+found DIRECTORY
CREATE? yes

** Phase 5 - Check cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes
1188338 files, 76416941 used, 150441439 free

At point, 'fsck -y' proceeded to clean up the other
filesystems and I rebooted.

Note, OWNER=sgk was hammering the filesystem by running
the GCC testsuite to test the recent libelf changes.
The only file moved to lost+found is

troutmask:root[204] cd lost+found/
troutmask:root[205] ls
#38437143
troutmask:root[206] file #38437143 
#38437143: ELF 64-bit LSB core file x86-64, version 1 (FreeBSD), FreeBSD-style, 
from '-1.exe'

which is from GCC testing.

This is the 2nd such lock up in the past 2 weeks.  If
there are any kernel options that will help aid in 
debugging this problem, I'll turn them on.  Just ask.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on sparc64/sparc64

[FreeBSD Tinderbox]

TB --- 2010-09-09 20:57:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-09 20:57:00 - starting HEAD tinderbox run for sparc64/sparc64
TB --- 2010-09-09 20:57:00 - cleaning the object tree
TB --- 2010-09-09 20:57:21 - cvsupping the source tree
TB --- 2010-09-09 20:57:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/sparc64/sparc64/supfile
TB --- 2010-09-09 20:57:57 - building world
TB --- 2010-09-09 20:57:57 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 20:57:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 20:57:57 - TARGET=sparc64
TB --- 2010-09-09 20:57:57 - TARGET_ARCH=sparc64
TB --- 2010-09-09 20:57:57 - TZ=UTC
TB --- 2010-09-09 20:57:57 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 20:57:57 - cd /src
TB --- 2010-09-09 20:57:57 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep  9 20:57:57 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Sep  9 22:07:14 UTC 2010
TB --- 2010-09-09 22:07:14 - generating LINT kernel config
TB --- 2010-09-09 22:07:14 - cd /src/sys/sparc64/conf
TB --- 2010-09-09 22:07:14 - /usr/bin/make -B LINT
TB --- 2010-09-09 22:07:14 - building LINT kernel
TB --- 2010-09-09 22:07:14 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 22:07:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 22:07:14 - TARGET=sparc64
TB --- 2010-09-09 22:07:14 - TARGET_ARCH=sparc64
TB --- 2010-09-09 22:07:14 - TZ=UTC
TB --- 2010-09-09 22:07:14 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 22:07:14 - cd /src
TB --- 2010-09-09 22:07:14 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep  9 22:07:14 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  
/src/sys/dev/mpt/mpt_user.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  
/src/sys/dev/msk/if_msk.c
/src/sys/dev/msk/if_msk.c: In function 'mskc_reset':
/src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
/src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported 
only once
/src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.)
/src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr':
/src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
*** Error code 1

Stop in /obj/sparc64.sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-09-09 22:14:10 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-09-09 22:14:10 - ERROR: failed to build lint kernel
TB --- 2010-09-09 22:14:10 - 3074.12 user 961.33 system 4629.98 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, Rob,

On 2010/09/09 15:01, Rob Farmer wrote:
[...]
>> Just a guess - are you compiling under X?  If so what about if you
>> compile under text mode?
> 
> Nope - this is a new install and X isn't running yet. It is installed,
> but not started yet. I ran across this building dependencies for KDE
> (why a desktop requires MySQL server is beyond me, but anyways).

I just tried to compile MySQL 5.1 client but it passed on my test system
(the compile time option is slightly different as the VFS debugging is
not yet enabled).  I'll do another round of test with these VFS options
enabled.

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMiVxTAAoJEATO+BI/yjfBrdwIALykmtHrgpaARlkBxAzzQFdu
+Ab0gvTBVrWMsyRHYqZgVhcD35ft80ItqYZOwH86/y1pqrvYTGXaexDMXDjwaG3/
9C7G73ZiKPWeEH7v0u1rInh8Ajz4+ZHjtpVRLBobk0Ef2F8pCU/0Yy3aLxa3z4Z4
C2ej6oA/jznqnk+76Iu+RyURV7Nb460uRYK5hB6iSSGDsYvdUYCUp0fFPHe3w5N4
aqhIZyGTo5MF/fgEmSXyWIHYvjiaj6IGSDILY0ju15HJajGmmkvSOo5wmxZWGGYH
jzskx5yUuv4ZAhZPCNeWPAgR2rWidgQ1k+95NZO7IvrXfMbUxh1oOe+fU31ukNc=
=jxCL
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on powerpc/powerpc

[FreeBSD Tinderbox]

TB --- 2010-09-09 20:23:24 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-09 20:23:24 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-09-09 20:23:24 - cleaning the object tree
TB --- 2010-09-09 20:23:47 - cvsupping the source tree
TB --- 2010-09-09 20:23:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2010-09-09 20:24:10 - building world
TB --- 2010-09-09 20:24:10 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 20:24:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 20:24:10 - TARGET=powerpc
TB --- 2010-09-09 20:24:10 - TARGET_ARCH=powerpc
TB --- 2010-09-09 20:24:10 - TZ=UTC
TB --- 2010-09-09 20:24:10 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 20:24:10 - cd /src
TB --- 2010-09-09 20:24:10 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep  9 20:24:11 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Sep  9 22:10:31 UTC 2010
TB --- 2010-09-09 22:10:31 - generating LINT kernel config
TB --- 2010-09-09 22:10:31 - cd /src/sys/powerpc/conf
TB --- 2010-09-09 22:10:31 - /usr/bin/make -B LINT
TB --- 2010-09-09 22:10:31 - building LINT kernel
TB --- 2010-09-09 22:10:31 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 22:10:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 22:10:31 - TARGET=powerpc
TB --- 2010-09-09 22:10:31 - TARGET_ARCH=powerpc
TB --- 2010-09-09 22:10:31 - TZ=UTC
TB --- 2010-09-09 22:10:31 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 22:10:31 - cd /src
TB --- 2010-09-09 22:10:31 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep  9 22:10:32 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer 
-msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/dev/mpt/mpt_user.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer 
-msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/dev/msk/if_msk.c
/src/sys/dev/msk/if_msk.c: In function 'mskc_reset':
/src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
/src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported 
only once
/src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.)
/src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr':
/src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
*** Error code 1

Stop in /obj/powerpc.powerpc/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-09-09 22:16:53 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-09-09 22:16:53 - ERROR: failed to build lint kernel
TB --- 2010-09-09 22:16:53 - 4857.24 user 1186.71 system 6808.99 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Rob Farmer]

On Thu, Sep 9, 2010 at 15:14, Xin LI  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi, Rob,
>
> On 2010/09/09 15:01, Rob Farmer wrote:
> [...]
>>> Just a guess - are you compiling under X?  If so what about if you
>>> compile under text mode?
>>
>> Nope - this is a new install and X isn't running yet. It is installed,
>> but not started yet. I ran across this building dependencies for KDE
>> (why a desktop requires MySQL server is beyond me, but anyways).
>
> I just tried to compile MySQL 5.1 client but it passed on my test system
> (the compile time option is slightly different as the VFS debugging is
> not yet enabled).  I'll do another round of test with these VFS options
> enabled.

Ok - so I shut the system down for about 15 minutes and then tried
again and it worked.

So maybe it was heat or something - I had reproduced it about 5 times
back to back at the exact same spot. I didn't think this laptop had
cooling problems but I will keep a closer eye on it in the future.

Sorry about the noise.

-- 
Rob Farmer

>
> Cheers,
> - --
> Xin LI     http://www.delphij.net/
> FreeBSD - The Power to Serve!          Live free or die
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.16 (FreeBSD)
>
> iQEcBAEBCAAGBQJMiVxTAAoJEATO+BI/yjfBrdwIALykmtHrgpaARlkBxAzzQFdu
> +Ab0gvTBVrWMsyRHYqZgVhcD35ft80ItqYZOwH86/y1pqrvYTGXaexDMXDjwaG3/
> 9C7G73ZiKPWeEH7v0u1rInh8Ajz4+ZHjtpVRLBobk0Ef2F8pCU/0Yy3aLxa3z4Z4
> C2ej6oA/jznqnk+76Iu+RyURV7Nb460uRYK5hB6iSSGDsYvdUYCUp0fFPHe3w5N4
> aqhIZyGTo5MF/fgEmSXyWIHYvjiaj6IGSDILY0ju15HJajGmmkvSOo5wmxZWGGYH
> jzskx5yUuv4ZAhZPCNeWPAgR2rWidgQ1k+95NZO7IvrXfMbUxh1oOe+fU31ukNc=
> =jxCL
> -END PGP SIGNATURE-
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on sparc64/sun4v

[FreeBSD Tinderbox]

TB --- 2010-09-09 21:15:35 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-09 21:15:35 - starting HEAD tinderbox run for sparc64/sun4v
TB --- 2010-09-09 21:15:35 - cleaning the object tree
TB --- 2010-09-09 21:16:03 - cvsupping the source tree
TB --- 2010-09-09 21:16:03 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/sparc64/sun4v/supfile
TB --- 2010-09-09 21:16:35 - building world
TB --- 2010-09-09 21:16:35 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 21:16:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 21:16:35 - TARGET=sun4v
TB --- 2010-09-09 21:16:35 - TARGET_ARCH=sparc64
TB --- 2010-09-09 21:16:35 - TZ=UTC
TB --- 2010-09-09 21:16:35 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 21:16:35 - cd /src
TB --- 2010-09-09 21:16:35 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep  9 21:16:36 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> World build completed on Thu Sep  9 22:24:00 UTC 2010
TB --- 2010-09-09 22:24:00 - generating LINT kernel config
TB --- 2010-09-09 22:24:00 - cd /src/sys/sun4v/conf
TB --- 2010-09-09 22:24:00 - /usr/bin/make -B LINT
TB --- 2010-09-09 22:24:00 - building LINT kernel
TB --- 2010-09-09 22:24:00 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 22:24:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 22:24:00 - TARGET=sun4v
TB --- 2010-09-09 22:24:00 - TARGET_ARCH=sparc64
TB --- 2010-09-09 22:24:00 - TZ=UTC
TB --- 2010-09-09 22:24:00 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 22:24:00 - cd /src
TB --- 2010-09-09 22:24:00 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep  9 22:24:00 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  
/src/sys/dev/mpt/mpt_user.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS 
-include opt_global.h -fno-common -finline-limit=15000 --param 
inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin 
-mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror  
/src/sys/dev/msk/if_msk.c
/src/sys/dev/msk/if_msk.c: In function 'mskc_reset':
/src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
/src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported 
only once
/src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.)
/src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr':
/src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
*** Error code 1

Stop in /obj/sun4v.sparc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-09-09 22:29:45 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-09-09 22:29:45 - ERROR: failed to build lint kernel
TB --- 2010-09-09 22:29:45 - 3042.69 user 921.43 system 4450.14 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/09/09 15:28, Rob Farmer wrote:
> On Thu, Sep 9, 2010 at 15:14, Xin LI  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hi, Rob,
>>
>> On 2010/09/09 15:01, Rob Farmer wrote:
>> [...]
 Just a guess - are you compiling under X?  If so what about if you
 compile under text mode?
>>>
>>> Nope - this is a new install and X isn't running yet. It is installed,
>>> but not started yet. I ran across this building dependencies for KDE
>>> (why a desktop requires MySQL server is beyond me, but anyways).
>>
>> I just tried to compile MySQL 5.1 client but it passed on my test system
>> (the compile time option is slightly different as the VFS debugging is
>> not yet enabled).  I'll do another round of test with these VFS options
>> enabled.
> 
> Ok - so I shut the system down for about 15 minutes and then tried
> again and it worked.
> 
> So maybe it was heat or something - I had reproduced it about 5 times
> back to back at the exact same spot. I didn't think this laptop had
> cooling problems but I will keep a closer eye on it in the future.

Oh...  If it's so reproducible like this way then I'm more inclined to
believe that it's a software issue.  I'll try to see if I can reproduce
the problem myself anyways, thanks for letting us know :)

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMiWCdAAoJEATO+BI/yjfB1swIAI3tpByC9UjdTvk5i+JKno8U
NpYg9tTJDuGbgLW4sEMNpBF42OK9nEFpXnFF3S47m+7BjzLNkwAzUFuLmcvVGcTn
J1MgUnQlwrOFKCQSZRTWdHirtojsFjKvDBauT2vLBds1AHmBmLAkZdOptqEsOnhS
D7eRb9O7WBrhyZDk60Eup+ucbFNTxxHsOLuBOphQEviUjHx0JJFDGyaMyomqmk+j
k4UWAf2ZAqxW1FTkCEoFun9jEGDiHGmH5RnAxpKV9AzFsrWhqG68nSS/260JJ6G6
G0Sq+Y8TsHoRMiMiBHtV8bqhCDqpaTqovIgGZaefV7oQqGbKGzoXFQ32Lhaheic=
=oD2H
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2010-09-09 20:49:37 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-09 20:49:37 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-09-09 20:49:37 - cleaning the object tree
TB --- 2010-09-09 20:50:05 - cvsupping the source tree
TB --- 2010-09-09 20:50:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2010-09-09 20:50:51 - building world
TB --- 2010-09-09 20:50:51 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 20:50:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 20:50:51 - TARGET=powerpc
TB --- 2010-09-09 20:50:51 - TARGET_ARCH=powerpc64
TB --- 2010-09-09 20:50:51 - TZ=UTC
TB --- 2010-09-09 20:50:51 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 20:50:51 - cd /src
TB --- 2010-09-09 20:50:51 - /usr/bin/make -B buildworld
>>> World build started on Thu Sep  9 20:50:52 UTC 2010
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
>>> stage 5.1: building 32 bit shim libraries
>>> World build completed on Thu Sep  9 22:32:26 UTC 2010
TB --- 2010-09-09 22:32:26 - generating LINT kernel config
TB --- 2010-09-09 22:32:26 - cd /src/sys/powerpc/conf
TB --- 2010-09-09 22:32:26 - /usr/bin/make -B LINT
TB --- 2010-09-09 22:32:26 - building LINT kernel
TB --- 2010-09-09 22:32:26 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-09 22:32:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-09 22:32:26 - TARGET=powerpc
TB --- 2010-09-09 22:32:26 - TARGET_ARCH=powerpc64
TB --- 2010-09-09 22:32:26 - TZ=UTC
TB --- 2010-09-09 22:32:26 - __MAKE_CONF=/dev/null
TB --- 2010-09-09 22:32:26 - cd /src
TB --- 2010-09-09 22:32:26 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Thu Sep  9 22:32:27 UTC 2010
>>> stage 1: configuring the kernel
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3.1: making dependencies
>>> stage 3.2: building everything
[...]
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer 
-msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/dev/mpt/mpt_user.c
cc -c -O2 -pipe -fno-strict-aliasing  -std=c99  -Wall -Wredundant-decls 
-Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
-Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  
-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
-finline-limit=15000 --param inline-unit-growth=100 --param 
large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer 
-msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/dev/msk/if_msk.c
/src/sys/dev/msk/if_msk.c: In function 'mskc_reset':
/src/sys/dev/msk/if_msk.c:1337: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
/src/sys/dev/msk/if_msk.c:1337: error: (Each undeclared identifier is reported 
only once
/src/sys/dev/msk/if_msk.c:1337: error: for each function it appears in.)
/src/sys/dev/msk/if_msk.c: In function 'msk_intr_hwerr':
/src/sys/dev/msk/if_msk.c:3408: error: 'PCIM_STATUS_PERRREPORT' undeclared 
(first use in this function)
*** Error code 1

Stop in /obj/powerpc.powerpc64/src/sys/LINT.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-09-09 22:38:18 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2010-09-09 22:38:18 - ERROR: failed to build lint kernel
TB --- 2010-09-09 22:38:18 - 4503.29 user 1297.73 system 6521.34 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [head tinderbox] failure on amd64/amd64

[Doug Barton]

On 9/8/2010 7:39 AM, Mike Tancsa wrote:

At 09:07 AM 9/8/2010, Denny Lin wrote:

On Wed, Sep 08, 2010 at 04:55:14AM -0700, Rob Farmer wrote:
> > TB --- 2010-09-08 10:16:32 - /usr/bin/csup -z -r 3 -g -L 1 -h
cvsup18.freebsd.org /tinderbox/HEAD/amd64/amd64/supfile
> > TB --- 2010-09-08 10:55:57 - WARNING: /usr/bin/csup returned exit
code  1
> > TB --- 2010-09-08 10:55:57 - ERROR: unable to cvsup the source tree
> > TB --- 2010-09-08 10:55:57 - 1.81 user 60.35 system 2456.66 real
>
> Is it possible to either have the tinderbox try multiple cvsup servers
> or just not send a message if cvsup fails? Counting all branches and
> all archs, there have been around 50 "ERROR: unable to cvsup the
> source tree" mails in the last week.

I don't think Tinderbox supports multiple CVSup servers at the moment.
It seems like a desirable feature.


Normally they are pointed to a local mirror here at Sentex. However,
that server was having hardware problems which I think we have isolated
and resolved now. I will repoint this tinderbox to the local site again.


The best way to handle this would be to have messages about csup failing 
to be directed only to those who are actually able to fix the problem. 
Assuming that the cvsup server is always going to work is contrary to 
both history and good system administration practices. :)



Perhaps as an interim measure a local procmail rule to filter out cvsup
failures from going to the list ?


That's a particularly unhelpful response. Not only is it borderline rude 
to attempt to shift the responsibility for this to the users, it's a 
violation of the robustness principle.


Perhaps more importantly though, the amount of tinderbox spam we already 
receive as a result of developers inadequately testing their work is bad 
enough, but the extra spam about csup failures is causing the whole 
tinderbox feature to be increasingly useless since more and more people 
are simply filtering the messages. Such filters, once added, are rather 
unlikely to be removed.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/09/09 15:33, Xin LI wrote:
> On 2010/09/09 15:28, Rob Farmer wrote:
>> On Thu, Sep 9, 2010 at 15:14, Xin LI  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> Hi, Rob,
>>>
>>> On 2010/09/09 15:01, Rob Farmer wrote:
>>> [...]
> Just a guess - are you compiling under X?  If so what about if you
> compile under text mode?

 Nope - this is a new install and X isn't running yet. It is installed,
 but not started yet. I ran across this building dependencies for KDE
 (why a desktop requires MySQL server is beyond me, but anyways).
>>>
>>> I just tried to compile MySQL 5.1 client but it passed on my test system
>>> (the compile time option is slightly different as the VFS debugging is
>>> not yet enabled).  I'll do another round of test with these VFS options
>>> enabled.
> 
>> Ok - so I shut the system down for about 15 minutes and then tried
>> again and it worked.
> 
>> So maybe it was heat or something - I had reproduced it about 5 times
>> back to back at the exact same spot. I didn't think this laptop had
>> cooling problems but I will keep a closer eye on it in the future.
> 
> Oh...  If it's so reproducible like this way then I'm more inclined to
> believe that it's a software issue.  I'll try to see if I can reproduce
> the problem myself anyways, thanks for letting us know :)

Ok mine went through with these recommended debugging options.

Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in
/sys/kern/subr_witness.c.  I'm not sure if it's related but without that
I used get a few panics in the past.

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMiWgSAAoJEATO+BI/yjfBtk8IAKBlemR61Hl5mThqejeXzbTy
QLaohvohm5Q3gu/YrtP79/xJ0fmGGE5WdbbpKJns4xPo9OzGJZ3Hbkx96H6a0R0j
9X73xh0zVfsbKHlg5VqxrTR8HU1QwEHJ6PWmTds+tQXzN3t6Et+85tlXS7jc6agW
T6wbdNocZEqI26N6FoKGCyTMo3N7fRAVN4+z7xudIVQ3DYAEYD30ku/oQzMpxeYA
rZmYdP8Nwu90g/NHI1IgwECiQRAvQAukzOZbi/LvNMEdy4GzVjT5zQU22KHGAd4v
RssppVJVYUxxRlxSFevc0gQLGnhJ4loiQggo5afhlsGJ60kOrF4MPmW9jx3iZNY=
=k7y7
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Rob Farmer]

On Thu, Sep 9, 2010 at 16:04, Xin LI  wrote:
> Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in
> /sys/kern/subr_witness.c.  I'm not sure if it's related but without that
> I used get a few panics in the past.

I have no idea what that does. Is it something you would recommend for
general ZFS use on current? (I assume it only matters when WITNESS is
enabled)

-- 
Rob Farmer
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Matthew Fleming]

On Thu, Sep 9, 2010 at 4:04 PM, Xin LI  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2010/09/09 15:33, Xin LI wrote:
>> On 2010/09/09 15:28, Rob Farmer wrote:
>>> On Thu, Sep 9, 2010 at 15:14, Xin LI  wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Hi, Rob,

 On 2010/09/09 15:01, Rob Farmer wrote:
 [...]
>> Just a guess - are you compiling under X?  If so what about if you
>> compile under text mode?
>
> Nope - this is a new install and X isn't running yet. It is installed,
> but not started yet. I ran across this building dependencies for KDE
> (why a desktop requires MySQL server is beyond me, but anyways).

 I just tried to compile MySQL 5.1 client but it passed on my test system
 (the compile time option is slightly different as the VFS debugging is
 not yet enabled).  I'll do another round of test with these VFS options
 enabled.
>>
>>> Ok - so I shut the system down for about 15 minutes and then tried
>>> again and it worked.
>>
>>> So maybe it was heat or something - I had reproduced it about 5 times
>>> back to back at the exact same spot. I didn't think this laptop had
>>> cooling problems but I will keep a closer eye on it in the future.
>>
>> Oh...  If it's so reproducible like this way then I'm more inclined to
>> believe that it's a software issue.  I'll try to see if I can reproduce
>> the problem myself anyways, thanks for letting us know :)
>
> Ok mine went through with these recommended debugging options.
>
> Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in
> /sys/kern/subr_witness.c.  I'm not sure if it's related but without that
> I used get a few panics in the past.

As of r212370 on CURRENT this is no longer necessary, as the
sbuf_printf() will drain to the sysctl struct.  The define and its use
are gone.

Thanks,
matthew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: System reboots building mysql51-client with ZFS v28

[Xin LI]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2010/09/09 16:15, Matthew Fleming wrote:
> On Thu, Sep 9, 2010 at 4:04 PM, Xin LI  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 2010/09/09 15:33, Xin LI wrote:
>>> On 2010/09/09 15:28, Rob Farmer wrote:
 On Thu, Sep 9, 2010 at 15:14, Xin LI  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi, Rob,
>
> On 2010/09/09 15:01, Rob Farmer wrote:
> [...]
>>> Just a guess - are you compiling under X?  If so what about if you
>>> compile under text mode?
>>
>> Nope - this is a new install and X isn't running yet. It is installed,
>> but not started yet. I ran across this building dependencies for KDE
>> (why a desktop requires MySQL server is beyond me, but anyways).
>
> I just tried to compile MySQL 5.1 client but it passed on my test system
> (the compile time option is slightly different as the VFS debugging is
> not yet enabled).  I'll do another round of test with these VFS options
> enabled.
>>>
 Ok - so I shut the system down for about 15 minutes and then tried
 again and it worked.
>>>
 So maybe it was heat or something - I had reproduced it about 5 times
 back to back at the exact same spot. I didn't think this laptop had
 cooling problems but I will keep a closer eye on it in the future.
>>>
>>> Oh...  If it's so reproducible like this way then I'm more inclined to
>>> believe that it's a software issue.  I'll try to see if I can reproduce
>>> the problem myself anyways, thanks for letting us know :)
>>
>> Ok mine went through with these recommended debugging options.
>>
>> Note that on my kernel I have bumped FULLGRAPH_SBUF_SIZE to 131072 in
>> /sys/kern/subr_witness.c.  I'm not sure if it's related but without that
>> I used get a few panics in the past.
> 
> As of r212370 on CURRENT this is no longer necessary, as the
> sbuf_printf() will drain to the sysctl struct.  The define and its use
> are gone.

Oh that's great, I'll update my code and revert the local workaround.

Cheers,
- -- 
Xin LI http://www.delphij.net/
FreeBSD - The Power to Serve!  Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJMiWwIAAoJEATO+BI/yjfBaAQH/R07HAVd/GaW0nVLAdR0nHeE
wOkoJpbudwZjrgLzR0mmdWuKVW3KIqH6o4K9wHPKrLCk7EEqcZXiBdeB3jDHSAGt
cywskjouvgpFDXabgTvdUUHyah9STLInG0l6zGoy8NLdUHW3K9GaTuDQg5750QRQ
UWOUyJ3t5h8fucJUIwWEtT3NOlRtMwnudS96AVvEiqtq2e5a0BBzU4XqeNwIlQGi
f8OSfQljJlmsZbgzmukAhimr5YcqpR19qxJkAYDeLEuG6xNrRkXolO9vb0X1+DDm
y3QCQ73+eY6Vt227euqHTir1In9/5RQNQ7Ylc89S1xaKEZKehiZhXsLn/ddwURc=
=+vf6
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Alexander Best]

On Thu Sep  9 10, Gordon Tetlow wrote:
> On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:
> 
> > All,
> >
> > I sat down and rewrote the man tools from a relatively old codebase to a
> > single shell script. My original motivation was to allow multiple
> > configuration files so port installations did not have to mess with
> > /etc/manpath.config (like perl for example) when needing to manipulate the
> > manpath. After looking at the existing code, I figured I could rewrite it as
> > a shell script relatively easily.
> >
> > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> > /usr/bin/whatis)
> > http://people.freebsd.org/~gordon/man.sh
> >
> > Features of the new code:
> >
> > 1. BSD licensed (old code is GPL).
> > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> > (purposefully changed the manpath.config file since it is a different
> > syntax).
> > 3. Allows ports to override the toolset used to display the manpage based
> > on language. This was done to try to merge the functionality of the
> > japanese/man port into the base system as much as possible.
> >
> > I've tried to make this mirror the functionality, directory search order,
> > and arguments as the current base implementation.
> >
> > This brings me to my next point. I need some testers willing to try this
> > out. It would be particularly great if I could get some foreign language
> > testers with localized manpage installations. If something doesn't work the
> > way you expect, please contact me and I can help debug it (using man -ddd
> >  will generally give me the debug information I need).
> >
> 
> I have a new set for testing:
> http://people.freebsd.org/~gordon/man.shar
> 
> This is going to be my final set before I commit it into the tree, barring
> any showstoppers. Now includes manpage documentation for the various parts
> of the new utilities. To install:
> # sh man.shar
> # make
> # make -DBINDIR=/usr/bin install
> 
> Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages
> would be appreciated. I'm new to manpage authoring and could use a review.

you forgot the AUTHORS section in all of the man pages. ;) it's always nice to
see who wrote the code by reading the man pages and not having to look at the
source itself imho.

cheers.
alex

> 
> Please let me know if you have any questions.
> 
> Thanks,
> Gordon

-- 
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Alexander Best]

On Thu Sep  9 10, Gordon Tetlow wrote:
> On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow  wrote:
> 
> > All,
> >
> > I sat down and rewrote the man tools from a relatively old codebase to a
> > single shell script. My original motivation was to allow multiple
> > configuration files so port installations did not have to mess with
> > /etc/manpath.config (like perl for example) when needing to manipulate the
> > manpath. After looking at the existing code, I figured I could rewrite it as
> > a shell script relatively easily.
> >
> > Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos,
> > /usr/bin/whatis)
> > http://people.freebsd.org/~gordon/man.sh
> >
> > Features of the new code:
> >
> > 1. BSD licensed (old code is GPL).
> > 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> > (purposefully changed the manpath.config file since it is a different
> > syntax).
> > 3. Allows ports to override the toolset used to display the manpage based
> > on language. This was done to try to merge the functionality of the
> > japanese/man port into the base system as much as possible.
> >
> > I've tried to make this mirror the functionality, directory search order,
> > and arguments as the current base implementation.
> >
> > This brings me to my next point. I need some testers willing to try this
> > out. It would be particularly great if I could get some foreign language
> > testers with localized manpage installations. If something doesn't work the
> > way you expect, please contact me and I can help debug it (using man -ddd
> >  will generally give me the debug information I need).
> >
> 
> I have a new set for testing:
> http://people.freebsd.org/~gordon/man.shar
> 
> This is going to be my final set before I commit it into the tree, barring
> any showstoppers. Now includes manpage documentation for the various parts
> of the new utilities. To install:
> # sh man.shar
> # make
> # make -DBINDIR=/usr/bin install
> 
> Feedback on the man(1), manpath(1), apropos(1), and man.conf(5) manpages
> would be appreciated. I'm new to manpage authoring and could use a review.

i also did some naive benchmarking using 'cat' as pager and your script is just
as fast as the current man binary. good work. :)

i was a bit surprised about how people complained about the new BSD grep being
slower than gnu grep. so the lesson we learnt is: never make things slower as
they are. ;)

cheers.
alex

> 
> Please let me know if you have any questions.
> 
> Thanks,
> Gordon

-- 
a13x
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: about in_multi_mtx @ netinet/in_mcast.c:1095

[John Baldwin]

On Thursday, September 09, 2010 1:41:46 pm Weongyo Jeong wrote:
> On Thu, Sep 09, 2010 at 09:36:19AM -0400, John Baldwin wrote:
> > On Wednesday, September 08, 2010 4:14:19 pm Weongyo Jeong wrote:
> > > Hello,
> > > 
> > > I have a question about IN_MULTI_LOCK() because it uses MTX_DEF flag
> > > when it's initialized so I always encounters the following LOR
> > > 
> > > lock order reversal: (sleepable after non-sleepable)
> > >  1st 0x80d0b560 in_multi_mtx (in_multi_mtx) @ 
> > netinet/in_mcast.c:1095
> > >  2nd 0xff00014e3850 USB device SX lock (USB device SX lock) @ 
> > 
/usr/home/freebsd_usb/sys/modules/usb/usb/../../../dev/usb/usb_request.c:441
> > > KDB: stack backtrace:
> > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> > > _witness_debugger() at _witness_debugger+0x2e
> > > witness_checkorder() at witness_checkorder+0x807
> > > _sx_xlock() at _sx_xlock+0x55
> > > usbd_do_request_flags() at usbd_do_request_flags+0xe5
> > > axe_cmd() at axe_cmd+0xc7
> > > axe_setmulti_locked() at axe_setmulti_locked+0x70
> > > axe_setmulti() at axe_setmulti+0x3e
> > > axe_ioctl() at axe_ioctl+0x132
> > > if_addmulti() at if_addmulti+0x19b
> > > in_joingroup_locked() at in_joingroup_locked+0x1bc
> > > in_joingroup() at in_joingroup+0x52
> > > in_control() at in_control+0x1144
> > > ifioctl() at ifioctl+0x1118
> > > kern_ioctl() at kern_ioctl+0xbe
> > > ioctl() at ioctl+0xfd
> > > syscallenter() at syscallenter+0x1aa
> > > syscall() at syscall+0x4c
> > > Xfast_syscall() at Xfast_syscall+0xe2
> > > 
> > > when I uses the following code at driver's ioctl routine:
> > > 
> > >   case SIOCADDMULTI:
> > >   case SIOCDELMULTI:
> > >   axe_setmulti(sc, 0);
> > >   break;
> > > 
> > > It means that USB driver always should defer SIOCADDMULTI /
> > > SIOCDELMULTI handling to the other process context to avoid LOR.
> > > 
> > > My question is that is it safe if the multicasting operations for USB
> > > device happens without IN_MULTI_LOCK?  Or is there any race cases if the
> > > task is deferred?
> > 
> > Why is USB using an sx lock instead of a mutex?
> 
> Frankly speaking I also don't know why hps@ uses sx lock.  That is one
> of things I'd like to change it.
> 
> Just looking the comment at usb_reques...@441:
> 
>   /*
>* Grab the default sx-lock so that serialisation
>* is achieved when multiple threads are involved:
>*/
>   sx_xlock(&udev->ctrl_sx);
> 
> I think he might want to hold the lock even if the thread is going into
> sleep. It might be for serialization.
> 
> However even if we succeed to change the lock from sx to mutex, it's
> hard to avoid the requests going into the sleep.  It means USB stack
> should call like below:
> 
>   mtx_sleep(chan, IN_MULTI_LOCK, ...);
> 
> to avoid the kernel's complain (would be `sleep with holding
> non-sleepable lock').
> 
> What I'd like to say is that the sleeping is big problem if mutex is
> used that it'd be worse when multiple mutex locks are used.
> 
> So I'm looking for a fundamental solution to solve this problem.
> Welcomes any ideas.

It is probably fine to just schedule a task to do the actual work of 
axe_setmulti().  I think you do not need to lock IN_MULTI_LOCK yourself in 
your task handler as long as your handler holds the appropriate lock 
(if_maddr_rlock() IIRC) when walking the interface's multicast address list.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CFR: Replace man/manpath/whatis/apropos with a shell script

[Anonymous]

Gordon Tetlow  writes:

> 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf
> (purposefully changed the manpath.config file since it is a different
> syntax).

Hmm, and if LOCALBASE != /usr/local? hier(7) does not specify /usr/local
as the only place installed packages may reside in, only default one.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [head tinderbox] failure on amd64/amd64

[Andriy Gapon]

on 10/09/2010 01:57 Doug Barton said the following:
> On 9/8/2010 7:39 AM, Mike Tancsa wrote:
>> Perhaps as an interim measure a local procmail rule to filter out cvsup
>> failures from going to the list ?
> 
> That's a particularly unhelpful response. Not only is it borderline rude to
> attempt to shift the responsibility for this to the users, it's a violation of
> the robustness principle.

My impression that the suggestion was to do the filtering on the sending end,
not the recipients' end.

-- 
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"