Re: ahci errors on 8-stable
Nenhum_de_Nos schrieb am 16.03.2010 02:01 (localtime): On Mon, March 15, 2010 14:21, Harald Schmalzbauer wrote: Nenhum_de_Nos schrieb am 09.03.2010 00:44 (localtime): On Mon, 8 Mar 2010 14:26:53 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote: On Mon, Mar 08, 2010 at 06:38:02PM -0300, Nenhum_de_Nos wrote: I've seen these errors in a production machine in deep disk load (scp and bsdtar in heavy use): Please provide the output from the following commands: As I had huge disk activity when those messages appeared, I did reboot after and now no more are there. I think the vmstat command should be issued when the problem was happening right ? (if so I can run the backup tar's and see what happens). What disks do you use? I have similar timeouts and mav has the hd firmware in mind to be the culprit http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-02/msg00737.html In my case it's the samsung EcoGreen SpinPouint F2 1.5TB, Firmware 1AG01113 and 1AG01118. The disk on ahcich2 (where the timeouts appear) has the newer firmware. 2 Seagate 1TB disks: Mar 8 13:49:45 optimus kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Mar 8 13:49:45 optimus kernel: ada1: ST31000528AS CC38 ATA-8 SATA 2.x device Mar 8 13:49:45 optimus kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) Mar 8 13:49:45 optimus kernel: ada1: Command Queueing enabled Mar 8 13:49:45 optimus kernel: ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) Mar 8 13:49:45 optimus kernel: ada2 at ahcich3 bus 0 scbus3 target 0 lun 0 Mar 8 13:49:45 optimus kernel: ada2: ST31000528AS CC38 ATA-8 SATA 2.x device Mar 8 13:49:45 optimus kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) Mar 8 13:49:45 optimus kernel: ada2: Command Queueing enabled Mar 8 13:49:45 optimus kernel: ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) those are known to be bad ? In my experience, these are reliable drives. And completely different to mine. So I think it's not liklely to be a firmware bug. I hope the problem can be pointed out. If there's anything I can help, please let me know. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Does zfs have it's own nfs server?
Hello, I observed some very strange filesystem security problems. Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it does't respect any settings in /etc/exports. Also I get very strange uid numbers when writing. If I turn sharenfs off, limitations in /etc/exports work as expected. I thought sharenfs and sharesmb are only working on OpenSolaris. What about shareiscsi? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: Does zfs have it's own nfs server?
sharenfs does work in freebsd but iscsi does not. I'm not sure about smb. about nfs: you should take a look at /etc/zfs/exports On Wed, Mar 17, 2010 at 9:15 AM, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: Hello, I observed some very strange filesystem security problems. Now I found that if I set sharenfs=yes data/pub I can mount_nfs but it does't respect any settings in /etc/exports. Also I get very strange uid numbers when writing. If I turn sharenfs off, limitations in /etc/exports work as expected. I thought sharenfs and sharesmb are only working on OpenSolaris. What about shareiscsi? Thanks, -Harry ___ 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: Does zfs have it's own nfs server?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17.03.2010 09:27, Matthias Gamsjager wrote: sharenfs does work in freebsd but iscsi does not. I'm not sure about smb. shareiscsi no longer works in Opensolaris either. The legacy iscsitgtd has been replaced with the COMSTAR stack, giving a lot of new features, along them the splendid sysadminfriendliness of having to handle GUIDs on cli. ;) //Svein - -- - +---+--- /\ |Svein Skogen | sv...@d80.iso100.no \ / |Solberg Østli 9| PGP Key: 0xE5E76831 X|2020 Skedsmokorset | sv...@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | sv...@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listm...@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +---+--- |msn messenger: | Mobile Phone: +47 907 03 575 |sv...@jernhuset.no | RIPE handle:SS16503-RIPE - +---+--- If you really are in a hurry, mail me at svein-mob...@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - Picture Gallery: https://gallery.stillbilde.net/v/svein/ - -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuglOsACgkQODUnwSLUlKTO2QCeKt4QnRRRuKczVBSrH2chG7mX gy0AoKhO0V0WZdkZ/kRSCaBcDuEvKC2T =fqHn -END PGP SIGNATURE- ___ 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: proliant server lockups with freebsd-amd64-stable (2010-03-10)
Am Fri, 12 Mar 2010 20:38:31 +0200 schrieb Alexander Motin m...@freebsd.org: Pawel Jakub Dawidek wrote: On Thu, Mar 11, 2010 at 01:39:16PM +0100, Kai Gallasch wrote: I have some trouble with an opteron server locking up spontaneously. It looses all networks connectivity and even through console I can get no shell. Lockups occur mostly under disk load (periodic daily, bacula backup running, make buildworld/buildkernel) and I can provoke them easily. [...] 4 0 0 0 LL *cissmtx 0xff04ed820c00 [g_down] [...] 100046 L *cissmtx 0xff04ed820c00 [irq257: ciss0] [...] I was analizing similar problem as potential ZFS bug. It turned out to be bug in ciss(4) and I believe mav@ (CCed) has fix for that. That my patch is already at 8-STABLE since r204873 of 2010-03-08. Make sure you have it. Rebuilding the kernel with your 8-STABLE commited ciss patch seems to have resolved this issue. Server now has an uptime of 5 days and survives under high filesystem load. Alexander, thanks for fixing ciss. Kai. -- Da das Pferd pfluegt, lasst uns den Esel satteln. ___ 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
7.2-p7 - 8-STABLE mergemaster core dump
Hi, anyone else tried to update (todas's cvsup) 7.3-p7 to 8-STABLE? make update make buildworld make kernel make installworld mergemaster and i got a bad system call (core dumped). reboot, mergemaster again and it was allright. i use freebsd from 3.3 (maybe) and this is the first time i had to reboot with new kernel/world to make a mergemaster (very dangerous, i was remote). anyone else? -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ 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: 7.2-p7 - 8-STABLE mergemaster core dump
On Wed, Mar 17, 2010 at 03:25:14PM +0100, Cristiano Deana wrote: Hi, anyone else tried to update (todas's cvsup) 7.3-p7 to 8-STABLE? make update make buildworld make kernel make installworld I'm not familiar with upgrading a working 7.x to 8.x box, so I can't tell you for certain if that's what caused your problem. But the above make commands *are not* the proper procedure to follow. /usr/src/Makefile contains the procedure: # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # [steps 3. 4. can be combined by using the kernel target] # 5. `reboot'(in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `make delete-old' # 9. `mergemaster' (you may wish to use -U or -ai). # 10. `reboot' # 11. `make delete-old-libs' (in case no 3rd party program uses them anymore) Chances are the failure you were seeing is/was induced by you doing things in the wrong order. If your system doesn't have remote serial console (for the single user steps), then you get to do it from the VGA console. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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: 7.2-p7 - 8-STABLE mergemaster core dump
On Wed, Mar 17, 2010 at 2:25 PM, Cristiano Deana cristiano.de...@gmail.com wrote: Hi, anyone else tried to update (todas's cvsup) 7.3-p7 to 8-STABLE? make update make buildworld make kernel make installworld mergemaster and i got a bad system call (core dumped). reboot, mergemaster again and it was allright. i use freebsd from 3.3 (maybe) and this is the first time i had to reboot with new kernel/world to make a mergemaster (very dangerous, i was remote). anyone else? You can't always run new userland on an old kernel, but you can always run old userland on a new kernel, which is why the process you went through is not the canonical way. See the handbook or /usr/src/UPDATING: To rebuild everything and install it on the current system. --- # Note: sometimes if you are running current you gotta do more than # is listed here if you are upgrading from a really old current. make sure you have good level 0 dumps make buildworld make kernel KERNCONF=YOUR_KERNEL_HERE [1] reboot in single user [3] mergemaster -p [5] make installworld make delete-old mergemaster [4] reboot Cheers Tom ___ 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: 7.2-p7 - 8-STABLE mergemaster core dump
On Wed, Mar 17, 2010 at 3:32 PM, Tom Evans tevans...@googlemail.com wrote: make update make buildworld make kernel make installworld mergemaster and i got a bad system call (core dumped). You can't always run new userland on an old kernel, but you can always run old userland on a new kernel, which is why the process you went through is not the canonical way. See the handbook or /usr/src/UPDATING: yes, i knew. but i was updating via ssh, so forget run in single user. i also know the exact procedure, but i upgrade hundreds of times before today making this procedure and always went fine. i was just wondering if was a one at a time upgrade failure OR if THIS upgrade (7.2 - 8) have this problem. thanks all. btw, reboot without mergmaster and system was on again. mergemaster, reboot and it's ready. lucky me and thanks to freebsd -- Cris, member of G.U.F.I Italian FreeBSD User Group http://www.gufi.org/ ___ 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: 7.2-p7 - 8-STABLE mergemaster core dump
On Wed, Mar 17, 2010 at 2:37 PM, Cristiano Deana cristiano.de...@gmail.com wrote: On Wed, Mar 17, 2010 at 3:32 PM, Tom Evans tevans...@googlemail.com wrote: make update make buildworld make kernel make installworld mergemaster and i got a bad system call (core dumped). You can't always run new userland on an old kernel, but you can always run old userland on a new kernel, which is why the process you went through is not the canonical way. See the handbook or /usr/src/UPDATING: yes, i knew. but i was updating via ssh, so forget run in single user. i also know the exact procedure, but i upgrade hundreds of times before today making this procedure and always went fine. i was just wondering if was a one at a time upgrade failure OR if THIS upgrade (7.2 - 8) have this problem. thanks all. btw, reboot without mergmaster and system was on again. mergemaster, reboot and it's ready. lucky me and thanks to freebsd It will happen whenever you upgrade incorrectly and the newly installed userland requires syscalls that aren't present in your kernel. You need to be running your new kernel when you install your new world. What can go wrong if you don't do this order? Well, as you can see, you couldn't run mergemaster (and probably many other programs) until running your new kernel. If your new kernel did not boot successfully, you would be left with a kernel.old that boots but cant run the userland and a kernel that does not boot that can run the userland - in other words, you would be screwed. When switching major versions, there is always the chance that something major changes, so I'd try to avoid risky behaviour. YMMV. Cheers Tom ___ 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
msk gigabit NIC missed interrupts and watchdog timeouts
Hello, I am testing FreeBSD-8_STABLE updated as of a few minutes ago along with a msk type NIC. Having trouble with missed TX interrupts and watchdog timeouts. Tested http://svn.freebsd.org/changeset/base/205161 which made the NIC a little more stable but it finally exhibited the same issues after 10 minutes of load vs 1 minute. Does anyone have any suggestions on things that I can do to make this NIC more robust? pciconf -l shows: ms...@pci0:2:0:0: class=0x02 card=0x34588086 chip=0x436111ab rev=0x18 hdr=0x00 dmesg -a | grep msk shows: mskc0: Marvell Yukon 88E8050 Gigabit Ethernet port 0xc800-0xc8ff mem 0xdedfc000-0xdedf irq 16 at device 0.0 on pci2 msk0: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02 on mskc0 msk0: Ethernet address: 00:0e:0c:a4:54:ad miibus0: MII bus on msk0 mskc0: [FILTER] Thanks in advance for any pointers, etc Scott ___ 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
Odd USB probing issues with USB disk drives
I have run into a really odd issue with my USB hard drive (SimpleTech box w/ Fujitsu 160 GB drive). If I have the drive connected at boot, it is fine. If I plug it in after the initial USB probe, it connects at full speed. At 12Mbps, it is pretty useless. It can take a couple of minutes just to mount. If I disconnect it (either after dismounting or before mounting in the first place) and then re-connect it, the drive is probed correctly as high speed and it is actually useful. Further disconnect/re-connect operations always seem to probe it a high speed. Only the first time the drive is plugged in after booting seems to fail to connect at high speed. Here is my usbconfig with the drive probed correctly. ugen0.1: UHCI root HUB Intel at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: UHCI root HUB Intel at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: UHCI root HUB Intel at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: UHCI root HUB Intel at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen4.2: product 0x4482 vendor 0x04b3 at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.4: SimpleTech SimpleDrive PS at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen2.2: Biometric Coprocessor STMicroelectronics at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON If it probes as full speed, it is almost the same except that it is: ugen1.2: SimpleTech SimpleDrive PS at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON System is 8-Stable i386 uniprocessor and I have been seeing this since v8 went into the release cycle. It's just an annoyance now that I realize what is going on, but I would like to see if anyone else has seen this and if there is any explanation. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: msk gigabit NIC missed interrupts and watchdog timeouts
On Wed, Mar 17, 2010 at 11:07:43AM -0500, Scott Ullrich wrote: Hello, I am testing FreeBSD-8_STABLE updated as of a few minutes ago along with a msk type NIC. Having trouble with missed TX interrupts and watchdog timeouts. Would you try latest msk(4) in HEAD? I think you can download if_msk.c and if_mskreg.h from HEAD and can build it on stable/8. Due to added interface capabilities you have to add the following code in the beginning of if_msk.c to build it on stable/8. #ifndef IFCAP_VLAN_HWTSO #define IFCAP_VLAN_HWTSO0 #endif Tested http://svn.freebsd.org/changeset/base/205161 which made the NIC a little more stable but it finally exhibited the same issues after 10 minutes of load vs 1 minute. Does anyone have any suggestions on things that I can do to make this NIC more robust? pciconf -l shows: ms...@pci0:2:0:0: class=0x02 card=0x34588086 chip=0x436111ab rev=0x18 hdr=0x00 dmesg -a | grep msk shows: mskc0: Marvell Yukon 88E8050 Gigabit Ethernet port 0xc800-0xc8ff mem 0xdedfc000-0xdedf irq 16 at device 0.0 on pci2 msk0: Marvell Technology Group Ltd. Yukon EC Id 0xb6 Rev 0x02 on mskc0 msk0: Ethernet address: 00:0e:0c:a4:54:ad miibus0: MII bus on msk0 mskc0: [FILTER] Also show me the output of devinfo -rv | grep phy. ___ 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: msk gigabit NIC missed interrupts and watchdog timeouts
On Wed, Mar 17, 2010 at 11:36 AM, Pyun YongHyeon pyu...@gmail.com wrote: Would you try latest msk(4) in HEAD? I think you can download if_msk.c and if_mskreg.h from HEAD and can build it on stable/8. Due to added interface capabilities you have to add the following code in the beginning of if_msk.c to build it on stable/8. #ifndef IFCAP_VLAN_HWTSO #define IFCAP_VLAN_HWTSO 0 #endif No problem. Just compiled a kernel containing the newest files. Also show me the output of devinfo -rv | grep phy. nas2# devinfo -rv | grep ph e1000phy0 pnpinfo oui=0x5043 model=0xc rev=0x2 at phyno=0 I am now testing the new kernel and it has been under load for quite a while. I shifted 2+ gigabytes through it and it seems OK now. Thanks for the help !! Scott ___ 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: msk gigabit NIC missed interrupts and watchdog timeouts
On Wed, Mar 17, 2010 at 01:06:22PM -0500, Scott Ullrich wrote: On Wed, Mar 17, 2010 at 11:36 AM, Pyun YongHyeon pyu...@gmail.com wrote: Would you try latest msk(4) in HEAD? I think you can download if_msk.c and if_mskreg.h from HEAD and can build it on stable/8. Due to added interface capabilities you have to add the following code in the beginning of if_msk.c to build it on stable/8. #ifndef IFCAP_VLAN_HWTSO #define IFCAP_VLAN_HWTSO ? ? ? ?0 #endif No problem. Just compiled a kernel containing the newest files. Also show me the output of devinfo -rv | grep phy. nas2# devinfo -rv | grep ph e1000phy0 pnpinfo oui=0x5043 model=0xc rev=0x2 at phyno=0 Ok, it's 88E PHY. I am now testing the new kernel and it has been under load for quite a while. I shifted 2+ gigabytes through it and it seems OK now. Glad to hear that. If you encounter issues again let me know. ___ 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
Freeze on closing terminal that runs wpa_supplicant
Hello! I am running 8.0-RELEASE on a notebook with the Intel 3945 WiFi. I usually start wpa_supplicant [...] on a terminal when entering gnome followed by the dhcpcd call to use the WiFi connection. After having finished work and closing the terminal that runs wpa_supplicant, everything freezes and I have to turn the power off. Any suggestions? Thanks in advance, Mathias ___ 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: Freeze on closing terminal that runs wpa_supplicant
Date: Wed, 17 Mar 2010 20:47:19 +0100 From: Mathias Sogorski mathias.sogor...@googlemail.com Sender: owner-freebsd-sta...@freebsd.org Hello! I am running 8.0-RELEASE on a notebook with the Intel 3945 WiFi. I usually start wpa_supplicant [...] on a terminal when entering gnome followed by the dhcpcd call to use the WiFi connection. After having finished work and closing the terminal that runs wpa_supplicant, everything freezes and I have to turn the power off. Any suggestions? Is there a reason you don't use the standard incantation of ifconfig_wlan0=WPA DHCP in /etc/rc.conf? An alternative would be to manually do an /etc/rc.d/netif stop wlan0 or, even ifconfig wlan0 down. I suspect that yanking the parent process out from under the wpa_supplicant is causing a deadlock. (This is a bug, but I have no idea how difficult it might be to fix.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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
Crash in pf(4) with a fairly recent RELENG_8
Luckily I could find this coredump: -- cut here -- #0 doadump () at pcpu.h:223 #1 0x802f4ace in boot (howto=260) at ../../../kern/kern_shutdown.c:416 #2 0x802f4eab in panic (fmt=Variable fmt is not available. ) at ../../../kern/kern_shutdown.c:579 #3 0x805064d2 in trap_fatal (frame=0xff8345c0, eva=0) at ../../../amd64/amd64/trap.c:857 #4 0x80506e8c in trap (frame=0xff8345c0) at ../../../amd64/amd64/trap.c:644 #5 0x804eec93 in calltrap () at ../../../amd64/amd64/exception.S:224 #6 0x801a1140 in pf_state_tree_id_RB_MINMAX () at ../../../contrib/pf/net/pf.c:401 #7 0x801a1210 in pf_src_tree_RB_FIND (head=Variable head is not available. ) at ../../../contrib/pf/net/pf.c:396 #8 0x801a3594 in pf_insert_src_node (sn=0xff834868, rule=0xff0001694000, src=0xff000d75701c, af=2 '\002') at ../../../contrib/pf/net/pf.c:850 #9 0x801acd6e in pf_test_tcp (rm=0xff834978, sm=0xff834970, direction=1, kif=0xff000132ab00, m=0xff001e052b00, off=20, h=0xff000d757010, pd=0xff834990, am=0xff834980, rsm=0xff834968, ifq=0x0, inp=0x0) at ../../../contrib/pf/net/pf.c:3500 #10 0x801ae7a6 in pf_test (dir=1, ifp=0xff0001201000, m0=0xff834ac8, eh=Variable eh is not available. ) at ../../../contrib/pf/net/pf.c:7066 #11 0x801b33a9 in pf_check_in (arg=Variable arg is not available. ) at ../../../contrib/pf/net/pf_ioctl.c:3646 -- and here -- -- Good, fast cheap. Pick any two. ___ 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: Crash in pf(4) with a fairly recent RELENG_8
On Thu, Mar 18, 2010 at 12:38 AM, Vlad Galu d...@dudu.ro wrote:
Luckily I could find this coredump:
-- cut here --
#0 doadump () at pcpu.h:223
#1 0x802f4ace in boot (howto=260) at
../../../kern/kern_shutdown.c:416
#2 0x802f4eab in panic (fmt=Variable fmt is not available.
) at ../../../kern/kern_shutdown.c:579
#3 0x805064d2 in trap_fatal (frame=0xff8345c0, eva=0)
at ../../../amd64/amd64/trap.c:857
#4 0x80506e8c in trap (frame=0xff8345c0)
at ../../../amd64/amd64/trap.c:644
#5 0x804eec93 in calltrap () at ../../../amd64/amd64/exception.S:224
#6 0x801a1140 in pf_state_tree_id_RB_MINMAX ()
at ../../../contrib/pf/net/pf.c:401
#7 0x801a1210 in pf_src_tree_RB_FIND (head=Variable head is
not available.
)
at ../../../contrib/pf/net/pf.c:396
#8 0x801a3594 in pf_insert_src_node (sn=0xff834868,
rule=0xff0001694000, src=0xff000d75701c, af=2 '\002')
at ../../../contrib/pf/net/pf.c:850
#9 0x801acd6e in pf_test_tcp (rm=0xff834978,
sm=0xff834970, direction=1, kif=0xff000132ab00,
m=0xff001e052b00, off=20, h=0xff000d757010, pd=0xff834990,
am=0xff834980, rsm=0xff834968, ifq=0x0, inp=0x0)
at ../../../contrib/pf/net/pf.c:3500
#10 0x801ae7a6 in pf_test (dir=1, ifp=0xff0001201000,
m0=0xff834ac8, eh=Variable eh is not available.
) at ../../../contrib/pf/net/pf.c:7066
#11 0x801b33a9 in pf_check_in (arg=Variable arg is not available.
)
at ../../../contrib/pf/net/pf_ioctl.c:3646
-- and here --
The pf_src_node struct in frame #8 is this:
-- cut here--
(kgdb) p k
$1 = {entry = {rbe_left = 0x0, rbe_right = 0x0,
rbe_parent = 0x, rbe_color = 0}, addr = {pfa = {v4 = {
s_addr = 1684237067}, v6 = {__u6_addr = {
__u6_addr8 = \vkcd\200???\001\000\000\000\000\000\000,
__u6_addr16 = {27403, 25699, 65408, 65535, 1, 0, 0, 0},
__u6_addr32 = {1684237067, 4294967168, 1, 0}}},
addr8 = \vkcd\200???\001\000\000\000\000\000\000, addr16 = {27403,
25699, 65408, 65535, 1, 0, 0, 0}, addr32 = {1684237067, 4294967168, 1,
0}}}, raddr = {pfa = {v4 = {s_addr = 12}, v6 = {__u6_addr = {
__u6_addr8 = \f\000\000\000\000\000\000\000\000?2\001\000???,
__u6_addr16 = {12, 0, 0, 0, 43776, 306, 65280, 65535},
__u6_addr32 = {12, 0, 20097792, 4294967040}}},
addr8 = \f\000\000\000\000\000\000\000\000?2\001\000???, addr16 = {12,
0, 0, 0, 43776, 306, 65280, 65535}, addr32 = {12, 0, 20097792,
4294967040}}}, rule = {ptr = 0xff0001694000, nr = 23674880},
kif = 0x801a9858, bytes = {18446743523953737740,
18446742974423724064}, packets = {3354, 17179869187}, states = 23510160,
conn = 4294967040, conn_rate = {limit = 23403040, seconds = 4294967040,
count = 20097792, last = 4294967040}, creation = 2, expire = 0,
af = 2 '\002', ruletype = 0 '\0'}
-- and here--
The byte count looks weird...
___
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: ahci errors on 8-stable
On Wed, March 17, 2010 05:07, Harald Schmalzbauer wrote: Nenhum_de_Nos schrieb am 16.03.2010 02:01 (localtime): On Mon, March 15, 2010 14:21, Harald Schmalzbauer wrote: Nenhum_de_Nos schrieb am 09.03.2010 00:44 (localtime): On Mon, 8 Mar 2010 14:26:53 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote: On Mon, Mar 08, 2010 at 06:38:02PM -0300, Nenhum_de_Nos wrote: I've seen these errors in a production machine in deep disk load (scp and bsdtar in heavy use): Please provide the output from the following commands: As I had huge disk activity when those messages appeared, I did reboot after and now no more are there. I think the vmstat command should be issued when the problem was happening right ? (if so I can run the backup tar's and see what happens). What disks do you use? I have similar timeouts and mav has the hd firmware in mind to be the culprit http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2010-02/msg00737.html In my case it's the samsung EcoGreen SpinPouint F2 1.5TB, Firmware 1AG01113 and 1AG01118. The disk on ahcich2 (where the timeouts appear) has the newer firmware. 2 Seagate 1TB disks: Mar 8 13:49:45 optimus kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Mar 8 13:49:45 optimus kernel: ada1: ST31000528AS CC38 ATA-8 SATA 2.x device Mar 8 13:49:45 optimus kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) Mar 8 13:49:45 optimus kernel: ada1: Command Queueing enabled Mar 8 13:49:45 optimus kernel: ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) Mar 8 13:49:45 optimus kernel: ada2 at ahcich3 bus 0 scbus3 target 0 lun 0 Mar 8 13:49:45 optimus kernel: ada2: ST31000528AS CC38 ATA-8 SATA 2.x device Mar 8 13:49:45 optimus kernel: ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) Mar 8 13:49:45 optimus kernel: ada2: Command Queueing enabled Mar 8 13:49:45 optimus kernel: ada2: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) those are known to be bad ? In my experience, these are reliable drives. And completely different to mine. So I think it's not liklely to be a firmware bug. I hope the problem can be pointed out. If there's anything I can help, please let me know. Thanks, -Harry thanks. but it was caused by a disk intensive script that was running to much (a cron line that said * on minute and */4 on hour). so disks were never idle. when I corrected it no more of those showed up. if needed more tests can be done :) thanks all, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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
