fxp hangs reseting to a stable state
This is the first time I've tried to run -current on this little board. Up-to-date RELENG_4 kernels run fine. The probe message (port & memory) values are the same. On -current, the kernel gets up to the point in the fxp code where it is supposedly doing a "reset to a stable state" and then it hangs. I have set the kernel option BREAK_TO_DEBUGGER, but I can't get it to drop to DDB. The fxp driver reports that it is using memory space register mapping, so I guess that there is something different about the memory access in -current compared to RELENG_4. The question is what? I assume it's not a bios setup problem since RELENG_4 works fine. The kernels are net booted (using etherboot) over the very device that -current hangs on. Weird. Any hints on what is going on? -- John Birrell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libkse with kvirc 3.0.0 problem.
today i tried to compile a snapshot of the kvirc program as of this snapshot it doesnt know that -pthread is deprecated in freebsd go i edited the configure script to make -pthread to -lkse seems to go well but when i run it i get the following: % kvirc Fatal error 'Spinlock called when not threaded.' at line 87 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) Abort % i dono something is weird wiht libkse and i would think that it would use a diff src but dono -chris _ Fast, faster, fastest: Upgrade to Cable or DSL today! https://broadband.msn.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic with ATAng + atapicam
FYI, a fresh cvsup from yesterdays sources causes a panic with atapicam in the kernel. My previous kernel was before ATAng was imported. Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x8:0xc03dcd5b stack pointer = 0x10:0xd70977c0 frame pointer = 0x10:0xd7097840 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 = 20 (swi3: cambio) kernel: type 18 trap, code = 0 Stopeed at __qdivrem+0x3b: divl %ecx, %ecx db> trace __qdivrem(dec0addf,0,0,0,0) at __qdivrem+0x3b __udivdi3(dec0addf,0,0,0,d7099910) at __udivdi3+0x2e cam_calc_geometry(d7099910,1,c028f8c0,c04a1ab0,1) at cam_calc_geometry+0x37 atapi_action(c41ecd00,d7097910,d70978f8,c027cd1a,c049c800) at atapi_action+0x2a0 xpt_action(d7097910,c45ca50,1,1,20) at xpt_action+-x32a dasetgeom(c41fd400,dec0adde,dec0adde,0,c41f0800) at dasetgeom+0x79 dadone(c41fd400,c41f1400,c0412745,0,c0485340) at dadone+0x3af camisr(c0485340,0,c0412745,215,c1526790) at camisr+0x23f ithread_loop(c151d580,d7097d48,c041259f,314,0) at ithread_loop+0x182 fork_exit(c0254f80,c151d580,d7097d48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp=0xd7097a7c, ebp=0 --- nm /boot/kernel/kernel | sort | more ... c03dcb50 T __divdi3 c03dcbf0 T __moddi3 c03dcca0 t shl c03dcd20 T __qdivrem c03dd180 T __ucmpdi2 ... It also detects a CD being present when there isn't one present. dmesg from kernel without atapicam: Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-CURRENT #2: Wed Sep 10 11:48:35 EDT 2003 [EMAIL PROTECTED]:/opt/FreeBSD/obj/opt/FreeBSD/src/src/sys/goldwing Preloaded elf kernel "/boot/kernel/kernel.crashes" at 0xc05e8000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05e824c. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (797.42-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ff real memory = 536608768 (511 MB) avail memory = 514768896 (490 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2c00 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.PS2M._STA] (Node 0xc4042a20), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.PS2M._STA] (Node 0xc4042a20), AE_AML_REGION_LIMIT acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz quality 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.PS2M._STA] (Node 0xc4042a20), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.PS2M._STA] (Node 0xc4042a20), AE_AML_REGION_LIMIT unknown: I/O range not supported acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib0: slot 31 INTD is routed to irq 11 pcib0: slot 31 INTB is routed to irq 9 pcib0: slot 31 INTC is routed to irq 10 pcib0: slot 31 INTB is routed to irq 9 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib0: slot 1 INTA is routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 pci2: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci1: on pcib2 pcib2: slot 8 INTA is routed to irq 11 pcib2: slot 10 INTA is routed to irq 11 fxp0: port 0xdf00-0xdf3f mem 0xfd9fe000-0xfd9fefff irq 11 at device 8.0 on pci1 fxp0: Ethernet address 00:d0:b7:c1:55:7d miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: port 0xdf80-0xdf9f irq 11 at device 10.0 on pci1 pcm0: isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0xef40-0xef5f irq 11 at device 31.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) uhci1: port 0xef80-0xef9f irq 10 at device 31.4 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm1: port 0xef00-0xef3f,0xe800-0xe8ff irq 9 at device 31.5 on pci0 pcm1: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.PS2M._STA] (Node 0xc4042a20), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.PS2M._STA] (Node 0xc4042a20), AE_AML_R
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, 2003-09-10 at 17:22, Steve Kargl wrote:
> On Wed, Sep 10, 2003 at 04:45:47PM -0700, Scott Reese wrote:
> > On Wed, 2003-09-10 at 16:40, Steve Kargl wrote:
> > > On Wed, Sep 10, 2003 at 04:34:31PM -0700, Scott Reese wrote:
> > > > On Wed, 2003-09-10 at 14:14, Scott Reese wrote:
> > > > >
> > > > > I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII
> > > > > 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B
> > > > > 400 motherboard with 512 MB RAM. The system starts and runs great, but
> > > > > I can't build anything with it anymore.
> > >
> > > Did you have these errors with your PIII 800 MHz processor and
> > > 256 MB of RAM? If the answer is no, the old harware wsa rock solid,
> > > then I suspect you have a hardware problem. For example, power
> > > supply can't supply enough power or the memory isn't seated correctly
> > > or insufficient heat sinking on the CPU or ...
> >
> > No, I didn't have these errors with the old hardware. It seemed very
> > solid to me. I would be extremely disappointed if this were a hardware
> > failure of some kind as I just got it upgraded this morning. :/
> >
> > One question, though...Doesn't flakey hardware usually cause *random*
> > errors? I ask because the error I'm receiving upon issuing 'make
> > buildworld' is recurring in exactly the same place every time. I'm
> > wondering if something somewhere got hosed...
>
> I deleted your original email, but I thought you said that
> you got ICE's while building a couple of ports. Do you
> set CFLAGS and/or CPUTYPE to some strange combination of
> options?
I have no CFLAGS set and CPUTYPE is also not set. Just successfully
built world, but the kernel compilation stopped with another ICE...the
same one I got earlier today when trying to build a kernel:
/usr/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_run_data_fifo':
/usr/src/sys/dev/aic7xxx/aic79xx.c:787: error: unrecognizable insn:
(insn 1427 1422 1440 48 0x284a9420 (parallel [
(set (reg/v:QI 4 sil [363])
(asm_operands/v:QI ("inb %%dx,%0") ("=a") 0 [
(reg/v:SI 1 edx [361])
]
[
(asm_input:SI ("d"))
] ("machine/cpufunc.h") 197))
(clobber (reg:QI 19 dirflag))
(clobber (reg:QI 18 fpsr))
(clobber (reg:QI 17 flags))
]) -1 (insn_list 1422 (nil))
(nil))
/usr/src/sys/dev/aic7xxx/aic79xx.c:787: internal compiler error: in
reload_cse_simplify_operands, at reload1.c:8345
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
*** Error code 1
Stop in /usr/obj/usr/src/sys/BORGES.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
Guess maybe it's hardware-related. Was hoping to find a solution that
would clear any charges against my new hardware, but I guess that's all
that's left. *sigh*
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Thu, Sep 11, 2003 at 01:41:05AM +0200, Michael Nottebrock wrote:
> Steve Kargl wrote:
>
> >Why? The portmgr can tag the ports collection at any point in
> >time before or after the -pthread deprecation date.
>
> Steve, ports-freeze dates are set and published ahead of time just as dates
> for releases are.
And the cvs tag can and has in the past been slid forward or
backwards when unforseen problems occur.
> Don't bother telling me I'm whining, pointing at the handbook again and
> saying "don't expect anything to work on -CURRENT at any given time",
> you're shooting the messenger.
If you want to use "g++ -pedantic", do the following
cd $HOME
mkdir gcc
cd gcc
cvs -qz9 -d :pserver:[EMAIL PROTECTED]:/cvsroot/gcc update\
-r tree-ssa-20020619-branch -PAd gcc
cd ..
mkdir obj
cd obj
../gcc/configure --enable-languages=c,c++ --prefix=$HOME
gmake bootstrap
gmake install
troutmask:sgk[205] $HOME/bin/g++ -static -pedantic -o a a.cc
troutmask:sgk[206] a
hello world
troutmask:sgk[207] cat a.cc
#include
int main(void) {
std::cout << "hello world\n";
return 0;
}
--
Steve
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, Sep 10, 2003 at 04:45:47PM -0700, Scott Reese wrote: > On Wed, 2003-09-10 at 16:40, Steve Kargl wrote: > > On Wed, Sep 10, 2003 at 04:34:31PM -0700, Scott Reese wrote: > > > On Wed, 2003-09-10 at 14:14, Scott Reese wrote: > > > > > > > > I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII > > > > 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B > > > > 400 motherboard with 512 MB RAM. The system starts and runs great, but > > > > I can't build anything with it anymore. > > > > Did you have these errors with your PIII 800 MHz processor and > > 256 MB of RAM? If the answer is no, the old harware wsa rock solid, > > then I suspect you have a hardware problem. For example, power > > supply can't supply enough power or the memory isn't seated correctly > > or insufficient heat sinking on the CPU or ... > > No, I didn't have these errors with the old hardware. It seemed very > solid to me. I would be extremely disappointed if this were a hardware > failure of some kind as I just got it upgraded this morning. :/ > > One question, though...Doesn't flakey hardware usually cause *random* > errors? I ask because the error I'm receiving upon issuing 'make > buildworld' is recurring in exactly the same place every time. I'm > wondering if something somewhere got hosed... I deleted your original email, but I thought you said that you got ICE's while building a couple of ports. Do you set CFLAGS and/or CPUTYPE to some strange combination of options? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new rc system
On Tue, 9 Sep 2003, Peter Jeremy wrote: > On Mon, Sep 08, 2003 at 12:59:11PM +0200, Philipp Grau wrote: > >Next problem is that /etc/rc.d/ntpd is evaluated before /etc/rc.d/devfs (see > >the output of "rcorder /etc/rc.d*) So the start of ntpd fails because it is > >requires the devfs link. Ntpd likes to open /dev/refclock-0. > > > >What should I do to circumvent this problem? By simply adding a > >"# REQUIRE: devfs" to the /etc/rc.d/ntpd file? Or this there some other > >mechanism? ntpd[ate] is a very difficult thing to order, because a lot of things need/want accurate time before they start, and yet by definition, ntp is a network protocol so it has a lot of other dependencies before it can even start. A lot of the things that ntp depends on (like network) want logging before they start, but syslog wants accurate time before IT starts... and we spiral back in time infinitely. I've currently been giving a reasonable amount of thought to a "two pass" concept to rc that would allow you to get a minimal system with logging up, fire up the network, do things like dns and ntp, then restart any systems that have to have accurate time to live within a running system. This is extremely non-trivial though. :) > This is a known shortcoming in the new rc system. Luke Mewburn > commented on it in a talk recently but does not yet have a > satisfactory solution. Can you describe in more detail what you mean by "this is a known shortcoming?" Doug -- This .signature sanitized for your protection ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
Daniel Eischen wrote: I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. Please, this is -current. If you want less pain then stick with -stable and you won't be annoyed by the -pthread removal. Perhaps I should make it clear that, personally, I'm NOT very much annoyed. I know my way around in ports@, I actually do know what -CURRENT means and I have no problem with using the ports-collection exclusively instead of quickly compiling my own stuff right there in my user-account. The problem is just that this -CURRENT is supposed to be -STABLE rather soon, as we all know (I think the RE status for HEAD is 'Semi-Frozen', too). There are many users out there with 5.1-Release installed which have at best only a very distant clue about the fact they're running an "early adopter's release" and they won't be upgrading to 4.9-R or 4.10-R when the time arrives. For someone coming from 5.0-R or 5.1-R, the new "necessary evil behaviour" of cc/c++, be it -pedantic or -pthread, will be totally unexpected. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, 2003-09-10 at 16:40, Steve Kargl wrote: > On Wed, Sep 10, 2003 at 04:34:31PM -0700, Scott Reese wrote: > > On Wed, 2003-09-10 at 14:14, Scott Reese wrote: > > > [I'm not presently subscribed to this list so please CC me in any > > > replies. Thank you] > > > > > > Hello, > > > > > > I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII > > > 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B > > > 400 motherboard with 512 MB RAM. The system starts and runs great, but > > > I can't build anything with it anymore. > > Did you have these errors with your PIII 800 MHz processor and > 256 MB of RAM? If the answer is no, the old harware wsa rock solid, > then I suspect you have a hardware problem. For example, power > supply can't supply enough power or the memory isn't seated correctly > or insufficient heat sinking on the CPU or ... No, I didn't have these errors with the old hardware. It seemed very solid to me. I would be extremely disappointed if this were a hardware failure of some kind as I just got it upgraded this morning. :/ One question, though...Doesn't flakey hardware usually cause *random* errors? I ask because the error I'm receiving upon issuing 'make buildworld' is recurring in exactly the same place every time. I'm wondering if something somewhere got hosed... Failing that, I guess I'll have to have a chat with the guy who built this thing... -Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
Steve Kargl wrote: Why? The portmgr can tag the ports collection at any point in time before or after the -pthread deprecation date. Steve, ports-freeze dates are set and published ahead of time just as dates for releases are. It's obviously not a good thing to have to try and be very conservative with commits to ports (in order to have a maximum number of them working for the next 4.x release) while at the same time there is loud demand for fixing a big number of them for -CURRENT. Don't bother telling me I'm whining, pointing at the handbook again and saying "don't expect anything to work on -CURRENT at any given time", you're shooting the messenger. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, Sep 10, 2003 at 04:34:31PM -0700, Scott Reese wrote: > On Wed, 2003-09-10 at 14:14, Scott Reese wrote: > > [I'm not presently subscribed to this list so please CC me in any > > replies. Thank you] > > > > Hello, > > > > I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII > > 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B > > 400 motherboard with 512 MB RAM. The system starts and runs great, but > > I can't build anything with it anymore. Did you have these errors with your PIII 800 MHz processor and 256 MB of RAM? If the answer is no, the old harware wsa rock solid, then I suspect you have a hardware problem. For example, power supply can't supply enough power or the memory isn't seated correctly or insufficient heat sinking on the CPU or ... -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Internal compiler error in reload_cse_simplify_operands
On Wed, 2003-09-10 at 14:14, Scott Reese wrote:
> [I'm not presently subscribed to this list so please CC me in any
> replies. Thank you]
>
> Hello,
>
> I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII
> 800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B
> 400 motherboard with 512 MB RAM. The system starts and runs great, but
> I can't build anything with it anymore. I keep getting internal
> compiler errors such as this one:
>
> /usr/src/crypto/openssl/crypto/des/des_enc.c: In function
> `DES_ede3_cbc_encrypt':
> /usr/src/crypto/openssl/crypto/des/des_enc.c:405: insn does not satisfy
> its constraints:
> (insn 655 653 657 (parallel[
> (set (reg:SI 2 ecx [219])
> (ashift:SI (reg:SI 0 eax [217])
> (const_int 16 [0x10])))
> (clobber (reg:CC 17 flags))
> ] ) 408 {*ashlsi3_1} (insn_list 653 (nil))
> (nil))
> /usr/src/crypto/openssl/crypto/des/des_enc.c:405: Internal compiler
> error in reload_cse_simplify_operands, at reload1.c:8338
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://www.gnu.org/software/gcc/bugs.html> for instructions.
> *** Error code 1
>
> Stop in /usr/src/secure/lib/libcrypto.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
> *** Error code 1
>
> Stop in /usr/src.
>
> That was from attempting to build world. I also tried building a new
> kernel and compiling gcc 3.3.1 from ports but all ended with an ICE
> similar to the one above and the error is never in the same place. I
> know there are some issues with PIV's that cause this kind of odd
> behavior so I was wondering if anyone has any clue what the problem
> might be. Searches in Google Groups have turned up nothing at all. I
> would be most grateful for any suggestions or pointers to FAQ's, docs or
> previous threads on this matter.
Replying to myself here, but I just wanted to add that I just cvsup'd to
-current and attempted to build world. I receive the internal compiler
error I mention above. Exactly the same error. Could something have
gotten hosed in my compiler somehow? If so, any idea how to
diagnose/fix the problem?
Thanks again,
Scott
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Dag-Erling Smørgrav writes: > > It would be really useful to know where the fault lies. We might even > (God forbid!) figure out a way to fix it. You can easily force the > system to boot with less than the full amount of memory by setting > hw.physmem to e.g. "64m" in /boot/loader.conf or at the loader prompt. > If you could just give instructions what you wanna get when system panics I might be able to persuade the other that we should crash our system once more. What scripts should we run continously until system panics? What you want to check with kdb after system panics? Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > Second trace didn't have anything to do with fs only fork system calls > there so your expanation sounds reasonable. We probably don't see this > problem again because system now has enough memory (256M). It would be really useful to know where the fault lies. We might even (God forbid!) figure out a way to fix it. You can easily force the system to boot with less than the full amount of memory by setting hw.physmem to e.g. "64m" in /boot/loader.conf or at the loader prompt. 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]"
most recently used by the ACD driver panic.
I'm looking at a call to panic() at line 137 of vm/uma_dbg.c. The panic string was "panic: Most recently used by ACD driver". If the ACD is the ATA CD driver, it was removed from this laptop (hot swapped) some time ago. The laptop panic'd while it aparently had many dirty buffers ... but while it was screen locked on my desk ... and shouldn't have been doing anything. Any ideas on where to look in this crash dump? Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAng: ata1-slave CDRW is only sometimes detected - RESOLVED
On Tue, Sep 09, 2003 at 08:37:17PM +0300, Lefteris Chatzibarbas wrote: > [...] > > Most of the time the CDRW drive is not detected and I get: > > [...] After today's commit to src/sys/dev/ata/ata-lowlevel.c (1.11 2003/09/10 09:57:16 sos), the ata1-slave CDRW is always detected correctly: atapci0: port 0xfc00-0xfc0f at device 17.1 on pci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0x90 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x7f err=0x7f lsb=0x7f msb=0x7f ata1-master: stat=0x10 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 mask=03 stat0=10 stat1=00 devices=0xc ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ad0: setting UDMA100 on VIA 8235 chip ad0: ATA-6 disk at ata0-master ad0: 76319MB (156301488 sectors), 155061 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=80pin ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin acd0: setting PIO4 on VIA 8235 chip acd0: DVDROM drive at ata1 as master acd0: read 8250KB/s (8250KB/s), 256KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: unknown transfer phase acd1: setting PIO4 on VIA 8235 chip acd1: CDRW drive at ata1 as slave acd1: read 6890KB/s (6890KB/s) write 4134KB/s (4134KB/s), 1404KB buffer, PIO4 acd1: Reads: CDR, CDRW, CDDA stream, packet acd1: Writes: CDR, CDRW, test write, burnproof acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Internal compiler error in reload_cse_simplify_operands
[I'm not presently subscribed to this list so please CC me in any
replies. Thank you]
Hello,
I'm running 5.1-RELEASE-p2 and I just upgraded my machine from a PIII
800 MHz processor with 256 MB RAM to a PIV 2.4 GHz processor and VIA P4B
400 motherboard with 512 MB RAM. The system starts and runs great, but
I can't build anything with it anymore. I keep getting internal
compiler errors such as this one:
/usr/src/crypto/openssl/crypto/des/des_enc.c: In function
`DES_ede3_cbc_encrypt':
/usr/src/crypto/openssl/crypto/des/des_enc.c:405: insn does not satisfy
its constraints:
(insn 655 653 657 (parallel[
(set (reg:SI 2 ecx [219])
(ashift:SI (reg:SI 0 eax [217])
(const_int 16 [0x10])))
(clobber (reg:CC 17 flags))
] ) 408 {*ashlsi3_1} (insn_list 653 (nil))
(nil))
/usr/src/crypto/openssl/crypto/des/des_enc.c:405: Internal compiler
error in reload_cse_simplify_operands, at reload1.c:8338
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
*** Error code 1
Stop in /usr/src/secure/lib/libcrypto.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
That was from attempting to build world. I also tried building a new
kernel and compiling gcc 3.3.1 from ports but all ended with an ICE
similar to the one above and the error is never in the same place. I
know there are some issues with PIV's that cause this kind of odd
behavior so I was wondering if anyone has any clue what the problem
might be. Searches in Google Groups have turned up nothing at all. I
would be most grateful for any suggestions or pointers to FAQ's, docs or
previous threads on this matter.
Thank you,
Scott
___
[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
TB --- 2003-09-10 19:49:21 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-09-10 19:49:21 - 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-09-10 19:52:23 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-09-10 20:49:01 - 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 Wed Sep 10 20:49:02 GMT 2003 >>> Kernel build for GENERIC completed on Wed Sep 10 21:00:51 GMT 2003 TB --- 2003-09-10 21:00:51 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-10 21:00:51 - 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 Wed Sep 10 21:00: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/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/dev/syscons/scterm.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/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/dev/syscons/scterm-dumb.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/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/dev/syscons/scvidctl.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/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-
Re: ufs related panic with latest current
Dag-Erling Smørgrav writes: > > The backtrace you showed seems to indicate that the panic happened > somewhere in the softupdates code, but IIRC that code has a fairly > conservative built-in limit on memory consumption and degrades > gracefully when it hits that limit. It's likely that something else > gobbled up all available kernel memory, and the mallloc() call from > softupdates was simply the straw that broke the camel's back. > > If you have a serial console hooked up, you could try running > > while :; do vmstat -m ; sleep 1 ; done > Second trace didn't have anything to do with fs only fork system calls there so your expanation sounds reasonable. We probably don't see this problem again because system now has enough memory (256M). Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > Dag-Erling Smørgrav writes: > > Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > > > First maxusers was 0 then when changed it to 8. > > That's a regression. Keep it at 0. > I understood that there is a bug on new kmem allocator and this was an > attempt to reduce kmem allocations but it didn't help. Do you know if > this is going to fixed somehow or should people just install more > memory to get system stay up? Well, reducing maxusers isn't going to help much as it only controls a small part of kernel memory, and setting it too low may render the system unusable. The backtrace you showed seems to indicate that the panic happened somewhere in the softupdates code, but IIRC that code has a fairly conservative built-in limit on memory consumption and degrades gracefully when it hits that limit. It's likely that something else gobbled up all available kernel memory, and the mallloc() call from softupdates was simply the straw that broke the camel's back. If you have a serial console hooked up, you could try running while :; do vmstat -m ; sleep 1 ; done on the serial console while doing whatever it is you do that causes the problem. This will tell you how much kernel memory was in use at the time of the panic and what it was used for. 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: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Wed, 10 Sep 2003, Michael Edenfield wrote:
> * David O'Brien <[EMAIL PROTECTED]> [030910 15:33]:
> > On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote:
> > > gnome2 depends on gnomemedia2.
> > > gnomemedia2 depends on gstreamer-plugins.
> > > gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
> > > includes -pthread.
> >
> > This is being worked on from the compiler stand point.
>
> Which is the main reason I didn't do a pr on it. But from reading other
> parts of the thread, it seems that ports should not be using -pthread
> anyway... would it be worthwhile to submit patches to remove -pthread
> (and, for that matter, -lpthread and other variants) in favor of
> ${PTHREAD_LIBS} regardless of wether `cc -pthread` is an error or a
> no-op, or some magical auto-thread-library-selector?
Yes, ${PTHREAD_LIBS} should be used, except perhaps for
ports that are libraries. Under the proposed scheme,
libraries could be weakly linked to a stub pthread
library (or even pthread stubs in libc I suppose). Then
when an application (strongly linked to _a_ threads
library) loads/references the library, that library
uses the same threads library that the application is
linked to.
But threaded executables still need to be linked to
some threads library, and that should be selectable
via PTHREAD_LIBS.
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Dag-Erling Smørgrav writes: > Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > > First maxusers was 0 then when changed it to 8. > > That's a regression. Keep it at 0. > I understood that there is a bug on new kmem allocator and this was an attempt to reduce kmem allocations but it didn't help. Do you know if this is going to fixed somehow or should people just install more memory to get system stay up? Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Tomi Vainio - Sun Finland <[EMAIL PROTECTED]> writes: > First maxusers was 0 then when changed it to 8. That's a regression. Keep it at 0. 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: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
* David O'Brien <[EMAIL PROTECTED]> [030910 15:33]:
> On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote:
> > gnome2 depends on gnomemedia2.
> > gnomemedia2 depends on gstreamer-plugins.
> > gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
> > includes -pthread.
>
> This is being worked on from the compiler stand point.
Which is the main reason I didn't do a pr on it. But from reading other
parts of the thread, it seems that ports should not be using -pthread
anyway... would it be worthwhile to submit patches to remove -pthread
(and, for that matter, -lpthread and other variants) in favor of
${PTHREAD_LIBS} regardless of wether `cc -pthread` is an error or a
no-op, or some magical auto-thread-library-selector?
--Mike
pgp0.pgp
Description: PGP signature
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Wed, 10 Sep 2003, Michael Nottebrock wrote: > Sorry if this sounds a bit flame-ish, but the way I see it we now have a > system compiler in -CURRENT that doesn't even compile a hello world if > -pedantic is specified and breaks with lots of existing software out there > that tries to use a threads library because -pthread errors out (why could > this change not have been made _after_ 4.9 is out the door, btw.? Or before > 5.0-R FWIW.) It should have been made 2 years ago, a few months after libc_r became disconnected from libc. There was a whole thread about how ports should be using PTHREAD_LIBS and not using -pthread. Here is the link: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=629118+0+archive/2001/freebsd-current/20010218.freebsd-current As to the timing; it had to happen soon. We need time to iron out the problems before 5.2-RELEASE. This was the first step; there may be a little more pain in the future but this needed to be addressed first. > Are we expecting people to be able to compile software directly from the > commandline at all these days and in the future on a (stable) FreeBSD-5? > > Is the decision criterion for making acceptable changes to core system > components that we can somehow make 3rd party software compiling via > ports-collection hacks? Things need to get worse before they can get better. If I didn't break -pthread, ports@ would have a harder time trying to make things build with a threading library that is selectable via PTHREAD_LIBS. We've had 2.5 years to do this, but now it needs to get done before 5.2-RELEASE. > I feel that a FreeBSD that manages to break so many existing configure-scripts > and build systems is degraded in usefulness. Please, this is -current. If you want less pain then stick with -stable and you won't be annoyed by the -pthread removal. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
Doug White writes: > On Tue, 9 Sep 2003, Tomi Vainio - Sun Finland wrote: > > > Tomi Vainio - Sun Finland writes: > > > Our system died when using iozone -a to ~300G vinum partition made > > > from four disks. Sources were cvsupped 7.9.2003. > > > > > Second panic an hour later. Any good ideas how to fix this? > > > > Tomppa > > > > panic: kmem_malloc(4096): kmem_map too small: 28229632 total allocated > > How much RAM is in the system? What do you have maxusers set to? > First maxusers was 0 then when changed it to 8. When system was still unstable we added memory from 64M to 256M. Now uptime is already 7 hours and we are waiting results. Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Wed, Sep 10, 2003 at 09:56:45AM -0700, Steve Kargl wrote: > > >4.9 and 5.0-R are independent branch. By your logic we should wait to > > >4.10 or 4.11 or 4.12 or ... before any substantial change can be made > > >to -CURRENT. > > > > The point is that is isn't wise to commit a change like the -pthread > > deprecation that breaks many ports just before a ports-freeze. > > Which threads library should -pthread link to your app (libc_r, > libkse, or libthr) on a 5.x system? It should be a stub that libmap then maps to the threading lib you wanted. Or variations on this. If you have a strong interest in this there is a long discussion about this going on. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Wed, Sep 10, 2003 at 12:41:41PM -0400, Michael Edenfield wrote: > gnome2 depends on gnomemedia2. > gnomemedia2 depends on gstreamer-plugins. > gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles > includes -pthread. This is being worked on from the compiler stand point. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs related panic with latest current
On Tue, 9 Sep 2003, Tomi Vainio - Sun Finland wrote: > Tomi Vainio - Sun Finland writes: > > Our system died when using iozone -a to ~300G vinum partition made > > from four disks. Sources were cvsupped 7.9.2003. > > > Second panic an hour later. Any good ideas how to fix this? > > Tomppa > > panic: kmem_malloc(4096): kmem_map too small: 28229632 total allocated How much RAM is in the system? What do you have maxusers set to? > trace > Debugger(c03cc728,c0429ce0,c03db0bd,ca3c6a80,100) at Debugger+0x54 > panic(c03db0bd,1000,1aec000,ca3c6ab0,ca3c6aa0) at panic+0xd5 > kmem_malloc(c082f0b0,1000,2,ca3c6b28,c034d1c5) at kmem_malloc+0x100 > page_alloc(c083aee0,1000,ca3c6b13,2,0) at page_alloc+0x27 > slab_zalloc(c083aee0,102,c09fc900,8108000,ca3c6cb8) at slab_zalloc+0xc5 > uma_zone_slab(c083aee0,102,ca3c6bbf,ca3c6bc0,a4) at uma_zone_slab+0xe8 > uma_zalloc_bucket(c083aee0,102,0,f,1) at uma_zalloc_bucket+0x185 > uma_zalloc_arg(c083aee0,0,102,ca3c6bfc,c083aee0) at uma_zalloc_arg+0x2c7 > malloc(adc,c03f8480,102,384,384) at malloc+0x5c > sigacts_alloc(c0429b00,0,0,280f3000,c026af9d) at sigacts_alloc+0x25 > fork1(c1224be0,14,0,ca3c6ccc,c022c226) at fork1+0x7ab > fork(c1224be0,ca3c6d10,2,c,0) at fork+0x2b > syscall(2f,2f,2f,0,8108000) at syscall+0x2b0 > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (2, FreeBSD ELF32, fork), eip = 0x807c3a7, esp = 0xbfbffb5c, ebp = 0 > xbfbffb88 --- > db> > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
useful workaround and analysis of vnode-backed md deadlock
There's been few reports of deadlocks in md on the lists recently, and I walked into it trying to generate flash images for my shiny new Soekris box. In particular, A previous mail mentioned something getting stuck in "wdrain": (Message-ID <[EMAIL PROTECTED]> from [EMAIL PROTECTED]) For the impatient, a way I found around the problem was to mount the md-backed filesystems with the "sync" option. I analysed the deadlock a little, and here's a synopsis, in case they're of use to anyone. This down as well as I could, and it appears to be an interaction between three processes. This may (and most likely isn't) the only md deadlock, but once I otherwise leave the backing file alone, I don't experience any problems once I mount the filesystem sync, And, because the underlying filesystem is async, access to the md filesystem isn't painfully slower than normal. 1: One thread is operating on the filesystem. In general, this thread is creating dirty buffers for later processing by the bufdaemon, and also making direct write requests. This doesn't actually participate in the deadlock, but does set the stage for it. 2: The "md" thread, processing requests from (1), attempts to lock the vnode for the underlying md device, in order to fulfill a queued write request on the md device. 3: Meanwhile the bufdaemon has kicked in, and is flushing dirty buffers. Some of these are for the files on the md filesystem, some are for the vnode backing the md device itself (actually, I assume that the flushing of the former causes a sudden surge in the latter, as the writes to the md filesystem are converted to writes to the backing vnode) The bufdaemon has locked the md vnode in order to write bufs to it. However, it needs to wait for "runningbufspace", which is designed to limit the number of in-flight async buffer writes. Once the running buffer space exceeds a high threshold, the scheduler is blocked, to be awakened when completed async writes bring it under the low threshold. However, a large chunk of the running buf space is sitting queued for the md thread to process. The md thread can't continue without the vnode lock, so the running buffer space will not fall, and the bufdaemon cannot continue without running buffer space, so will never release the vnode lock. -- Peter Edwards. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Radeon DRM issues under -current (As of 9/10)
On Wed, 10 Sep 2003, Andre Guibert de Bruet wrote: > I'm trying to enable DRM on an ATI Radeon AIW 8500DV (Which gets detected > as a Radeon R200 BB-class board). I've added both "device radeondrm" and > "device agp" to my kernel config file and made sure that XFree86 has both > a "load dri" and a "load glx" directive. > > I'm seeing the following in my all.log: > Sep 10 00:22:36 bling kernel: error: [drm:radeon_cp_init] *ERROR* radeon_cp_init > called without lock held > Sep 10 00:22:36 bling kernel: error: [drm:radeon_unlock] *ERROR* Process 1945 using > kernel context 0 > > I've put a number of configs and logs up: > Kernel config is at: http://bling.properkernel.com/BLING > XF86Config is at:http://bling.properkernel.com/XF86Config > boot -v is at: http://bling.properkernel.com/boot-v > XFree86.0.log is at: http://bling.properkernel.com/XFree86.0.log > glxinfo -v is at:http://bling.properkernel.com/glxinfo Okay, so I missed a couple of messages in the archive. ForcePCIMode true causes DRM to work, but I can't help but think that it's by luck rather than design... I'll update the boot -v with a version from a kernel with DRM_DEBUG in just a little bit. Sep 10 13:13:05 bling kernel: info: [drm] Loading R200 Microcode Sep 10 13:13:05 bling kernel: drm0: [MPSAFE] Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[current tinderbox] failure on alpha/alpha
TB --- 2003-09-10 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-09-10 16:00:01 - 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-09-10 16:03:28 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-09-10 17:06:26 - 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 Wed Sep 10 17:06:26 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/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/pci/if_dc.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/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/pci/if_de.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/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/pci/if_pcn.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/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/pci/if_rl.c /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/pci/if_rl.c: In function `rl_probe': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/pci/if_rl.c:884: error: `RL_HWREV_8110' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/pci/if_rl.c:884: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/pci/if_rl.c:884: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/a
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Wed, Sep 10, 2003 at 05:23:55PM +0200, Michael Nottebrock wrote: > Steve Kargl wrote: > > >I have no problems in building the traditional C "hello world" > >program with "cc -pedantic". > > You're right about that, you'll need a C++ hello world (, cout). > This is in the archives anyway and (should be) well known. Yes, it is a well known issue. The user is getting exactly what they wanted when she gave -pedantic to g++. > >>(why could > >>this change not have been made _after_ 4.9 is out the door, btw.? Or > >>before 5.0-R FWIW.) > > > > > >4.9 and 5.0-R are independent branch. By your logic we should wait to > >4.10 or 4.11 or 4.12 or ... before any substantial change can be made > >to -CURRENT. > > The point is that is isn't wise to commit a change like the -pthread > deprecation that breaks many ports just before a ports-freeze. Which threads library should -pthread link to your app (libc_r, libkse, or libthr) on a 5.x system? > > >The reason gcc-3.3.1 was committed before 5.0-R should > >be fairly obvious. > > I was concerned with the -pthread deprecation. Why? The portmgr can tag the ports collection at any point in time before or after the -pthread deprecation date. Additionally, your initial email started with your whining about -pedantic a and "Hello world" programs, which is completely orthogonal to -pthread. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
* Alexander Leidinger <[EMAIL PROTECTED]> [030910 10:53]:
> In 5-current we have 3 threads libraries and want to be able to install
> and use them in parallel. So there has to be a way to specify which one.
> This is why we need the ports collection to respect the PTHREAD*
> variables. A lot of ports already do this (e.g. the GNOME ones), but not
> all.
Err, not quite. Tried to build gnome2 lately? :)
gnome2 depends on gnomemedia2.
gnomemedia2 depends on gstreamer-plugins.
gstreamer-plugins fails because ARTSD_FLAGS in several dozen Makefiles
includes -pthread.
The fix is a pretty simple thing:
post-configure::
find ${WRKSRCDIR} -name Makefile | xargs ${SED} -e
"s#-pthread#${PTHREAD_LIBS}#g' -i
But of course, it's not a problem on 4.x and the ports tree's frozen at
the moment, so it will probably be a bit until gnome2 fully compiles.
--Mike
pgp0.pgp
Description: PGP signature
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
Am Mi, 2003-09-10 um 15.30 schrieb Michael Nottebrock: > Sorry if this sounds a bit flame-ish, but the way I see it we now have a > system compiler in -CURRENT that doesn't even compile a hello world if > -pedantic is specified and breaks with lots of existing software out there Yes. I agree on this. I would also like to have a compiler which compiles with strictest warning settings possible, because I'm developing on several platforms at once. But I like gcc-3.x (for my C++ programs) very much and would like to continue programming with this compiler, even it does not compile hello world with -pedantic. Wouldn't it be better to complain in a gcc mailing list? You know exactly that FreeBSD-current is offering the most recent technologies and _this_ is why I like it. Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
Steve Kargl wrote: I have no problems in building the traditional C "hello world" program with "cc -pedantic". You're right about that, you'll need a C++ hello world (, cout). This is in the archives anyway and (should be) well known. (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) 4.9 and 5.0-R are independent branch. By your logic we should wait to 4.10 or 4.11 or 4.12 or ... before any substantial change can be made to -CURRENT. The point is that is isn't wise to commit a change like the -pthread deprecation that breaks many ports just before a ports-freeze. The reason gcc-3.3.1 was committed before 5.0-R should be fairly obvious. I was concerned with the -pthread deprecation. I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. Please see the Handbook for the distinction between -CURRENT and -STABLE. Oh please. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PXE boot loader
This is the exact output: CLIENT MAC ADDR: 00 00 24 C1 2D F0 CLIENT IP: 10.0.0.36 MASK: 255.255.255.0 DHCP IP: 10.0.0.1 GATEWAY IP: 10.0.0.4 PXE Loader 1.00 Building the boot loader arguments Relocating the loader and the BTX Starting the BTX loader POST: 012345... rebooting...the pxeboot has been built only with CPUTYPE=i486 CFLAGS="-O -pipe" (from /etc/make.conf) BOOT_COMCONSOLE_SPEED=57600 -DLOADER_TFTP_SUPPORT (on command line) parameters. With -STABLE no problems arise. -- Alex Dupre [EMAIL PROTECTED] http://www.alexdupre.com/ [EMAIL PROTECTED] Today's excuse: We need a licensed electrician to replace the light bulbs in the computer room. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Radeon DRM issues under -current (As of 9/10)
Hi, I'm trying to enable DRM on an ATI Radeon AIW 8500DV (Which gets detected as a Radeon R200 BB-class board). I've added both "device radeondrm" and "device agp" to my kernel config file and made sure that XFree86 has both a "load dri" and a "load glx" directive. I'm seeing the following in my all.log: Sep 10 00:22:36 bling kernel: error: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Sep 10 00:22:36 bling kernel: error: [drm:radeon_unlock] *ERROR* Process 1945 using kernel context 0 I've put a number of configs and logs up: Kernel config is at: http://bling.properkernel.com/BLING XF86Config is at:http://bling.properkernel.com/XF86Config boot -v is at: http://bling.properkernel.com/boot-v XFree86.0.log is at: http://bling.properkernel.com/XFree86.0.log glxinfo -v is at:http://bling.properkernel.com/glxinfo FreeBSD bling.home 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Wed Sep 10 01:18:53 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BLING i386 I've read the radeon(4) manpage and searched the archives but it didn't turn up anything which resolved this. Any ideas? > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Quo vadis, -CURRENT? (recent changes to cc & compatibility)
On Wed, 10 Sep 2003 15:30:28 +0200 Michael Nottebrock <[EMAIL PROTECTED]> wrote: > Sorry if this sounds a bit flame-ish, but the way I see it we now have > a system compiler in -CURRENT that doesn't even compile a hello world > if-pedantic is specified and breaks with lots of existing software out > there This you have to ask the gcc people... > that tries to use a threads library because -pthread errors out (why > could this change not have been made _after_ 4.9 is out the door, > btw.? Or before 5.0-R FWIW.) I don't see the connection between the change in the 5-current compiler and 4.9... > Is the decision criterion for making acceptable changes to core system > components that we can somehow make 3rd party software compiling via > ports-collection hacks? > > I feel that a FreeBSD that manages to break so many existing > configure-scripts and build systems is degraded in usefulness. In 5-current we have 3 threads libraries and want to be able to install and use them in parallel. So there has to be a way to specify which one. This is why we need the ports collection to respect the PTHREAD* variables. A lot of ports already do this (e.g. the GNOME ones), but not all. It may be inconvenient in the short term, but beneficial in the long term. Bye, Alexander. -- If Bill Gates had a dime for every time a Windows box crashed... ...Oh, wait a minute, he already does. 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: network collision increase
The following thing became clear as a result of investigating many things. Network collision increased strangely, after it turned into the following revision. /src/sys/pci/if_dc.c Revision 1.115 Sun Jul 6 21:45:31 2003 UTC Why does collision increase by this change? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
devfs.conf - no man page
Is devfs.conf still valid? I didn't find a man page. Also man devfs doesn't list any FILES section. I want to have own da0 root:stick perm da0 0660 and when I put this in /etc/devfs.conf it doesn't seem to have any effect. -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PXE boot loader
I was trying to boot my net4501 board with PXE. This worked like a charm with pxeboot compiled on -STABLE, but using -CURRENT to build it my net4501 continuously reboot just after the DHCP/TFTP phase (it appears something like "POST12345" and then reboots). Any hint? -- Alex Dupre [EMAIL PROTECTED] http://www.alexdupre.com/ [EMAIL PROTECTED] Today's excuse: The Usenet news is out of date ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Quo vadis, -CURRENT? (recent changes to cc & compatibility)
Sorry if this sounds a bit flame-ish, but the way I see it we now have a system compiler in -CURRENT that doesn't even compile a hello world if -pedantic is specified and breaks with lots of existing software out there that tries to use a threads library because -pthread errors out (why could this change not have been made _after_ 4.9 is out the door, btw.? Or before 5.0-R FWIW.) Are we expecting people to be able to compile software directly from the commandline at all these days and in the future on a (stable) FreeBSD-5? Is the decision criterion for making acceptable changes to core system components that we can somehow make 3rd party software compiling via ports-collection hacks? I feel that a FreeBSD that manages to break so many existing configure-scripts and build systems is degraded in usefulness. - ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org ___ [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
TB --- 2003-09-10 10:46:59 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-09-10 10:46:59 - 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-09-10 10:48:53 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-09-10 11:42:28 - 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 Wed Sep 10 11:42:28 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/sparc64/sparc64/src/sys -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/nfsserver/nfs_srvsubs.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/sparc64/sparc64/src/sys -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/nfsserver/nfs_syscalls.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/sparc64/sparc64/src/sys -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_dc.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/sparc64/sparc64/src/sys -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 -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_rl.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_rl.c: In function `rl_probe': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_rl.c:884: error: `RL_HWREV_8110' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_rl.c:884: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_rl.c:884: error: for each function it appears in.) *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/
[current tinderbox] failure on ia64/ia64
TB --- 2003-09-10 09:33:53 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-09-10 09:33: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-09-10 09:37:18 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-09-10 10:39:57 - 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 Wed Sep 10 10:39:57 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/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/pci/if_dc.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/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/pci/if_de.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/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/pci/if_pcn.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/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/pci/if_rl.c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/pci/if_rl.c: In function `rl_probe': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/pci/if_rl.c:884: error: `RL_HWREV_8110' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/pci/if_rl.c:884: error: (Each undeclared identifier is re
bsdlabel wierd.
Hi I was experimenting with growfs yesterday and I noticed this wierd thing crop up in my label. Notice the 'a' partition which I can no longer get rid of and appears automatically. using bsdlabel -e I have to delete this partition if I want to change any of the other partitions (it complains about overlapping partitions otherwise). [brane-dead] / # bsdlabel /dev/ad0s1 # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 20044064 16unused0 0 c: 200440800unused 1024 8192 # "raw" part, don't edit e: 2004408004.2BSD 1024 8192 46248 What am I missing? BTW, growfs barfed too with a 'rdfs: read error'. [brane-dead] /var/log # fdisk /dev/ad0 *** Working on device /dev/ad0 *** parameters extracted from in-core disklabel are: cylinders=19885 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=19885 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 20044080 (9787 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 428/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: Ian ___ [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
TB --- 2003-09-10 08:11:32 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-09-10 08:11:32 - 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-09-10 08:16:01 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: populating >>> /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything.. TB --- 2003-09-10 09:12:44 - 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 Wed Sep 10 09:12:44 GMT 2003 >>> Kernel build for GENERIC completed on Wed Sep 10 09:24:26 GMT 2003 TB --- 2003-09-10 09:24:26 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-09-10 09:24:26 - 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 Wed Sep 10 09:24:27 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/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/dev/syscons/scterm.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/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/dev/syscons/scterm-dumb.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/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/dev/syscons/scvidctl.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/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-
