Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Sunday,  3 August 2003 at  0:31:45 -0400, John Baldwin wrote:
>
> On 03-Aug-2003 Greg 'groggy' Lehey wrote:
>> On Saturday,  2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote:
>>> [EMAIL PROTECTED]:~/tmp/debug > gdb -k kernel.debug
>>> (kgdb) list *(g_dev_strategy+29)
>>
>> This is almost certainly the wrong function.  At the very list you
>> should look at the arguments passed to it.
>
> Actually, this line can be very instructive.  Since 'bp' is valid
> it is probably the bp2 from g_clone_bio() that is NULL.  You might
> want to ask phk about that one.

I think you'll find that there's a null dev pointer in there.  As I
say, I've seen this scenario before (without GEOM), and I'd be
surprised if this were phk's problem.

>>> (kgdb) list *(launch_requests+448)
>>> No symbol "launch_requests" in current context.
>>> (kgdb) list *(vinumstart+2b2)
>>> No symbol "vinumstart" in current context.
>>> (kgdb)
>>
>> Read the links I just sent you.  You haven't loaded the Vinum symbols.
>
> Bah, this isn't hard for you to do either:

... once you've loaded the symbols.  That's why I pointed to the
links.

As I said to Terry, the real issue here is probably what was happening
at the time, not the contents of the dump.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[John Baldwin]

On 03-Aug-2003 Greg 'groggy' Lehey wrote:
> On Saturday,  2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote:
>> --On 2. august 2003 02:11 -0700 Terry Lambert <[EMAIL PROTECTED]>
>> wrote:
 db> trace
 g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
 g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
 launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6)
 at vinumstart+0x2b2
>>> gdb -k kernel.debug
>>> (gdb) list *(g_dev_strategy+29)
>>> [ ... ]
>>> (gdb) list *(launch_requests+448)
>>> [ ... ]
>>> (gdb) list *(vinumstart+2b2)
>>> [ ... ]
>>> Will give you the exact source lines involved, assuming you
>>> built a debug kernel.
>>
>> I did. At least I've tried to. :)
>> (I have a kernel.debug which was compiled at the same time as the real
>> kernel I'm using, and it's approx. 30MB in size).
>>
>>> You don't actually need a crash dump to debug a stack traceback.
>>
>> This is what I found by using those commands you mentioned:
>>
>> [EMAIL PROTECTED]:~/tmp/debug > gdb -k kernel.debug
>> GNU gdb 5.2.1 (FreeBSD)
>> Copyright 2002 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>> This GDB was configured as "i386-undermydesk-freebsd"...
>> (kgdb) list *(g_dev_strategy+29)
> 
> This is almost certainly the wrong function.  At the very list you
> should look at the arguments passed to it.

Actually, this line can be very instructive.  Since 'bp' is valid
it is probably the bp2 from g_clone_bio() that is NULL.  You might
want to ask phk about that one.

>> (kgdb) list *(launch_requests+448)
>> No symbol "launch_requests" in current context.
>> (kgdb) list *(vinumstart+2b2)
>> No symbol "vinumstart" in current context.
>> (kgdb)
> 
> Read the links I just sent you.  You haven't loaded the Vinum symbols.

Bah, this isn't hard for you to do either:

(gdb) l *(launch_requests+0x448)
0xad58 is in launch_requests (/usr/src/sys/dev/vinum/vinumrequest.c:448).
443 microtime(&rqe->launchtime);/* time we 
launched this
request */
444 logrq(loginfo_rqe, (union rqinfou) rqe, rq->bp);
445 }
446 #endif
447 /* fire off the request */
448 DEV_STRATEGY(&rqe->b);
449 }
450 }
451 }
452 return 0;

But you knew that.  Also, Eivind, you need to use hex, not decimal
offsets from the functions.  You might want to redo the g_dev_strategy()
line with 0x29 instead of 29.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Waiting on "allproc" w/ with non-sleepable locks held

[John Baldwin]

On 01-Aug-2003 Lars Eggert wrote:
> Hi,
> 
> yet another funky console message with today's -current:
> 
> Waiting on "allproc" with the following non-sleepablelocks held:
> exclusive sleep mutex callout_dont_sleep r = 0 (0xc0371fa0) locked @ 
> /usr/src/sys/kern/kern_timeout.c:223
> 
> Got this twice in a row; system didn't enter ddb so I got no trace.

Known bug atm in SCHED_4BSD.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: spin lock sched lock held for > 5 seconds

[John Baldwin]

On 01-Aug-2003 Lars Eggert wrote:
> Hi,
> 
> got the following panic overnight running with all debugging options on
> (WITNESS, MUTEX_DEBUG, DIAGNOSTIC, INVARIANTS; WITNESS_SKIPSPIN off):
> 
> panic: spin lock sched lock held by 0xc658e130 for > 5 seconds
> cpuid = 0; lapic.id = 
> Stack backtrace:
> backtrace(c031d030,0,c031c4c5,df0dab8c,100) at backtrace+0x17
> panic(c031c4c5,c031c62e,c658e130,c036f160,18b) at panic+0x13d
> _mtx_lock_spin(c036f160,2,c031a229,18b,c21b2ab0) at _mtx_lock_spin+0x83
> _mtx_lock_spin_flags(c036f160,2,c031a229,18b,df0dac0c) at
> _mtx_lock_spin_flags+0xb9
> statclock(df0dac00,df0dac44,c02d8a9c,0,c2198d00) at statclock+0x39
> rtcintr(0) at rtcintr+0x4f
> Xfastunpend8(df0dacb8,c02d1f05,8,608,c0372e60) at Xfastunpend8+0x1c
> call_fast_unpend(8,608,c0372e60,ffc00034,0) at call_fast_unpend+0xd
> i386_unpend(c036f160,c21b0790,df0dacd0,c01b1ae0,df0dacec) at
> i386_unpend+0x8d
> cpu_unpend(df0dacec,c01a2534,c036f160,1,c031c2e2) at cpu_unpend+0x2d
> critical_exit(c036f160,1,c031c2e2,1bc,1) at critical_exit+0x2d
> _mtx_unlock_spin_flags(c036f160,0,c031ac9f,7c,c21b2ab0) at
> _mtx_unlock_spin_flags+0xbb
> idle_proc(0,df0dad48,c031ab89,312,c21b2ab0) at idle_proc+0xb0
> fork_exit(c0199972,0,df0dad48) at fork_exit+0xc3
> fork_trampoline() at fork_trampoline+0x1a
> --- trap 0x1, eip = 0, esp = 0xdf0dad7c, ebp = 0 ---
> Debugger("panic")
> timeout stopping cpus
> Stopped at  Debugger+0x4f:  xchgl   %ebx,in_Debugger.0
> db>
> 
> The machine is still in ddb, let me know if I can provide additional info.

Try updating to a more recent current.  I recently added some extra
debugging here that will attempt to better show who owns the lock and
where it was acquired.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Fatal trap 12 under RELENG_5_1, anyone who can help?

[John Baldwin]

On 01-Aug-2003 Eivind Olsen wrote:
> Hello.
> My FreeBSD RELENG_5_1 server (cvsupped 4 days ago) seems to have problems - 
> it crashes from time to time (approx. once a day).
> 
> I've rebuilt the kernel with debug-symbols and enabled the debugger and 
> caught a crash tonight:
> 
> Here's what I had on screen (I also ran "show reg" and "trace"):
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x14
> fault code  = supervisor write, page not present
> instruction pointer = 0x8:0xc02e8139
> stack pointer   = 0x10:0xcfbf684c
> frame pointer   = 0x10:0xcfbf6880
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 46373 (ctl_cyrusdb)
> kernel: type 12 trap, code=0
> Stopped at  g_dev_strategy+0x29:movl%eax,0x14(%ebx)
> db> show reg
> cs 0x8
> ds0x10
> es0x10
> fs0x18
> ss0x10
> eax 0xf7255200
> ecx  0
> edx  0
> ebx  0
> esp 0xcfbf684c
> ebp 0xcfbf6880
> esi 0xc201e824
> edi 0xc2044900
> eip 0xc02e8139  g_dev_strategy+0x29
> efl0x10286
> dr0  0
> dr1  0
> dr2  0
> dr3  0
> dr4 0x0ff0
> dr5  0x400
> dr6 0x0ff0
> dr7  0x400
> g_dev_strategy+0x29:movl%eax,0x14(%ebx)
> db> trace
> g_dev_strategy(c201e824,c2152800,0,cfbf68d0,c2098eca) at g_dev_strategy+0x29
> launch_requests(c2e16e80,0,1,,43) at launch_requests+0x448
> vinumstart(c5ad9da8,0,c243aab0,cfbf694c,c02e5bc6) at vinumstart+0x2b2
> vinumstrategy(c5ad9da8,0,c0b79490,40,0) at vinumstrategy+0xa6
> spec_xstrategy(c215b7fc,c5ad9da8,cfbf6968,c02e4f18,cfbf6994) at 
> spec_xstrategy+0x306
> spec_specstrategy(cfbf6994,cfbf69b0,c044f7ad,cfbf6994,0) at 
> spec_specstrategy+0x1b
> spec_vnoperate(cfbf6994,0,c0b79490,f,c5ad9da8) at spec_vnoperate+0x18
> ufs_strategy(cfbf69d8,cfbf6a0c,c0359a87,cfbf69d8,1) at ufs_strategy+0xdd
> ufs_vnoperate(cfbf69d8,1,c0504f45,35e,cfbf69f8) at ufs_vnoperate+0x18
> bwrite(c5ad9da8,cfbf6a5c,c0361aca,c5ad9da8,c5ad9ed8) at bwrite+0x3a7
> bawrite(c5ad9da8,c5ad9ed8,10,3c6,20020080) at bawrite+0x1c
> cluster_wbuild(c302c000,4000,4c,0,4) at cluster_wbuild+0x6ba
> cluster_write(c5afaf08,84cf9c,0,51,c2f82300) at cluster_write+0x571
> ffs_write(cfbf6be0,c1fb97f8,c243aab0,227,c2158600) at ffs_wrie+0x5ff
> vn_write(c1fb97f8,cfbf6c7c,c2f82300,0,c243aab0) at vn_write+0x192
> write(c243aab0,cfbf6d10,c0518514,3fb,3) at write+0x69
> syscall(2f,2f,2f,0,807e000) at syscall+0x24e
> Xint0x80_syscall() at Xint0x80_syscall+0x1d
> --- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c, 
> ebp = 0xbfbfec38 ---
> db>

I think this might be a bug in vinum, but I'm not sure.  Either the
buf passed in to DEV_STRATEGY() in launch_requests() has a NULL device
(which I doubt), or the dev_t device has a NULL si_drv2 field.  Greg
(cc'd) might be able to help out further.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: panic: blockable sleep lock (sleep mutex) sellck @kern/sys_generic.c:1192

[John Baldwin]

On 01-Aug-2003 [EMAIL PROTECTED] wrote:
> 
>  Hi, I am running FreeBSD-5.1 current (cvsup from yesterday).
> I got a SB Audigy 2, using the OSS
> commercial sound drivers. I have been using the OSS
> drivers without too much trouble in a 5.1-current
> system of like 4 weeks ago (but I decided to format
> and start from scratch). However whenever I try to
> play a MP3 with xmms it panics. If I try to play the
> very same file with mpg123 it works.
> 
> dmesg: http://www.chatpr.org/~elec/dmesg
> back trace: http://www.chatpr.org/~elec/btfull

This appears to be due to a bug in the sound driver.
Without the source to that driver I can't tell for
sure however.

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

port 0xd800-0xd80f at device 7.1on pci0

[ryan chris]

with dma enabled, a sysinstall will only work under the minimal install,
and after a certain point, apparently using too much hard drive space
(showed up with a tar
-xvf ports.tar) causes a panic with anic errors

disabling dma seems to solve all of my problems (just runs slowly, of
course)


--
-bash-2.05b$ dmesg|grep atapci


atapci0:  port 0xd800-0xd80f at device 7.1
on pci0
atapci0: Correcting VIA config for southbridge data corruption bug
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
atapci0:  port 0xd800-0xd80f at device 7.1
on pci0
atapci0: Correcting VIA config for southbridge data corruption bug
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0


-
Here are the specifications to my recent a7v-ve mainboard purchase


http://www.hp.com/cposupport/personal_computing/support_doc/bph07371.html
I have also updated to the latest bios


Here are the specifications to my recent western digital harddrive
purchase


http://www.wdc.com/en/products/products.asp?DriveID=36




the computer runs on that motherboard with an amd 1600+, and with that
hard drive

thanks,
ryan

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Evan Dower]

I fear we may have gotten a bit off-topic.
E

From: Greg 'groggy' Lehey <[EMAIL PROTECTED]>
To: Terry Lambert <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Yet another crash in FreeBSD 5.1
Date: Sun, 3 Aug 2003 11:21:41 +0930
On Saturday,  2 August 2003 at 18:36:24 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> The information I gave him gets him to lines of source code, instead
>>> of just function names with strange hexadecimal numbers that resolve
>>> to instruction offsets that may be specific to his compile flags,
>>> date of checkout of the sources from CVS, etc..
>>
>> The first step of the link above does the same thing.  But it's only
>> the first step.
>>> by eyeballing the lines of source code in question and understanding
>>> the code around it well enough that you can tell *how* a pointer
>>> there could be NULL.  My instructions *get* him those lines of
>>> source.
>>
>> You obviously still haven't read the reference.  Do that first, and
>> come back when you have either understood things or are having
>> difficulty understanding.  But don't shoot off your mouth without
>> knowing what's going on.
>
> I read the reference.
>
> How does it apply in cases like this one, where you don't have a
> vmcore file?
You don't seem to have read the reference very well.  It also asks for
other supporting information.  That's the most important thing at the
moment.  I know that because I've been there before, and I've looked
at a number of these dumps: it's almost certainly related to something
he's doing which is not normal.  You don't know that, and that's
excusable, but it's not excusable that after four or five requests,
you still haven't RTFM'd.
> The way I would approach finding this, with only:
>
> 1) The line of code where the failure occurred
> 2) The stack traceback, with no arguments
> 3) The sources for the code in the stack traceback
>
> would be to eyeball the code in #1, and try to figure out how
> I gould get to that point with that pointer having a NULL value,
> given my apriori knowledge of the forward call graph.
You have that?

> I would examine every intermediate conditional and function call
> that could effect the value of the pointer and cause it to be NULL
> at the point in question.
Go for it.  Once I get the log files, I'll start there.

> One of the details I wish you would check is whether or not he has a
> vmcore file, or the ability to get one...
We'll address that issue when it becomes necessary.

Greg
--
See complete headers for address and phone numbers
<< attach3 >>
_
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at 18:36:24 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> The information I gave him gets him to lines of source code, instead
>>> of just function names with strange hexadecimal numbers that resolve
>>> to instruction offsets that may be specific to his compile flags,
>>> date of checkout of the sources from CVS, etc..
>>
>> The first step of the link above does the same thing.  But it's only
>> the first step.
>>> by eyeballing the lines of source code in question and understanding
>>> the code around it well enough that you can tell *how* a pointer
>>> there could be NULL.  My instructions *get* him those lines of
>>> source.
>>
>> You obviously still haven't read the reference.  Do that first, and
>> come back when you have either understood things or are having
>> difficulty understanding.  But don't shoot off your mouth without
>> knowing what's going on.
>
> I read the reference.
>
> How does it apply in cases like this one, where you don't have a
> vmcore file?

You don't seem to have read the reference very well.  It also asks for
other supporting information.  That's the most important thing at the
moment.  I know that because I've been there before, and I've looked
at a number of these dumps: it's almost certainly related to something
he's doing which is not normal.  You don't know that, and that's
excusable, but it's not excusable that after four or five requests,
you still haven't RTFM'd.

> The way I would approach finding this, with only:
>
> 1)The line of code where the failure occurred
> 2)The stack traceback, with no arguments
> 3)The sources for the code in the stack traceback
>
> would be to eyeball the code in #1, and try to figure out how
> I gould get to that point with that pointer having a NULL value,
> given my apriori knowledge of the forward call graph.

You have that?

> I would examine every intermediate conditional and function call
> that could effect the value of the pointer and cause it to be NULL
> at the point in question.

Go for it.  Once I get the log files, I'll start there.

> One of the details I wish you would check is whether or not he has a
> vmcore file, or the ability to get one...

We'll address that issue when it becomes necessary.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Greg 'groggy' Lehey wrote:
> > The information I gave him gets him to lines of source code, instead
> > of just function names with strange hexadecimal numbers that resolve
> > to instruction offsets that may be specific to his compile flags,
> > date of checkout of the sources from CVS, etc..
> 
> The first step of the link above does the same thing.  But it's only
> the first step.

No, it does not.  The first step of your debugging link does
not deal with anything but having a vmcore lying around *which
he does not have*.


> Terry, why don't you come to my debug tutorial at the BSDCon next
> month?  I'll show you how to do this properly.  I'm not asking for
> people to interpret hex.  I'm asking for people, you included, to find
> out what debugging help is available.

I might do this; it depends on whether things die down at work
by then, or not.  Currently, though, I'm really busy fixing bugs
exatly like this one.  In the past 3 weeks, I've fixed 61 of them,
which average out to 4 a day.

> > If it's a NULL pointer dereference, the place to find it is by
> > turning on what debugging there is, and, if that fails, which it
> > probably will,
> 
> No, that will find the null pointer dereference pretty quickly.

You'd hope the entirety of the kernel were that well instrumented...


> > by eyeballing the lines of source code in question and understanding
> > the code around it well enough that you can tell *how* a pointer
> > there could be NULL.  My instructions *get* him those lines of
> > source.
> 
> You obviously still haven't read the reference.  Do that first, and
> come back when you have either understood things or are having
> difficulty understanding.  But don't shoot off your mouth without
> knowing what's going on.

I read the reference.

How does it apply in cases like this one, where you don't have a
vmcore file?


> > If you'll notice from his followup posting of the source in
> > question, Vinum is loaded as a module, and it's the FreeBSD code
> > that Vinum calls, not Vinum, that's causing the crash.
> 
> The bug is almost certainly in Vinum.

Most likely; I think that it's passing a bad argument to the
inferior function.  The way I would approach finding this, with
only:

1)  The line of code where the failure occurred
2)  The stack traceback, with no arguments
3)  The sources for the code in the stack traceback

would be to eyeball the code in #1, and try to figure out how
I gould get to that point with that pointer having a NULL value,
given my apriori knowledge of the forward call graph.

I would examine every intermediate conditional and function call
that could effect the value of the pointer and cause it to be
NULL at the point in question.


> This has nothing to do with being paranoid about babies.  This has to
> do with people shooting off their mouths in a public forum without
> bothering to check details first.

It's really hard to talk to you about Vinum.

One of the details I wish you would check is whether or not he
has a vmcore file, or the ability to get one...

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Greg 'groggy' Lehey wrote:
> > If this is repeatable for you, it's recommended that you compile
> > Vinum statically into your kernel, so that you can look at the
> > other symbols in the traceback and obtain source lines for them,
> > as well.
> 
> No.  It is explicitly discouraged.

It saves the dicking around with the .ko files.

> > It may be that this will be debuggable without that information, but
> > in my experience with similar problems, without a list of arguments
> > to the functions from a live remote debug session and/or a
> > crashdump, the problem is going to have to be found by an engineer
> > eyeballing the call graph and seeing how that particular line could
> > end up with a NULL in bp2 or bp.
> 
> Terry hasn't read the debug instructions.  You can load symbols from
> klds.  See the links I pointed to.

I read them.  You didn't provide examples for a non-crashdump
debug session.  Rather than give him incorrect information, I
gave him a workaround that would guarantee that what information
he did obtain would, in fact, be correct.

If you would care to take over, without insisting that he be able
to produce a crash dump (which he has already stated that he has
had trouble doing), be my guest.

The best information I can get him, without finding some way to
fix his obtaining a crashdump issue (I myself have been unable to
obtain one off and on during long stretches, due to the changes
in that area by PHK), is to translate his ddb traceback into
source code line numbers.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at 18:06:36 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> Please take a look at an older thread named (IIRC) vinum or geom bug?
>>> Greg asked for special debug output, but it never happened again for me.
>>> A real murphy bug - it happend on three machines once a day and after
>>> Gregs response nothing happened over weeks.
>>
>> This is the real issue.  Until you supply the information I ask for in
>> the man page or at http://www.vinumvm.org/vinum/how-to-debug.html,
>> only Terry can help you.
>
> This is BS, Greg.
>
> I deal with about a traceback every other day, and sometimes as
> high as 5 in a single day, if it's a busy day for it.

Stack traces are pretty common stuff.  Your point?

> The information I gave him gets him to lines of source code, instead
> of just function names with strange hexadecimal numbers that resolve
> to instruction offsets that may be specific to his compile flags,
> date of checkout of the sources from CVS, etc..

The first step of the link above does the same thing.  But it's only
the first step.

> I don't know about you, but I can't easily write assembly
> instructions to tape, run them the tape through my teeth, and read
> the bits using my dental fillings.

Terry, why don't you come to my debug tutorial at the BSDCon next
month?  I'll show you how to do this properly.  I'm not asking for
people to interpret hex.  I'm asking for people, you included, to find
out what debugging help is available.

> If it's a NULL pointer dereference, the place to find it is by
> turning on what debugging there is, and, if that fails, which it
> probably will,

No, that will find the null pointer dereference pretty quickly.

> by eyeballing the lines of source code in question and understanding
> the code around it well enough that you can tell *how* a pointer
> there could be NULL.  My instructions *get* him those lines of
> source.

You obviously still haven't read the reference.  Do that first, and
come back when you have either understood things or are having
difficulty understanding.  But don't shoot off your mouth without
knowing what's going on.

> If you'll notice from his followup posting of the source in
> question, Vinum is loaded as a module, and it's the FreeBSD code
> that Vinum calls, not Vinum, that's causing the crash.

The bug is almost certainly in Vinum.

> There's no reason to be paranoid about your baby with me; unlike
> some people, personally I like Vinum, so relax and realize that I'm
> not trying to blame your code by trying to help him squeeze more
> information out of the data he *is* able to gather.

This has nothing to do with being paranoid about babies.  This has to
do with people shooting off their mouths in a public forum without
bothering to check details first.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at 17:56:49 -0700, Terry Lambert wrote:
> Greg 'groggy' Lehey wrote:
>>> You don't actually need a crash dump to debug a stack traceback.
>>
>> Great!  So you know the answer?  Please submit a patch.
>>
>> Seriously, this is nonsense.  Yes, it's a null pointer dereference.
>> What?
>
> That is precisely what doing what I suggested discovers, Greg.

Yes, that's what you said already.

> If you haven't seen his response posting:

I saw it and explained why it didn't help.

> Clearly, bp2 or bp is NULL at the time of the dereference.
>
>> Why?
>
> Programmer error.  Either bp2 or bp is a NULL pointer.

You're repeating yourself.

>> How do you fix it?
>
> It depends on the root cause.

*bingo*  Here you are having found the first (obvious) step and acting
as if the problem has been solved.

> I really can't answer it

OK, why don't you either:

1.  Find a way to answer it, or
2.  Keep quiet.

You're just confusing the issue here.

>> Finding the first step doesn't solve the problem.
>
> No.  Finding the first step is *necessary* to solving the problem,
> but you are entirely correct in pointing out that it's not in
> itself *sufficient*.
>
> But it's one step farther along than he was.  I didn't see anyone
> else helping him take that first step, so I did.

Sorry, I don't hack in the middle of the night.  If you had read the
documentation at your disposal, you'd have discovered a lot of help,
and also that this is a known problem that crops up sporadically, and
that so far we can't find out why.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Terry Lambert wrote:
> There's no reason to be paranoid about your baby with me; unlike
> some people, personally I like Vinum, so relax and realize that
> I'm not trying to blame your code by trying to help him squeeze
> more information out of the data he *is* able to gather.

To follow this up:

Sometimes you have to work with the information you have available,
rather than the information you wish you had available.  in an
earlier post, he said that he was having problems collecting
system crash dumps.  So what he has is pretty much what we get to
work with.

If you think that's fun, try translating a traceback that's a set
of hexadecimal instruction addresses for a released product (at
least you get the symbol'ed kernel to look at in gdb) from a
blurry digital photograph of a computer monitor...

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at 17:54:03 -0700, Terry Lambert wrote:
> Eivind Olsen wrote:
>> (kgdb) list *(launch_requests+448)
>> No symbol "launch_requests" in current context.
>> (kgdb) list *(vinumstart+2b2)
>> No symbol "vinumstart" in current context.
>> (kgdb)
>>
>> If anyone wants to take a look at this themselves I've put the compressed
>> (gzip) debug-kernel available on
>> http://eivind.aminor.no/debug/kernel.debug.gz
>> NOTE! It's approx. 13MB compressed!
>
> If this is repeatable for you, it's recommended that you compile
> Vinum statically into your kernel, so that you can look at the
> other symbols in the traceback and obtain source lines for them,
> as well.

No.  It is explicitly discouraged.

> It may be that this will be debuggable without that information, but
> in my experience with similar problems, without a list of arguments
> to the functions from a live remote debug session and/or a
> crashdump, the problem is going to have to be found by an engineer
> eyeballing the call graph and seeing how that particular line could
> end up with a NULL in bp2 or bp.

Terry hasn't read the debug instructions.  You can load symbols from
klds.  See the links I pointed to.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Greg 'groggy' Lehey wrote:
> > Please take a look at an older thread named (IIRC) vinum or geom bug?
> > Greg asked for special debug output, but it never happened again for me.
> > A real murphy bug - it happend on three machines once a day and after
> > Gregs response nothing happened over weeks.
> 
> This is the real issue.  Until you supply the information I ask for in
> the man page or at http://www.vinumvm.org/vinum/how-to-debug.html,
> only Terry can help you.

This is BS, Greg.

I deal with about a traceback every other day, and sometimes as
high as 5 in a single day, if it's a busy day for it.

The information I gave him gets him to lines of source code,
instead of just function names with strange hexadecimal numbers
that resolve to instruction offsets that may be specific to his
compile flags, date of checkout of the sources from CVS, etc..

I don't know about you, but I can't easily write assembly
instructions to tape, run them the tape through my teeth, and
read the bits using my dental fillings.


If it's a NULL pointer dereference, the place to find it is by
turning on what debugging there is, and, if that fails, which
it probably will, by eyeballing the lines of source code in
question and understanding the code around it well enough that
you can tell *how* a pointer there could be NULL.  My instructions
*get* him those lines of source.

If you'll notice from his followup posting of the source in
question, Vinum is loaded as a module, and it's the FreeBSD
code that Vinum calls, not Vinum, that's causing the crash.

There's no reason to be paranoid about your baby with me; unlike
some people, personally I like Vinum, so relax and realize that
I'm not trying to blame your code by trying to help him squeeze
more information out of the data he *is* able to gather.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Greg 'groggy' Lehey wrote:
> > You don't actually need a crash dump to debug a stack traceback.
> 
> Great!  So you know the answer?  Please submit a patch.
> 
> Seriously, this is nonsense.  Yes, it's a null pointer dereference.
> What?

That is precisely what doing what I suggested discovers, Greg.

If you haven't seen his response posting:

(kgdb) list *(g_dev_strategy+29)
0xc02e812d is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:415).
410 KASSERT(cp->acr || cp->acw,
411 ("Consumer with zero access count in g_dev_strategy"));
412
413 bp2 = g_clone_bio(bp);
414 KASSERT(bp2 != NULL, ("XXX: ENOMEM in a bad place"));
415 bp2->bio_offset = (off_t)bp->bio_blkno << DEV_BSHIFT;
416 KASSERT(bp2->bio_offset >= 0,
417 ("Negative bio_offset (%jd) on bio %p",
418 (intmax_t)bp2->bio_offset, bp));
419 bp2->bio_length = (off_t)bp->bio_bcount;


Clearly, bp2 or bp is NULL at the time of the dereference.


> Why?

Programmer error.  Either bp2 or bp is a NULL pointer.


> How do you fix it?

It depends on the root cause.  If the root cause is that the bp is
NULL, then I'd hope that it would have been caught higher up; if it
wasn't, then I'd hope that g_clone_bio(bp) would have returned NULL.

Is the KASSERT() active at the time of the problem?  I don't know;
if it isn't, it probably should be converted to an if()...panic().

If it is, then I'd have to expect that the validity fell out from
under it as a result of an interrupt, preemption, reentrancy (if
the locking didn't prevent it) or SMP races (if the locking didn't
prevent it).

I really can't answer it for the same reason that I couldn't locate
the line in the source code that was failing for him from his
posting of hex offsets into functions compiled from unknown source
code: I don't have his object set for the problem in question, nor
his debug kernel.


> Finding the first step doesn't solve the problem.

No.  Finding the first step is *necessary* to solving the problem,
but you are entirely correct in pointing out that it's not in
itself *sufficient*.

But it's one step farther along than he was.  I didn't see anyone
else helping him take that first step, so I did.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Eivind Olsen wrote:
> (kgdb) list *(launch_requests+448)
> No symbol "launch_requests" in current context.
> (kgdb) list *(vinumstart+2b2)
> No symbol "vinumstart" in current context.
> (kgdb)
> 
> If anyone wants to take a look at this themselves I've put the compressed
> (gzip) debug-kernel available on
> http://eivind.aminor.no/debug/kernel.debug.gz
> NOTE! It's approx. 13MB compressed!

If this is repeatable for you, it's recommended that you compile
Vinum statically into your kernel, so that you can look at the
other symbols in the traceback and obtain source lines for them,
as well.  It may be that this will be debuggable without that
information, but in my experience with similar problems, without
a list of arguments to the functions from a live remote debug
session and/or a crashdump, the problem is going to have to be
found by an engineer eyeballing the call graph and seeing how
that particular line could end up with a NULL in bp2 or bp.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bge & vlan stranges

[Terry Lambert]

Tom Samplonius wrote:
>   Probably wouldn't be affective anyhow.  L2 switches assume that they can
> encapsulate 1500 byte ethernet frames into 802.1q properly.  It is part of
> the 802.1q standard.  If the NIC can't understand the frame because it is
> now 1504 bytes, it will be a layer 2 discard.  There will be no ICMP
> message sent in this case.  You could argue that the switch should also be
> configured with a 1456 byte MTU to allow for the addition of the 802.1q
> encapsulation.  But a L2 switch is not going to send a L3 message like a
> ICMP "unable to fragment" fragment.  So MTU detection buys you nothing.
> 
>   The fact of the matter is, if you use 802.1q encapsulation, the total
> frame size can be 1504.  That is the standard.

This is truly evil.

I would suggest, though, that L2 switches shouldn't be boundaries
for this type of encapsulation, if this is the case.  Worst case,
though, an attempt at PMTU through a switch that did this anyway
should end up with whatever MTU the host has setup.

I expect that the 802.1q encapsulation of 1500 MTU packets (yielding
1504 MTU packets on the wire) was actually intended to operate in
switch-to-switch trunking, not sitch-to-host trunking.

Effectively, this means the machine that's doing it's own VLAN
stuff is really a trunk endpoint, not a traditional ethernet
endpoint.

I have no problem with this.

I'm just pointing out that not all cards will be able to support
the idea, and that if you depend on arbitrary cards supporting
it, you are going to get shot in the foot.

You'll agree that a PMTU discovery through an L2 switch that was
doing 802.1q to a machine with a card that couldn't handle more
than 1500 MTU total, should result in a discovery of "1496" and
not "1500", right?

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at 16:47:13 +0200, Eivind Olsen wrote:
> --On 2. august 2003 02:11 -0700 Terry Lambert <[EMAIL PROTECTED]>
> wrote:
>>> db> trace
>>> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
>>> g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
>>> launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6)
>>> at vinumstart+0x2b2
>> gdb -k kernel.debug
>> (gdb) list *(g_dev_strategy+29)
>> [ ... ]
>> (gdb) list *(launch_requests+448)
>> [ ... ]
>> (gdb) list *(vinumstart+2b2)
>> [ ... ]
>> Will give you the exact source lines involved, assuming you
>> built a debug kernel.
>
> I did. At least I've tried to. :)
> (I have a kernel.debug which was compiled at the same time as the real
> kernel I'm using, and it's approx. 30MB in size).
>
>> You don't actually need a crash dump to debug a stack traceback.
>
> This is what I found by using those commands you mentioned:
>
> [EMAIL PROTECTED]:~/tmp/debug > gdb -k kernel.debug
> GNU gdb 5.2.1 (FreeBSD)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-undermydesk-freebsd"...
> (kgdb) list *(g_dev_strategy+29)

This is almost certainly the wrong function.  At the very list you
should look at the arguments passed to it.

> (kgdb) list *(launch_requests+448)
> No symbol "launch_requests" in current context.
> (kgdb) list *(vinumstart+2b2)
> No symbol "vinumstart" in current context.
> (kgdb)

Read the links I just sent you.  You haven't loaded the Vinum symbols.

> If anyone wants to take a look at this themselves I've put the compressed
> (gzip) debug-kernel available on
> http://eivind.aminor.no/debug/kernel.debug.gz
> NOTE! It's approx. 13MB compressed!

The kernel's not much use by itself.  

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at 17:00:59 +0200, Eivind Olsen wrote:
> --On 2. august 2003 11:16 +0200 Bernd Walter <[EMAIL PROTECTED]>
> wrote:
>>> Looks like a problem in vinum.  The other backtrace was the same, right?
>> Please take a look at an older thread named (IIRC) vinum or geom bug?
>> Greg asked for special debug output, but it never happened again for me.
>> A real murphy bug - it happend on three machines once a day and after
>> Gregs response nothing happened over weeks.
>
> Are you thinking of the thread "vinum and/or geom panic on alpha" from 10th
> of June? I forgot to mention this but my system is i386 uniprocessor
> (Pentium2 at 450MHz).
>
> In case it's relevant, yes I do run vinum:

Yes, of course you do.  That's what the stack trace says, and that's
why people mentioned Vinum in the first place:

On Saturday,  2 August 2003 at 10:11:24 +0200, Eivind Olsen wrote:
> Here's some output from DDB:
>
> db> trace
> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
> vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
> vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6

On Saturday,  2 August 2003 at 11:16:21 +0200, Bernd Walter wrote:
> On Sat, Aug 02, 2003 at 02:00:52AM -0700, Kris Kennaway wrote:
>> On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:
>>
>>> db> trace
>>> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
>>> launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
>>> vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
>>> vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6
>>
>> Looks like a problem in vinum.  The other backtrace was the same, right?
>
> Please take a look at an older thread named (IIRC) vinum or geom bug?
> Greg asked for special debug output, but it never happened again for me.
> A real murphy bug - it happend on three machines once a day and after
> Gregs response nothing happened over weeks.

This is the real issue.  Until you supply the information I ask for in
the man page or at http://www.vinumvm.org/vinum/how-to-debug.html,
only Terry can help you.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: Yet another crash in FreeBSD 5.1

[Greg 'groggy' Lehey]

On Saturday,  2 August 2003 at  2:11:24 -0700, Terry Lambert wrote:
> Eivind Olsen wrote:
>> Can anyone suggest what I do next to find out about this crash?
>
>> Fatal trap 12: page fault while in kernel mode
>> fault virtual address   = 0x14
>
> Dereference of NULL pointer; reference is for element at offset
> 0x14 in some structure; this is the equivalent of 5 32 bit ints
> or pointers into the structure.
>
>> db> trace
>> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
>> launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
>> vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
>
> gdb -k kernel.debug
> (gdb) list *(g_dev_strategy+29)
> [ ... ]
> (gdb) list *(launch_requests+448)
> [ ... ]
> (gdb) list *(vinumstart+2b2)
> [ ... ]
>
> Will give you the exact source lines involved, assuming you
> built a debug kernel.
>
> You don't actually need a crash dump to debug a stack traceback.

Great!  So you know the answer?  Please submit a patch.

Seriously, this is nonsense.  Yes, it's a null pointer dereference.
What?  Why?  How do you fix it?  Finding the first step doesn't solve
the problem.

Greg
--
See complete headers for address and phone numbers


pgp0.pgp
Description: PGP signature

Re: bge & vlan stranges

[Terry Lambert]

Boris Kovalenko wrote:
> No, this is test machine, I have installed it two days ago and have
> firewall_type="OPEN" in my settings. So I have not disabled MTU path
> discovery You are speaking of. Nevertheless, what is "substracted from
> available MTU?" Why? The correct way it should work:
> 1500 bytes packet + 14 bytes ethernet header + 4 bytes CRC = 1518 bytes
> is standard ethernet frame and
> 1500 bytes packet + 14 bytes ethernet header + 4 bytes 802.1Q tag + 4
> bytes CRC = 1522 bytes of standard 802.1Q encapsulated frame. All 802.1Q
> realizations I know working the same.

The way it *does* work is:

MTU = 1518
- 14 bytes ethernet header
- 4 bytes CRC
= 1500

MTU = 1518
- 14 bytes ethernet header
- 4 bytes 802.1Q tag
- 4 bytes CRC
= 1496

...unless you have some strange card magic that lets it send packets
larger than allowed for by the standard.

BTW: the reason the length is what it is by default is that the
ethernet standardard is a CSMA/CD type transport (designed after
the old "Aloha" radio system), and the length is picked to be as
large as possible for the bandwidth to provide for a medium that
has as few collisions as possible.  Effectively, since people
transmit randomly, with a random back-off on collisions, this is
a hash function with the length chosen to represent a best-guess
effort at an 85% fill rate.

Relying on card magic is bad, unless you can guarantee a completely
homogenous environment (i.e. everyone has the same card magic).

Path MTU discovery is an issue on packets with the DF (Don't Frag.")
bit set, since those packets, if they are sent from a system with a
high MTU to another with the same MTU, but an intermediate MTU is
smaller, get "black holed" (hence the term "black hole routes").

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: groff and mkdep?

[Peorth]

I wasn't running make with -e.
I believe the commandline was similar to 'make -DNO_KERBEROS -DNO_WERROR
buildworld', and never saw miscellaneous switches passed. So, yeah, it
worked only after I unset CFLAGS and CXXFLAGS for that session's
environment.
Like I said, I'm generally new to this. Not so much FreeBSD as why
something on that level was breaking.
I didn't set -e, and didn't see it miscellaneously set someplace, so
could this be a bug that I stumbled across? That was using the
5.1-RELEASE version of make to do that buildworld of CURRENT, so I'll
have to check later if it has similar behavior with CURRENT's make.

On Sat, 2003-08-02 at 10:23, Ruslan Ermilov wrote:
> On Fri, Aug 01, 2003 at 11:08:33PM -0700, Peorth wrote:
> > That seems so weird.
> > CFLAGS and CXXFLAGS were set to something in the general environment,
> > for non-port builds, but I thought the FreeBSD make system used for
> > ports and such wouldn't get polluted by simply having that defined as a
> > variable in the env. *headscratch* Maybe just my mistake, but thanks a
> > lot. I never would've realized it was CFLAGS! Perhaps make should warn
> > if setting CFLAGS/CXXFLAGS are going to pollute, at least on certain
> > things like in the /usr/src tree, though up 'till that point, everything
> > built fine, too. *shrug*
> > 
> Hmm.  From the make(1) manpage:
> 
> : The four different classes of variables (in order of increasing prece-
> : dence) are:
> : 
> : Environment variables
> :  Variables defined as part of make's environment.
> : 
> : Global variables
> :  Variables defined in the makefile or in included makefiles.
> : 
> : Command line variables
> :  Variables defined as part of the command line.
> : 
> : Local variables
> :  Variables that are defined specific to a certain target.  The
> :  seven local variables are as follows:
> 
> Are you telling me that setting CFLAGS in the ENVIRONMENT causes
> this strange behavior?  (I cannot reproduce it here, because
> environment variables are of a lower precedence than globals.)
> 
> Are you sure you weren't running make(1) with the -e option?
> (I can reproduce this with this option, as it causes environment
> variables to take higher precedence than globals.)
> 
> 
> Cheers,

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Anyone use WINE at all anywhere?

[Scot W. Hetzel]

From: "Julian Elischer" <[EMAIL PROTECTED]>
> 
> Is the re ANYONE that uses wine on -current...?
> 
> for that matter, a -current user that uses wine on 4.x?
> 
I set up wine on current to run D2GS (Diablo II Game Server) using XVFB.

I haven't used wine for any other purposes than this.

Scot
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Anyone use WINE at all anywhere?

[Alex Zepeda]

On Fri, Aug 01, 2003 at 05:38:33PM -0700, Julian Elischer wrote:

> Is the re ANYONE that uses wine on -current...?

Sure, I use wine on current.  However, the problems I seem to be getting 
are wine related and not due to problems with fbsd.. as far as I can tell.

- alex
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: newsyslog problems with -C

[Garance A Drosihn]

At 2:38 AM +0200 8/2/03, Riccardo Torrini wrote:
Looking into sources I found two close(fd).
Here is the patch:
-8<-[ patch ]-8<-
# diff -u newsyslog.c.orig newsyslog.c
--- newsyslog.c.origSun May 25 18:46:13 2003
+++ newsyslog.c Sat Aug  2 02:28:50 2003
@@ -1764,7 +1764,6 @@
failed = fchown(fd, ent->uid, ent->gid);
if (failed)
err(1, "can't fchown temp file %s", tempfile);
-   (void) close(fd);
}
}
-8<-[ patch ]-8<-
I committed this in -current.  I'll MFC it into -stable in a
few days.  Thanks!
--
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically

[Jens Rehsack]

On 02.08.2003 01:29, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote:
On 29.07.2003 19:21, Mike Makonnen wrote:

>On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
>Yeah, I'll take care of this. I had asked scott to mail me his final
>patch so I could commit it, but I never heard back from him. I'll
>dig out the revisions from my mail archives and combine the
>two.
You can mail me the patch first, so that I can test it before you
commit it, if you want.
Hi Jens,

Can you apply the attached patches and let me know how it goes?

Cheers.
Is there a difference to those Scot send me yesterday evening?
If not, I'm working on it, but after a hard week I took a free
day today and tomorrow starts with an meeting. So don't expect
results of test before monday morning (7:00 GMT)
Best regards,
Jens
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vfprintf() has a 4096-byte memory leak?

[Dan Nelson]

In the last episode (Aug 02), Ryan T. Dean said:
> Aha.  setbuf(stdout, NULL); does prevent the buffer from being
> allocated. However, in the case of stdout and stderr, if you don't
> setbuf() it to null, a buffer is malloc'd.  The corresponding free()
> is in fclose.  So, if you [f]printf() to stdout/stderr, and
> fclose(stdout/stderr), you are fine.  If, however, you don't know
> that buffers are being allocated for stdin/stdout and don't fclose()
> or setbuf() to NULL, a 4096-byte chunk of memory is allocated and
> never freed.  For shits and giggles, I checked a DeadRat 8 box - no
> buffering by default.  I guess the only reason I'm worried is the
> potential number of programs in the ports tree originally written on
> a system where stdout/stderr behave differently, or people (like
> myself) who didn't have a clue any sort of output buffering was
> enabled on stdout/stderr, and as a result have memory leaks.  If the
> porter did their job, it shouldn't be an issue (was caught, patched,
> and the patch submitted upstream), but, then, we never know, right?

A memory leak is memory allocated, used, then discarded by the program
without freeing, possibly repeatedly so you build up memory that the
program never uses and cannot reclaim.  These buffers /are/ used, every
time you use stdio to stdout or stderr, so it's not a leak.  They're
simply not freed on exit.

> int main (void)
> {
>   printf("Test\n");
>   return 0;
> }
> test1 memory debug output:
> 1059825156: 1: *** alloc: at 'ra=0x2816ee86' for 4096 bytes, got '0x804b008|s1'
> 1059825156: 1: top 10 allocations:
> 1059825156: 1:  total-size  count in-use-size  count  source
> 1059825156: 1:4096  14096  1  ra=0x2816ee86
> 1059825156: 1:4096  14096  1  Total of 1
> 1059825156: 1: dumping not-freed pointers changed since 0:
> 1059825156: 1:  not freed: '0x804b008|s1' (4096 bytes) from 'ra=0x2816ee86'
> 1059825156: 1:  total-size  count  source
> 1059825156: 1:4096  1  ra=0x2816ee86
> 1059825156: 1:4096  1  Total of 1
> 1059825156: 1:  unknown memory: 1 pointer, 4096 bytes

The stdio buffers are correctly flushed by exit(), but fclose() is not
called to free the buffers.  Why bother when the memory will be
deallocated in .0001 seconds when the process exits? :)  If you want,
you can swap the comment on the two lines in
src/lib/libc/stdio/findfp.c to close all open files on exit:

void
_cleanup()
{   
/* (void) _fwalk(fclose); */
(void) _fwalk(__sflush);/* `cheating' */
}


-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Mozilla V1.3.1 crashing on FreeBSD 5.1-C (older cvsup level)

[Joe Marcus Clarke]

On Sat, 2003-08-02 at 16:20, Tom Parquette wrote:
> Periodically, Mozilla V1.3.1 will appear to crash on some web sites.
> I finally got the following messages out of it.  It's not much but I was 
> hoping someone might have an idea.
> 
> This was from an attempt to point at www.historychannel.com.  TIA

Try upgrading to Mozilla 1.4.  There were numerous problems with 1.3.x. 
I am unable to reproduce this on 1.4 compiled with Xft and the GTK+-2
GUI.

Joe

> 
> $ export DISPLAY=Stargate.Tom.Parquette.name:0
> $ mozilla
> No running window found.
> /dev/dsp: No such file or directory
> open dsp: No such file or directory
> Gdk-ERROR **: BadAccess (attempt to access private resource denied)
>serial 26 error_code 10 request_code 147 minor_code 1
> $
> 
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


signature.asc
Description: This is a digitally signed message part

Re: bge & vlan stranges

[Tom Samplonius]

On Sat, 2 Aug 2003, Terry Lambert wrote:

...
> I suppose you want to do this because you are trunking a channel
> that goes to a border device, and for some reason you have disabled
> receipt of all ICMP, instead of only abusable ICMP, and thus you
> have broken end-to-end path MTU discovery.
> 
> It would be best if you were to simply fix your ICMP.

  Probably wouldn't be affective anyhow.  L2 switches assume that they can
encapsulate 1500 byte ethernet frames into 802.1q properly.  It is part of
the 802.1q standard.  If the NIC can't understand the frame because it is
now 1504 bytes, it will be a layer 2 discard.  There will be no ICMP
message sent in this case.  You could argue that the switch should also be
configured with a 1456 byte MTU to allow for the addition of the 802.1q
encapsulation.  But a L2 switch is not going to send a L3 message like a
ICMP "unable to fragment" fragment.  So MTU detection buys you nothing.

  The fact of the matter is, if you use 802.1q encapsulation, the total
frame size can be 1504.  That is the standard.

> -- Terry


Tom

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Mozilla V1.3.1 crashing on FreeBSD 5.1-C (older cvsup level)

[Tom Parquette]

Periodically, Mozilla V1.3.1 will appear to crash on some web sites.
I finally got the following messages out of it.  It's not much but I was 
hoping someone might have an idea.

This was from an attempt to point at www.historychannel.com.  TIA

$ export DISPLAY=Stargate.Tom.Parquette.name:0
$ mozilla
No running window found.
/dev/dsp: No such file or directory
open dsp: No such file or directory
Gdk-ERROR **: BadAccess (attempt to access private resource denied)
  serial 26 error_code 10 request_code 147 minor_code 1
$
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ACLS on UFS2 from FreeBSD 5.1-RELEASE install.

[Scott M. Likens]

Has anyone noticed the ACLS being disabled?

tunefs -p /dev/da1s1c shows that ACLS are disabled on every partition I
have, i've gone through them all.

any reason why?



tunefs: ACLs: (-a) disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  2048
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: optimization preference: (-o)  time
tunefs: volume label: (-L) 


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)

[Marcel Moolenaar]

On Sat, Aug 02, 2003 at 01:53:31AM -0700, Terry Lambert wrote:
> Marcel Moolenaar wrote:
> > But if we only use the dynamic allocation then it can only fail for
> > a combination of 3rd party code.
> 
> You meant to say static here, e.g. when there are two libraries
> linked into a single aplication, and both libraries want to get
> entry #6, right?

Yes. My wording was incomplete.

> In the dynamic case, this will Just Work(tm), because each one
> will end up getting a different value.

Correct.

-- 
 Marcel Moolenaar USPA: A-39004  [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on i386/i386

[Tinderbox]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on amd64/amd64

[Tinderbox]

TB --- 2003-08-02 17:11:23 - starting CURRENT tinderbox run for amd64/amd64
TB --- 2003-08-02 17:11:23 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 17:13:57 - building world
TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include
>>> stage 4: building libraries
[...]
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/time.c: 
Input/output error
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/transited.c:
 Input/output error
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/verify_init.c:
 Input/output error
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/verify_user.c:
 Input/output error
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/version.c:
 Input/output error
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/warn.c: 
Input/output error
cc1: 
/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/crypto/heimdal/lib/krb5/write_message.c:
 Input/output error
mkdep: compile failed
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/kerberos5/lib/libkrb5.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
*** Error code 1

Stop in /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src.
TB --- 2003-08-02 17:23:58 - /usr/bin/make returned exit code  1 
TB --- 2003-08-02 17:23:58 - ERROR: failed to build world
TB --- 2003-08-02 17:23:58 - tinderbox aborted

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: groff and mkdep?

[Ruslan Ermilov]

On Fri, Aug 01, 2003 at 11:08:33PM -0700, Peorth wrote:
> That seems so weird.
> CFLAGS and CXXFLAGS were set to something in the general environment,
> for non-port builds, but I thought the FreeBSD make system used for
> ports and such wouldn't get polluted by simply having that defined as a
> variable in the env. *headscratch* Maybe just my mistake, but thanks a
> lot. I never would've realized it was CFLAGS! Perhaps make should warn
> if setting CFLAGS/CXXFLAGS are going to pollute, at least on certain
> things like in the /usr/src tree, though up 'till that point, everything
> built fine, too. *shrug*
> 
Hmm.  From the make(1) manpage:

: The four different classes of variables (in order of increasing prece-
: dence) are:
: 
: Environment variables
:  Variables defined as part of make's environment.
: 
: Global variables
:  Variables defined in the makefile or in included makefiles.
: 
: Command line variables
:  Variables defined as part of the command line.
: 
: Local variables
:  Variables that are defined specific to a certain target.  The
:  seven local variables are as follows:

Are you telling me that setting CFLAGS in the ENVIRONMENT causes
this strange behavior?  (I cannot reproduce it here, because
environment variables are of a lower precedence than globals.)

Are you sure you weren't running make(1) with the -e option?
(I can reproduce this with this option, as it causes environment
variables to take higher precedence than globals.)


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature

[current tinderbox] failure on alpha/alpha

[Tinderbox]

TB --- 2003-08-02 16:00:07 - starting CURRENT tinderbox run for alpha/alpha
TB --- 2003-08-02 16:00:07 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 16:02:22 - building world
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-08-02 17:08:46 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sat Aug  2 17:08:46 GMT 2003
[...]
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwdev.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwdma.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwmem.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwohci.c
cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys

Re: MSDOSFS woes

[Bruce Evans]

On Sat, 2 Aug 2003, Ruslan Ermilov wrote:

> While working with Marcel on a bootable CD-ROM for IA64 issue,
> I've stumbled upon the following problem.  I needed to increase
> the size of the EFI partition (which is an MS-DOS file system)
> to 64M, and that made two of my machines stuck solidly -- a lot
> of process are waiting on the "wdrain" event.
>
> The issue is not IA64 specific, both machines in question are
> i386.  The following script makes my machines unhappy:
>
> EFISZ=131072
> dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ
> md=`mdconfig -a -t vnode -f $BASE/$EFIPART`
> newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md
> mount -t msdosfs /dev/$md /mnt
> dd if=/dev/zero of=/mnt/foo

Try fixing newfs_msdos so that the -s option actually works, or adjusting
sizes.  Otherwise the file system doesn't fit on the device:

Filesystem1024-blocksUsed   Avail Capacity iused   ifree %iused  Mounted on
/dev/md065568  64   65504 0% 512   0  100%   /mnt

so bad things should be expected to happen when msdosfs runs off the end.
The kernel should handle this gracefully, but might not.

newfs has an end-of-partition check to avoid this problem.

I still get assorted panics and strange behaviour after increasing the
device size, but suspect unrelated bugs from version skew.  The
strangeness was the second dd failing with EINVAL for one run and with
the correct error ENOSPC for another.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [current tinderbox] failure on i386/i386

[Dag-Erling Smørgrav]

Scott Long <[EMAIL PROTECTED]> writes:
> Anyone know what is up with this?  I'm not getting it on my LINT builds.

revision 1.41
date: 2003/08/01 17:00:49;  author: obrien;  state: Exp;  lines: +1 -1
Fix kernel build -- 'c' was the unused var, not 'lines'.

DES
-- 
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: MSDOSFS woes

[Ruslan Ermilov]

On Sat, Aug 02, 2003 at 05:00:45PM +0100, Bruce Cran wrote:
> On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote:
> > Gang, :-)
> > 
> > While working with Marcel on a bootable CD-ROM for IA64 issue,
> > I've stumbled upon the following problem.  I needed to increase
> > the size of the EFI partition (which is an MS-DOS file system)
> > to 64M, and that made two of my machines stuck solidly -- a lot
> > of process are waiting on the "wdrain" event.
> > 
> > The issue is not IA64 specific, both machines in question are
> > i386.  The following script makes my machines unhappy:
> > 
> > EFISZ=131072
> > dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ
> > md=`mdconfig -a -t vnode -f $BASE/$EFIPART`
> > newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md
> > mount -t msdosfs /dev/$md /mnt
> > dd if=/dev/zero of=/mnt/foo
> > 
> > Changing to the -F 16 does not take any (good) effect.
> > Anyone is interested in narrowing it down?
> > 
> 
> I've also seen this happening on my Athlon XP system running -CURRENT.  I 
> presumed it was the deadlock in vnode-backed md disks.  It seems that when
> a lot of disk activity occurs on the md partition, the process stops - 
> this is on a 30GB image containing UFS2 partitions /dev/md0s1[a,d,e].
> Attempting to reboot results in the message 'processes would not die - ps
> axl advised', I had to reset the computer because nothing more happened.
> 
Yes, the same here.

And I have just been able to reproduce this with only a 16MB MS-DOS file
system on a vnode backed md(4) device.


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature

Re: MSDOSFS woes

[Bruce Cran]

On Sat, Aug 02, 2003 at 06:08:50PM +0300, Ruslan Ermilov wrote:
> Gang, :-)
> 
> While working with Marcel on a bootable CD-ROM for IA64 issue,
> I've stumbled upon the following problem.  I needed to increase
> the size of the EFI partition (which is an MS-DOS file system)
> to 64M, and that made two of my machines stuck solidly -- a lot
> of process are waiting on the "wdrain" event.
> 
> The issue is not IA64 specific, both machines in question are
> i386.  The following script makes my machines unhappy:
> 
> EFISZ=131072
> dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ
> md=`mdconfig -a -t vnode -f $BASE/$EFIPART`
> newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md
> mount -t msdosfs /dev/$md /mnt
> dd if=/dev/zero of=/mnt/foo
> 
> Changing to the -F 16 does not take any (good) effect.
> Anyone is interested in narrowing it down?
> 

I've also seen this happening on my Athlon XP system running -CURRENT.  I 
presumed it was the deadlock in vnode-backed md disks.  It seems that when
a lot of disk activity occurs on the md partition, the process stops - 
this is on a 30GB image containing UFS2 partitions /dev/md0s1[a,d,e].
Attempting to reboot results in the message 'processes would not die - ps
axl advised', I had to reset the computer because nothing more happened.

--
Bruce Cran
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [current tinderbox] failure on i386/i386

[Scott Long]

Anyone know what is up with this?  I'm not getting it on my LINT builds.

Scott

Tinderbox wrote:
TB --- 2003-08-02 06:21:10 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-08-02 06:21:10 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 06:23:46 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
Rebuilding the temporary build tree
stage 1: legacy release compatibility shims
stage 1: bootstrap tools
stage 2: cleaning up the object tree
stage 2: rebuilding the object tree
stage 2: build tools
stage 3: cross tools
stage 4: populating 
/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
stage 4: building libraries
stage 4: make dependencies
stage 4: building everything..
TB --- 2003-08-02 07:29:24 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
Kernel build for GENERIC started on Sat Aug  2 07:29:24 GMT 2003
Kernel build for GENERIC completed on Sat Aug  2 07:43:54 GMT 2003
TB --- 2003-08-02 07:43:54 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-08-02 07:43:54 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
Kernel build for LINT started on Sat Aug  2 07:43:54 GMT 2003
[...]
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_thr.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_kthread.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c: In function 
`db_ktr_all':
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: 
`lines' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: 
for each function it appears in.)
/vol/vol0/users/des/tinderbo

MSDOSFS woes

[Ruslan Ermilov]

Gang, :-)

While working with Marcel on a bootable CD-ROM for IA64 issue,
I've stumbled upon the following problem.  I needed to increase
the size of the EFI partition (which is an MS-DOS file system)
to 64M, and that made two of my machines stuck solidly -- a lot
of process are waiting on the "wdrain" event.

The issue is not IA64 specific, both machines in question are
i386.  The following script makes my machines unhappy:

EFISZ=131072
dd if=/dev/zero of=$BASE/$EFIPART count=$EFISZ
md=`mdconfig -a -t vnode -f $BASE/$EFIPART`
newfs_msdos -F 12 -S 512 -h 4 -o 0 -s $EFISZ -u 16 $md
mount -t msdosfs /dev/$md /mnt
dd if=/dev/zero of=/mnt/foo

Changing to the -F 16 does not take any (good) effect.
Anyone is interested in narrowing it down?


Cheers,
-- 
Ruslan Ermilov  Sysadmin and DBA,
[EMAIL PROTECTED]   Sunbay Software Ltd,
[EMAIL PROTECTED]   FreeBSD committer


pgp0.pgp
Description: PGP signature

Re: vinum bug? (Re: Yet another crash in FreeBSD 5.1)

[Eivind Olsen]

--On 2. august 2003 11:16 +0200 Bernd Walter <[EMAIL PROTECTED]> 
wrote:
Looks like a problem in vinum.  The other backtrace was the same, right?
Please take a look at an older thread named (IIRC) vinum or geom bug?
Greg asked for special debug output, but it never happened again for me.
A real murphy bug - it happend on three machines once a day and after
Gregs response nothing happened over weeks.
Are you thinking of the thread "vinum and/or geom panic on alpha" from 10th 
of June? I forgot to mention this but my system is i386 uniprocessor 
(Pentium2 at 450MHz).

In case it's relevant, yes I do run vinum:

vinum -> l
2 drives:
D WHITE State: up   /dev/ad2s1e A: 0/113046 MB (0%)
D BLACK State: up   /dev/ad0s1d A: 0/113046 MB (0%)
6 volumes:
V var   State: up   Plexes:   2 Size:   6144 MB
V usrlocal  State: up   Plexes:   2 Size:   6144 MB
V tmp   State: up   Plexes:   1 Size:255 MB
V usr   State: up   Plexes:   2 Size:   6144 MB
V home  State: up   Plexes:   2 Size:   8192 MB
V storage   State: up   Plexes:   1 Size:168 GB
10 plexes:
P var.p0  C State: up   Subdisks: 1 Size:   6144 MB
P var.p1  C State: up   Subdisks: 1 Size:   6144 MB
P usrlocal.p0 C State: up   Subdisks: 1 Size:   6144 MB
P usrlocal.p1 C State: up   Subdisks: 1 Size:   6144 MB
P tmp.p0  S State: up   Subdisks: 2 Size:255 MB
P usr.p0  C State: up   Subdisks: 1 Size:   6144 MB
P usr.p1  C State: up   Subdisks: 1 Size:   6144 MB
P home.p0 C State: up   Subdisks: 1 Size:   8192 MB
P home.p1 C State: up   Subdisks: 1 Size:   8192 MB
P storage.p0  S State: up   Subdisks: 2 Size:168 GB
12 subdisks:
S var.p0.s0 State: up   D: BLACKSize:   6144 MB
S var.p1.s0 State: up   D: WHITESize:   6144 MB
S usrlocal.p0.s0State: up   D: BLACKSize:   6144 MB
S usrlocal.p1.s0State: up   D: WHITESize:   6144 MB
S tmp.p0.s0 State: up   D: BLACKSize:127 MB
S tmp.p0.s1 State: up   D: WHITESize:127 MB
S usr.p0.s0 State: up   D: BLACKSize:   6144 MB
S usr.p1.s0 State: up   D: WHITESize:   6144 MB
S home.p0.s0State: up   D: BLACKSize:   8192 MB
S home.p1.s0State: up   D: WHITESize:   8192 MB
S storage.p0.s0 State: up   D: BLACKSize: 84 GB
S storage.p0.s1 State: up   D: WHITESize: 84 GB
vinum ->
--
Regards / Hilsen
Eivind Olsen
<[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

usbd does not use detach

[Jan Stocker]

Hi,
my usbd on -current does not call my script (or any command) given in
the detach-value in usbd.conf. This is the output


usbd: ucom0 matches ucom0
usbd: Found action 'Palm Handheld Device' for Palm Handheld, Palm, Inc.
at ucom0usbd: action 0: Palm Handheld Device
  vndr=0x0830 prdct=0x0060
  devname: ucom0
  attach='/usr/sbin/ppp -auto palm'
  detach='/test.sh'
usbd: Setting DEVNAME='ucom0'
usbd: Executing '/usr/sbin/ppp -auto palm'
Working in auto mode
Using interface: tun0
usbd: '/usr/sbin/ppp -auto palm' is ok
usbd: processing event queue on /dev/usb
usbd: driver-detach event cookie=3217029340 devname=ucom0
USB_EVENT_DRIVER_DETACH




P.S. i am tring to get my usb palm working with FreeBSD. The most
prefered solution is doing this with a ppp connection and a network sync
(all solutions i found in web are not correct but a good advice).
Does anyone has a USB palm directly syncing over USB?

-- 
Jan Stocker <[EMAIL PROTECTED]>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Eivind Olsen]

--On 2. august 2003 02:11 -0700 Terry Lambert <[EMAIL PROTECTED]> 
wrote:
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6)
at vinumstart+0x2b2
gdb -k kernel.debug
(gdb) list *(g_dev_strategy+29)
[ ... ]
(gdb) list *(launch_requests+448)
[ ... ]
(gdb) list *(vinumstart+2b2)
[ ... ]
Will give you the exact source lines involved, assuming you
built a debug kernel.
I did. At least I've tried to. :)
(I have a kernel.debug which was compiled at the same time as the real 
kernel I'm using, and it's approx. 30MB in size).

You don't actually need a crash dump to debug a stack traceback.
This is what I found by using those commands you mentioned:

[EMAIL PROTECTED]:~/tmp/debug > gdb -k kernel.debug
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-undermydesk-freebsd"...
(kgdb) list *(g_dev_strategy+29)
0xc02e812d is in g_dev_strategy (/usr/src/sys/geom/geom_dev.c:415).
410 KASSERT(cp->acr || cp->acw,
411 ("Consumer with zero access count in g_dev_strategy"));
412
413 bp2 = g_clone_bio(bp);
414 KASSERT(bp2 != NULL, ("XXX: ENOMEM in a bad place"));
415 bp2->bio_offset = (off_t)bp->bio_blkno << DEV_BSHIFT;
416 KASSERT(bp2->bio_offset >= 0,
417 ("Negative bio_offset (%jd) on bio %p",
418 (intmax_t)bp2->bio_offset, bp));
419 bp2->bio_length = (off_t)bp->bio_bcount;
(kgdb) list *(launch_requests+448)
No symbol "launch_requests" in current context.
(kgdb) list *(vinumstart+2b2)
No symbol "vinumstart" in current context.
(kgdb)

If anyone wants to take a look at this themselves I've put the compressed 
(gzip) debug-kernel available on 
http://eivind.aminor.no/debug/kernel.debug.gz
NOTE! It's approx. 13MB compressed!

--
Regards / Hilsen
Eivind Olsen
<[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vinum bug? (Re: Yet another crash in FreeBSD 5.1)

[Eivind Olsen]

[Sending to [EMAIL PROTECTED], and Kris copied in Greg so I'll also do that]

--On 2. august 2003 02:00 -0700 Kris Kennaway <[EMAIL PROTECTED]> wrote:
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
launch_requests+0x448 vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6)
at vinumstart+0x2b2 vinumstrategy(c5ada2d0,0,c09719b0,40,0) at
vinumstrategy+0xa6
Looks like a problem in vinum.  The other backtrace was the same, right?
Basically the same, yes. Some differences (and many similarities) in the 
addresses that were referenced. And also almost the same output from the 
"trace" command (I see that my first example is missing the dofilewrite() 
between vn_write() and write() but that might just be because I've 
forgotten to write down that line (I wrote all this down by hand).

So, it looks like it's the same crash again (well, it does look like that 
to my untrained eye).

--
Regards / Hilsen
Eivind Olsen
<[EMAIL PROTECTED]>
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sil3112 controller

[Christian Brueffer]

--Dxnq1zWXvFF0Q93v
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 02, 2003 at 04:48:07PM +0300, Petri Helenius wrote:
> Christian Brueffer wrote:
>=20
> >On Sat, Aug 02, 2003 at 11:19:48AM +0300, Petri Helenius wrote:
> >=20
> >
> >>I just wish there would either be more functionality in the twe driver=
=20
> >>or somebody would come
> >>out with 8-12 port SATA controller. Looking at the issues for example=
=20
> >>the Adaptec SCSI RAIDs
> >>have, it seems SATA will take them over quite quickly.
> >>
> >>  =20
> >>
> >
> >FYI, 3ware sells 8 and 12 port SATA controllers.
> >
> >- Christian
> >
> >=20
> >
> Sure, but the visibility for the array from the operating system is zero=
=20
> with the twe
> driver? Or am I missing an utility?
>=20

Ah, no.  I have talked to some 3ware guys at Linuxtag.  They don't release
their controller binaries for FreeBSD, because they have seen near zero
demand for them yet.
Asking them might work :-)

- Christian

--=20
Christian Brueffer  [EMAIL PROTECTED]   [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D

--Dxnq1zWXvFF0Q93v
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/K8MCbHYXjKDtmC0RAggfAJ4m+yd7Mt+D6ZoKOd18sMc0/QMDOwCfWA20
2C+x1hbwsSDAKGdbwhvOt9s=
=e1F0
-END PGP SIGNATURE-

--Dxnq1zWXvFF0Q93v--

Re: sil3112 controller

[Petri Helenius]

Christian Brueffer wrote:

On Sat, Aug 02, 2003 at 11:19:48AM +0300, Petri Helenius wrote:
 

I just wish there would either be more functionality in the twe driver 
or somebody would come
out with 8-12 port SATA controller. Looking at the issues for example 
the Adaptec SCSI RAIDs
have, it seems SATA will take them over quite quickly.

   

FYI, 3ware sells 8 and 12 port SATA controllers.

- Christian

 

Sure, but the visibility for the array from the operating system is zero 
with the twe
driver? Or am I missing an utility?

Pete

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

warnpassword and warnexpire in 5.1 login.conf

[Mats Larsson]

Hello!

Tried this question to the questions list with no response, perhaps
current is the correct list for questions related to 5.1-RELEASE??

I am trying to use warnexpire and warnpassword in login.conf but with no
result, are the warnexpire and warnpassword still used in 5.1 or have they
been superseded with a PAM module in the same way as minpasswordlen and
minpasswordcase??

// Mats Larsson
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sil3112 controller

[Christian Brueffer]

--cHMo6Wbp1wrKhbfi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 02, 2003 at 11:19:48AM +0300, Petri Helenius wrote:
>=20
> I just wish there would either be more functionality in the twe driver=20
> or somebody would come
> out with 8-12 port SATA controller. Looking at the issues for example=20
> the Adaptec SCSI RAIDs
> have, it seems SATA will take them over quite quickly.
>=20

FYI, 3ware sells 8 and 12 port SATA controllers.

- Christian

--=20
Christian Brueffer  [EMAIL PROTECTED]   [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D

--cHMo6Wbp1wrKhbfi
Content-Type: application/pgp-signature
Content-Disposition: inline

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/K7lPbHYXjKDtmC0RAhcmAKCZitcW4HFLTNDs1RjD5UGH1Plb5QCeLXx5
sk7PsU+dXAaJti1Fr8XnAL8=
=Xd0P
-END PGP SIGNATURE-

--cHMo6Wbp1wrKhbfi--

Re: vfprintf() has a 4096-byte memory leak?

[Ryan T. Dean]

"Poul-Henning Kamp" wrote:
In message <3F2B9C59.3060209 at cytherianage.net 
>, "Ryan T. Dean" writes:
>/Hey all-
/> >/I was doing some app debugging tonight, and noticed what appears to 
/> >/be a memory leak in vfprintf().
/> 
This is probably the buffer which stdio uses for all I/O.

Try calling 
	setbuf(stdout, NULL);
	setbuf(stderr, NULL);

as the very first thing in your program, and you will probably see
that it does not allocate the 4k buffer, you may also be able to
measure the performance change due to this.
In other words, what you see is perfectly normal, and to be expected,
but if it is a problem for you, the above is the workaround.
Aha.  setbuf(stdout, NULL); does prevent the buffer from being allocated.
However, in the case of stdout and stderr, if you don't setbuf() it to null, 
a buffer is malloc'd.  The corresponding free() is in fclose.  So, if you 
[f]printf() to stdout/stderr, and fclose(stdout/stderr), you are fine.  If, 
however, you don't know that buffers are being allocated for stdin/stdout 
and don't fclose() or setbuf() to NULL, a 4096-byte chunk of memory is 
allocated and never freed.  For shits and giggles, I checked a DeadRat 8 
box - no buffering by default.  I guess the only reason I'm worried is the
potential number of programs in the ports tree originally written on a system
where stdout/stderr behave differently, or people (like myself) who didn't
have a clue any sort of output buffering was enabled on stdout/stderr, and as 
a result have memory leaks.  If the porter did their job, it shouldn't be an 
issue (was caught, patched, and the patch submitted upstream), but, then, we 
never know, right?

I don't know.  I'm tired and not thinking the straightest.  I'd like to 
apologize for any incoherence in my thoughts.  I appreciate the prompt reply.

	-Ryan T. Dean

(Code tested below on FBSD)
test1.c:
#include 
int main (void)
{
  printf("Test\n");
  return 0;
}
test1 memory debug output:
1059825156: 1: *** alloc: at 'ra=0x2816ee86' for 4096 bytes, got '0x804b008|s1'
1059825156: 1: top 10 allocations:
1059825156: 1:  total-size  count in-use-size  count  source
1059825156: 1:4096  14096  1  ra=0x2816ee86
1059825156: 1:4096  14096  1  Total of 1
1059825156: 1: dumping not-freed pointers changed since 0:
1059825156: 1:  not freed: '0x804b008|s1' (4096 bytes) from 'ra=0x2816ee86'
1059825156: 1:  total-size  count  source
1059825156: 1:4096  1  ra=0x2816ee86
1059825156: 1:4096  1  Total of 1
1059825156: 1:  unknown memory: 1 pointer, 4096 bytes
test2.c:
#include 
int main (void)
{
  printf("Test\n");
  fclose(stdout);
  return 0;
}
test2 memory debug output:
1059825216: 1: *** alloc: at 'ra=0x2816ee86' for 4096 bytes, got '0x804b008|s1'
1059825216: 2: *** free: at 'ra=0x2815c431' pnt '0x804b008|s2': size 4096, alloced at 
'ra=0x2816ee86'
1059825216: 2: top 10 allocations:
1059825216: 2:  total-size  count in-use-size  count  source
1059825216: 2:4096  1   0  0  ra=0x2816ee86
1059825216: 2:4096  1   0  0  Total of 1
1059825216: 2: dumping not-freed pointers changed since 0:
1059825216: 2:  memory table is empty
test3.c:
#include 
int main (void)
{
  setbuf(stdout, NULL);
  printf("Test\n");
  return 0;
}
test3 memory debug output:
(no output generated)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

What is it about kern_ktr.c ?

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Tinderbox wri
tes:
>/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c: In 
>function `db_ktr_all':
>/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: 
>error: `lines' undeclared (first use in this function)
>/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: 
>error: (Each undeclared identifier is reported only once
>/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: 
>error: for each function it appears in.)
>/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:270: 
>warning: unused variable `c'
>*** Error code 1

What gives ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on sparc64/sparc64

[Tinderbox]

TB --- 2003-08-02 10:36:54 - starting CURRENT tinderbox run for sparc64/sparc64
TB --- 2003-08-02 10:36:54 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 10:39:03 - building world
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-08-02 11:37:25 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sat Aug  2 11:37:26 GMT 2003
>>> Kernel build for GENERIC completed on Sat Aug  2 11:46:36 GMT 2003
TB --- 2003-08-02 11:46:36 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-08-02 11:46:36 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Aug  2 11:46:36 GMT 2003
[...]
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_thr.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_kthread.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd
 -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing 
-fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c: In 
function `db_ktr_all':
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: 
error: `lines' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: 
error: (Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: 
error: for each function it appears in.)
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:270: 
warning: unused variable `c'
*** Error code 1

Stop in 
/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/t

Re: Anyone use WINE at all anywhere?

[Bruce Evans]

On Fri, 1 Aug 2003, Julian Elischer wrote:

> Is the re ANYONE that uses wine on -current...?
>
> for that matter, a -current user that uses wine on 4.x?

I use it a lot for 1 application, but I mostly use my version of a 6
month old version of -current for large parts of -current, and a 2.4 year
old version of wine.

Known problems:
(1) rfork() in -current (not my version) was temporarily broken.  This
broke the old version of wine though not an 0.4 year old one.
(2) Wine apparently lost something in the screen redrawing methods used
by the application (they became too slow and glitchy), so versions
newer than the 2.4 year old one are unusuable for me.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vfprintf() has a 4096-byte memory leak?

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, "Ryan T. Dean" writes:
>Hey all-
>I was doing some app debugging tonight, and noticed what appears to 
>be a memory leak in vfprintf().

This is probably the buffer which stdio uses for all I/O.

Try calling 
setbuf(stdout, NULL);
setbuf(stderr, NULL);

as the very first thing in your program, and you will probably see
that it does not allocate the 4k buffer, you may also be able to
measure the performance change due to this.

In other words, what you see is perfectly normal, and to be expected,
but if it is a problem for you, the above is the workaround.




-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

vfprintf() has a 4096-byte memory leak?

[Ryan T. Dean]

Hey all-
   I was doing some app debugging tonight, and noticed what appears to 
be a memory leak in vfprintf().  I've tested it on -CURRENT and -STABLE; 
any program that makes use of vfprintf() (ie, uses printf) appears to 
have a 4096 byte memory leak.  The memory is allocated on the first 
vfprintf() call and is never deallocated.  I've observed the memory leak 
on -CURRENT as of 30 Jul and -STABLE as of 29 Jul.  It was also 
reported, indirectly, on ports@ on 21 Jul.  The memory leak has been 
observed using dmalloc (devel/dmalloc; dmalloc.com) and NJAMD 
(sourceforge.net/projects/njamd).  I suspect that there may be a similar 
leak in vsprintf() as well.  I did file a PR (misc/55181), but I thought 
I should maybe give a shout-out to the list as well.
 -Ryan T. Dean

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bge & vlan stranges

[Boris Kovalenko]

Terry Lambert wrote:
Hello!
Boris Kovalenko wrote:
 

 I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and
FreeBSD 5.1R installed. There are no problems if I use bge as usual
network card, but when I try to use 802.1Q vlans, I can't receive (only
receive, sending is ok) packets more then 1456 bytes! What is the
problem? BGE driver, VLAN driver or my network configuration?
   

The encapsulation information is subtracted from your available
MTU, so that is correct.
Some cards have a bogus feature that lets you send longer frames
than the normal MTU, but you can't rely on this feature being
interoperable between card vendors, or being supported on all
cards.
I suppose you want to do this because you are trunking a channel
that goes to a border device, and for some reason you have disabled
receipt of all ICMP, instead of only abusable ICMP, and thus you
have broken end-to-end path MTU discovery.
It would be best if you were to simply fix your ICMP.
 

No, this is test machine, I have installed it two days ago and have
firewall_type="OPEN" in my settings. So I have not disabled MTU path
discovery You are speaking of. Nevertheless, what is "substracted from
available MTU?" Why? The correct way it should work:
1500 bytes packet + 14 bytes ethernet header + 4 bytes CRC = 1518 bytes
is standard ethernet frame and
1500 bytes packet + 14 bytes ethernet header + 4 bytes 802.1Q tag + 4
bytes CRC = 1522 bytes of standard 802.1Q encapsulated frame. All 802.1Q
realizations I know working the same.
-- Terry

 

Boris



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on ia64/ia64

[Tinderbox]

TB --- 2003-08-02 09:22:53 - starting CURRENT tinderbox run for ia64/ia64
TB --- 2003-08-02 09:22:53 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 09:25:33 - building world
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-08-02 10:32:47 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sat Aug  2 10:32:47 GMT 2003
[...]
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwdev.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwdma.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwmem.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions 
-std=c99 -g -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd 
-I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror  
/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwohci.c
cc -c -O -pipe  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype

Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)

[Bruce Evans]

On Fri, 1 Aug 2003, Julian Elischer wrote:

> On Fri, 1 Aug 2003, Julian Elischer wrote:
> > I also noticed that if we disable the 'splat' mode, we'd break sysVR4
> > binary code as they do that.. (though it's #if 0'd out at the moment)
>
> not to mention linux (more important..) though I might add that that
> code could do with rewriting to get rid of a lot of "stackgap" stuff.

Even changing the semantics of i386_set_ldt() to support dynamic allocation
may break ABI compatibility with Linux (not to mention both API and ABI
compatibility with OtherBSD).  I wondered about this when the change was
proposed, but only had a quick look at an old version of Linux for API
compatibility.  Linux seem to have a different API.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)

[Bruce Evans]

On Fri, 1 Aug 2003, Julian Elischer wrote:

> looking at it further, it appears that NLDT is not really a
> 'reservation' as much as a description of how much space we may
> need to allocate initially.

Correct, except it seems that there are some bugs from the kernel using
the code and data selectors see another reply).

> I think that it wouldn't matter (for example) if you used one of the
> existing defined numbers as long as you are not running a program that
> used them..
> i.e you could use as you are not a BSDI binary that needs it.

Even changing the code and data selectors so that user code can't run
should be just foot shooting.  It seems to be allowed before rev.1.84.
The LDT is a user resource and the kernel can do very little about
applications and libraries mismanaging it.  It can just help them
manage it.  Dynamic allocation seems to be a correct first step towards
letting them manage it.

> Also it's interesting to note that '0' is defined..
> this is intersting as a value of a segment register of '0'
> is not allowed from my memory.
> I guess that only applies to GDTEs.

Correct.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on i386/pc98

[Tinderbox]

TB --- 2003-08-02 07:52:40 - starting CURRENT tinderbox run for i386/pc98
TB --- 2003-08-02 07:52:40 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 07:58:15 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-08-02 09:03:49 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sat Aug  2 09:03:49 GMT 2003
>>> Kernel build for GENERIC completed on Sat Aug  2 09:15:50 GMT 2003
TB --- 2003-08-02 09:15:50 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-08-02 09:15:50 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Aug  2 09:15:51 GMT 2003
[...]
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_thr.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_kthread.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c: In function 
`db_ktr_all':
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: 
`lines' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: 
for each function it appears in.)
/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/

Re: Anyone use WINE at all anywhere?

[Jens Schweikhardt]

On Fri, Aug 01, 2003 at 05:38:33PM -0700, Julian Elischer wrote:
# 
# Is the re ANYONE that uses wine on -current...?
# 
# for that matter, a -current user that uses wine on 4.x?

I use it on a 4.7 at work; the only apps I use are the word-, excel- and
ppt viewers for the occasional doc/xl/ppt files I receive as attachments.
Corporate windows environment, you know :-)

It's a bitch to configure and integrate with mutt. And all the messages
about font diddling look scary, but it does what I want, viewing the
files without rebooting or buying vmware.

Regards,

Jens
-- 
Jens Schweikhardt http://www.schweikhardt.net/
SIGSIG -- signature too long (core dumped)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vinum bug? (Re: Yet another crash in FreeBSD 5.1)

[Bernd Walter]

On Sat, Aug 02, 2003 at 02:00:52AM -0700, Kris Kennaway wrote:
> On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:
> 
> > db> trace
> > g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> > launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
> > vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
> > vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6
> 
> Looks like a problem in vinum.  The other backtrace was the same, right?

Please take a look at an older thread named (IIRC) vinum or geom bug?
Greg asked for special debug output, but it never happened again for me.
A real murphy bug - it happend on three machines once a day and after
Gregs response nothing happened over weeks.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Yet another crash in FreeBSD 5.1

[Terry Lambert]

Eivind Olsen wrote:
> Can anyone suggest what I do next to find out about this crash?

> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x14

Dereference of NULL pointer; reference is for element at offset
0x14 in some structure; this is the equivalent of 5 32 bit ints
or pointers into the structure.

> db> trace
> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
> vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2

gdb -k kernel.debug
(gdb) list *(g_dev_strategy+29)
[ ... ]
(gdb) list *(launch_requests+448)
[ ... ]
(gdb) list *(vinumstart+2b2)
[ ... ]

Will give you the exact source lines involved, assuming you
built a debug kernel.

You don't actually need a crash dump to debug a stack traceback.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

vinum bug? (Re: Yet another crash in FreeBSD 5.1)

[Kris Kennaway]

On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:

> db> trace
> g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
> launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
> vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
> vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6

Looks like a problem in vinum.  The other backtrace was the same, right?

Kris


pgp0.pgp
Description: PGP signature

Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)

[Terry Lambert]

Julian Elischer wrote:
> +   if (ldt_warnings++ < NUM_LDT_WARNINGS) {

Still broken on rollover; use:

+   if (ldt_warnings < NUM_LDT_WARNINGS) {
+   ldt_warnings++;

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)

[Terry Lambert]

Marcel Moolenaar wrote:
> But if we only use the dynamic allocation then it can only fail for
> a combination of 3rd party code.

You meant to say static here, e.g. when there are two libraries
linked into a single aplication, and both libraries want to get
entry #6, right?

In the dynamic case, this will Just Work(tm), because each one
will end up getting a different value.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)

[Terry Lambert]

Julian Elischer wrote:

It's not that likely to roll, but...

> static int complained = 6;
> 
> if (complained-- ) {
if (complained) {
complained--;
> printf ("process (PID %d) Use static LDT allocation.\n",
>  td->td_proc->p_pid);
> printf ("man i386_set_ldt for more information\n");
> }

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: bge & vlan stranges

[Terry Lambert]

Boris Kovalenko wrote:
>   I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and
> FreeBSD 5.1R installed. There are no problems if I use bge as usual
> network card, but when I try to use 802.1Q vlans, I can't receive (only
> receive, sending is ok) packets more then 1456 bytes! What is the
> problem? BGE driver, VLAN driver or my network configuration?

The encapsulation information is subtracted from your available
MTU, so that is correct.

Some cards have a bogus feature that lets you send longer frames
than the normal MTU, but you can't rely on this feature being
interoperable between card vendors, or being supported on all
cards.

I suppose you want to do this because you are trunking a channel
that goes to a border device, and for some reason you have disabled
receipt of all ICMP, instead of only abusable ICMP, and thus you
have broken end-to-end path MTU discovery.

It would be best if you were to simply fix your ICMP.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sil3112 controller

[Petri Helenius]

Soeren Schmidt wrote:

So that drives could be assigned to a mirror / stripe set before installing without
having to build the mirror on another machine first?
(in this case the BIOS does not help)
   

You cant boot from a stripe on a controller that doesn't have a BIOS
to do it.
 

Sure, but I can boot off a mirror, which I actually do in a few cases. 
Most ATA RAID controllers
seem to be targeted towards home-user and thus do not support unattended 
operation.

I just can't create the mirror while installing. 

I just wish there would either be more functionality in the twe driver 
or somebody would come
out with 8-12 port SATA controller. Looking at the issues for example 
the Adaptec SCSI RAIDs
have, it seems SATA will take them over quite quickly.

Pete


 



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Yet another crash in FreeBSD 5.1

[Eivind Olsen]

I've now had yet another crash under FreeBSD 5.1 (RELENG_5_1, cvsupped 5-6
days ago) and it looks almost the same as the crash I posted about
yesterday (or was it the day before?

Here's some output from DDB:

Krasj 2.7.2003:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x14
fault code  = supervisor write, page not present
instruction pointer = 0x8:0xc02e8139
stack pointer   = 0x10:0xcfb5284c
frame pointer   = 0x10:0xcfb52880
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 10785 (ctl_cyrusdb)
kernel: type 12 trap, code=0
Stopped at  g_dev_strategy+0x29:movl%eax,0x14(%ebx)
db> show reg
cs 0x8
ds0x10
es0x10
fs0x18
ss0x10
eax 0xfd235200
ecx  0
edx  0
ebx  0
esp 0xcfb5284c
ebp 0xcfb52880
esi 0xc2156024  _end+0x5ae4
edi 0xc2044900
eip 0xc02e8139  g_dev_strategy+0x29
efl0x10286
dr0  0
dr1  0
dr2  0
dr3  0
dr4 0x0ff0
dr5  0x400
dr6 0x0ff0
dr7  0x400
g_dev_strategy+0x29:movl%eax,0x14(%ebx)
db> trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6
spec_xstrategy(c215c5b4,c5ada2d0,cfb52968,c02e4f18,cfb52994) at
spec_xstrategy+0x306
spec_specstrategy(cfb52994,cfb529b0,c044f7ad,cfb52994,0) at
spec_specstrategy+0x1b
spec_vnoperate(cfb52994,0,c09719b0,f,c5ada2d0) at spec_vnoperate+0x18
ufs_strategy(cfb529d8,cfb52a0c,c0359a87,cfb529d8,1) at ufs_strategy+0xdd
ufs_vnoperate(cfb529d8,1,c0504f45,35e,cfb529f8) at ufs_vnoperate+0x18
bwrite(c5ada2d0,cfb52a5c,c0361aca,c5ada2d0,c5ada400) at bwrite+0x3a7
bawrite(c5ada2d0,c5ada400,10,3c6,20020080) at bawrite+0x1c
cluster_wbuild(c30c7124,4000,50,0,4) at cluster_wbuild+0x6ba
cluster_write(c5b735c0,9c7c64,0,55,c252b880) at cluster_write+0x571
ffs_write(cfb52be0,c21c2528,c22ab000,227,c2025e00) at ffs_wrie+0x5ff
vn_write(c21c2528,cfb52c7c,c252b880,0,c22ab000) at vn_write+0x192
dofilewrite(c22ab000,c21c2528,8,807e000,4000) at dofilewrite+0xe8
write(c22ab000,cfb52d10,c0518514,3fb,3) at write+0x69
syscall(2f,807002f,bfbf002f,0,807e000) at syscall+0x24e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c,
ebp = 0xbfbfec38 ---
db>

I tried creating a crash dump by issuing the commands "panic" and then
"continue" but everything seemingly stopped then and nothing was dumped to
disk.

Can anyone suggest what I do next to find out about this crash?

-- 
Regards
Eivind Olsen
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: sil3112 controller

[Soeren Schmidt]

It seems Petri Helenius wrote:
> 
> Should there be an option to run atacontrol in sysinstall?

hmm, maybe...

> So that drives could be assigned to a mirror / stripe set before installing without
> having to build the mirror on another machine first?
> (in this case the BIOS does not help)

You cant boot from a stripe on a controller that doesn't have a BIOS
to do it.

-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

[current tinderbox] failure on i386/i386

[Tinderbox]

TB --- 2003-08-02 06:21:10 - starting CURRENT tinderbox run for i386/i386
TB --- 2003-08-02 06:21:10 - checking out the source tree
TB --- cd /home/des/tinderbox/CURRENT/i386/i386
TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
TB --- 2003-08-02 06:23:46 - building world
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make -B buildworld
>>> Rebuilding the temporary build tree
>>> stage 1: legacy release compatibility shims
>>> stage 1: bootstrap tools
>>> stage 2: cleaning up the object tree
>>> stage 2: rebuilding the object tree
>>> stage 2: build tools
>>> stage 3: cross tools
>>> stage 4: populating 
>>> /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include
>>> stage 4: building libraries
>>> stage 4: make dependencies
>>> stage 4: building everything..
TB --- 2003-08-02 07:29:24 - building generic kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=GENERIC
>>> Kernel build for GENERIC started on Sat Aug  2 07:29:24 GMT 2003
>>> Kernel build for GENERIC completed on Sat Aug  2 07:43:54 GMT 2003
TB --- 2003-08-02 07:43:54 - generating LINT kernel config
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf
TB --- /usr/bin/make -B LINT
TB --- 2003-08-02 07:43:54 - building LINT kernel
TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src
TB --- /usr/bin/make buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Sat Aug  2 07:43:54 GMT 2003
[...]
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_thr.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_kthread.c
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99  -nostdinc -I-  -I. 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath 
-I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 
-DGUPROF -finline-limit=15000 -fno-strict-aliasing -fno-builtin 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror 
-finstrument-functions -Wno-inline 
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c: In function 
`db_ktr_all':
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: 
`lines' undeclared (first use in this function)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: 
(Each undeclared identifier is reported only once
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: 
for each function it appears in.)
/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_

Re: world broken with a gcc 3.2 world? (resolution)

[Alexander Leidinger]

On Thu, 31 Jul 2003 11:27:56 +0200
Alexander Leidinger <[EMAIL PROTECTED]> wrote:

> with a Jul 10 world, a clean /usr/obj and the sources as of yesterday I
> get
> ---snip---
> /big/usr/src/contrib/gcc/dwarf2out.c:11739:75: missing terminating ' character
> /big/usr/src/contrib/gcc/dwarf2out.c:11741:71: warning: multi-line string litera
> ls are deprecated
> /big/usr/src/contrib/gcc/dwarf2out.c:11743:26: missing terminating ' character
> /big/usr/src/contrib/gcc/dwarf2out.c:12095:28: missing terminating ' character
> /big/usr/src/contrib/gcc/dwarf2out.c:12190:7: missing terminating ' character
> /big/usr/src/contrib/gcc/dwarf2out.c:12475:58: macro "ASM_OUTPUT_INTERNAL_LABEL"
>  passed 5 arguments, but takes just 3
> /big/usr/src/contrib/gcc/dwarf2out.c:12756:2: #else without #if
> /big/usr/src/contrib/gcc/dwarf2out.c:12761:2: #endif without #if
> /big/usr/src/contrib/gcc/dwarf2out.c:12764:2: #endif without #if
> mkdep: compile failed
> *** Error code 1
> ---snip---

My local CVS repository was broken.

Bye,
Alexander.

-- 
   "One world, one web, one program"  -- Microsoft promotional ad
 "Ein Volk, ein Reich, ein Fuehrer"  -- Adolf Hitler

http://www.Leidinger.net   Alexander @ Leidinger.net
  GPG fingerprint = C518 BC70 E67F 143F BE91  3365 79E2 9C60 B006 3FE7
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [current tinderbox] failure on alpha/alpha

[Hidetoshi Shimokawa]

At Sat, 02 Aug 2003 00:47:45 -0600,
Scott Long wrote:
> 
> Is anyone willing to fix this?  The warning is bogus as it's quite 
> obvious that the variable is being initialized.  Strange that it doesn't
> show up on other platforms.
> 
> Scott

I have already committed a workaround for this.

/\ Hidetoshi Shimokawa
\/  [EMAIL PROTECTED]
PGP public key: http://www.sat.t.u-tokyo.ac.jp/~simokawa/pgp.html
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"