Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

freebsd-current Digest, Vol 68, Issue 41

3 views

Skip to first unread message

freebsd-cur...@freebsd.org

unread,

Jul 18, 2004, 8:01:14 AM7/18/04

Send freebsd-current mailing list submissions to
freebsd...@freebsd.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-current
or, via email, send a message with subject or body 'help' to
freebsd-cur...@freebsd.org

You can reach the person managing the list at
freebsd-cu...@freebsd.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-current digest..."

Today's Topics:

1. Re: Call for PRs: nullfs (Norikatsu Shigemura)
2. Re: panic: APIC: Previous IPI is stuck (Doug White)
3. Re: Call for PRs: nullfs (Robert Watson)
4. Re: kernel build error in cam_periph_mapmem (Robert Watson)
5. Re: kernel build error in cam_periph_mapmem (Robert Watson)
6. Re: panic: APIC: Previous IPI is stuck (Matthew Dillon)
7. RE: panic: APIC: Previous IPI is stuck (Don Bowman)
8. Re: CVSUP and 5.2.1 RELEASE (Jonathan)
9. RE: panic: APIC: Previous IPI is stuck (Matthew Dillon)
10. Re: panic: APIC: Previous IPI is stuck (Matthias Buelow)
11. Re: pccbb crashes when detaching (unsafe interrupt handler)
(M. Warner Losh)
12. Re: panic: APIC: Previous IPI is stuck (Scott Long)
13. Re: panic: APIC: Previous IPI is stuck (Matthias Buelow)
14. Creative Nomad MP3 / EHCI problems (Craig Rodrigues)
15. Running the network stack without Giant -- what to try and
when (Robert Watson)
16. World breakage: -O2 and new libthr/libc_r code (Daniel Eriksson)
17. Re: [current tinderbox] failure on i386/i386 (Johan Karlsson)
18. Re: sk0 problems (Stefan Ehmann)
19. [current tinderbox] failure on alpha/alpha (FreeBSD Tinderbox)
20. [current tinderbox] failure on amd64/amd64 (FreeBSD Tinderbox)
21. Re: World breakage: -O2 and new libthr/libc_r code (David Xu)
22. [current tinderbox] failure on i386/i386 (FreeBSD Tinderbox)
23. [current tinderbox] failure on i386/pc98 (FreeBSD Tinderbox)
24. Preemption issues (Eirik Oeverby)
25. [current tinderbox] failure on ia64/ia64 (FreeBSD Tinderbox)
26. xfce4 help (Sebastian Foss)
27. [current tinderbox] failure on sparc64/sparc64 (FreeBSD Tinderbox)

----------------------------------------------------------------------

Message: 1
Date: Sun, 18 Jul 2004 06:47:37 +0900 (JST)
From: Norikatsu Shigemura <no...@FreeBSD.org>
Subject: Re: Call for PRs: nullfs
To: Alex Vasylenko <l...@omut.org>
Cc: freebsd...@FreeBSD.org
Message-ID: <200407172147....@sakura.ninth-nine.com>
Content-Type: text/plain; charset=US-ASCII

On Sat, 17 Jul 2004 15:59:31 -0400
Alex Vasylenko <l...@omut.org> wrote:
> I find the performance of nullfs somewhat lacking as measured in the test
> described below (a config with nullfs performs worse (~2x slower) than the same
> config with vnodefs). For simplicity the test was done in chroot, doing it in a
> jail has no significant impact on performance.

Wow, I confirmed this behavior with 'make buildworld' on
5-current(2004/7/2, SMP).

nullfs mounted /usr/src, /usr/obj: about 5000sec
ln -s'ed /usr/src, /usr/obj: about 3000sec

------------------------------

Message: 2
Date: Sat, 17 Jul 2004 15:53:13 -0700 (PDT)
From: Doug White <dwh...@gumbysoft.com>
Subject: Re: panic: APIC: Previous IPI is stuck
To: Kris Kennaway <kr...@obsecurity.org>
Cc: "cur...@freebsd.org" <cur...@freebsd.org>
Message-ID: <2004071715...@carver.gumbysoft.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 17 Jul 2004, Kris Kennaway wrote:

> > Does it only happen with a constant $NCPU+ load average? I have never
> > seen it here.
>
> Yeah, it's usually a pretty busy machine. It does a lot of
> buildworlds, nfs, concurrent www serving and ssh dispatching.

I triggered one of these last weekend, too. Peter mentioned something to
me about it being caused by both CPUs IPIng at once and there no deadlock
avoidance in that case. It died for me in installworld, though, which
made for a messy fixup job.

I guess our work on getting the kernel free-running is uncovering all
sorts of fun issues.

--
Doug White | FreeBSD: The Power to Serve
dwh...@gumbysoft.com | www.FreeBSD.org

------------------------------

Message: 3
Date: Sat, 17 Jul 2004 19:00:33 -0400 (EDT)
From: Robert Watson <rwa...@FreeBSD.org>
Subject: Re: Call for PRs: nullfs
To: Norikatsu Shigemura <no...@FreeBSD.org>
Cc: Alex Vasylenko <l...@omut.org>
Message-ID:
<Pine.NEB.3.96L.104071...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 18 Jul 2004, Norikatsu Shigemura wrote:

> On Sat, 17 Jul 2004 15:59:31 -0400
> Alex Vasylenko <l...@omut.org> wrote:
> > I find the performance of nullfs somewhat lacking as measured in the test
> > described below (a config with nullfs performs worse (~2x slower) than the same
> > config with vnodefs). For simplicity the test was done in chroot, doing it in a
> > jail has no significant impact on performance.
>
> Wow, I confirmed this behavior with 'make buildworld' on
> 5-current(2004/7/2, SMP).
>
> nullfs mounted /usr/src, /usr/obj: about 5000sec
> ln -s'ed /usr/src, /usr/obj: about 3000sec

There are a number of potential causes for this, and working out which it
is would be useful. One is the direct overhead associated with stacking
-- extra computation, locking, function calls, etc. Another is the
indirect overhead associated allocating additional twice as many vnodes
for every file system object (original location, new location). This can
be measured in both actual memory overhead, but also the impact on hitting
the maxvnodes bound, which causes vnodes to be recycled. It could be that
you're hitting the bound and as a result useful vnodes are leaving the
vnode cache.

You might try looking at the value of vfs.numvnodes, vfs.wantfreevnodes,
vfs.freevnodes, and kern.maxvnodes at intervals through the benchmark --
maybe running a script that pulls down the sysctl values every 10 seconds
or 20 seconds or such. On some systmes, "memory is no object" -- on other
systems it is -- it would be interesting to know how much memory your
system has. Finally, it might be interesting to know what the page fault
rate and disk I/O transaction rates during the benchmark. These might
point at the additional memory consumption creating pressure for necessary
memory.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Principal Research Scientist, McAfee Research

------------------------------

Message: 4
Date: Sat, 17 Jul 2004 19:06:47 -0400 (EDT)
From: Robert Watson <rwa...@freebsd.org>
Subject: Re: kernel build error in cam_periph_mapmem
To: Harald Schmalzbauer <h...@schmalzbauer.de>
Cc: freebsd...@freebsd.org
Message-ID:
<Pine.NEB.3.96L.104071...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 18 Jul 2004, Harald Schmalzbauer wrote:

> Yes, it's "cam_periph.c,v 1.56 2003/11/08 10:56:57 scottl" I didn't any
> local modification! I just removed my obj directory but that didn't
> help. CVsup done half an hour ago. Btw, can anybody exlain me what
> timezone the timestamp is from? Shouldn't it be UTC (or at least include
> the TZ code)?

Can you check to see if your local copy contains an include of mutex.h?
The above time stamp looks right, FYI.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Principal Research Scientist, McAfee Research

------------------------------

Message: 5
Date: Sat, 17 Jul 2004 20:37:06 -0400 (EDT)
From: Robert Watson <rwa...@freebsd.org>
Subject: Re: kernel build error in cam_periph_mapmem
To: Harald Schmalzbauer <h...@schmalzbauer.de>
Cc: freebsd...@freebsd.org
Message-ID:
<Pine.NEB.3.96L.104071...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 18 Jul 2004, Harald Schmalzbauer wrote:

> Am Sonntag, 18. Juli 2004 01:06 schrieb Robert Watson:
> > On Sun, 18 Jul 2004, Harald Schmalzbauer wrote:
> > > Yes, it's "cam_periph.c,v 1.56 2003/11/08 10:56:57 scottl" I didn't any
> > > local modification! I just removed my obj directory but that didn't
> > > help. CVsup done half an hour ago. Btw, can anybody exlain me what
> > > timezone the timestamp is from? Shouldn't it be UTC (or at least include
> > > the TZ code)?
> >
> > Can you check to see if your local copy contains an include of mutex.h?
> > The above time stamp looks right, FYI.
>
> Ok, since nobody else seems to have this problem I started poking int
> the dark and found the "error": When I remove #options INVARIANTS from
> my kernel.config it doesn't stop at the cam any more. Now I have a pf
> show stopper but I'm sure this will be fixed soon.

Still odd on the CAM front. The patch I'm building with to get pf working
is attached. I also had to remove a reference to "caddr_t sg" from a
function prototype in the Linux compat socket code. Seems to be a bad
kernel compile day.

Index: pf.c
===================================================================
RCS file: /data/ncvs/src/sys/contrib/pf/net/pf.c,v
retrieving revision 1.13
diff -u -r1.13 pf.c
--- pf.c 17 Jul 2004 17:15:15 -0000 1.13
+++ pf.c 17 Jul 2004 23:42:44 -0000
@@ -5161,7 +5161,7 @@
if ((m0 = m_copym2(*m, 0, M_COPYALL, M_NOWAIT)) == NULL)
#endif
return;
- if ((mtag = m_tag_copy(mtag)) == NULL)
+ if ((mtag = m_tag_copy(mtag, M_DONTWAIT)) == NULL)
goto bad;
m_tag_prepend(m0, mtag);
} else {
@@ -5444,7 +5444,7 @@
if ((m0 = m_copym2(*m, 0, M_COPYALL, M_NOWAIT)) == NULL)
#endif
return;
- if ((mtag = m_tag_copy(mtag)) == NULL)
+ if ((mtag = m_tag_copy(mtag, M_DONTWAIT)) == NULL)
goto bad;
m_tag_prepend(m0, mtag);
} else {

------------------------------

Message: 6
Date: Sat, 17 Jul 2004 17:37:57 -0700 (PDT)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: Re: panic: APIC: Previous IPI is stuck
To: Doug White <dwh...@gumbysoft.com>
Cc: "cur...@freebsd.org" <cur...@freebsd.org>
Message-ID: <200407180037....@apollo.backplane.com>

[ tick tock tick tock tick tock... You are getting sleepy... sleepy!
You are becoming receptive. You will port DragonFly's IPI messaging
subsystem. At the snap of my fingers you will wake up .... 1 ....
2 ..... 3 .... SNAP! ].

-Matt

------------------------------

Message: 7
Date: Sat, 17 Jul 2004 21:07:17 -0400
From: Don Bowman <d...@sandvine.com>
Subject: RE: panic: APIC: Previous IPI is stuck
To: 'Matthew Dillon' <dil...@apollo.backplane.com>
Cc: cur...@freebsd.org
Message-ID:
<FE045D4D9F7AED4CBFF1...@mail.sandvine.com>
Content-Type: text/plain; charset="iso-8859-1"

From: Matthew Dillon [mailto:dil...@apollo.backplane.com]
> [ tick tock tick tock tick tock... You are getting
> sleepy... sleepy!
> You are becoming receptive. You will port DragonFly's
> IPI messaging
> subsystem. At the snap of my fingers you will wake up
> .... 1 ....
> 2 ..... 3 .... SNAP! ].
>
> -Matt

Although you meant this as a bit of a joke (and
it is kind of funny...) what would be involved
in this port?

Have you done any benchmarks to see how well
this performs?

--don

------------------------------

Message: 8
Date: Sat, 17 Jul 2004 21:17:15 -0400
From: Jonathan <jonathan.mic...@us.army.mil>
Subject: Re: CVSUP and 5.2.1 RELEASE
To: freebsd...@FreeBSD.org
Message-ID: <40F9CF9B...@us.army.mil>
Content-Type: text/plain; format=flowed; charset=us-ascii

Steve O'Hara-Smith wrote:
> On Wed, 14 Jul 2004 11:03:10 +0200 Michael Nottebrock
> <michaeln...@gmx.net> wrote:
>
>
>> mergemaster -p needs to happen before installworld, earlier than
>> that is not required.
>
>
> From man mergemaster:
>
> -p Pre-buildworld mode. Compares only files known to be
> essen- tial to the success of {build|install}world, including
> /etc/make.conf.
>
> I rest my case.
>
Shouldn't the handbook be fixed then? The handbook says mergemaster -p
should be preformed AFTER the reboot...
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html

To update your system, you should use the following procedure:

# make buildworld
# make buildkernel
# make installkernel
# reboot

You should boot in single user mode (using boot -s from loader prompt
for example). Then run:

# mergemaster -p
# make installworld
# mergemaster
# reboot

>
>>> A mount -a or thereabouts is usually needed here.
>>
>> No, you don't need to try and mount your nfs, linux, windows and
>> smb filesystems. :)
>
>
> Hence the "or thereabouts" - you may well need the NFS filesystem if
> /usr/src is on NFS.
>

------------------------------

Message: 9
Date: Sat, 17 Jul 2004 18:46:44 -0700 (PDT)
From: Matthew Dillon <dil...@apollo.backplane.com>
Subject: RE: panic: APIC: Previous IPI is stuck
To: Don Bowman <d...@sandvine.com>
Cc: cur...@freebsd.org
Message-ID: <200407180146....@apollo.backplane.com>

:Although you meant this as a bit of a joke (and
:it is kind of funny...) what would be involved
:in this port?
:
:Have you done any benchmarks to see how well
:this performs?
:
:--don

I would expect it to perform about the same as the existing code. The
main reasons to use it are that it consolidates the half dozen IPI
mechanisms used by FreeBSD-5 into *one* mechanism, it completely
solves deadlock issue(s), and it makes a really simple abstraction/API
available for the machine independant C code to use, which would lead to
greater use of the mechanism and less use of IPI-avoidance hacks (the
idle loop halt code and thread scheduling / thread scheduler mutex
being prime examples).

Examples of APIs that the IPI messaging can replace: clock distribution
(hardclock and statclock), signal forwarding/ast, page invalidation
(3 kinds), lazy pmap, SMP rendezvous. Examples of APIs that could use
IPI messaging instead of mutexes without too much fuss: core thread
scheduler, slab allocator, portions of the memory subsystem (well, maybe
the core thread scheduler would require some fuss).

It requires some assembly work, obviously, but no more then is already
required to mess with existing IPI mechanisms. Some per-cpu structural
work, and bringing in the code module. The callbacks would operate
about the same as a FAST interrupt from the point of view of FreeBSD-5.
A critical section should protect against an IPI callback occuring on
the current cpu (as it does in DFly).

The mechanism would be extremely useful even without implementing any
of the other myrid suggestions I've made (1), which is why I recommend it.

(1) nobody seems to have taken any of those suggestions seriously, but
the last few years of constant instability and continuing, serious code
and algorithmic fragility pretty much has proved my point that a major
simpification of your MP model is necessary to put FreeBSD-5 back on
track. I figure that if I cannot get FreeBSD-5 to adopt the most obviously
useful bit, which is the IPI Messaging, that I might as well give up
trying.

-Matt
Matthew Dillon
<dil...@backplane.com>

------------------------------

Message: 10
Date: Sun, 18 Jul 2004 04:14:51 +0200
From: Matthias Buelow <m...@mukappabeta.de>
Subject: Re: panic: APIC: Previous IPI is stuck
To: cur...@freebsd.org
Message-ID: <40F9DD1B...@mukappabeta.de>
Content-Type: text/plain; charset=us-ascii; format=flowed

Matthew Dillon wrote:

> I would expect it to perform about the same as the existing code. The
> main reasons to use it are that it consolidates the half dozen IPI
> mechanisms used by FreeBSD-5 into *one* mechanism, it completely

Don't you (and others on this list) think that these things come a bit
late now? I have just subscribed to this list since I'm using 5.2.1 and
what I expected were discussions like, the last few bugs being ironed
out, things getting polished for a stable 5.x tree, and not grass-roots
discussions about the basic system architecture. This comes about 2-3
years late, folks. Please get your things together and stabilize the
beast now.

--
Matthias Buelow; mkb@{mukappabeta,informatik.uni-wuerzburg}.de

------------------------------

Message: 11
Date: Sat, 17 Jul 2004 20:27:29 -0600 (MDT)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: pccbb crashes when detaching (unsafe interrupt handler)
To: gr...@freebsd.org
Cc: cur...@freebsd.org
Message-ID: <20040717.20272...@bsdimp.com>
Content-Type: Text/Plain; charset=us-ascii

In message: <2004071719...@green.homeunix.org>
Brian Fundakowski Feldman <gr...@FreeBSD.ORG> writes:
: On Sat, Jul 17, 2004 at 12:48:03PM -0600, M. Warner Losh wrote:
: > In message: <2004071718...@green.homeunix.org>
: > : FreeBSD 5.x is not based on the spl
: > : model anymore, and unless you want to ADD the ability to do something like
: > : that, which is certainly quite feasible (that is, add a "blocking" count
: > : to the interrupt handler, which the ithread has to ack before you can
: > : return with the interrupt "blocked") there will be a specific cost inside
: > : the pccbb driver to do things safely and it will involve some sort of
: > : synchronization.
: >
: > I don't assume that things are spl based, I just had never seen the
: > race that you found. I don't want to use sx locks to solve this
: > because I'd one day like to make the cbb isr a fast interrupt handler
: > so that we can restore fast interrupt handlers to pccard and cardbus
: > modems. sx locks sleep, and can't be used in a fast interrupt
: > handler.
:
: I'd love it if we could tone down the anger and incredulity. From this
: point on, let's start off assuming each one of us knows what the other is
: talking about. None of us likes feeling insulted or slighted, so I would
: like to publically apologize for being provoked and taking an angry tone
: when I am simply interested in fixing this matter (and many others) so
: that 5.3 Does Not Suck.

I'd also like to appologize for getting my nose out of joint. I have
some personal issues hitting finality in my life right now, and I've
noticed I have a thinner skin of late as a result.

: Okay, using an sx_xlock() (instead of sx_tryxlock()) would certainly prevent
: that, but I can understand not wanting to add more weight to the fast
: path. It's something no one wants, even if it's the cleanest solution.

One thing that I could do, if we *KNOW* that the bridge ISR is run
first of all the shared interrupts, is to use atomic ops to clear/set
the OK flag. That would prevent me from calling the ISR, while
pushing down into kern_intr.c the details of dealing with the issues
of inserting/removing from the list. This would also get the priority
right, which I currently don't do right in the pccbb code. I'd then
register a wrapper for these interrupts that checks the OK flag and
neglects to call them if it isn't OK. This does add a little
overhead, but not all that much, to the ISR. And it would ensure that
pccard/cardbus interrupts have the same semantics as others in the
system.

The question is do we know this? And are there plans that the ISRs
might run on different CPUs in parallel...

I also did some research. I likely didn't see this because I grab
Giant when attaching/detaching cards and the ISR used to be marked as
needing Giant, so the race you've found wouldn't happened. When I
removed the Giant flag from the bridge ISR, this race reared its ugly
head.

: So now that I've had more time to think about it, here's my idea on the
: feasibility of an ithread handler critical section. It should cost no
: more in the fast path than it does now, other than increasing the amount
: of code jumped past by several instructions when it's skipped.
:
: >From currentish kern_intr.c:
: if ((ih->ih_flags & IH_DEAD) != 0) {
: mtx_lock(&ithd->it_lock);
: TAILQ_REMOVE(&ithd->it_handlers, ih,
: ih_next);
: wakeup(ih);
: mtx_unlock(&ithd->it_lock);
: goto restart;
: }
: We add a flag IH_PIN:
: if ((ih->ih_flags & (IH_DEAD | IH_PIN)) != 0) {
: if ((ih->ih_flags & IH_DEAD) == 0) {
: wakeup(ih);
: continue;
: }
: mtx_lock(&ithd->it_lock);
: TAILQ_REMOVE(&ithd->it_handlers,
: ih, ih_next);
: wakeup(ih);
: mtx_unlock(&ithd->it_lock);
: goto restart;
: }
:
: The implementation for the caller would look almost the same as the
: ithread_remove_handler() function. It would push essentially all of the
: cost out to the code actually modifying the specifics of the interrupt
: handler, and should provide a sufficient critical section for any such
: drivers that want to create their own interrupt sub-handlers.
:
: So ithread_pin_handler()/ithread_unpin_handler() seem like a reasonable
: solution, if a little bit ugly to be calling ithread support code from
: drivers directly? I don't know if there's any reason on FreeBSD the
: driver should not be able to know for certain that all interrupts are
: registered as an intrhand on on ithread.

I'm not sure what I think of this, so I'll think about it for a while
and reply later.

Warner

------------------------------

Message: 12
Date: Sat, 17 Jul 2004 20:30:35 -0600
From: Scott Long <sco...@samsco.org>
Subject: Re: panic: APIC: Previous IPI is stuck
To: Matthias Buelow <m...@mukappabeta.de>
Cc: cur...@freebsd.org
Message-ID: <40F9E0CB...@samsco.org>
Content-Type: text/plain; charset=us-ascii; format=flowed

Matthias Buelow wrote:
> Matthew Dillon wrote:
>
>> I would expect it to perform about the same as the existing code.
>> The
>> main reasons to use it are that it consolidates the half dozen IPI
>> mechanisms used by FreeBSD-5 into *one* mechanism, it completely
>
>
> Don't you (and others on this list) think that these things come a bit
> late now? I have just subscribed to this list since I'm using 5.2.1 and
> what I expected were discussions like, the last few bugs being ironed
> out, things getting polished for a stable 5.x tree, and not grass-roots
> discussions about the basic system architecture. This comes about 2-3
> years late, folks. Please get your things together and stabilize the
> beast now.
>

The 'fix the bugs' discussions are going on too. However, this is the
freebsd-current list, and it's always nice to discuss things that might
be suitable further down the road.

Scott

------------------------------

Message: 13
Date: Sun, 18 Jul 2004 04:48:56 +0200
From: Matthias Buelow <m...@mukappabeta.de>
Subject: Re: panic: APIC: Previous IPI is stuck
To: cur...@freebsd.org
Message-ID: <40F9E518...@mukappabeta.de>
Content-Type: text/plain; charset=us-ascii; format=flowed

Scott Long wrote:

> The 'fix the bugs' discussions are going on too. However, this is the
> freebsd-current list, and it's always nice to discuss things that might
> be suitable further down the road.

Yes, I might have gotten this wrong, I thought he was talking
specifically about 5.x (which to me, and I guess many other users, means
the long awaited stabilization of the 5.x tree).

--
Matthias Buelow; mkb@{mukappabeta,informatik.uni-wuerzburg}.de

------------------------------

Message: 14
Date: Sun, 18 Jul 2004 01:32:19 -0400
From: Craig Rodrigues <rod...@crodrigues.org>
Subject: Creative Nomad MP3 / EHCI problems
To: freebsd...@freebsd.org
Message-ID: <2004071805...@crodrigues.org>
Content-Type: text/plain; charset=us-ascii

Hi,

I updated from CVS about 2 days ago and rebuilt kernel and world.

I am having problems with my Creative Nomad MP3 player and EHCI.
The Creative Nomad MP3 player is accessed via the ugen driver.

I am using the Gnomad2 ( http://gnomad2.sourceforge.net ) program to
access the MP3 player and upload files to it.

When gnomad2 starts, it tries to scan the songs on the MP3
player, but it never completes.

I set the following syctl values:

hw.usb.ehci.debug: 1
hw.usb.ugen.debug: 1

I don't know where to look for useful information.

I got some of this output from dmesg:

ehci_device_clear_toggle: epipe=0xc1b80900 status=0x0
usbd_dump_pipe: pipe=0xc1b80900
usbd_dump_iface: iface=0xc15e9f00
device=0xc15f4800 idesc=0xc15e9f29 index=0 altindex=0 priv=0
usbd_dump_device: dev=0xc15f4800
bus=0xc161c800 default_pipe=0xc15f4780
address=2 config=1 depth=1 speed=3 self_powered=1 power=0 langid=1033
usbd_dump_endpoint: endp=0xc16585e0
edesc=0xc15e9f32 refcnt=1
bEndpointAddress=0x01
(usbd_dump_pipe:)
refcnt=1 running=0 aborting=0
intrxfer=0, repeat=0, interval=-1
ehci_device_clear_toggle: epipe=0xc1b80980 status=0x0
usbd_dump_pipe: pipe=0xc1b80980
usbd_dump_iface: iface=0xc15e9f00
device=0xc15f4800 idesc=0xc15e9f29 index=0 altindex=0 priv=0
usbd_dump_device: dev=0xc15f4800
bus=0xc161c800 default_pipe=0xc15f4780
address=2 config=1 depth=1 speed=3 self_powered=1 power=0 langid=1033
usbd_dump_endpoint: endp=0xc16585e8
edesc=0xc15e9f39 refcnt=1
bEndpointAddress=0x82
(usbd_dump_pipe:)
refcnt=1 running=0 aborting=0
intrxfer=0, repeat=0, interval=-1

ehci_idone: need toggle update status=00080248 nstatus=80008d80
ehci_idone: error, addr=2, endpt=0x00, status 0x48<HALTED,XACTERR>
ehci_pcd: change=0x40
ehci_device_bulk_close: pipe=0xc1b80900
ehci_intr1: door bell
ehci_device_bulk_close: pipe=0xc1b80980
ehci_intr1: door bell
ehci_idone: need toggle update status=00080248 nstatus=80028d80
ehci_idone: error, addr=2, endpt=0x00, status 0x48<HALTED,XACTERR>
ugen0: detached
ehci_device_ctrl_close: pipe=0xc15f4780
ehci_intr1: door bell

Any ideas how I can further debug this problem?
Thanks.

--
Craig Rodrigues
http://crodrigues.org
rod...@crodrigues.org

------------------------------

Message: 15
Date: Sun, 18 Jul 2004 01:37:20 -0400 (EDT)
From: Robert Watson <rwa...@FreeBSD.org>
Subject: Running the network stack without Giant -- what to try and
when
To: cur...@FreeBSD.org
Message-ID:
<Pine.NEB.3.96L.104071...@fledge.watson.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII

As many of you have seen from status reports, e-mails, bug reports, etc,
the FreeBSD Project has been working for some time on getting the network
stack to run in parallel on multiple CPUs. We're now at a point where a
substantial amount of functionality appears to run pretty successfully
without the Giant lock, and we're ready for more people to start running
it that way so we can find and fix problems. Let me start by enumerating
a few caveats:

- While we've been doing pretty heavy testing in MPSAFE configurations,
the nature of multiprocessor development and adapting code for MP safety
means that it's unlikely this will "just work" for all takers. However,
it may well work for many.

- We've focussed primarily on getting mainstream network configurations
to run without Giant: this means that less mainstream subsystems (parts
of IPv6, some netgraph nodes, IPX, etc) are currently unsafe without the
Giant lock turned on. Some less mainstream network devices are also not
currently able to operate without Giant. There is active work in all of
these area to remedy this issue.

- You may run into hard to diagnose problems. We'd like to try to
diagnose them anyway, but if you start to experience new problems,
you'll want to go read the Handbook chapter on preparing kernel bug
reports and diagnosing problems. You'll also want to be prepared to run
the system with INVARIANTS and WITNESS turned on.

- Not all workloads will experience a performance benefit -- some, for
various reasons, will get worse. However, several interesting
performance loads get measurably better. If you don't see an
improvement, or you see things get worse, please don't be surprised --
you may want to look at some of the suggestions I make below on ways to
make the results more predictable. Generally, you shouldn't see
substantial performance degradation, if any, but it can't be ruled out,
especially due to scheduling issues, etc.

- We can and will destroy your data. We don't mean to, because we like
your data, and we try not to, but this is, after all, operating system
development.

With all that in mind, now is in fact a good time to start experimenting
with things, as these changes appear to be relatively stable in our
initial testing. Note that there is some current instability in the CVS
HEAD, and so I'd ask for some caution in reporting problems as being
caused by debug.mpsafenet -- it may or may not be our fault :-). I've
disabled PREEMPTION locally for thread centric testing, but haven't needed
to for other testing.

Here's some technical information on how to get started:

(1) Determine if all of the stack components you will operate with are
MPsafe. For common configurations, answering the following questions
will help you decide this:

- Are you using IPv6, IPX, ATM, or KAME IPSEC? If you answered
yes to any of these questions, it is not yet safe for you to run
without Giant.

- Are your using Netgraph? If yes, it may be that you are not yet
able to run without Giant. It is worth giving it a try, but you
may experience panics, etc, especially in MP configurations.

- Are you using SLIP or kernel PPP (not to be confused with user
ppp, which is what most FreeBSD users use with modems).

- Are you using any physical network interfaces other than the
following: bge, dc, em, ep, fxp, rl, sis, xl, wi.

The following may well work: en, gx, pcn, sf. However, they
have not been marked MPSAFE by the driver maintainer.

NOTE: Do you maintain a network interface driver? Is it not on
this list? Shame on you! Or maybe shame on me for not listing
it, even though it should work. Drop me a private e-mail with
and questions or comments. Please update the busdma driver
status web page with your driver's status.

(2) If you are comfortable that you are using an MPSAFE-supported
configuration, then you can use the following tunable in loader.conf
to disable the Giant lock over the network stack on your system:

debug.mpsafenet="1"

Note that this is a boot-time only flag; you can inspect the setting
with a sysctl, but it cannot currently be changed at runtime.

Do a dmesg and confirm that all your probed network interfaces are
marked as MPSAFE or not GIANT LOCKED (or whatever we call it now). If
you have a network interface that is still GIANT LOCKED, it may not be
able to function correctly with debug.mpsafenet=1. However, if you're
not actively using it, it probably won't cause a problem. For
example, firewire network interfaces can't currently be used with
debug.mpsafenet=1. However, if idle, they shouldn't cause any
problems. We're currently working to improve compatibility with
device drivers that aren't mpsafe, and hope to have a prototype soon.

Some notes:

On SMP-centric performance measurements, such as local UNIX domain socket
use by MySQL on MP systems, I've observed 30%-40% performance improvements
by disabling Giant (some details below). My recommended configuration for
testing out the impact of disabling Giant on MP systems is:

- Set "options ADAPTIVE_MUTEXES" -- this seems to help a lot with
contention and load.

- Disable HTT. In my workloads, which tended to pound the kernel,
this hurt quite a bit. Obviously, the effectiveness of HTT
depends on the instruction mix, so this may not be for you.

- Pick one of ULE and 4BSD, and then try the other. I found 4BSD
helped a lot for MySQL, but I've seen other benchmarks with quite
different results.

- For stability purposes with MySQL, I currently have to disable
PREEMPTION, as the MySQL benchmarks I use are pretty
thread-centric and trigger preemption-related bugs with the kernel
threading bits.

- If you want to measure performance, make sure to disable
INVARIANTS, INVARIANTS_SUPPORT, WITNESS, etc.

Some notes on bug reporting:

- Make sure to identify that you are running with debug.mpsafenet.
If the problem is reproduceable, make sure to indicate if it goes
away or persists when you disable debug.mpsafenet.

- If you appear to be experiencing a hang/deadlock, please try
running with WITNESS. I'd actually like to see most people
running with WITNESS for a bit to shake out lock order issues, as
I've introduced a lot of orders. If experiencing lock order
reversals, please include the full console warning including
stack trace.

- INVARIANTS also considered good. Even if you aren't running
with WITNESS, do run with INVARIANTS.

- If you experience a hang, see if you can get into DDB -- if you
are having problems getting in using a console break, try a serial
console. When debugging, at minimum DDB 'ps' output, along with
traces of interesting processes. Typically interesting will be
processes that appear to be involved in the hang, etc.
Obviously, this requires some intuition about what causes the
hang and I can't offer hard and fast rules here.

- Experimenting with debug.mpsafenet=1 and UP is also interesting,
not just SMP. With PREEMPTION turned on, it may result in lower
latency and/or lower throughput. Or not. Regardless, it's
interesting -- you don't have to have SMP to give it a spin.

FYI, while results can and will vary, I was pleased to observe moving from
a UP->MP speedup of 1.07 on a dual-processor box to a speedup of 1.42 with
the supersmack benchmark using 11 workers and 1000 select transactions
with MySQL. For reference, that was with the 4BSD scheduler and adaptive
mutexes. For loopback netperf with TCP and UDP, I observed no change in
performance (well, 1% better for UDP RR, but basically no change). Note
that the MySQL benchmark here is basically a UNIX domain socket IPC test,
and so real world databases will give pretty different results since they
won't be pure IPC. The results appear to be very sensitive to the choice
of scheduler, and for a variety of reasons I've preferred 4BSD during
recent testing (not least, better results in terms of throughput).

There are a lot of people who have been working on this for quite some
time -- I can't thank them all here, but I will point at the netperf web
page as a place to look for ongoing patches, change logs, and some
credits:

http://www.watson.org/~robert/freebsd/netperf/

I try to keep it up to date about once a week or so as I drop new patch
sets.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
rob...@fledge.watson.org Principal Research Scientist, McAfee Research

------------------------------

Message: 16
Date: Sun, 18 Jul 2004 09:39:14 +0200
From: "Daniel Eriksson" <daniel_k...@telia.com>
Subject: World breakage: -O2 and new libthr/libc_r code
To: <freebsd...@freebsd.org>
Message-ID:
<!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAA0VcX9IoJqUaXPS8MjT1PdsKAAAAQAAAAngAsq0iTkUuG/pC0kCDf...@telia.com>

Content-Type: text/plain; charset="us-ascii"

Marcel Moolenaar's latest libthr libc_r commit seems to have broken world
for CFLAGS containing -O2.

===> lib/libthread_db
cc -O2 -pipe -fno-builtin -march=athlon-xp -I. -I/usr/src/lib/libthread_db
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /u
cc -fpic -DPIC -O2 -pipe -fno-builtin -march=athlon-xp -I.
-I/usr/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uniniti
cc -O2 -pipe -fno-builtin -march=athlon-xp -I. -I/usr/src/lib/libthread_db
-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /u
cc -fpic -DPIC -O2 -pipe -fno-builtin -march=athlon-xp -I.
-I/usr/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uniniti
In file included from libpthread.h:3,
from /usr/src/lib/libthread_db/libpthread_db.c:41:
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_kcb_get':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:162: warning:
dereferencing type-punned pointer will break strict-aliasing rules
In file included from libpthread.h:3,
from /usr/src/lib/libthread_db/libpthread_db.c:41:
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_kcb_get':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:162: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_kcb_critical_leave':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:177: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_kcb_in_critical':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:183: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_tcb_get':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:195: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_kcb_critical_leave':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:177: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_kcb_in_critical':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:183: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_tcb_get':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:195: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_get_curthread':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:203: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_get_curthread':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:203: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_get_curkse':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:213: warning:
dereferencing type-punned pointer will break strict-aliasing rules
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
`_get_curkse':
/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:213: warning:
dereferencing type-punned pointer will break strict-aliasing rules
*** Error code 1

/Daniel Eriksson

------------------------------

Message: 17
Date: Sun, 18 Jul 2004 10:10:58 +0200
From: Johan Karlsson <jo...@freebsd.org>
Subject: Re: [current tinderbox] failure on i386/i386
To: Grover Lines <gro...@ceribus.net>
Cc: freebsd...@freebsd.org
Message-ID: <20040718081...@numeri.campus.luth.se>
Content-Type: text/plain; charset=us-ascii

On Sat, Jul 17, 2004 at 09:45 (-0700), Grover Lines wrote:
> I guess no one is reading current, I reported that failure about 16hrs ago.
> It's caused from the WARNS?= 2 in

I guess you are using -O2 when building. I did not :-(

Anyway, I have reverted that part since yesterday evening.

Sorry for the breakage.

/Johan K

--
Johan Karlsson mailto:jo...@FreeBSD.org

------------------------------

Message: 18
Date: Sun, 18 Jul 2004 10:32:47 +0200
From: Stefan Ehmann <shoe...@gmx.net>
Subject: Re: sk0 problems
To: Tomas Randa <li...@hosting50.cz>
Cc: cur...@freebsd.org
Message-ID: <1090139567.944.6.camel@taxman>
Content-Type: text/plain

On Sat, 2004-07-17 at 16:16, Tomas Randa wrote:
> Hi,
>
> i am using network card Marvell Semiconductor 88E1000 with sk driver on
> FreeBSD 5.2.1 on two machines, but i have problem with it.
> When a high traffic is going through the interface (about 6-9MB/s), the
> card stops working, no ping, no answer, no message in log. Sometimes
> help do ifconfig sk0 down and up, but sometimes not.

Not sure if the problem is related.

I got the same problem with an onboard vr card and also similar symptons
with an ipfi isdn card.

------------------------------

Message: 19
Date: Sun, 18 Jul 2004 04:32:57 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on alpha/alpha
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<al...@freebsd.org>
Message-ID: <200407180832...@freebsd-current.sentex.ca>

TB --- 2004-07-18 08:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-07-18 08:00:00 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2004-07-18 08:00:00 - checking out the source tree
TB --- 2004-07-18 08:00:00 - cd /home/tinderbox/sandbox/CURRENT/alpha/alpha
TB --- 2004-07-18 08:00:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-07-18 08:04:52 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-07-18 08:04:52 - cd /home/tinderbox/sandbox/CURRENT/alpha/alpha/src
TB --- 2004-07-18 08:04:52 - /usr/bin/make -B buildworld
>>> 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
[...]
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:31: warning: its scope is only this definition or declaration, which is probably not what you want
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:36: error: syntax error before '*' token
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:37: warning: return type defaults to `int'
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:41: error: syntax error before "ucontext_t"
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:41: warning: `struct fpreg' declared inside parameter list
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:46: error: syntax error before '*' token
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:47: warning: return type defaults to `int'
/tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db/arch/alpha/libpthread_md.c:56: warning: `struct reg' declared inside parameter list
*** Error code 1

Stop in /tinderbox/CURRENT/alpha/alpha/src/lib/libthread_db.
*** Error code 1

Stop in /tinderbox/CURRENT/alpha/alpha/src/lib.
*** Error code 1

Stop in /tinderbox/CURRENT/alpha/alpha/src.
*** Error code 1

Stop in /tinderbox/CURRENT/alpha/alpha/src.
TB --- 2004-07-18 08:32:57 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-07-18 08:32:57 - ERROR: failed to build world
TB --- 2004-07-18 08:32:57 - tinderbox aborted

------------------------------

Message: 20
Date: Sun, 18 Jul 2004 05:03:05 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on amd64/amd64
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<am...@freebsd.org>
Message-ID: <200407180903...@freebsd-current.sentex.ca>

TB --- 2004-07-18 08:32:57 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-07-18 08:32:57 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2004-07-18 08:32:57 - checking out the source tree
TB --- 2004-07-18 08:32:57 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64
TB --- 2004-07-18 08:32:57 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-07-18 08:37:27 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-07-18 08:37:27 - cd /home/tinderbox/sandbox/CURRENT/amd64/amd64/src
TB --- 2004-07-18 08:37:27 - /usr/bin/make -B buildworld
>>> 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
[...]
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h: In function `_kcb_in_critical':
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h:179: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h: In function `_tcb_get':
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h:191: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h: In function `_get_curthread':
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h:199: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h: In function `_get_curkse':
/tinderbox/CURRENT/amd64/amd64/src/lib/libpthread/arch/amd64/include/pthread_md.h:209: warning: dereferencing type-punned pointer will break strict-aliasing rules
*** Error code 1

Stop in /tinderbox/CURRENT/amd64/amd64/src/lib/libthread_db.
*** Error code 1

Stop in /tinderbox/CURRENT/amd64/amd64/src/lib.
*** Error code 1

Stop in /tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /tinderbox/CURRENT/amd64/amd64/src.
TB --- 2004-07-18 09:03:05 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-07-18 09:03:05 - ERROR: failed to build world
TB --- 2004-07-18 09:03:05 - tinderbox aborted

------------------------------

Message: 21
Date: Sun, 18 Jul 2004 17:16:34 +0800
From: David Xu <dav...@freebsd.org>
Subject: Re: World breakage: -O2 and new libthr/libc_r code
To: Daniel Eriksson <daniel_k...@telia.com>
Cc: freebsd...@freebsd.org
Message-ID: <40FA3FF2...@freebsd.org>
Content-Type: text/plain; charset=us-ascii; format=flowed

libpthread used to have the warning message when being
compiled with -02, it should be fixed.

David Xu

Daniel Eriksson wrote:

>Marcel Moolenaar's latest libthr libc_r commit seems to have broken world
>for CFLAGS containing -O2.
>
>
>===> lib/libthread_db
>cc -O2 -pipe -fno-builtin -march=athlon-xp -I. -I/usr/src/lib/libthread_db
>-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /u
>cc -fpic -DPIC -O2 -pipe -fno-builtin -march=athlon-xp -I.
>-I/usr/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k
>-Wno-uniniti
>cc -O2 -pipe -fno-builtin -march=athlon-xp -I. -I/usr/src/lib/libthread_db
>-Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /u
>cc -fpic -DPIC -O2 -pipe -fno-builtin -march=athlon-xp -I.
>-I/usr/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k
>-Wno-uniniti
>In file included from libpthread.h:3,
> from /usr/src/lib/libthread_db/libpthread_db.c:41:
>/usr/src/lib/libpthread/arch/i386/include/pthread_md.h: In function
>`_kcb_get':
>/usr/src/lib/libpthread/arch/i386/include/pthread_md.h:162: warning:
>dereferencing type-punned pointer will break strict-aliasing rules
>In file included from libpthread.h:3,
>
>

------------------------------

Message: 22
Date: Sun, 18 Jul 2004 05:31:43 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on i386/i386
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<i3...@freebsd.org>
Message-ID: <200407180931...@freebsd-current.sentex.ca>

TB --- 2004-07-18 09:03:06 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-07-18 09:03:06 - starting CURRENT tinderbox run for i386/i386
TB --- 2004-07-18 09:03:06 - checking out the source tree
TB --- 2004-07-18 09:03:06 - cd /home/tinderbox/sandbox/CURRENT/i386/i386
TB --- 2004-07-18 09:03:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-07-18 09:07:17 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-07-18 09:07:17 - cd /home/tinderbox/sandbox/CURRENT/i386/i386/src
TB --- 2004-07-18 09:07:17 - /usr/bin/make -B buildworld
>>> 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
[...]
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_kcb_in_critical':
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h:183: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_tcb_get':
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h:195: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_get_curthread':
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h:203: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_get_curkse':
/tinderbox/CURRENT/i386/i386/src/lib/libpthread/arch/i386/include/pthread_md.h:213: warning: dereferencing type-punned pointer will break strict-aliasing rules
*** Error code 1

Stop in /tinderbox/CURRENT/i386/i386/src/lib/libthread_db.
*** Error code 1

Stop in /tinderbox/CURRENT/i386/i386/src/lib.
*** Error code 1

Stop in /tinderbox/CURRENT/i386/i386/src.
*** Error code 1

Stop in /tinderbox/CURRENT/i386/i386/src.
TB --- 2004-07-18 09:31:43 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-07-18 09:31:43 - ERROR: failed to build world
TB --- 2004-07-18 09:31:43 - tinderbox aborted

------------------------------

Message: 23
Date: Sun, 18 Jul 2004 06:00:22 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on i386/pc98
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<i3...@freebsd.org>
Message-ID: <200407181000...@freebsd-current.sentex.ca>

TB --- 2004-07-18 09:31:43 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-07-18 09:31:43 - starting CURRENT tinderbox run for i386/pc98
TB --- 2004-07-18 09:31:43 - checking out the source tree
TB --- 2004-07-18 09:31:43 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98
TB --- 2004-07-18 09:31:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2004-07-18 09:36:11 - building world (CFLAGS=-O2 -pipe)
TB --- 2004-07-18 09:36:11 - cd /home/tinderbox/sandbox/CURRENT/i386/pc98/src
TB --- 2004-07-18 09:36:11 - /usr/bin/make -B buildworld
>>> 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
[...]
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_kcb_in_critical':
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h:183: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_tcb_get':
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h:195: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_get_curthread':
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h:203: warning: dereferencing type-punned pointer will break strict-aliasing rules
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h: In function `_get_curkse':
/tinderbox/CURRENT/i386/pc98/src/lib/libpthread/arch/i386/include/pthread_md.h:213: warning: dereferencing type-punned pointer will break strict-aliasing rules
*** Error code 1

Stop in /tinderbox/CURRENT/i386/pc98/src/lib/libthread_db.
*** Error code 1

Stop in /tinderbox/CURRENT/i386/pc98/src/lib.
*** Error code 1

Stop in /tinderbox/CURRENT/i386/pc98/src.
*** Error code 1

Stop in /tinderbox/CURRENT/i386/pc98/src.
TB --- 2004-07-18 10:00:22 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-07-18 10:00:22 - ERROR: failed to build world
TB --- 2004-07-18 10:00:22 - tinderbox aborted

------------------------------

Message: 24
Date: Sun, 18 Jul 2004 07:41:57 +0200
From: Eirik Oeverby <ltn...@anduin.net>
Subject: Preemption issues
To: cur...@freebsd.org
Message-ID: <40FA0DA...@anduin.net>
Content-Type: text/plain; charset=us-ascii; format=flowed

Hoi all, and in particulars the power-that-be:

Any news about the preemption(?) issue? I'm itching to go -CURRENT on
some boxen here, but I'm not sure if it's a good idea right now.

Thanks,
/Eirik

------------------------------

Message: 25
Date: Sun, 18 Jul 2004 06:31:50 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on ia64/ia64
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<ia...@freebsd.org>
Message-ID: <200407181031...@freebsd-current.sentex.ca>

TB --- 2004-07-18 10:00:23 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-07-18 10:00:23 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2004-07-18 10:00:23 - cleaning the sandbox
TB --- 2004-07-18 10:01:37 - checking out the source tree
TB --- 2004-07-18 10:01:37 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64
TB --- 2004-07-18 10:01:37 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src
TB --- 2004-07-18 10:09:40 - WARNING: /home/tinderbox/sandbox/ia64.diff does not exist
TB --- 2004-07-18 10:09:40 - building world (CFLAGS=-O -pipe)
TB --- 2004-07-18 10:09:40 - cd /home/tinderbox/sandbox/CURRENT/ia64/ia64/src
TB --- 2004-07-18 10:09:40 - /usr/bin/make -B buildworld
>>> 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
[...]
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:31: warning: its scope is only this definition or declaration, which is probably not what you want
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:36: error: syntax error before '*' token
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:37: warning: return type defaults to `int'
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:41: error: syntax error before "ucontext_t"
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:41: warning: `struct fpreg' declared inside parameter list
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:46: error: syntax error before '*' token
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:47: warning: return type defaults to `int'
/tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db/arch/ia64/libpthread_md.c:56: warning: `struct reg' declared inside parameter list
*** Error code 1

Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/libthread_db.
*** Error code 1

Stop in /tinderbox/CURRENT/ia64/ia64/src/lib.
*** Error code 1

Stop in /tinderbox/CURRENT/ia64/ia64/src.
*** Error code 1

Stop in /tinderbox/CURRENT/ia64/ia64/src.
TB --- 2004-07-18 10:31:50 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-07-18 10:31:50 - ERROR: failed to build world
TB --- 2004-07-18 10:31:50 - tinderbox aborted

------------------------------

Message: 26
Date: Sun, 18 Jul 2004 13:02:34 +0200
From: "Sebastian Foss" <seg...@gmx.de>
Subject: xfce4 help
To: <freebsd...@freebsd.org>
Message-ID: <005d01c46cb6$bb1ffd20$0100a8c0@LEVELONE>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original

Hi!

I know this may be a little O.T. but im quite desperate...
Maybe someone can help me to find this original desktop wallpaper for
freebsd because i like it so much:
http://xfce.org/images/screenshots/jimmiejaz_26122003.jpg

Thank you very much for any help!

Sebastian

------------------------------

Message: 27
Date: Sun, 18 Jul 2004 07:55:29 -0400 (EDT)
From: FreeBSD Tinderbox <tind...@freebsd.org>
Subject: [current tinderbox] failure on sparc64/sparc64
To: FreeBSD Tinderbox <tind...@freebsd.org>, <cur...@freebsd.org>,
<spa...@freebsd.org>
Message-ID: <200407181155...@freebsd-current.sentex.ca>

TB --- 2004-07-18 11:27:50 - tinderbox 2.3 running on freebsd-current.sentex.ca
TB --- 2004-07-18 11:27:50 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2004-07-18 11:27:50 - cleaning the sandbox
TB --- 2004-07-18 11:28:55 - checking out the source tree
TB --- 2004-07-18 11:28:55 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64
TB --- 2004-07-18 11:28:55 - /usr/bin/cvs -f -R -Q -d/home/ncvs checkout -P -A src
TB --- 2004-07-18 11:36:06 - patching the sources
TB --- 2004-07-18 11:36:06 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src
TB --- 2004-07-18 11:36:06 - /usr/bin/patch -f -s -i/home/tinderbox/sandbox/sparc64.diff
TB --- 2004-07-18 11:36:06 - building world (CFLAGS=-O -pipe)
TB --- 2004-07-18 11:36:06 - cd /home/tinderbox/sandbox/CURRENT/sparc64/sparc64/src
TB --- 2004-07-18 11:36:06 - /usr/bin/make -B buildworld
>>> 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
[...]
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:31: warning: its scope is only this definition or declaration, which is probably not what you want
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:36: error: syntax error before '*' token
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:37: warning: return type defaults to `int'
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:41: error: syntax error before "ucontext_t"
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:41: warning: `struct fpreg' declared inside parameter list
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:46: error: syntax error before '*' token
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:47: warning: return type defaults to `int'
/tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db/arch/sparc64/libpthread_md.c:56: warning: `struct reg' declared inside parameter list
*** Error code 1

Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib/libthread_db.
*** Error code 1

Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib.
*** Error code 1

Stop in /tinderbox/CURRENT/sparc64/sparc64/src.
*** Error code 1

Stop in /tinderbox/CURRENT/sparc64/sparc64/src.
TB --- 2004-07-18 11:55:29 - WARNING: /usr/bin/make returned exit code 1
TB --- 2004-07-18 11:55:29 - ERROR: failed to build world
TB --- 2004-07-18 11:55:29 - tinderbox aborted

------------------------------

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

End of freebsd-current Digest, Vol 68, Issue 41
***********************************************

0 new messages