Re: vm_map_entry for kernel virtual addres
2008/12/3 Mark Tinguely <[EMAIL PROTECTED]>
> > 2008/12/3 Mark Tinguely <[EMAIL PROTECTED]>
> >
> > > on 3 Dec 2008 15:35:27, Alexej Sokolov <[EMAIL PROTECTED]>
> asked:
> > >
> > > > Hello,
> > > > If I allocate memory from a kernel module:
> > > > MALLOC(addr, vm_offset_t, PAGE_SIZE, M_DEVBUF, M_WAITOK | M_ZERO);
> > > >
> > > > how can I get a pointer to vm_map_entry structure which describes
> the
> > > memory
> > > > region where "addr" is ?
> > > >
> > > > Thanks,
> > > > Alexey
> > >
> > > MALLOC is a macro for malloc() which returns a kernel virtual address
> into
> > > the variable addr in this case.
> > >
> > > You want to find the vm_map_entry, use something like:
> > >
> > >vm_map_entry_t *result;
> > >if (vm_map_lookup_entry(kernel_map, addr, result)) {
> > >/* found */
> > >} else {
> > >/* not found */
> > >}
> >
> >
> > 1. Should i use any locks or mutex for doing it ?
>
> Good question, it really should be:
>
>vm_map_lock(map);
>
> > 2. What map is used by MALLOC? It can be a some submap. Should i use
> then a
> > submap for searching entry?
>
> I thought originally that malloc() allocated memory from kernel map
> (kernel_map), but on closer inspection, malloc() seems to use the
> default UMA zone allocator [page_alloc()] which takes the memory from
> the kmem_map. Which I should have know, big mallocs fill the kmem space.
> sooo I guess the more correct code would be:
>
>vm_map_entry_t result;
>vm_map_lock(kmem_map);
>if (vm_map_lookup_entry(kmem_map, addr, &result)) {
>/* found */
>} else {
>/* not found */
>}
>vm_map_unlock(kmem_map);
>
> Ok, thanks a lot!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Tue, Dec 2, 2008 at 5:18 PM, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: > I decided to take the comments about testing ZFS to heart --- so I decided > to try copying my 7.0 "v6" ZFS configuration into a qemu instance and > upgrading it. To do this, I carefully copied my UFS boot partition and my > ZFS partion to a physical USB disk that I could put on a system to do the > test. > > After compiling qemu and loading the kqemu and aio kernel module, I started > the emulator, first in VNC mode. It loaded the kernel (currently 7.1-RC) > and tried to boot, but kept failing either shortly after kbdmux detected a > keyboard or it would get through to mounting root and not find any drives. > For reference, besides the display option (ie: -vnc or whatever), my command > line was: > > qemu-system-x86_64 -hda /dev/da0 -snapshot -m 512 > > I couldn't scroll back in VNC mode using the pause/break key, so I tried to > get qemu running directly in X. > > Now... I see a few posts stating that running qemu remotely causes an X > protocol error. I can confirm that. Something about Qemu's use of X will > no work over an SSH remote connection (with -X), nor will it work with > dxpc. It dies for me every time at X event sequence number 22. Xterms > work. Gimp even works. qemu does not. > > So I got a vnc server running to run it locally. > > And now it crashes reliably in one spot. boot0 and boot1 don't recognize > the keyboard ... but the press space after crash does. Besides that quirk, > the 7.1-RC kernel crashes with the following transcript reliably: > > MADT: Forcing active-low polarity and level trigger for SCI > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id=00 > instruction pointer = 0x8:0x > > ... and so on. > > I'd like to test this... has anyone any successes with the AMD64 qemu? Are you running the ports version, or a different version, and/or are you using kqemu (I've heard this was broken, in the past)? My group at Cisco has several issues with older versions of qemu for PPC and when we applied patches, it improved support greatly in some cases, and introduced bugs in other cases =\. I'd definitely hit the devel list for QEMU and see what they say while you're waiting for a more substantial reply here. Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help debugging, machine won't boot anymore.
On Tue, Dec 2, 2008 at 8:52 AM, Baldur Gislason <[EMAIL PROTECTED]> wrote: > I have a machine running 7.0-STABLE/amd64 and it has suddenly > stopped booting. It just leaves me at the debugger with this message: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x8:0x804d913d > stack pointer = 0x10:0x80c9ec10 > frame pointer = 0x10:0x80c9ec70 > code segment= base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at device_probe_child+0x61:movq0x28(%rax),%rsi > db> > > dmesg at http://foo.is/~baldur/enigmaboot.txt > The ACPI warning has always been there. > > Any places of interest in the debugger? What's a likely culprit? bad RAM? > > Baldur As the stopped area suggests, it looks like it's stuck probing a device. Have you added any new hardware to your system recently? Have you checked the connections internally in the machine? Does all of the hardware work with a vanilla livefs 7.0-RELEASE CD? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel vm_submap's
Hello, Where/How can I get information about vm_submap's in the actual stable kernel: % uname -v FreeBSD 7.0-RELEASE-p5 #0: Tue Oct 7 19:05:20 CEST 2008 And what kind of data is present in these submaps (mallocs, mbufs, DMA-buffer..)? Thanks, ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel vm_submap's
2008/12/4 Alexej Sokolov <[EMAIL PROTECTED]>: > Hello, > Where/How can I get information about vm_submap's in the actual stable > kernel: > % uname -v > FreeBSD 7.0-RELEASE-p5 #0: Tue Oct 7 19:05:20 CEST 2008 > And what kind of data is present in these submaps (mallocs, mbufs, > DMA-buffer..)? > vm_map_submap(9) might help you. btw, it's called only from one place I can find: kmem_suballoc. > Thanks, -- wbr, pluknet ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel vm_submap's
2008/12/4 pluknet <[EMAIL PROTECTED]> > 2008/12/4 Alexej Sokolov <[EMAIL PROTECTED]>: > > Hello, > > Where/How can I get information about vm_submap's in the actual stable > > kernel: > > % uname -v > > FreeBSD 7.0-RELEASE-p5 #0: Tue Oct 7 19:05:20 CEST 2008 > > And what kind of data is present in these submaps (mallocs, mbufs, > > DMA-buffer..)? > > > > vm_map_submap(9) might help you. > btw, it's called only from one place I can find: kmem_suballoc. Ok, then the next question: If I have some kernel virtual addres, what is the best way to find out which submap it belongs to? > > > > Thanks, > > -- > wbr, > pluknet > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: > > Are you running the ports version, or a different version, and/or are > you using kqemu (I've heard this was broken, in the past)? My group at > Cisco has several issues with older versions of qemu for PPC and when > we applied patches, it improved support greatly in some cases, and > introduced bugs in other cases =\. > > I'd definitely hit the devel list for QEMU and see what they say while > you're waiting for a more substantial reply here. I'm using the ports version. I am using kqemu... although I can try without the kernel module later today. How out-of-date is the port? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ichwd problem: watchdog doesn't "bark"
on 28/11/2008 16:28 Andriy Gapon said the following: > uname: > FreeBSD 7.1-PRERELEASE r185311 amd64 > > dmesg: > ichwd0: on isa0 > ichwd0: Intel ICH9R watchdog timer (ICH9 or equivalent) > ichwd0: timer disabled > > pciconf: > [EMAIL PROTECTED]:0:31:0: class=0x060100 card=0x50448086 chip=0x29168086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801IR (ICH9R) LPC Interface Controller' > class = bridge > subclass = PCI-ISA > > > When I start watchdogd I see the following messages: > timer enabled > timeout set to 28 ticks > and then a flow of messages: > timer reloaded > > Then I kill -9 watchdogd. > "timer reloded" messages are no longer produced. > And there are no other messages. > > But nothing happens for many minutes that I waited. > BTW, can someone knowledgeable tell me if watchdog better be firing SMI or NMI when it runs down? My bet is on NMI, but who knows. Thanks! Or maybe I am trying to ask a different question. I see that NMI2SMI_EN bit of TCO1_CNT is set 1 on my machine and our watchdog driver is careful to preserve this bit unmodified. This means that watchdog would try to cause SMI instead of NMI. On the other hand I see that bit GBL_SMI_EN of SMI_EN is set to zero, which means that chipset would never generate an SMI. So I think this is why I don't see anything happening. Now, would should try first - reset NMI2SMI_EN to zero or set GBL_SMI_EN to 1? As additional data points: I see that TCO_EN bit of SMI_EN is 1 and it is locked to that value because TCO_LOCK bit of TCO1_CNT is 1. SMI_LOCK in PCI config register GEN_PMCON_1 is not set. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dd if=/dev/mem can hang a machine?
BTW, I think it was related to reading memory-mapped registers intended to put CPU into Cx states (x >= 2). -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Thu, Dec 4, 2008 at 9:52 AM, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: > On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: >> >> Are you running the ports version, or a different version, and/or are >> you using kqemu (I've heard this was broken, in the past)? My group at >> Cisco has several issues with older versions of qemu for PPC and when >> we applied patches, it improved support greatly in some cases, and >> introduced bugs in other cases =\. >> >> I'd definitely hit the devel list for QEMU and see what they say while >> you're waiting for a more substantial reply here. > > I'm using the ports version. I am using kqemu... although I can try without > the kernel module later today. > > How out-of-date is the port? 1. Try without kqemu :) (or at least rebuild it, then disable it if you continue to run into problems). 2. emulators/qemu is the latest stable, but there are typically a number of changes floating out in the devel branch (emulators/qemu-devel) that might be of interest to you: [EMAIL PROTECTED] /store]# grep -r ^PORTVERSION /usr/ports/emulators/qemu* /usr/ports/emulators/qemu/Makefile:PORTVERSION= 0.9.1 /usr/ports/emulators/qemu-devel/Makefile:PORTVERSION= 0.9.1s.20080620 -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Issues with 7.0-RELEASE-p2 and netstat/ld.elf.so-1
When running netstat on many boxes with this version of BSD, I'm seeing funky errors in my /var/log/messages, such as: Dec 4 14:55:49 server10 kernel: up_symbol Dec 4 14:55:49 server10 kernel: : missing Dec 4 14:55:49 server10 kernel: symbol h Dec 4 14:55:49 server10 kernel: ash tabl Dec 4 14:55:49 server10 kernel: e Dec 4 14:55:49 server10 kernel: I've traced this to whenever netstat runs. Unfortunately the box in question is "inherited" from a previous admin, and I don't have any other boxes that I've setup to check these files against. Can anyone running 7.0-release-p2 verify these MD5's? MD5 (/usr/bin/netstat) = e9e062b6523f2ccbc5befc8b52584346 MD5 (/libexec/ld-elf.so.1) = 86610ef79a07643572603c9b09b1af53 Thanks! Tyler Aviss ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
In article <[EMAIL PROTECTED]> you write: >On Thu, Dec 4, 2008 at 9:52 AM, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: >> On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: >>> >>> Are you running the ports version, or a different version, and/or are >>> you using kqemu (I've heard this was broken, in the past)? My group at >>> Cisco has several issues with older versions of qemu for PPC and when >>> we applied patches, it improved support greatly in some cases, and >>> introduced bugs in other cases =\. >>> >>> I'd definitely hit the devel list for QEMU and see what they say while >>> you're waiting for a more substantial reply here. >> >> I'm using the ports version. I am using kqemu... although I can try without >> the kernel module later today. >> >> How out-of-date is the port? > >1. Try without kqemu :) (or at least rebuild it, then disable it if >you continue to run into problems). >2. emulators/qemu is the latest stable, but there are typically a >number of changes floating out in the devel branch >(emulators/qemu-devel) that might be of interest to you: > >[EMAIL PROTECTED] /store]# grep -r ^PORTVERSION /usr/ports/emulators/qemu* >/usr/ports/emulators/qemu/Makefile:PORTVERSION= 0.9.1 >/usr/ports/emulators/qemu-devel/Makefile:PORTVERSION= 0.9.1s.20080620 Yes, qemu-devel is worth a try. I also post experimental port updates on -emulation once in a while that bring the qemu-devel port to more recent svn snapshots, like here: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-November/005530.html Oh and btw -kernel-kqemu is known to be broken with FreeBSD/amd64 guests, I was still able to boot 7.1-BETA2-amd64-livefs.iso into fixit->cdrom and try a few things in there using `regular' (userland) kqemu and my latest qemu-devel snapshot tho. HTH, Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Help debugging, machine won't boot anymore.
On Tuesday 02 December 2008 11:52:58 am Baldur Gislason wrote: > I have a machine running 7.0-STABLE/amd64 and it has suddenly > stopped booting. It just leaves me at the debugger with this message: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x8:0x804d913d > stack pointer = 0x10:0x80c9ec10 > frame pointer = 0x10:0x80c9ec70 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 0 ] > Stopped at device_probe_child+0x61:movq0x28(%rax),%rsi > db> > > dmesg at http://foo.is/~baldur/enigmaboot.txt > The ACPI warning has always been there. > > Any places of interest in the debugger? What's a likely culprit? bad RAM? I would get a stack trace first. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Thu, Dec 04, 2008 at 09:46:12PM +0100, I wrote: > In article <[EMAIL PROTECTED]> you write: > >On Thu, Dec 4, 2008 at 9:52 AM, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: > >> On Thu, Dec 4, 2008 at 6:27 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: > >>> > >>> Are you running the ports version, or a different version, and/or are > >>> you using kqemu (I've heard this was broken, in the past)? My group at > >>> Cisco has several issues with older versions of qemu for PPC and when > >>> we applied patches, it improved support greatly in some cases, and > >>> introduced bugs in other cases =\. > >>> > >>> I'd definitely hit the devel list for QEMU and see what they say while > >>> you're waiting for a more substantial reply here. > >> > >> I'm using the ports version. I am using kqemu... although I can try > >> without > >> the kernel module later today. > >> > >> How out-of-date is the port? > > > >1. Try without kqemu :) (or at least rebuild it, then disable it if > >you continue to run into problems). > >2. emulators/qemu is the latest stable, but there are typically a > >number of changes floating out in the devel branch > >(emulators/qemu-devel) that might be of interest to you: > > > >[EMAIL PROTECTED] /store]# grep -r ^PORTVERSION /usr/ports/emulators/qemu* > >/usr/ports/emulators/qemu/Makefile:PORTVERSION= 0.9.1 > >/usr/ports/emulators/qemu-devel/Makefile:PORTVERSION= 0.9.1s.20080620 > > Yes, qemu-devel is worth a try. I also post experimental port updates > on -emulation once in a while that bring the qemu-devel port to more recent > svn snapshots, like here: > > http://lists.freebsd.org/pipermail/freebsd-emulation/2008-November/005530.html > > Oh and btw -kernel-kqemu is known to be broken with FreeBSD/amd64 guests, > I was still able to boot 7.1-BETA2-amd64-livefs.iso into fixit->cdrom > and try a few things in there using `regular' (userland) kqemu and my > latest qemu-devel snapshot tho. I forgot to say the qemu-devel port (as well as the later snapshots I posted about on -emulation) also support -curses, which shows the emulated vga text(!)console on qemu's tty. This works quite well with FreeBSD guests (even the isos) if you extend your xterm/whatever by one line (the default vga textconsole is 80x25 instead of 80x24.) Of course if you have an installed guest you can also configure it for a serial console (in a FreeBSD guest:) # echo console=\"comconsole\" >>/boot/loader.conf # sed -i -e '/^ttyd0/s/off/on/' /etc/ttys and from then on run qemu with -nographic. (with -nographic, the guest's serial console and qemu's monitor are multiplexed on qemu's tty, hit ctrl-a and then `h' to show a small help.) -nographic also works with older qemu versions. HTH, Juergen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: AMD64 qemu completely broken?
On Thu, 4 Dec 2008, Juergen Lock wrote: I forgot to say the qemu-devel port (as well as the later snapshots I posted about on -emulation) also support -curses, which shows the emulated vga text(!)console on qemu's tty. This works quite well with FreeBSD guests (even the isos) if you extend your xterm/whatever by one line (the default vga textconsole is 80x25 instead of 80x24.) As long as we're sharing tips about qemu: I've recently been working with qemu on amd64 and have set up a Debian etch i386 guest which is working well. I am using the qemu-devel and kqemu-kmod-devel ports. I am not using -kernel-kqemu at the moment; I thought I would get things working before trying to speed up. Using qemu I've finally achieved my goal of being able to use flash on FreeBSD/amd64 (in some sense :-O). savevm and loadvm don't work due to a security patch. Since my guest system is trusted I reverted the patch. I filed a PR as ports/129417 . I found that '-net user' is horribly broken on amd64 (qemu segfaults). It uses some ancient [*] BSD TCP/IP code (via slirp) which assumes that pointers are 32 bits and doesn't hesitate to shove them into random 32-bit corners of externally defined structures if it's convenient. Looks like a pain to clean up. '-net tap' works fine, but requires root privileges and is more work to set up. [*] Out of curiosity, I looked at some Unix Archive stuff and found the identical code in BSD's Net2, circa 1991. It is identified in a comment as a "quick hack" and adorned with several /* XXX */. Naturally the code and the comments survive intact, 17 years later. :-( -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
local APIC 2 interrupt fifo limit
Hello, There is this comment in apicvar.h in the amd64 tree that talks about why the kernel uses smp_ipi_mtx and how it prevents more than 2 outstanding IPIs per interrupt vector. It appears that modern CPUs collapse the IRR bit if there is an interrupt when both the IRR and ISR bits are set. I was wondering why we need smp_ipi_mtx besides the fact that the kernel uses global variables for things like invalidate page ranges. Thanks, Ravi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
