Re: Previously working PXE setup now fails
Hi and thanks for your input. If I may, I have several more Q's regarding this issue: As I think I've mentioned before, a NFSv4 root fs won't work, so don't bother trying... Q1: I did not realise that. I took out the V4: in exports. However, is it possible to have a mixed-mode, something like /data/amd64 as V3 but /home as V4? Q2: I now get to the BTX loader, wireshark shows correct mount call 192.168.2.3, 192.168.2.1, MOUNT, V3 MNT Call (Reply In 14072) /data/amd64. Unfortunately, I get a complete black screen when I hit enter from BTX (it looks like a lock-up) and wireshark shows no traffic for the problem. To get to this point, I re-anabled some of what I had taken out before, and I now forget which config options are necessary at this point. What I have: (always had this) fstab: 192.168.2.1:/data/amd64 / nfs ro 0 0 boot/loader.conf: boot.nfsroot.server=192.168.2.1 boot.nfsroot.path=/data/amd64 ##_re-enabled_## vfs.root.mountfrom=nfs:192.168.2.1:/data/amd64 vfs.root.mountfrom=nfs boot.nfsroot.options=nolockd vfs.root.mountfrom.options=ro re-enabled in dhcpd.conf option root-path 192.168.2.1:/data/amd64; I can't figure out what needs to be modified and what options can be removed? Thanks for your help. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Previously-working-PXE-setup-now-fails-tp5919662p5923355.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ahci panics when detaching...
On Monday, June 23, 2014 9:06:26 pm John-Mark Gurney wrote:
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...
What did you change in attach? :) If the resource list isn't setup the same
then that could cause this. In particular, the PCI bus pre-reserves resources
for BARs so that they are allocated even if a driver hasn't allocated them.
--
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...
John Baldwin wrote this message on Tue, Jun 24, 2014 at 09:51 -0400:
On Monday, June 23, 2014 9:06:26 pm John-Mark Gurney wrote:
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...
What did you change in attach? :) If the resource list isn't setup the same
then that could cause this. In particular, the PCI bus pre-reserves resources
for BARs so that they are allocated even if a driver hasn't allocated them.
What I mean by that is that I setup a few things in pci_attach_common,
like if the device has a slot that can hotplug, I attach an interrupt,
enable interrupts and a couple bookkeeping items... But that code
shouldn't change anything for ahci..
--
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
Trimmed CC a bit. On Mon, Jun 23, 2014 at 11:42:20PM -0600, Warner Losh wrote: On Jun 23, 2014, at 8:24 PM, Glen Barber g...@freebsd.org wrote: 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. To be clear, I am talking about the other direction. Meaning, being able to reliably build N-2 from head/, without needing to do silliness like 'make make buildworld', or not using -jN. 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. True. Thank you for the sanity check. 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? There have been a number of times where changes that should deem a __FreeBSD_version bump necessary either 1) do not bump __FreeBSD_version at all, or 2) bump __FreeBSD_version several days (or longer) later. So, we're left with a window of time where something is different enough, but there is no corresponding version change to reference. This is somewhat tangential to my original annoyance here though. :) 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.) Yea, if you are using crochet, that’s because crochet uses xdev rather than a ports compiler (which in all fairness didn’t exist when it started) to build u-boot, which basically requires gcc. The compiler rework in head is still a work in progress. What’s there now is better than before, but still isn’t quite right. I do plan on fixing that before summer is out. It isn't just head that is a problem with crochet, though. stable/10 has been a problem since, as far as I can tell, roughly early May. 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. As Ozzy once sang: I'm just a dreamer I dream my life away I'm just a dreamer Who dreams of better days” Since I was commenting on the opposite problem of what you were wanting comments on, my harshness is justified. My comment wasn't a comment on your comment. :-) What you want though, we largely already do, though maybe with a few more warts than necessary (which we should try to fix). Most of the warts are due to gcc/clang division being done badly and unsustainable initially and the cleanup taking a bit of time, not specific version issues. Back to your basic point, the issue becomes a testability one: not all committers can reasonable be expected to have 8 or 9 systems to test every change. Having a 10.x system to test changes is a bit of a stretch as it is, but it is the official policy that many folks play fast and loose with the rules because they haven’t been burned too
Re: Problems building FreeBSD 9.2 on FreeBSD 10
On Jun 24, 2014, at 8:43 AM, Glen Barber g...@freebsd.org wrote: Trimmed CC a bit. On Mon, Jun 23, 2014 at 11:42:20PM -0600, Warner Losh wrote: On Jun 23, 2014, at 8:24 PM, Glen Barber g...@freebsd.org wrote: 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. To be clear, I am talking about the other direction. Meaning, being able to reliably build N-2 from head/, without needing to do silliness like 'make make buildworld', or not using -jN.” Yea, that’s never been officially supported, but generally works. In fact, in the past, you were required to have exactly the same version on the host as you were building a release for to ensure nothing weird happening. Having the full release process work across multiple major versions and have it produce identical results to the exact version built release is not well tested and caused all kinds of problems back in the day. To make it work, you’ll need to make it work. And you’ll need to keep it working as people break it. We focus on the project as “I’m updating from version X to version Y, where X Y” in all our make infrastructure. While we could add bits where X Y, and for the release, there are likely several items that will need to be fixed to get there. You are currently hitting this turbulence with cross-version races in multiple job builds. By all means fix them, but since this is an unusual use case (from a historical perspective), expect there to be bumps, and expect there to need to be fixes to make it work (and also from a historical perspective, expect people will break it innocently). 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. True. Thank you for the sanity check. 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? There have been a number of times where changes that should deem a __FreeBSD_version bump necessary either 1) do not bump __FreeBSD_version at all, or 2) bump __FreeBSD_version several days (or longer) later. So, we're left with a window of time where something is different enough, but there is no corresponding version change to reference. This is somewhat tangential to my original annoyance here though. :) With -current, a few days is more than enough granularity. There are bumps, and this is one of them. 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.) Yea, if you are using crochet, that’s because crochet uses xdev rather than a ports compiler (which in all fairness didn’t exist when it started) to build u-boot, which basically requires gcc. The compiler rework in head is still a work in progress. What’s there now is better than before, but still isn’t quite right. I do plan on fixing that before summer is out. It isn't just head that is a problem with crochet, though. stable/10 has been a problem since, as far as I can tell, roughly early May. Building release 9 on 10 falls under the X Y category above. If if breaks, and you want it to work, you gotta fix it. If there’s several somebodies that want it working, they gotta keep it working and fix
Problem with tagged vlan after upgrading
Hello all. After upgrading my system to 11.0-CURRENT r267824, I cannot use the vlan interfaces as I used before. I have in rc.conf: ifconfig_em0=media 1000baseT mediaopt full-duplex cloned_interfaces=vlan1 vlan2 vlan100 vlan150 ifconfig_vlan1=inet 10.0.0.20 netmask 255.0.0.0 vlan 1 vlandev em0 ifconfig_vlan2=inet my_actual_ip netmask 255.255.255.192 vlan 2 vlandev em0 ifconfig_vlan100=vlan 100 vlandev em0 ifconfig_vlan150=inet 192.168.2.10 netmask 255.255.255.0 vlan 150 vlandev em0 But this isn't working anymore. When I remove the vlan tag in my switch and set the inet to the em0 card, everithing works fine. I have done a make delete-old after the mergemaster and I wonder if I removed something by mistake. Is there anything I can do to debug/fix this? TIA, -- Ricardo. ___ 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
panic: pmap active 0xfffff8002d2ae9f8
Hi, I have a system running CURRENT at r266925 from May 31. While doing some software builds using poudriere, the system panicked. Unfortunately this system was not configured with swap space, so I cannot do a kernel dump. The system is currently at the ddb prompt. Here is the backtrace: Here is the backtrace from ddb: panic: pmap active 0xf8002d2ae9f8 cpuid = 5 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe183958a7d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe183958a880 vpanic() at vpanic+0x126/frame 0xfe183958a8c0 kassert_panic() at kassert_panic+0x139/frame 0xfe183958a930 pmap_remove_pages() at pmap_remove_pages+0x8c/frame 0xfe183958aa20 vmspace_exit() at vmspace_exit+0xa1/frame 0xfe183958aa60 exit1() at exit1+0x541/frame 0xfe183958aad0 sys_sys_exit() at sys_sys_exit+0xe/frame 0xfe183958aae0 amd64_syscall() at amd64_syscall+0x25a/frame 0xfe183958abf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe183958abf0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip - 0x800b195aa, rsp - 0x7ffe3e8, rbp = 0x7e400 KDB: enter: panic [ thread pid 94762 tid 101570 ] Stopped at kdb_enter+0x3e: movq$0.kdb_why db Is this a known problem? Are there other commands I should type at the ddb prompt? -- 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: Previously working PXE setup now fails
Beeblebrox wrote: Hi and thanks for your input. If I may, I have several more Q's regarding this issue: As I think I've mentioned before, a NFSv4 root fs won't work, so don't bother trying... Q1: I did not realise that. I took out the V4: in exports. However, is it possible to have a mixed-mode, something like /data/amd64 as V3 but /home as V4? Yes, that should be fine. It is only the root fs that won`t work. There are 2 problems: 1 - nfsuserd can`t be running when the root fs is first accessed, so uid vs username mappings aren`t available. (A recent change in the spec that allows a username that is a string of uid digits works around this. It was driven by Linux folks that wanted NFSv4 root file systems to work. This spec is still an IETF draft, so it is hard to say if it supported yet.) 2 - The client mount needs a unique identifier for the client machine. The host uuid used for this is set during booting. To make an NFSv4 root fs to work, there needs to be some way to generate a unique identifier for the machine before it accesses the root fs. So, someday NFSv4 root file systems may work, but not right now. I need to check to make sure this is in the mount_nfs and nfsv4 man pages. Q2: I now get to the BTX loader, wireshark shows correct mount call 192.168.2.3, 192.168.2.1, MOUNT, V3 MNT Call (Reply In 14072) /data/amd64. Unfortunately, I get a complete black screen when I hit enter from BTX (it looks like a lock-up) and wireshark shows no traffic for the problem. To get to this point, I re-anabled some of what I had taken out before, and I now forget which config options are necessary at this point. What I have: (always had this) fstab: 192.168.2.1:/data/amd64 / nfs ro 0 0 boot/loader.conf: boot.nfsroot.server=192.168.2.1 boot.nfsroot.path=/data/amd64 ##_re-enabled_## vfs.root.mountfrom=nfs:192.168.2.1:/data/amd64 vfs.root.mountfrom=nfs boot.nfsroot.options=nolockd vfs.root.mountfrom.options=ro When I`ve done it (not recently), I don`t think I set any of the above in loader.conf. However I also didn`t use a read-only root fs. Hopefully someone who uses NFS root file systems can suggest help. All I did was follow some web page instructions exactly. rick re-enabled in dhcpd.conf option root-path 192.168.2.1:/data/amd64; I can't figure out what needs to be modified and what options can be removed? Thanks for your help. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/Previously-working-PXE-setup-now-fails-tp5919662p5923355.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ 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
