Re: trap 12
On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote: > Quoting John Baldwin : > > > On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: > >> Quoting Ian J Hart : > >> > >>> Quoting Ian J Hart : > >>> > Is this likely to be hardware? Details will follow if not. > > [copied from a screen dump] > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x0 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0x807c6c12 > stack pointer = 0x10:0x510e7890 > frame pointer = 0x10:0xff00054a6c90 > 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 = 75372 (printf) > trap number = 12 > panic: page fault > cpuid = 1 > uptime: 8m2s > Cannot dump. No dump device defined. > > > >>> Ran crashinfo, now have much more info than I need ;) > >>> > >>> Starting another portupgrade run now to see how reproducable this is. > >>> > >>> Later BIOS waiting in USB floppy. > >>> > >> [snip dmesg] > >> > >> It took 2 runs of portupgrade -af.Some corruption in the dbs may have > >> to pkg_delete -a. > >> > >> FreeBSD * 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 > >> 18:03:10 BST 2009 *...@*:/usr/obj/usr/src/sys/GENERIC amd64 > >> > >> panic: page fault > >> > >> GNU gdb 6.1.1 [FreeBSD] > >> Copyright 2004 Free Software Foundation, Inc. > >> GDB is free software, covered by the GNU General Public License, and you are > >> welcome to change it and/or distribute copies of it under certain > > conditions. > >> Type "show copying" to see the conditions. > >> There is absolutely no warranty for GDB. Type "show warranty" for details. > >> This GDB was configured as "amd64-marcel-freebsd"... > >> > >> Unread portion of the kernel message buffer: > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 1; apic id = 01 > >> fault virtual address = 0xf570 > >> fault code = supervisor write data, page not present > >> instruction pointer = 0x8:0x807c429b > >> stack pointer = 0x10:0x511e4710 > >> frame pointer = 0x10:0x20 > >> 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 = 69996 (mkdir) > >> trap number = 12 > >> panic: page fault > > > > This one does look like a hardware issue from the stack trace. It's hard to > > know if the first panic you saw was a hardware issue as well without the > > stack trace information. > > > >> #7 0x807b706e in calltrap () > >> at /usr/src/sys/amd64/amd64/exception.S:209 > >> #8 0x807c429b in free_pv_entry (pmap=0x80b66c80, > >> pv=Variable "pv" is not available. > >> ) > >> at /usr/src/sys/amd64/amd64/pmap.c:1905 > >> #9 0x807c4403 in pmap_remove_entry (pmap=Variable "pmap" is > >> not available. > >> ) > >> at /usr/src/sys/amd64/amd64/pmap.c:2131 > >> #10 0x807c6447 in pmap_remove_pte (pmap=0x80b66c80, > >> ptq=0xaaa8, va=18446744070506639360, ptepde=23601251, > >> free=0x511e4790) at /usr/src/sys/amd64/amd64/pmap.c:2366 > >> #11 0x807cab87 in pmap_remove (pmap=0x80b66c80, > >> sva=18446744070506639360, eva=18446744070506909696) > >> at /usr/src/sys/amd64/amd64/pmap.c:2510 > > > > -- > > John Baldwin > > > > The remote backup continues to run so there was definitely some issue > there. No more reboots, but it wasn't doing that regularly without > some additional load. > > Hopefully I can swap parts around until I find the offending item. > > Thanks for your input. I would try running memtest86 to check your RAM. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with Soekris net5501 and USB hub
Graham Menhennitt wrote: I originally sent this to the Soekris list thinking it was platform specific. I got a couple of replies suggesting that it's a FreeBSD problem instead. So, if anybody can offer any insights, I would most appreciate it. I have a Soekris net5501 running FreeBSD 7-Stable. I want to connect a number of USB devices to it: - a HP Laserjet 1020 printer - an APC Back UPS 350 UPS - a 6-in-one card reader (not so fussed about this one). The Soekris box has only one USB port brought out to a connector on the case, so rather than mod the box to add another port, I thought I would just use an external hub. If I plug any of the devcies directly into the Soekris's USB port it works fine. However, if I use a USB hub then it doesn't work at all. I've tried it with two different hubs and two different cables. I've tried the hubs both with a plug pack, and being powered from the USB bus. The only thing common to the failures is the Soefkis and freeBSD. The hubs are both USB 2.0 according to their advertising. The hub itself is recognised (although I don't have the output from usbdevs available at the moment). The UPS doesn't ever seem to be recognised when connected via the hub - there's nothing in dmesg and nothing in usbdevs. Ditto for the 6-in-one card reader - the LED on the front of it doesn't even light up. The printer sometimes gets partially recognised. The output from "usbdevs -v" when the printer is connected directly and working properly looks like: Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x), AMD(0x), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x), AMD(0x), rev 1.00 port 1 addr 2: high speed, self powered, config 1, HP LaserJet 1020(0x2b17), Hewlett-Packard(0x03f0), rev 1.00 port 2 powered port 3 powered port 4 powered However, if I connect it via the hub, it sometimes doesn't show it at all, while other times it says something like (doing this from memory): port 1 addr 2: high speed, self powered, config 1, 0x2b17(0x2b17), vendor 0x03f0(0x03f0), rev 1.00 So, it can see it but it doesn't resolve the vendor or device ids. It looks like the Soekris can see whatever is directly connected to it, but can't (reliably) see things that more than one step away. My (custom) kernel has: device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device uhci# UHCI PCI->USB interface device ohci# OHCI PCI->USB interface device ehci# EHCI PCI->USB interface (USB 2.0) device ugen# Generic So, does anybody have any ideas about how to fix this. Thanks for any help, Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" see http://www.freebsd.org/cgi/query-pr.cgi?pr=131074 i think your case is very similar to mine -- SY, Marat smime.p7s Description: S/MIME Cryptographic Signature
Re: trap 12
Quoting John Baldwin : On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote: Quoting Ian J Hart : Quoting Ian J Hart : Is this likely to be hardware? Details will follow if not. [copied from a screen dump] Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c6c12 stack pointer = 0x10:0x510e7890 frame pointer = 0x10:0xff00054a6c90 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 = 75372 (printf) trap number = 12 panic: page fault cpuid = 1 uptime: 8m2s Cannot dump. No dump device defined. Ran crashinfo, now have much more info than I need ;) Starting another portupgrade run now to see how reproducable this is. Later BIOS waiting in USB floppy. [snip dmesg] It took 2 runs of portupgrade -af.Some corruption in the dbs may have to pkg_delete -a. FreeBSD * 7.2-RELEASE-p1 FreeBSD 7.2-RELEASE-p1 #0: Tue Jun 16 18:03:10 BST 2009 *...@*:/usr/obj/usr/src/sys/GENERIC amd64 panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xf570 fault code = supervisor write data, page not present instruction pointer = 0x8:0x807c429b stack pointer = 0x10:0x511e4710 frame pointer = 0x10:0x20 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 = 69996 (mkdir) trap number = 12 panic: page fault This one does look like a hardware issue from the stack trace. It's hard to know if the first panic you saw was a hardware issue as well without the stack trace information. #7 0x807b706e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209 #8 0x807c429b in free_pv_entry (pmap=0x80b66c80, pv=Variable "pv" is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:1905 #9 0x807c4403 in pmap_remove_entry (pmap=Variable "pmap" is not available. ) at /usr/src/sys/amd64/amd64/pmap.c:2131 #10 0x807c6447 in pmap_remove_pte (pmap=0x80b66c80, ptq=0xaaa8, va=18446744070506639360, ptepde=23601251, free=0x511e4790) at /usr/src/sys/amd64/amd64/pmap.c:2366 #11 0x807cab87 in pmap_remove (pmap=0x80b66c80, sva=18446744070506639360, eva=18446744070506909696) at /usr/src/sys/amd64/amd64/pmap.c:2510 -- John Baldwin The remote backup continues to run so there was definitely some issue there. No more reboots, but it wasn't doing that regularly without some additional load. Hopefully I can swap parts around until I find the offending item. Thanks for your input. -- ian j hart This message was sent using IMP, the Internet Messaging Program. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: pw groupadd/useradd fail when the nscd cache is used for name/group resolution
On Mon, 2009-07-13 at 13:43 -0400, Adam McDougall wrote: > Michael Proto wrote: > > On Mon, Jul 13, 2009 at 12:57 PM, Ulrich Spörlein wrote: > > > >> On Thu, 09.07.2009 at 16:13:25 +0300, Vlad Galu wrote: > >> > >>> I've stumbled upon this while installing postgres. In > >>> /etc/nsswitch.conf I had "group: cache files compat" and "passwd: > >>> cache files compat". Once I commented them out things started working > >>> again. Before the change, this is how it looked like: > >>> > >>> -- cut here -- > >>> [r...@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql > >>> -g 70 > >>> pw: group disappeared during update > >>> [r...@vgalu /usr/ports/databases/postgresql84-server]# pw group add pgsql > >>> -g 70 > >>> pw: group 'pgsql' already exists > >>> [r...@vgalu /usr/ports/databases/postgresql84-server]# > >>> -- and here -- > >>> > >>> Shouldn't 'files' be used upon a cache miss? If this is a PEBKAC, > >>> sorry for the noise. > >>> > >> Just a me too. This is most likely because nscd is also caching negative > >> lookups. The usual workaround would be to restart it using > >> /etc/rc.d/nscd restart > >> > >> > > A slightly lower-impact alternative would be to use "nscd -i passwd" > > to invalidate the password cache. > > > > > I was intending to report this soon as well (its been on my list for a > while) as a problematic > issue while installing ports. The other issue I had was Java would > crash immediately if I had > nscd running (configured to cache YP). I plan to report that soon if it > still happens with 1.6. > I probably tested with 1.4 or 1.5. This is a known problem with nscd(8), see ports/125330 and bin/119695. If you have any further information (or even a patch) it's probably best to append it to the second of those PRs. Thanks, Gavin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS, unionfs - Operation not supported
Oliver Pinter wrote: Hi all! It is the problematic FS: zpower on /mnt/zpower (zfs, local) /usr/src on /mnt/zpower/jail/default/ports (nullfs, local) and the failed command: mount_unionfs -o below /mnt/zpower/jail/default/ports/ /mnt/zpower/jail/www/usr/ports/ (truss mount_unionfs -o below /mnt/zpower/jail/default/ports/ /mnt/zpower/jail/www/usr/ports/ ) > & /tmp/unionfs.log Have I any chance, to unionmount ZFS with UFS or ZFS not supported this operations? Yes, unionfs is not supported with ZFS. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: portsnap and freebsd-update (metadata) failure
* Hans F. Nordhaug [2009-07-08]: > Hi! > > Quick question: Is it just me and my freshly installed FreeBSD 7.2 > that fails when running freebsd-update or portsnap right now? With > freebsd-update I tried update4 and update1. Just ask for more info, if > it's needed to debug the problem. Apperently it was only meand my machine ;-) I reinstalled FreeBSD 7.2 on a newer computer and then freebsd-update or portsnap worked nicely. Best regards, Hans Nordhaug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
