Re: FreeBSD 10 and zfsd
op 24-03-14 01:18, Alan Somers schreef: On Sun, Mar 23, 2014 at 4:23 PM, Mark Felder f...@freebsd.org wrote: Hi guys, Any updates? I've been very busy, but I did finally get those two seqpacket related bugs fixed in head. The next step is finding time for the merge. Right now my FreeBSD todo list goes: 1) Commit fixes for half a dozen FIB related bugs. I already have them fixed in my private stable/9 branch, but need to port the fixes to HEAD. 2) Update the zfsd branch. I think that I'll be able to get number 1 done next week, or at least send patches out for review. I don't know if I'll get to number 2. -Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Hello all. Sorry for bringing up on old thread. Is there any news on the zfsd part. It seems it has been included in Truenas, but I did not see anything hit the tree regarding zfsd. Have I missed it or is it still not done. FreeBSD 9.3 is about to get released, and 10.1 will follow it would be nice to have in a new build.. regards Johan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT]: weird memory/linker problem?
Am Sun, 22 Jun 2014 10:10:04 -0700 Adrian Chadd adr...@freebsd.org schrieb: When they segfault, where do they segfault? -a I have not investigated this issue so far, since I was convinced - in the first place - it is triggered by a defetive memory system. So I rebooted immediately being glad having found a solution. I will check next time it happens again. oh On 22 June 2014 07:56, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Hello. I face a strange problem on a set of CURRENT driven boxes. The systems in question are all the same version of CURRENT (more or less, a week or so discrepancy). The boxes affected have 8 GB of RAM and are old-style Core2Duo systems. The phenomenon: Starting up the box shows the operating system working. But sometimes it is impossible to start certain applications, like Firefox - they segfault. More disturbing is the fail of the linker when building world. Sometimes I get strange messages like relocation truncated to fit: R_X86_64_PC32 against symbol `__error' defined in .text when compiling/linking. The funny thing is: rebooting the box and doing exactly the same very often leaves the system then operable - starting applications works, compiling works! First I thought this could be a indication of a dying system and so I checked the memory for two days non-stop without any indication of anything wrong. The boxes do not have ECC RAM - it's Intel. I see this problem on two C2D based boxes relatively often (one E8400 two core, another Q6600 quadcore, both systems have 8 GB RAM). This phenomenon also occured two or three months ago on another machine with 32 GB RAM and a Core-i7 3930K, but it went away (it was the very same error as shown above). Another system, a i3-3220 with 16 GB RAM never showed the problem although that system build world also on a regular basis very frequent as the C2D systems do. Well, I feel a bit confused. On the first view, the problem looks weird and it indicates a kind of memory problem - but testing the memory didn't show anything wrong. Today windowmaker stopped starting due to a malformed command in one of windowmaker's library. I did reboot the box and everything was all right. Then, also today, I tried compiling world and I got a weird error message about a misspelled Int__xxx, I can not remember exactly the text, I rebooted and everything was all right again. Those errors are frequent on 8GB, C2D based systems and at the moment not present any more on more modern systems with more memory as described above. This could be a coincidence, but it is strange anyway. I do not exclude dying hardware, but I'd like to ask whether there is something strange going on with FreeBSD's memory management at the moment and whether those problems could also be triggered by some nasty bug? I never see a crash (which would also indicated faulty hardware), I mostly realise those strange behaviour either after a fresh boot or after I ran some memory disk i/o intensive jobs, like updating the ports tree. By the way, FreeBSD CURRENT suffer from a tremendous performance cut these days when compiling world and updating the ports tree and running portmaster. On one box, on which ports reside on a UFS partion, it takes more than 8 minutes to pass the portmaster -da, which is quick when not compiling world. On another system on which /usr/ports is residing on ZFS (the box has 16GB RAM!), it takes sometimes 30(!) minutes to perform a svn update while compiling world (that is the i3-3220 with 16 GB RAM system), it takes 6 - 15 minutes when the box is relaxed and updating the ports tree the first time (every subsequent update is much faster). Well, I know these reports of mine are a bit weird since I have no exact log of the problems, but I think if there is an issue not with the hardware, I report those in. Regards, oh signature.asc Description: PGP signature
No devices/nodes/files in /dev after building and installing world
Hi all, I'm currently stuck on the following. Haven't built HEAD in a while, and now after a make buildworld kernel installworld distrib-dirs distribution I don't have any nodes in /dev at all. As far as I remember there was always a minimum set of nodes in there, like ttys etc. What happened? Which changes did I miss? Cheers, Mat ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: No devices/nodes/files in /dev after building and installing world
Mattia Rossi wrote this message on Mon, Jun 23, 2014 at 12:48 +0200: I'm currently stuck on the following. Haven't built HEAD in a while, and now after a make buildworld kernel installworld distrib-dirs distribution I don't have any nodes in /dev at all. As far as I remember there was always a minimum set of nodes in there, like ttys etc. What happened? Which changes did I miss? We use devfs, so you don't need anything in /dev... when the system boots, it'll automatically mount /dev for you.. -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ahci panics when detaching...
So, when I try to eject a ESATA card, the machine panics... I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...
When I try w/ ahci, I get a panic... The panic backtrace is:
#8 0x80ced4e2 in calltrap () at ../../../amd64/amd64/exception.S:231
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active (rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
In frame 9:
(kgdb) fr 9
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de,
r_bushandle = 0xdeadc0dedeadc0de}
So, looks like something is corrupted the resource data...
Attach dmesg:
atapci0: JMicron JMB363 UDMA133 controller at device 0.0 on pci2
ahci1: JMicron JMB363 AHCI SATA controller at channel -1 on atapci0
ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
ahci1: quirks=0x1NOFORCE
ahcich6: AHCI channel at channel 0 on ahci1
ahcich7: AHCI channel at channel 1 on ahci1
ata2: ATA channel at channel 0 on atapci0
[eject card]
ahcich6: stopping AHCI engine failed
ahcich6: stopping AHCI FR engine failed
ahcich6: detached
ahcich7: stopping AHCI engine failed
ahcich7: stopping AHCI FR engine failed
ahcich7: detached
ahci1: detached
ata2: detached
atapci0: detached
Fatal trap 9: general protection fault while in kernel mode
Also, has anyone thought about adding a case in your trap
handler that when we hit the deadc0de address, to print up a
special message or something? At least flag it, or do we not get
the faulting address?
This is HEAD as of r266429.
Let me know if there is anything else you need to know.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ahci panics when detaching...
On 06/23/2014 08:44, John-Mark Gurney wrote:
So, when I try to eject a ESATA card, the machine panics... I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...
When I try w/ ahci, I get a panic... The panic backtrace is:
#8 0x80ced4e2 in calltrap () at ../../../amd64/amd64/exception.S:231
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active (rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
In frame 9:
(kgdb) fr 9
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de,
r_bushandle = 0xdeadc0dedeadc0de}
So, looks like something is corrupted the resource data...
The resource data has been freed.
Attach dmesg:
atapci0: JMicron JMB363 UDMA133 controller at device 0.0 on pci2
ahci1: JMicron JMB363 AHCI SATA controller at channel -1 on atapci0
ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
ahci1: quirks=0x1NOFORCE
ahcich6: AHCI channel at channel 0 on ahci1
ahcich7: AHCI channel at channel 1 on ahci1
ata2: ATA channel at channel 0 on atapci0
[eject card]
ahcich6: stopping AHCI engine failed
ahcich6: stopping AHCI FR engine failed
ahcich6: detached
ahcich7: stopping AHCI engine failed
ahcich7: stopping AHCI FR engine failed
ahcich7: detached
ahci1: detached
ata2: detached
atapci0: detached
Fatal trap 9: general protection fault while in kernel mode
Also, has anyone thought about adding a case in your trap
handler that when we hit the deadc0de address, to print up a
special message or something? At least flag it, or do we not get
the faulting address?
This is HEAD as of r266429.
Let me know if there is anything else you need to know.
The full stack trace might be useful.
Eric
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ahci panics when detaching...
Eric van Gyzen wrote this message on Mon, Jun 23, 2014 at 08:57 -0500:
On 06/23/2014 08:44, John-Mark Gurney wrote:
So, when I try to eject a ESATA card, the machine panics... I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...
When I try w/ ahci, I get a panic... The panic backtrace is:
#8 0x80ced4e2 in calltrap () at
../../../amd64/amd64/exception.S:231
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active
(rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
In frame 9:
(kgdb) fr 9
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de,
r_bushandle = 0xdeadc0dedeadc0de}
So, looks like something is corrupted the resource data...
The resource data has been freed.
Well, that is a type of corruption.. :) If we free it, why wasn't
it removed from the list? or properly NULL'd out?
Attach dmesg:
atapci0: JMicron JMB363 UDMA133 controller at device 0.0 on pci2
ahci1: JMicron JMB363 AHCI SATA controller at channel -1 on atapci0
ahci1: AHCI v1.00 with 2 3Gbps ports, Port Multiplier supported
ahci1: quirks=0x1NOFORCE
ahcich6: AHCI channel at channel 0 on ahci1
ahcich7: AHCI channel at channel 1 on ahci1
ata2: ATA channel at channel 0 on atapci0
[eject card]
ahcich6: stopping AHCI engine failed
ahcich6: stopping AHCI FR engine failed
ahcich6: detached
ahcich7: stopping AHCI engine failed
ahcich7: stopping AHCI FR engine failed
ahcich7: detached
ahci1: detached
ata2: detached
atapci0: detached
Fatal trap 9: general protection fault while in kernel mode
Also, has anyone thought about adding a case in your trap
handler that when we hit the deadc0de address, to print up a
special message or something? At least flag it, or do we not get
the faulting address?
This is HEAD as of r266429.
Let me know if there is anything else you need to know.
The full stack trace might be useful.
I could give it to you, but it contains code I can't release (at
least not yet)... It's basicly an interrupt that calls
pci_delete_child, so there isn't anymore useful information there..
I'm just puzzled why uart and re don't have this same problem..
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT]: weird memory/linker problem?
Am Sun, 22 Jun 2014 10:10:04 -0700 Adrian Chadd adr...@freebsd.org schrieb: When they segfault, where do they segfault? -a Now I get more fun. After a buildworld and reboot, the box in question is at CURRENT: FreeBSD 11.0-CURRENT #0 r267782: Mon Jun 23 13:12:56 CEST 2014 amd64 After a reboot, everything is/was all right. After reboot, I did an update of the ports tree (I do this regularily). I configured /etc/make.conf that way, that ports tree update is performed via using /usr/bin/svn. Now, ~ three hours of regular work (KDevelop, some GIMP, LaTeX work, nothing special, but a bit memory consuming regrading GIMP) I tried updating the ports tree and surprisingly the tree is left over in a unclean condition while /usr/bin/svn segfault (on console: pid 18013 (svn), uid 0: exited on signal 11 (core dumped)). Using /usr/local/bin/svn, which is from the devel/subversion port, performs well, while FreeBSD 11's svn contribution dies as described. It did not hours ago! Well, this drives me nuts. Is it a bug in FreeBSD (maybe relocating libs, the memory map or something else) or is it in fact the agony of my computer system? As reported below, memory checks via memtest didn't show up any kind of faulty memory. I'm out of ideas. Is there a way to stress test the CPU and memory system to check whether RAM, the CPU itself and, as an additional possibility, the disk i/o controller (Intel ICH10)? Thanks for your patience, Oliver On 22 June 2014 07:56, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Hello. I face a strange problem on a set of CURRENT driven boxes. The systems in question are all the same version of CURRENT (more or less, a week or so discrepancy). The boxes affected have 8 GB of RAM and are old-style Core2Duo systems. The phenomenon: Starting up the box shows the operating system working. But sometimes it is impossible to start certain applications, like Firefox - they segfault. More disturbing is the fail of the linker when building world. Sometimes I get strange messages like relocation truncated to fit: R_X86_64_PC32 against symbol `__error' defined in .text when compiling/linking. The funny thing is: rebooting the box and doing exactly the same very often leaves the system then operable - starting applications works, compiling works! First I thought this could be a indication of a dying system and so I checked the memory for two days non-stop without any indication of anything wrong. The boxes do not have ECC RAM - it's Intel. I see this problem on two C2D based boxes relatively often (one E8400 two core, another Q6600 quadcore, both systems have 8 GB RAM). This phenomenon also occured two or three months ago on another machine with 32 GB RAM and a Core-i7 3930K, but it went away (it was the very same error as shown above). Another system, a i3-3220 with 16 GB RAM never showed the problem although that system build world also on a regular basis very frequent as the C2D systems do. Well, I feel a bit confused. On the first view, the problem looks weird and it indicates a kind of memory problem - but testing the memory didn't show anything wrong. Today windowmaker stopped starting due to a malformed command in one of windowmaker's library. I did reboot the box and everything was all right. Then, also today, I tried compiling world and I got a weird error message about a misspelled Int__xxx, I can not remember exactly the text, I rebooted and everything was all right again. Those errors are frequent on 8GB, C2D based systems and at the moment not present any more on more modern systems with more memory as described above. This could be a coincidence, but it is strange anyway. I do not exclude dying hardware, but I'd like to ask whether there is something strange going on with FreeBSD's memory management at the moment and whether those problems could also be triggered by some nasty bug? I never see a crash (which would also indicated faulty hardware), I mostly realise those strange behaviour either after a fresh boot or after I ran some memory disk i/o intensive jobs, like updating the ports tree. By the way, FreeBSD CURRENT suffer from a tremendous performance cut these days when compiling world and updating the ports tree and running portmaster. On one box, on which ports reside on a UFS partion, it takes more than 8 minutes to pass the portmaster -da, which is quick when not compiling world. On another system on which /usr/ports is residing on ZFS (the box has 16GB RAM!), it takes sometimes 30(!) minutes to perform a svn update while compiling world (that is the i3-3220 with 16 GB RAM system), it takes 6 - 15 minutes when the box is relaxed and updating the ports tree the first time (every subsequent update is much faster). Well, I know these reports
Re: [CURRENT]: weird memory/linker problem?
On 23 Jun 2014, at 16:31, O. Hartmann ohart...@zedat.fu-berlin.de wrote: Am Sun, 22 Jun 2014 10:10:04 -0700 Adrian Chadd adr...@freebsd.org schrieb: When they segfault, where do they segfault? ... GIMP, LaTeX work, nothing special, but a bit memory consuming regrading GIMP) I tried updating the ports tree and surprisingly the tree is left over in a unclean condition while /usr/bin/svn segfault (on console: pid 18013 (svn), uid 0: exited on signal 11 (core dumped)). Using /usr/local/bin/svn, which is from the devel/subversion port, performs well, while FreeBSD 11's svn contribution dies as described. It did not hours ago! I think what Adrian meant was: can you run svn (or another crashing program) in gdb, and post a backtrace? Or maybe run ktrace, and see where it dies? Alternatively, put a core dump and the executable (with debug info) in a tarball, and upload it somewhere, so somebody else can analyze it. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [CURRENT]: weird memory/linker problem?
On Mon, 2014-06-23 at 16:31 +0200, O. Hartmann wrote: I'm out of ideas. Is there a way to stress test the CPU and memory system to check whether RAM, the CPU itself and, as an additional possibility, the disk i/o controller (Intel ICH10)? Thanks for your patience, A really good tool for stress-testing a system is ports/math/mprime. It will find memory and cpu errors that memtest86 and other tools completely overlook. Run one copy per cpu, something like this: for i in $(jot $(sysctl -n hw.ncpu) 0) ; do sleep $((i * 2)) mprime -t -a$i /tmp/mprime$i.log done Many overclockers use this to ensure the system is stable with the OC settings. If your system can run a copy of mprime per cpu continuously for 24 hours the hardware is fine. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Latest -current panic in uaudio_detach() / bus_dmamem_free()
On Monday, June 23, 2014 12:03:20 am Andrey Chernov wrote: On 23.06.2014 6:46, Alexander Kabaev wrote: Please provide us with the information on the actual audio hardware you are using, preferably in form of a dmesg output. uaudio0: vendor 0x046d product 0x0990, class 239/2, rev 2.00/0.05, addr 7 on usbus3 uaudio0: No playback. uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer. uaudio0: No MIDI sequencer. pcm7: USB audio on uaudio0 uaudio0: No HID volume keys found. Thanx, after backing out the patch below this panic is gone. Probably even additional b-dmatag NULL check is needed for bus_dmamap_unload() too. No, buf_addr should only be set if bus_dmamap_load() was called. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ahci panics when detaching...
On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote:
So, when I try to eject a ESATA card, the machine panics... I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...
When I try w/ ahci, I get a panic... The panic backtrace is:
#8 0x80ced4e2 in calltrap () at
../../../amd64/amd64/exception.S:231
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active
(rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
In frame 9:
(kgdb) fr 9
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de,
r_bushandle = 0xdeadc0dedeadc0de}
So, looks like something is corrupted the resource data...
This is the malloc junking on free. However, I wonder if the
problem is that the resource was freed without being properly
cleared from the resource_list in the PCI ivars. Is this with local
patches that you have?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CURRENT]: weird memory/linker problem?
Am Mon, 23 Jun 2014 09:27:46 -0600 Ian Lepore i...@freebsd.org schrieb: On Mon, 2014-06-23 at 16:31 +0200, O. Hartmann wrote: I'm out of ideas. Is there a way to stress test the CPU and memory system to check whether RAM, the CPU itself and, as an additional possibility, the disk i/o controller (Intel ICH10)? Thanks for your patience, A really good tool for stress-testing a system is ports/math/mprime. It will find memory and cpu errors that memtest86 and other tools completely overlook. Run one copy per cpu, something like this: for i in $(jot $(sysctl -n hw.ncpu) 0) ; do sleep $((i * 2)) mprime -t -a$i /tmp/mprime$i.log done Many overclockers use this to ensure the system is stable with the OC settings. If your system can run a copy of mprime per cpu continuously for 24 hours the hardware is fine. -- Ian A great idea, but regretably I receive this error while trying to install that neat port: mprime-0.0.24.14 is only for i386, while you are running amd64. *** Error code 1 Is there a 64bit counterpart? Oliver signature.asc Description: PGP signature
Re: FreeBSD 10 and zfsd
On Mon, Jun 23, 2014 at 12:50 AM, Johan Hendriks joh.hendr...@gmail.com wrote: op 24-03-14 01:18, Alan Somers schreef: On Sun, Mar 23, 2014 at 4:23 PM, Mark Felder f...@freebsd.org wrote: Hi guys, Any updates? I've been very busy, but I did finally get those two seqpacket related bugs fixed in head. The next step is finding time for the merge. Right now my FreeBSD todo list goes: 1) Commit fixes for half a dozen FIB related bugs. I already have them fixed in my private stable/9 branch, but need to port the fixes to HEAD. 2) Update the zfsd branch. I think that I'll be able to get number 1 done next week, or at least send patches out for review. I don't know if I'll get to number 2. -Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Hello all. Sorry for bringing up on old thread. Is there any news on the zfsd part. It seems it has been included in Truenas, but I did not see anything hit the tree regarding zfsd. Have I missed it or is it still not done. FreeBSD 9.3 is about to get released, and 10.1 will follow it would be nice to have in a new build.. The projects/zfsd project branch is up to date. Merging it to CURRENT is blocked on these tasks. 1) (The biggie) We must resolve the issue with multiple geom opens. Geom tries to prevent any two consumers from simultaneously opening the same provider. This is why, for example, you can't do dd if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system. However, ZFS internally opens spare devices multiple times. The only way that geom will allow that is if ZFS opens devices non-exclusively. That means that you will lose your protection. Fixing this correctly requires deep changes to ZFS to remove the multiple opens. 2) Need to merge in zfsd's functional tests. I'm currently working on this issue as time allows. 3) It needs a manpage. 4) Various bug fixes need to be merged to the kernel and to LibZFS. Coordinating with Illumos makes that process slow. will@ is working on it as time allows. 5) libdevctl needs to be made private 6) The sequential packet feature added to devd in the zfsd project branch at revision r266519 must be merged to head. It's currently waiting for review from imp@ and ian@. For TrueNAS, I believe that delphij@ merged an older version of zfsd from the project branch. -Alan regards Johan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Previously working PXE setup now fails
see if you can run wireshark on your NFS server that is being mounted. That should narrow down the RPC error. It took a while to get around to this, but the problem looks like NFS v3 - v4 conflict. Wireshark shows these errors: Program Version: 3 \ V3 Procedure: MNT (1) \Status: ERR_ACCESS (13) But NFS is started as v4. /etc/exports (not sure if correct syntax): V4: / -network 192.168.2.0/26 /data/amd64 -ro -network 192.168.2.0/26 # NFS root /usr/local -ro -maproot=0 -network 192.168.2.0/26 /home -network 192.168.2.0/26 The PXE structure (dhcp tftp) are started as a jail with the jail root folder as the NFS export root (/data/amd64). The jail and NFS services are not started with boot but with separate script. /etc/rc.conf has: rpcbind_flags=-h 192.168.2.1 mountd_flags=-r -n -l -h 192.168.2.1 nfsd_flags=-u -t -n 4 -h 192.168.2.1 nfsv4_only=YES nfsv4_server_enable=YES pxe_start_script.sh: jail -c pxe service rpcbind onestart service mountd onestart service nfsd onestart service nfsuserd onestart # disabled_not_needed? rpc_lockd_enable=YES rpc_statd_enable= I should probablymove the rc.conf flags into my pxe_start_script.sh, but not sure how to pass service start flags in an sh script. Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
Op maandag 23 juni 2014 heeft Alan Somers asom...@freebsd.org het volgende geschreven: On Mon, Jun 23, 2014 at 12:50 AM, Johan Hendriks joh.hendr...@gmail.com javascript:; wrote: op 24-03-14 01:18, Alan Somers schreef: On Sun, Mar 23, 2014 at 4:23 PM, Mark Felder f...@freebsd.org javascript:; wrote: Hi guys, Any updates? I've been very busy, but I did finally get those two seqpacket related bugs fixed in head. The next step is finding time for the merge. Right now my FreeBSD todo list goes: 1) Commit fixes for half a dozen FIB related bugs. I already have them fixed in my private stable/9 branch, but need to port the fixes to HEAD. 2) Update the zfsd branch. I think that I'll be able to get number 1 done next week, or at least send patches out for review. I don't know if I'll get to number 2. -Alan ___ freebsd-current@freebsd.org javascript:; mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org javascript:; Hello all. Sorry for bringing up on old thread. Is there any news on the zfsd part. It seems it has been included in Truenas, but I did not see anything hit the tree regarding zfsd. Have I missed it or is it still not done. FreeBSD 9.3 is about to get released, and 10.1 will follow it would be nice to have in a new build.. The projects/zfsd project branch is up to date. Merging it to CURRENT is blocked on these tasks. 1) (The biggie) We must resolve the issue with multiple geom opens. Geom tries to prevent any two consumers from simultaneously opening the same provider. This is why, for example, you can't do dd if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system. However, ZFS internally opens spare devices multiple times. The only way that geom will allow that is if ZFS opens devices non-exclusively. That means that you will lose your protection. Fixing this correctly requires deep changes to ZFS to remove the multiple opens. 2) Need to merge in zfsd's functional tests. I'm currently working on this issue as time allows. 3) It needs a manpage. 4) Various bug fixes need to be merged to the kernel and to LibZFS. Coordinating with Illumos makes that process slow. will@ is working on it as time allows. 5) libdevctl needs to be made private 6) The sequential packet feature added to devd in the zfsd project branch at revision r266519 must be merged to head. It's currently waiting for review from imp@ and ian@. For TrueNAS, I believe that delphij@ merged an older version of zfsd from the project branch. -Alan regards Johan ___ freebsd-current@freebsd.org javascript:; mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org javascript:; Thanks for the headsup and your time explaning the issues.. Regards Johan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 and zfsd
On 2014-06-23 12:39, Alan Somers wrote: The projects/zfsd project branch is up to date. Merging it to CURRENT is blocked on these tasks. 1) (The biggie) We must resolve the issue with multiple geom opens. Geom tries to prevent any two consumers from simultaneously opening the same provider. This is why, for example, you can't do dd if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system. However, ZFS internally opens spare devices multiple times. The only way that geom will allow that is if ZFS opens devices non-exclusively. That means that you will lose your protection. Fixing this correctly requires deep changes to ZFS to remove the multiple opens. 2) Need to merge in zfsd's functional tests. I'm currently working on this issue as time allows. 3) It needs a manpage. I can help with a man page. Is there an outline or readme to start from? 4) Various bug fixes need to be merged to the kernel and to LibZFS. Coordinating with Illumos makes that process slow. will@ is working on it as time allows. 5) libdevctl needs to be made private 6) The sequential packet feature added to devd in the zfsd project branch at revision r266519 must be merged to head. It's currently waiting for review from imp@ and ian@. For TrueNAS, I believe that delphij@ merged an older version of zfsd from the project branch. -Alan -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: FreeBSD 10 and zfsd
On Mon, Jun 23, 2014 at 1:25 PM, Allan Jude allanj...@freebsd.org wrote: On 2014-06-23 12:39, Alan Somers wrote: The projects/zfsd project branch is up to date. Merging it to CURRENT is blocked on these tasks. 1) (The biggie) We must resolve the issue with multiple geom opens. Geom tries to prevent any two consumers from simultaneously opening the same provider. This is why, for example, you can't do dd if=/dev/zero of=/dev/ada0 if your ada0 has a mounted file system. However, ZFS internally opens spare devices multiple times. The only way that geom will allow that is if ZFS opens devices non-exclusively. That means that you will lose your protection. Fixing this correctly requires deep changes to ZFS to remove the multiple opens. 2) Need to merge in zfsd's functional tests. I'm currently working on this issue as time allows. 3) It needs a manpage. I can help with a man page. Is there an outline or readme to start from? None that I know of. Usage is simple; there is only one option. -d runs in the foreground instead of daemonizing. But the man page should also describe the location of the case files and the types of damage that zfsd can fix. Unfortunately, that's not documented anywhere except in the source right now. I appreciate the offer of help, Allan, but you may get frustrated; you just don't have much to work with. -Alan with a single l. 4) Various bug fixes need to be merged to the kernel and to LibZFS. Coordinating with Illumos makes that process slow. will@ is working on it as time allows. 5) libdevctl needs to be made private 6) The sequential packet feature added to devd in the zfsd project branch at revision r266519 must be merged to head. It's currently waiting for review from imp@ and ian@. For TrueNAS, I believe that delphij@ merged an older version of zfsd from the project branch. -Alan -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Sat, 21 Jun 2014 18:55:40 -0400, Glen Barber writes: make make make -j8 -DNO_CLEAN buildworld This is, IMHO, the worst solution I've heard on this topic so far. I didn't say it was a good solution - but if you want -j you may not have a choice (unless you fix src/Makefile). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Thu, Jun 19, 2014 at 9:00 PM, Warner Losh i...@bsdimp.com wrote: OK. I must be daft, or maybe just missing something. But I can build 9.3 almost branch point on a current jail running on a 10.x system (to simulate the 9 on current case). I don't see the problem being talked about at all. As for 9 on 10, I was also able to do a build, but my 10.x system may not have been pristine. I was able to reproduce the problem by building FreeNAS/master branch (which uses FreeBSD 9.2-ish sources) on a FreeBSD 10 host, using make make buildworld as suggested by Glen. The FreeNAS build generates is following make.conf file and uses that to build FreeBSD 9.2. It works fine on a FreeBSD-9 host, but bombs out on a FreeBSD 10 host. = #WITHOUT_ACPI=true WITHOUT_ATM=true WITHOUT_BIND_DNSSEC=true WITHOUT_BIND_ETC=true WITHOUT_BIND_LIBS_LWRES=true WITHOUT_BIND_NAMED=true WITHOUT_BLUETOOTH=true WITHOUT_CALENDAR=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_DICT=true WITHOUT_EXAMPLES=true WITHOUT_FORTRAN=true WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=true WITHOUT_GCOV=true WITHOUT_GPIB=true WITHOUT_HTML=true WITHOUT_I4B=true WITHOUT_IPFILTER=true WITHOUT_IPX=true WITHOUT_LIB32=true WITHOUT_LIBKSE=true # Required for proper terminal locale #WITHOUT_LOCALES=true WITHOUT_LPR=true WITHOUT_MAN=true WITHOUT_NDIS=true WITHOUT_NLS=true WITHOUT_NS_CACHING=true WITHOUT_OBJC=true WITHOUT_PORTSNAP=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_RCMDS=true WITHOUT_SENDMAIL=true # Knob needs to be fixed on systems that don't have the docs stuff # preinstalled, e.g. 9.x bsdinstall images. #WITHOUT_SHAREDOCS=true WITHOUT_SYSINSTALL=true # Telnet's a useful tool to have on the remote box. #WITHOUT_TELNET=true WITHOUT_WIRELESS=true WITHOUT_WPA_SUPPLICANT_EAPOL=true DEFAULT_VERSIONS=python=2.7 NOPORTDOCS=true LOCAL_DIRS= WITHOUT_CLANG=true WITHOUT_SSP=true = -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 5:02 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Thu, Jun 19, 2014 at 9:00 PM, Warner Losh i...@bsdimp.com wrote: OK. I must be daft, or maybe just missing something. But I can build 9.3 almost branch point on a current jail running on a 10.x system (to simulate the 9 on current case). I don’t see the problem being talked about at all. As for 9 on 10, I was also able to do a build, but my 10.x system may not have been pristine. I was able to reproduce the problem by building FreeNAS/master branch (which uses FreeBSD 9.2-ish sources) on a FreeBSD 10 host, using make make buildworld as suggested by Glen. The FreeNAS build generates is following make.conf file and uses that to build FreeBSD 9.2. It works fine on a FreeBSD-9 host, but bombs out on a FreeBSD 10 host. Which bombing out are you seeing (two or three have been sighted in this thread)? And is this a nanobsd build, or a straight buildworld? And I specifically was doing my testing on -current, not 10.x. I haven’t back ported much of anything I’ve done to the build system, and if anybody else has, then it is on them to make it work in the 10.x environment. While it has usually worked, 9 on 10 isn’t in the supported matrix we’ve traditionally had in this project. Warner = #WITHOUT_ACPI=true WITHOUT_ATM=true WITHOUT_BIND_DNSSEC=true WITHOUT_BIND_ETC=true WITHOUT_BIND_LIBS_LWRES=true WITHOUT_BIND_NAMED=true WITHOUT_BLUETOOTH=true WITHOUT_CALENDAR=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_DICT=true WITHOUT_EXAMPLES=true WITHOUT_FORTRAN=true WITHOUT_FREEBSD_UPDATE=yes WITHOUT_GAMES=true WITHOUT_GCOV=true WITHOUT_GPIB=true WITHOUT_HTML=true WITHOUT_I4B=true WITHOUT_IPFILTER=true WITHOUT_IPX=true WITHOUT_LIB32=true WITHOUT_LIBKSE=true # Required for proper terminal locale #WITHOUT_LOCALES=true WITHOUT_LPR=true WITHOUT_MAN=true WITHOUT_NDIS=true WITHOUT_NLS=true WITHOUT_NS_CACHING=true WITHOUT_OBJC=true WITHOUT_PORTSNAP=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_RCMDS=true WITHOUT_SENDMAIL=true # Knob needs to be fixed on systems that don't have the docs stuff # preinstalled, e.g. 9.x bsdinstall images. #WITHOUT_SHAREDOCS=true WITHOUT_SYSINSTALL=true # Telnet's a useful tool to have on the remote box. #WITHOUT_TELNET=true WITHOUT_WIRELESS=true WITHOUT_WPA_SUPPLICANT_EAPOL=true DEFAULT_VERSIONS=python=2.7 NOPORTDOCS=true LOCAL_DIRS= WITHOUT_CLANG=true WITHOUT_SSP=true You might have to (bogusly IMHO) define WITHOUT_CLANG_IS_CC=true as well for things to work. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Previously working PXE setup now fails
Beeblebrox wrote: see if you can run wireshark on your NFS server that is being mounted. That should narrow down the RPC error. It took a while to get around to this, but the problem looks like NFS v3 - v4 conflict. Wireshark shows these errors: Program Version: 3 \ V3 Procedure: MNT (1) \Status: ERR_ACCESS (13) But NFS is started as v4. /etc/exports (not sure if correct syntax): V4: / -network 192.168.2.0/26 /data/amd64 -ro -network 192.168.2.0/26 # NFS root /usr/local -ro -maproot=0 -network 192.168.2.0/26 /home -network 192.168.2.0/26 The PXE structure (dhcp tftp) are started as a jail with the jail root folder as the NFS export root (/data/amd64). The jail and NFS services are not started with boot but with separate script. The Mount protocol request in your packet trace specifies a path of /. For the above exports to work, the MNT path must be /data/amd64. (I think this is the root-path option specified in your entry for the client on your dhcp server.) Look at the MNT Call lines in the wireshark trace and get the path to be /data/amd64 and not /. It isn't using NFSv4, so the the V4: / ... line is not relevent to this. As I think I've mentioned before, a NFSv4 root fs won't work, so don't bother trying... Good luck with it, rick /etc/rc.conf has: rpcbind_flags=-h 192.168.2.1 mountd_flags=-r -n -l -h 192.168.2.1 nfsd_flags=-u -t -n 4 -h 192.168.2.1 nfsv4_only=YES nfsv4_server_enable=YES pxe_start_script.sh: jail -c pxe service rpcbind onestart service mountd onestart service nfsd onestart service nfsuserd onestart # disabled_not_needed? rpc_lockd_enable=YES rpc_statd_enable= I should probablymove the rc.conf flags into my pxe_start_script.sh, but not sure how to pass service start flags in an sh script. Regards. -- FreeBSD_amd64_11-Current_RadeonKMS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh i...@bsdimp.com wrote: Which bombing out are you seeing (two or three have been sighted in this thread)? And is this a nanobsd build, or a straight buildworld? When building FreeNAS, with a hacked the nanobsd script to does make make buildworld, and the make.conf which I posted, I am seeing this: -- stage 1.2: bootstrap tools -- cd /zroot/build/r/freenas2/FreeBSD/src; MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp INSTALL=sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp VERSION=9.3-ALPHA MAKEFLAGS=-m /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9 .MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64 TARGET_ARCH=amd64 COMPILER_TYPE=clang /zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD bootstrap-tools === gnu/usr.bin/gperf (obj,depend,all,install) === gnu/usr.bin/gperf/doc (obj) === gnu/usr.bin/gperf/doc (depend) make: don't know how to make /usr/lib/libstdc++.a. Stop *** [bootstrap-tools] Error code 2 1 error *** [_bootstrap-tools] Error code 2 1 error *** [buildworld] Error code 2 make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src 1 error make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src === ERROR: build FAILED; see above or log file here: /zroot/build/r/freenas2/os-base/amd64/_.bw *** Error code 2 Stop. make: stopped in /zroot/build/r/freenas2 And I specifically was doing my testing on -current, not 10.x. I haven't back ported much of anything I've done to the build system, and if anybody else has, then it is on them to make it work in the 10.x environment. While it has usually worked, 9 on 10 isn't in the supported matrix we've traditionally had in this project. I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r267305 ). -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 5:19 PM, Craig Rodrigues rodr...@freebsd.org wrote: On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh i...@bsdimp.com wrote: Which bombing out are you seeing (two or three have been sighted in this thread)? And is this a nanobsd build, or a straight buildworld? When building FreeNAS, with a hacked the nanobsd script to does make make buildworld, and the make.conf which I posted, I am seeing this: -- stage 1.2: bootstrap tools -- cd /zroot/build/r/freenas2/FreeBSD/src; MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp INSTALL=sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp VERSION=9.3-ALPHA MAKEFLAGS=-m /zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9 .MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null __MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m /zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64 TARGET_ARCH=amd64 COMPILER_TYPE=clang /zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make -f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS= -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF -DEARLY_BUILD bootstrap-tools === gnu/usr.bin/gperf (obj,depend,all,install) === gnu/usr.bin/gperf/doc (obj) === gnu/usr.bin/gperf/doc (depend) make: don't know how to make /usr/lib/libstdc++.a. Stop *** [bootstrap-tools] Error code 2 1 error *** [_bootstrap-tools] Error code 2 1 error *** [buildworld] Error code 2 make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src 1 error make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src === ERROR: build FAILED; see above or log file here: /zroot/build/r/freenas2/os-base/amd64/_.bw *** Error code 2 Stop. make: stopped in /zroot/build/r/freenas2 And I specifically was doing my testing on -current, not 10.x. I haven’t back ported much of anything I’ve done to the build system, and if anybody else has, then it is on them to make it work in the 10.x environment. While it has usually worked, 9 on 10 isn’t in the supported matrix we’ve traditionally had in this project. I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r267305 ). I wonder how this could possibly happen on stable-10, since EARLY_BUILD is still there to preclude the line being added. I’ll have to re-run my test WITHOUT_CLANG. I just used the defaults. Any chance you can narrow the number of options required to trigger this? Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
Hi,
OK, I think I see the issue. I looked here:
http://svnweb.freebsd.org/base/stable/9/share/mk/bsd.prog.mk?view=log
and saw that dim@ MFC'd his EARLY_BUILD stuff in r257812.
That is why you can build stable/9 on a stable/10 host.
I am building FreeBSD 9.2 which doesn't have that change.
bsd.prog.mk in stable/9
==
.if defined(PROG_CXX) !defined(EARLY_BUILD)
.if !empty(CXXFLAGS:M-stdlib=libc++)
echo ${PROG}: ${LIBCPLUSPLUS} ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
bsd.prog.mk in 9.2
.if defined(PROG_CXX)
.if !empty(CXXFLAGS:M-stdlib=libc++)
echo ${PROG}: ${LIBCPLUSPLUS} ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
bsd.prog.mk in CURRENT
.if defined(PROG_CXX)
.if ${COMPILER_TYPE} == clang empty(CXXFLAGS:M-stdlib=libstdc++)
echo ${PROG}: ${LIBCPLUSPLUS} ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
So, I guess that stable/9 can build properly on a stable/10 box.
For FreeBSD 9.2, there is no easy way out.
--
Craig
On Mon, Jun 23, 2014 at 4:23 PM, Warner Losh i...@bsdimp.com wrote:
On Jun 23, 2014, at 5:19 PM, Craig Rodrigues rodr...@freebsd.org wrote:
On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh i...@bsdimp.com wrote:
Which bombing out are you seeing (two or three have been sighted in this
thread)? And is this a nanobsd build, or a straight buildworld?
When building FreeNAS, with a hacked the nanobsd
script to does make make buildworld, and the make.conf which I posted,
I
am seeing this:
--
stage 1.2: bootstrap tools
--
cd /zroot/build/r/freenas2/FreeBSD/src;
MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
INSTALL=sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh
PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
VERSION=9.3-ALPHA MAKEFLAGS=-m
/zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9
.MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null
__MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m
/zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64
TARGET_ARCH=amd64 COMPILER_TYPE=clang
/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make
-f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS=
-DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC
-DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF
-DEARLY_BUILD bootstrap-tools
=== gnu/usr.bin/gperf (obj,depend,all,install)
=== gnu/usr.bin/gperf/doc (obj)
=== gnu/usr.bin/gperf/doc (depend)
make: don't know how to make /usr/lib/libstdc++.a. Stop
*** [bootstrap-tools] Error code 2
1 error
*** [_bootstrap-tools] Error code 2
1 error
*** [buildworld] Error code 2
make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
1 error
make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
===
ERROR: build FAILED; see above or log file here:
/zroot/build/r/freenas2/os-base/amd64/_.bw
*** Error code 2
Stop.
make: stopped in /zroot/build/r/freenas2
And I specifically was doing my testing on -current, not 10.x. I haven't
back ported much of anything I've done to the build system, and if anybody
else has, then it is on them to make it work in the 10.x environment. While
it has usually worked, 9 on 10 isn't in the supported matrix we've
traditionally had in this project.
I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT
FreeBSD 11.0-CURRENT #1 r267305 ).
I wonder how this could possibly happen on stable-10, since EARLY_BUILD is
still there to preclude the line being added.
I'll have to re-run my test WITHOUT_CLANG. I just used the defaults.
Any chance you can narrow the number of options required to trigger this?
Warner
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 6:15 PM, Craig Rodrigues rodr...@freebsd.org wrote:
Hi,
OK, I think I see the issue. I looked here:
http://svnweb.freebsd.org/base/stable/9/share/mk/bsd.prog.mk?view=log
and saw that dim@ MFC'd his EARLY_BUILD stuff in r257812.
That is why you can build stable/9 on a stable/10 host.
I am building FreeBSD 9.2 which doesn't have that change.
bsd.prog.mk in stable/9
==
.if defined(PROG_CXX) !defined(EARLY_BUILD)
.if !empty(CXXFLAGS:M-stdlib=libc++)
echo ${PROG}: ${LIBCPLUSPLUS} ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
bsd.prog.mk in 9.2
.if defined(PROG_CXX)
.if !empty(CXXFLAGS:M-stdlib=libc++)
echo ${PROG}: ${LIBCPLUSPLUS} ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
bsd.prog.mk in CURRENT
.if defined(PROG_CXX)
.if ${COMPILER_TYPE} == clang empty(CXXFLAGS:M-stdlib=libstdc++)
echo ${PROG}: ${LIBCPLUSPLUS} ${DEPENDFILE}
.else
echo ${PROG}: ${LIBSTDCPLUSPLUS} ${DEPENDFILE}
.endif
.endif
So, I guess that stable/9 can build properly on a stable/10 box.
For FreeBSD 9.2, there is no easy way out.
You’ll have to back port the patch then. We don’t guarantee forward
compatibility like this since 9.2 is frozen in time now.
stable/9 builds fine on both stable/10 and current hosts.
Warner
--
Craig
On Mon, Jun 23, 2014 at 4:23 PM, Warner Losh i...@bsdimp.com wrote:
On Jun 23, 2014, at 5:19 PM, Craig Rodrigues rodr...@freebsd.org wrote:
On Mon, Jun 23, 2014 at 4:13 PM, Warner Losh i...@bsdimp.com wrote:
Which bombing out are you seeing (two or three have been sighted in this
thread)? And is this a nanobsd build, or a straight buildworld?
When building FreeNAS, with a hacked the nanobsd
script to does make make buildworld, and the make.conf which I posted, I
am seeing this:
--
stage 1.2: bootstrap tools
--
cd /zroot/build/r/freenas2/FreeBSD/src;
MAKEOBJDIRPREFIX=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
INSTALL=sh /zroot/build/r/freenas2/FreeBSD/src/tools/install.sh
PATH=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/sbin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/bin:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/usr/games:/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
WORLDTMP=/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/tmp
VERSION=9.3-ALPHA MAKEFLAGS=-m
/zroot/build/r/freenas2/FreeBSD/src/tools/build/mk -j 9
.MAKE.LEVEL.ENV=MAKELEVEL NO_CLEAN=1 SRCCONF=/dev/null
__MAKE_CONF=/zroot/build/r/freenas2/os-base/amd64/make.conf.build -m
/zroot/build/r/freenas2/FreeBSD/src/share/mk TARGET=amd64
TARGET_ARCH=amd64 COMPILER_TYPE=clang
/zroot/build/r/freenas2/os-base/amd64/zroot/build/r/freenas2/FreeBSD/src/make.amd64/make
-f Makefile.inc1 DESTDIR= BOOTSTRAPPING=1100022 SSP_CFLAGS=
-DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DNO_PIC
-DWITHOUT_PROFILE -DNO_SHARED -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF
-DEARLY_BUILD bootstrap-tools
=== gnu/usr.bin/gperf (obj,depend,all,install)
=== gnu/usr.bin/gperf/doc (obj)
=== gnu/usr.bin/gperf/doc (depend)
make: don't know how to make /usr/lib/libstdc++.a. Stop
*** [bootstrap-tools] Error code 2
1 error
*** [_bootstrap-tools] Error code 2
1 error
*** [buildworld] Error code 2
make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
1 error
make[1]: stopped in /zroot/build/r/freenas2/FreeBSD/src
===
ERROR: build FAILED; see above or log file here:
/zroot/build/r/freenas2/os-base/amd64/_.bw
*** Error code 2
Stop.
make: stopped in /zroot/build/r/freenas2
And I specifically was doing my testing on -current, not 10.x. I haven’t
back ported much of anything I’ve done to the build system, and if anybody
else has, then it is on them to make it work in the 10.x environment. While
it has usually worked, 9 on 10 isn’t in the supported matrix we’ve
traditionally had in this project.
I reproduced the same problem using a CURRENT build host ( 11.0-CURRENT
FreeBSD 11.0-CURRENT #1 r267305 ).
I wonder how this could possibly happen on stable-10, since EARLY_BUILD is
still there to preclude the line being added.
I’ll have to re-run my test WITHOUT_CLANG. I just used the defaults.
Any chance you can narrow the number of options required to trigger this?
Warner
signature.asc
Description: Message signed with
Re: ahci panics when detaching...
John Baldwin wrote this message on Mon, Jun 23, 2014 at 10:49 -0400:
On Monday, June 23, 2014 9:44:08 am John-Mark Gurney wrote:
So, when I try to eject a ESATA card, the machine panics... I am able
to successfully eject other cards, an ethernet (re) and a serial card
(uart), and both handle the removal of their device w/o issue and with
out crashes...
When I try w/ ahci, I get a panic... The panic backtrace is:
#8 0x80ced4e2 in calltrap () at
../../../amd64/amd64/exception.S:231
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
#10 0x8092b888 in resource_list_release_active
(rl=0xf80006d39c08,
bus=0xf80002cd9000, child=0xf80006b6d700, type=3)
at ../../../kern/subr_bus.c:3419
#11 0x8065d7a1 in pci_child_detached (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4133
---Type return to continue, or q return to quit---
#12 0x80929708 in device_detach (dev=0xf80006b6d700)
at bus_if.h:181
#13 0x8065f9f7 in pci_delete_child (dev=0xf80002cd9000,
child=0xf80006b6d700) at ../../../dev/pci/pci.c:4710
In frame 9:
(kgdb) fr 9
#9 0x8093d037 in rman_get_rid (r=0xf800064c9380)
at ../../../kern/subr_rman.c:979
979 return (r-__r_i-r_rid);
(kgdb) print r
$1 = (struct resource *) 0xf800064c9380
(kgdb) print/x *r
$4 = {__r_i = 0xdeadc0dedeadc0de, r_bustag = 0xdeadc0dedeadc0de,
r_bushandle = 0xdeadc0dedeadc0de}
So, looks like something is corrupted the resource data...
This is the malloc junking on free. However, I wonder if the
problem is that the resource was freed without being properly
cleared from the resource_list in the PCI ivars. Is this with local
patches that you have?
Yes, but I didn't patch any of the pci code, or the resource code, so
this bug is in the original code... My patches only effect the attach
case, don't touch the detach case...
I was hoping someone who knows the code was like, yeh, I do remeber
that place in the code where we free something, but don't properly
NULL out the pointer, etc...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: On Jun 23, 2014, at 6:15 PM, Craig Rodrigues rodr...@freebsd.org wrote: So, I guess that stable/9 can build properly on a stable/10 box. For FreeBSD 9.2, there is no easy way out. You’ll have to back port the patch then. We don’t guarantee forward compatibility like this since 9.2 is frozen in time now. I'd really like to discuss rethinking our forward-compatibility policies, since we have (now) 3 active stable/ branches, plus head/. What I would like to see, with my RE hat on, is a best effort backwards compatibility to being able to build the lowest-numbered supported stable/ branch on head/. Sure, this won't always work, but best effort is better than no effort, which the latter is why we do not have stable/8 snapshot builds, to be honest. I won't spend the time on the stable/8/release/ code nor the snapshot build scripts to waste the time. Building stable/9 on head/ is annoying alone. Glen pgpVo1iO5DLks.pgp Description: PGP signature
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 7:12 PM, Glen Barber g...@freebsd.org wrote: On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: On Jun 23, 2014, at 6:15 PM, Craig Rodrigues rodr...@freebsd.org wrote: So, I guess that stable/9 can build properly on a stable/10 box. For FreeBSD 9.2, there is no easy way out. You’ll have to back port the patch then. We don’t guarantee forward compatibility like this since 9.2 is frozen in time now. I'd really like to discuss rethinking our forward-compatibility policies, since we have (now) 3 active stable/ branches, plus head/. Generally, in the past, the rule has been “head will build from the last stable branch tip.” This was extended, for a while, to “last stable branch point” when Ruslan made sure that worked. While -stable has generally built on -head, this was never part of the contract. It usually did, but is very very hard to guarantee given the nature of head’s tools changing in ways that are allowed for head, but that break prior branches. What I would like to see, with my RE hat on, is a best effort backwards compatibility to being able to build the lowest-numbered supported stable/ branch on head/. I think, that as in the past, this will generally work. However, it won’t always work. Things break in this area a lot. More than you might think, especially with the huge amount of churn we’ve had wrt compilers, make, etc. I suspect that new imports of clang will break this every time, since every import of clang has required changes to the tree to either disable warnings, or to fix newly flagged things. I suspect there will be a lot of churn here, and releases will go stale the fastest… With -current starting to support building multiple versions of clang (and gcc), there’s hope for the future, but back-porting this code is beyond what I have the time to do. That’s going to make things increasingly difficult as we march forward. This isn’t even getting into cross build scenarios…. Or building releases, which is a whole different set of lightly tested code that is mostly host independent, but sometimes isn’t as much as you’d had hoped... Sure, this won't always work, but best effort is better than no effort, which the latter is why we do not have stable/8 snapshot builds, to be honest. I won't spend the time on the stable/8/release/ code nor the snapshot build scripts to waste the time. Building stable/9 on head/ is annoying alone. stable/9 builds on head. If there’s a race, that needs to be fixed in stable/9. That’s quasi supported because people do it. The “best effort” involves people that are interested in the bugs being fixed fixing them, or convincing others to fix them. For me, this scenario is outside the area I care about, have the ability to test, or have time for. So “best effort” involves more than me making an effort. I may or I may not. It all depends on my time and inclination. If it is going to work, bugs need to be fixed in stable/9 that prevents it from building on head, while not breaking the ability to build on 9. So there’s a lot of heavy lifting that will be needed in short order to keep this working once the clang folks can figure out how to get past the angst of the upgrade path and push forward to 3.5. Some architectures will break when that happens, no doubt. But 9.2 will never build on head because it is broken with bmake, which is now standard for head. Since 9.2 cannot be changed, and since we’ve removed (or nearly) fmake in current, chances are quite good it will never build on head again without some special handling. In summary, good luck! there’s a lot of use cases here, and it will take time and effort of multiple people over the long haul to keep it working. Best effort may be larger than you estimate… I won’t stand in your way, but I’m afraid my time available to help is limited. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote: On Jun 23, 2014, at 7:12 PM, Glen Barber g...@freebsd.org wrote: On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: On Jun 23, 2014, at 6:15 PM, Craig Rodrigues rodr...@freebsd.org wrote: So, I guess that stable/9 can build properly on a stable/10 box. For FreeBSD 9.2, there is no easy way out. You’ll have to back port the patch then. We don’t guarantee forward compatibility like this since 9.2 is frozen in time now. I'd really like to discuss rethinking our forward-compatibility policies, since we have (now) 3 active stable/ branches, plus head/. Generally, in the past, the rule has been “head will build from the last stable branch tip.” This was extended, for a while, to “last stable branch point” when Ruslan made sure that worked. While -stable has generally built on -head, this was never part of the contract. It usually did, but is very very hard to guarantee given the nature of head’s tools changing in ways that are allowed for head, but that break prior branches. I sort of typed what I meant a bit backwards from what I intended to write. What I meant (sort of) is, I would like to discuss our forward thinking on backward-compatibility. I fully understand forward-compatibility is not feasible. What I would like to see, with my RE hat on, is a best effort backwards compatibility to being able to build the lowest-numbered supported stable/ branch on head/. I think, that as in the past, this will generally work. However, it won’t always work. Things break in this area a lot. More than you might think, especially with the huge amount of churn we’ve had wrt compilers, make, etc. I suspect that new imports of clang will break this every time, since every import of clang has required changes to the tree to either disable warnings, or to fix newly flagged things. I suspect there will be a lot of churn here, and releases will go stale the fastest… With -current starting to support building multiple versions of clang (and gcc), there’s hope for the future, but back-porting this code is beyond what I have the time to do. That’s going to make things increasingly difficult as we march forward. I hate to even suggest this, but the ports tree (ab)uses the notion of using the kern.osreldate for certain things. This, however, requires proper bumping of __FreeBSD_version when needed, and maintenance of the Makefiles for the kern.osreldate-specific things. The benefit to this is that it would help prevent pissing off ports developers and make their lives a bit easier when userland / kernel things change. It would, however, (expectedly) is that it would force src committers to do the right thing. Win-win, IMHO. This isn’t even getting into cross build scenarios…. Or building releases, which is a whole different set of lightly tested code that is mostly host independent, but sometimes isn’t as much as you’d had hoped... Sure, this won't always work, but best effort is better than no effort, which the latter is why we do not have stable/8 snapshot builds, to be honest. I won't spend the time on the stable/8/release/ code nor the snapshot build scripts to waste the time. Building stable/9 on head/ is annoying alone. stable/9 builds on head. If there’s a race, that needs to be fixed in stable/9. That’s quasi supported because people do it. The “best effort” involves people that are interested in the bugs being fixed fixing them, or convincing others to fix them. For me, this scenario is outside the area I care about, have the ability to test, or have time for. So “best effort” involves more than me making an effort. I may or I may not. It all depends on my time and inclination. If it is going to work, bugs need to be fixed in stable/9 that prevents it from building on head, while not breaking the ability to build on 9. So there’s a lot of heavy lifting that will be needed in short order to keep this working once the clang folks can figure out how to get past the angst of the upgrade path and push forward to 3.5. Some architectures will break when that happens, no doubt. Personally, and no I won't discuss more on this, I'm in the camp of I don't really see clang as a feature. It caused our ports developers and maintainers a mountain of headache to convert to the invisibly new great thing, it increases our overall buildworld by a non-insignificant amount of time, and it has personally caused me headaches (still ongoing) trying to figure out what the correct incantation of evil to wish over the cauldron to get BeagleBone images to build. (They're failing because gcc is not being installed on both head/ and stable/10/, and despite the game of musical KNOBS I've been playing over the past few days, I'm running out of hair to pull out of my head.) But 9.2 will never build on head because it is broken with bmake, which is
Re: ucom_free Fatal trap on shutdown / module unload
On 06/23/14 07:34, Lundberg, Johannes wrote: I added some logging to see what is going on and this is what I got (none of the proposed solution solved the problem) uhso_detach gets called 7 times (for oid 0-6). It crashes the 2nd time on the call usbd_transfer_unsetup(sc-sc_xfer, 3); Hi, You are running -stable presumably? Can you set hw.usb.debug=16 and collects the 10 last prints before the panic, and backtrace would be nice too. This does not happen when you unplug the device, correct? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ucom_free Fatal trap on shutdown / module unload
Hi Well I'm running the snaphot memstick image from June of 11-CURRENT amd64, with newcons. The device is embedded in the laptop and I can not remove it easily so I don't know what would happen if I do. I'm sending you the screenshots separately in direct mail so we don't have to wait for large attachment approval on the list. -- Johannes Lundberg BRILLIANTSERVICE CO., LTD. On Tue, Jun 24, 2014 at 1:39 PM, Hans Petter Selasky h...@selasky.org wrote: On 06/23/14 07:34, Lundberg, Johannes wrote: I added some logging to see what is going on and this is what I got (none of the proposed solution solved the problem) uhso_detach gets called 7 times (for oid 0-6). It crashes the 2nd time on the call usbd_transfer_unsetup(sc-sc_xfer, 3); Hi, You are running -stable presumably? Can you set hw.usb.debug=16 and collects the 10 last prints before the panic, and backtrace would be nice too. This does not happen when you unplug the device, correct? --HPS -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。 もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、 複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。 --- CONFIDENTIALITY NOTE: The information in this email is confidential and intended solely for the addressee. Disclosure, copying, distribution or any other action of use of this email by person other than intended recipient, is prohibited. If you are not the intended recipient and have received this email in error, please destroy the original message. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 23, 2014, at 8:24 PM, Glen Barber g...@freebsd.org wrote: On Mon, Jun 23, 2014 at 07:42:27PM -0600, Warner Losh wrote: On Jun 23, 2014, at 7:12 PM, Glen Barber g...@freebsd.org wrote: On Mon, Jun 23, 2014 at 06:57:15PM -0600, Warner Losh wrote: On Jun 23, 2014, at 6:15 PM, Craig Rodrigues rodr...@freebsd.org wrote: So, I guess that stable/9 can build properly on a stable/10 box. For FreeBSD 9.2, there is no easy way out. You’ll have to back port the patch then. We don’t guarantee forward compatibility like this since 9.2 is frozen in time now. I'd really like to discuss rethinking our forward-compatibility policies, since we have (now) 3 active stable/ branches, plus head/. Generally, in the past, the rule has been “head will build from the last stable branch tip.” This was extended, for a while, to “last stable branch point” when Ruslan made sure that worked. While -stable has generally built on -head, this was never part of the contract. It usually did, but is very very hard to guarantee given the nature of head’s tools changing in ways that are allowed for head, but that break prior branches. I sort of typed what I meant a bit backwards from what I intended to write. What I meant (sort of) is, I would like to discuss our forward thinking on backward-compatibility. I fully understand forward-compatibility is not feasible. We already build current back to the stable/8 branch. 7.x is no longer feasible, supported or tested. stable/10 is the only one that is required, but enough people use stable/9 machines it will work. stable/8 has one customer that is keeping it going, so I suspect it will stop working in the coming years, maybe before 11 is branched. What I would like to see, with my RE hat on, is a best effort backwards compatibility to being able to build the lowest-numbered supported stable/ branch on head/. I think, that as in the past, this will generally work. However, it won’t always work. Things break in this area a lot. More than you might think, especially with the huge amount of churn we’ve had wrt compilers, make, etc. I suspect that new imports of clang will break this every time, since every import of clang has required changes to the tree to either disable warnings, or to fix newly flagged things. I suspect there will be a lot of churn here, and releases will go stale the fastest… With -current starting to support building multiple versions of clang (and gcc), there’s hope for the future, but back-porting this code is beyond what I have the time to do. That’s going to make things increasingly difficult as we march forward. I hate to even suggest this, but the ports tree (ab)uses the notion of using the kern.osreldate for certain things. This, however, requires proper bumping of __FreeBSD_version when needed, and maintenance of the Makefiles for the kern.osreldate-specific things. We already do that. It mostly works most of the time, so long as the delta isn’t too great, and we don’t have high compiler/tools/make velocity… Except we don’t use the kernel version, but rather the installed tools version as indicated by a .h file. That’s more robust. The benefit to this is that it would help prevent pissing off ports developers and make their lives a bit easier when userland / kernel things change. It would, however, (expectedly) is that it would force src committers to do the right thing. Win-win, IMHO. What should we do we aren’t doing today? This isn’t even getting into cross build scenarios…. Or building releases, which is a whole different set of lightly tested code that is mostly host independent, but sometimes isn’t as much as you’d had hoped... Sure, this won't always work, but best effort is better than no effort, which the latter is why we do not have stable/8 snapshot builds, to be honest. I won't spend the time on the stable/8/release/ code nor the snapshot build scripts to waste the time. Building stable/9 on head/ is annoying alone. stable/9 builds on head. If there’s a race, that needs to be fixed in stable/9. That’s quasi supported because people do it. The “best effort” involves people that are interested in the bugs being fixed fixing them, or convincing others to fix them. For me, this scenario is outside the area I care about, have the ability to test, or have time for. So “best effort” involves more than me making an effort. I may or I may not. It all depends on my time and inclination. If it is going to work, bugs need to be fixed in stable/9 that prevents it from building on head, while not breaking the ability to build on 9. So there’s a lot of heavy lifting that will be needed in short order to keep this working once the clang folks can figure out how to get past the angst of the upgrade path and push forward to 3.5. Some architectures will break when that happens, no doubt. Personally, and no I won't discuss more on
