Re: Order in which a driver attaches to devices
On Friday, September 07, 2012 10:48:39 am John Baldwin wrote: On Thursday, September 06, 2012 5:08:27 pm Navdeep Parhar wrote: I have a system with multiple cards supported by cxgbe(4). When I build a kernel with the driver compiled in, it attaches to the cards in a different order from when it's loaded as a module. Why? The network interfaces get re-ordered and this is quite annoying. H. The boot time probe does a depth first walk of the PCI bus. This is what is suggested by PCI-SIG for enumerating PCI buses (and is normally how BIOSs walk the bus assigning bus numbers). The walk that is done at kldload time walks the 'pciX' bus devices in numerical order (rather than walking the tree). I suspect your BIOS is doing something weird and assigning bus numbers in a non-depth first ordering so that the two orderings are not consisent as they are on other machines. BTW, another fix is to stop trying to force unit numbers to patch PCI bus numbers (e.g. change pcib_attach() in pci_pci.c to use -1 instead of sc-secbus). A few other places would need to be changed as well: acpi_pcib_attach(), legacy_pcib_attach(), qpi_pcib_attach(), mptable_hostb_attach(). If we went this route we should probably do it on other platforms as well. (Some, such as sparc64 already do this.) -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wed, 12 Sep 2012 14:20:26 -0500, John Baldwin j...@freebsd.org wrote: Are you still seeing this, and if so can you get a crashdump? Also, I'm curious if you only see this with SUJ or if plain UFS+SU works fine? The crash on demand right now is producable on 8.x and 9.x, so SUJ isn't a requirement. Also, there is no crashdump available. The OS just hangs and stops taking input. There's no panic or coredump or anything of the like. You just have to nuke the VM and re-boot it back up. And for the record we can't reproduce this crash in Xen... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
on 13/09/2012 17:50 Mark Felder said the following: On Wed, 12 Sep 2012 14:20:26 -0500, John Baldwin j...@freebsd.org wrote: Are you still seeing this, and if so can you get a crashdump? Also, I'm curious if you only see this with SUJ or if plain UFS+SU works fine? The crash on demand right now is producable on 8.x and 9.x, so SUJ isn't a requirement. Also, there is no crashdump available. The OS just hangs and stops taking input. There's no panic or coredump or anything of the like. You just have to nuke the VM and re-boot it back up. And for the record we can't reproduce this crash in Xen... Just curious - does VMWare provide a remote debugger support (gdb stub)? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon a...@freebsd.org wrote: Just curious - does VMWare provide a remote debugger support (gdb stub)? I'm not aware of one. What I have been able to successfully do is break into the debugger during the hang but the info I've posted so far has not been relevant to anyone. I'm hoping someone on the core team will eventually be able to follow my guide and figure out what went wrong. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, Sep 13, 2012 at 11:14:49AM -0500, Mark Felder wrote: On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon a...@freebsd.org wrote: Just curious - does VMWare provide a remote debugger support (gdb stub)? I'm not aware of one. What I have been able to successfully do is break into the debugger during the hang but the info I've posted so far has not been relevant to anyone. I'm hoping someone on the core team will eventually be able to follow my guide and figure out what went wrong. Isn't this what you want? http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 13 Sep 2012 11:28:15 -0500, Kurt Lidl l...@pix.net wrote: Isn't this what you want? http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html -Kurt Interesting -- it looks like that's an option on ESX as well. The only question is: what do I do with that? It's going to give me the debugging entire VM, not the kernel inside. Without being a VMWare developer I imagine its data will be a bit useless :-( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
on 13/09/2012 22:57 Mark Felder said the following: On Thu, 13 Sep 2012 11:28:15 -0500, Kurt Lidl l...@pix.net wrote: Isn't this what you want? http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html -Kurt Interesting -- it looks like that's an option on ESX as well. The only question is: what do I do with that? It's going to give me the debugging entire VM, not the kernel inside. Without being a VMWare developer I imagine its data will be a bit useless :-( No, gdb stub is for debugging what is running inside the VM. E.g. look here for an example of how to do that with qemu: http://andriygapon.wikispaces.com/QemuSetup VMWare with gdb stub enabled should not be any different. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
--- On Sep 13, 2012, at 5:13 PM, Andriy Gapon a...@freebsd.org wrote: on 13/09/2012 22:57 Mark Felder said the following: On Thu, 13 Sep 2012 11:28:15 -0500, Kurt Lidl l...@pix.net wrote: Isn't this what you want? http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html -Kurt Interesting -- it looks like that's an option on ESX as well. The only question is: what do I do with that? It's going to give me the debugging entire VM, not the kernel inside. Without being a VMWare developer I imagine its data will be a bit useless :-( No, gdb stub is for debugging what is running inside the VM. E.g. look here for an example of how to do that with qemu: http://andriygapon.wikispaces.com/QemuSetup VMWare with gdb stub enabled should not be any different. -- Andriy Gapon _ Mark did you try changing the time counter choice sysctl from hpet to Acpi-safe/fast or tsc ? In esx 4.1 an newer using hpet timers causes issues for bsd and linux vms in some cases . The sysctl is kern.timecounter.choice . This sounds like another VMware issues I have seen and read about . See this post http://forums.freebsd.org/archive/index.php/t-32104.html --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Changing timer source has not been tested. It doesn't crash in 7.x, so did something timer related change in 8.x? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
--- On Sep 13, 2012, at 7:45 PM, Mark Felder f...@feld.me wrote: Changing timer source has not been tested. It doesn't crash in 7.x, so did something timer related change in 8.x? Mark Yes the time counter choice priority changed , in 8 favoring higher precision hardware like hpet over acpi-fast/safe . I am not sure why or when thus was done; or if this is a side effect of another change. Interestingly centos/rhel/suse has made similar changes and VMware has odd issues with them as well. Can you boot up a 7 environment and get us the value sysctl kern.timecounter . Then get that from an a 8 and 9 environment . Then if the 7 environment uses a different time counter can you try using that value on your crashing setup and report back what the result is . --- Mark saad | mark.s...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
vm info from a hung system
Need some expert help. I have a system that is hung hard, and I was able to get it into gdb. From show_vmstat I see: (kgdb-amd64-7.4-95) show_vmstat SYSTEM MEMORY INFORMATION: mem_wire: 285970432 (272MB) Wired: disabled for paging out mem_active: +400105472 (381MB) Active: recently referenced mem_inactive:+ 56840192 ( 54MB) Inactive: recently not referenced mem_cache: +0 ( 0MB) Cached: almost avail. for allocation mem_free:+0 ( 0MB) Free: fully available for allocation mem_gap_vm: + 753664 ( 0MB) Memory gap: vm -- --- -- mem_all: =743669760 (709MB) Total real memory managed mem_gap_sys: + 22765568 ( 21MB) Memory gap: system -- --- mem_phys:=766435328 (730MB) Total phys memory -- --- SYSTEM MEMORY SUMMARY: mem_used: 709595136 (676MB) Used memory mem_avail: + 56840192 ( 54MB) Available memory -- --- -- mem_total: =766435328 (730MB) Total memory What is this telling me? -vijay ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
