From cbeckham at gmail.com Mon Sep 1 07:16:00 2008 From: cbeckham at gmail.com (Charles Beckham) Date: Mon Sep 1 07:16:07 2008 Subject: Obytes counter in netstat not incrementing Message-ID: after configuring some rrd's and expecting to grab the data from netstat to log, i noticed that most addresses on the system arn't having the OBytes counter increased. is this just me, or am i missing something? i also have ipfw count rules for each address on the system, to check if the problem was maybe my command line. below is some snippets. x# netstat -ibdnW | grep 208.110.87.83 | perl -p -e 's/ */ /g' fxp0 1500 208.110.87 208.110.87.83 148701705 - 3765807065 1520 - 136897 - - x# ipfw show 5000 | grep 208.110.87.83 05000 423144 18533923 count ip from any to 208.110.87.83 05000 419195 85561587 count ip from 208.110.87.83 to any x# netstat -ibdnW | grep 208.110.87.83 | perl -p -e 's/ */ /g' fxp0 1500 208.110.87 208.110.87.83 148702426 - 3765843377 1520 - 136897 - - x# ipfw show 5000 | grep 208.110.87.83 05000 423198 18536930 count ip from any to 208.110.87.83 05000 419228 85565367 count ip from 208.110.87.83 to any x# netstat -ibdnW | grep 208.110.87.83 | perl -p -e 's/ */ /g' fxp0 1500 208.110.87 208.110.87.83 148702600 - 3765853440 1520 - 136897 - - as you can see, the ipfw counters are increasing, but not the netstat output, any ideas, or am i missing something? -- - Charles Beckham From ahornung at gmail.com Mon Sep 1 09:06:23 2008 From: ahornung at gmail.com (Alex) Date: Mon Sep 1 09:06:29 2008 Subject: Driver to Driver communication, with kobj? Message-ID: <10fba67b0809010206ya78c526n566e4e643f7a2b64@mail.gmail.com> Hi, I was wondering what the best way of doing driver to driver communication is. I'm trying to enqueue an ata-command from a completely different driver (nothing to do with storage / ata). I would just bluntly use the ata_controlcmd() function, but it would require for me to know the device_t of the drive I'm trying to access. I don't know which device_t it would be, nor do I know how to find it out. If this is a no-go... I really need some help with kobj, as I can't figure it out fully... How do you use a kobj "exported" method from another driver? Thank you in advance, Alex From laladelausanne at gmail.com Mon Sep 1 11:22:57 2008 From: laladelausanne at gmail.com (=?UTF-8?Q?Nikola_Kne=C5=BEevi=C4=87?=) Date: Mon Sep 1 11:23:05 2008 Subject: kldload: unexpected relocation type 10 Message-ID: <0F17887A-AC71-49F0-B25D-8F2DC8BB5465@gmail.com> Hi guys, I'm trying to do something unusual - to build my own module, mixed with the Click (Modular Router). In order to do so, I had to write a Makefile which borrows a lot from Click's Makefile. Like all other kernel modules, I include , but I'm modifying CFLAGS (with +=), and CXXFLAGS. I also have -DHAVE_INT64_IS_LONG there. For CXXFLAGS I use -fpermissive -fno-exceptions -fno-rtti. I had to do all this creaziness because I had to build CLick first (its .cc files), and then link all them with my code. Now I'm getting this: "kldload: unexpected relocation type 10" and: "link_elf_obj: symbol M_TEMP undefined" I cannot find where this M_TEMP comes from, because I'm including . for the relocation, I don't know what to do. I'm not using - g, as described on some web forum. Any hints? Cheers, Nikola From lme at FreeBSD.org Mon Sep 1 22:07:09 2008 From: lme at FreeBSD.org (Lars Engels) Date: Mon Sep 1 22:07:20 2008 Subject: USB Video class In-Reply-To: <20080819175332.482767np3ciixag4@webmail.leidinger.net> References: <200808191305.m7JD5Tbl007123@brother.ludd.ltu.se> <20080819175332.482767np3ciixag4@webmail.leidinger.net> Message-ID: <20080901220706.GB3961@e.0x20.net> On Tue, Aug 19, 2008 at 05:53:32PM +0200, Alexander Leidinger wrote: > Quoting "Peter B" (from Tue, 19 Aug 2008 15:05:29 +0200 (MEST)): > > > > >Is there any ongoing project towards USB Video class support in FreeBSD ..? > > This is better asked on usb@ (CCed). I'm not aware of such an effort, feel free to start it (you better wait some days until the > new USB stack hits CVS). NetBSD had a Summer of Code project and it seems to be pretty successful: http://netbsd-soc.sourceforge.net/projects/uvc/ Perhaps one can take this as a starting point? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080901/65879886/attachment.pgp From pb at ludd.ltu.se Mon Sep 1 23:19:41 2008 From: pb at ludd.ltu.se (Peter B) Date: Tue Sep 2 02:46:01 2008 Subject: USB Video class In-Reply-To: <20080901220706.GB3961@e.0x20.net> from "Lars Engels" at Sep 02, 2008 12:07:06 AM Message-ID: <200809012319.m81NJckk006025@brother.ludd.ltu.se> >> > >> >Is there any ongoing project towards USB Video class support in FreeBSD = >=2E.? >>=20 >> This is better asked on usb@ (CCed). I'm not aware of such an effort, fee= >l free to start it (you better wait some days until the=20 >> new USB stack hits CVS). >NetBSD had a Summer of Code project and it seems to be pretty >successful: >http://netbsd-soc.sourceforge.net/projects/uvc/ >Perhaps one can take this as a starting point? When testing. I found it seems to be easier to port the OpenBSD code. I think it's because it's more integrated into the kernel sources. The current status is proper probe, attach, and capability dump. I think I know how to approach the problem better now after messing with code for awhile. (however some other things are using my time atm) From david at catwhisker.org Tue Sep 2 16:14:59 2008 From: david at catwhisker.org (David Wolfskill) Date: Tue Sep 2 16:15:06 2008 Subject: Obytes counter in netstat not incrementing In-Reply-To: References: Message-ID: <20080902154131.GH1089@bunrab.catwhisker.org> On Sun, Aug 31, 2008 at 11:46:36PM -0700, Charles Beckham wrote: > [... "netstat -ibdnW" doesn't show changes in Obytes (or Opkts)...] > ... > as you can see, the ipfw counters are increasing, but not the netstat > output, any ideas, or am i missing something? First, what is the output of "uname -r" (at least)? I'm experimenting with using "netstat -nibf inet" to acquire such information, and on a FreeBSD 6.3-STABLE system built 25 Aug 2008, I do not see the problem: dwolf-bsd(6.3-S)[1] date;netstat -nibf inet; sleep 10; date; netstat -nibf inet Tue Sep 2 08:40:26 PDT 2008 Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll em0 1500 172.24.24/22 172.24.24.91 16954669 - 3460328864 8173509 - 1440161156 - lo0 16384 127 127.0.0.1 4283768 - 627953338 4283768 - 627953338 - Tue Sep 2 08:40:36 PDT 2008 Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll em0 1500 172.24.24/22 172.24.24.91 16954688 - 3460330996 8173528 - 1440163696 - lo0 16384 127 127.0.0.1 4283806 - 627956814 4283807 - 627957022 - dwolf-bsd(6.3-S)[2] Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080902/c92bed7d/attachment.pgp From cbeckham at gmail.com Tue Sep 2 20:15:17 2008 From: cbeckham at gmail.com (Charles Beckham) Date: Tue Sep 2 20:15:24 2008 Subject: Obytes counter in netstat not incrementing In-Reply-To: <20080902154131.GH1089@bunrab.catwhisker.org> References: <20080902154131.GH1089@bunrab.catwhisker.org> Message-ID: sorry, heres a uname x# uname -a FreeBSD x.worxtech.net 6.3-STABLE FreeBSD 6.3-STABLE #1: Sun May 25 12:15:51 CDT 2008 worxtech@x.worxtech.net:/usr/obj/usr/src/sys/X i386 also i should point out that this machine has ~ 100 alias addresses on it, and the problem doesnt seem to appear with all of them, some appear to have a proper counter. x# netstat -nibf inet Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll fxp0 1500 208.110.87 208.110.87.43 16734290 - 3093571704 284564171 - 685127971 - fxp0 1500 208.110.87 208.110.87.44 848085 - 82624659 46376 - 2604545 - heres output from the address i posted before, which is the highest usage on the machine fxp0 1500 208.110.87 208.110.87.83 169838660 - 400838840 1520 - 136897 - as you can see, the obytes hasnt gone up in a few days. i'm not quite sure why this problem is persistent but could it be related to my netmask address for the inet alias? i did some research and it appears i should be using 0xffffffff for my netmask for the alias interface? please let me know any thaughts you may have. x# ifconfig fxp0 fxp0: flags=8843 mtu 1500 options=b inet 208.110.87.43 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.44 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.45 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.46 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.47 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.48 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.49 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.20 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.120 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.121 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.122 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.123 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.124 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.125 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.126 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.127 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.128 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.129 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.130 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.131 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.132 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.133 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.134 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.135 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.136 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.137 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.138 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.139 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.140 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.141 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.142 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.143 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.144 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.145 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.146 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.147 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.148 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.149 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.150 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.151 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.152 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.153 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.154 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.155 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.156 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.157 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.158 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.159 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.160 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.40 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.98 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.99 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.100 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.101 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.41 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.42 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.50 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.51 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.52 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.53 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.54 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.55 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.56 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.57 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.58 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.59 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.60 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.61 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.62 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.63 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.64 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.65 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.66 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.67 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.68 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.69 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.70 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.71 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.72 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.73 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.74 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.75 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.76 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.77 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.78 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.79 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.80 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.81 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.82 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.83 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.84 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.85 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.86 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.87 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.88 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.89 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.90 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.91 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.92 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.93 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.94 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.95 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.96 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.97 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.102 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.103 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.104 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.105 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.106 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.107 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.108 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.109 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.110 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.111 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.112 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.113 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.114 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.115 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.116 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.117 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.118 netmask 0xffffff00 broadcast 208.110.87.255 inet 208.110.87.119 netmask 0xffffff00 broadcast 208.110.87.255 ether 00:30:48:24:85:7d media: Ethernet autoselect (100baseTX ) status: active x# On Tue, Sep 2, 2008 at 8:41 AM, David Wolfskill wrote: > On Sun, Aug 31, 2008 at 11:46:36PM -0700, Charles Beckham wrote: >> [... "netstat -ibdnW" doesn't show changes in Obytes (or Opkts)...] >> ... >> as you can see, the ipfw counters are increasing, but not the netstat >> output, any ideas, or am i missing something? > > First, what is the output of "uname -r" (at least)? > > I'm experimenting with using "netstat -nibf inet" to acquire such > information, and on a FreeBSD 6.3-STABLE system built 25 Aug 2008, I do > not see the problem: > > dwolf-bsd(6.3-S)[1] date;netstat -nibf inet; sleep 10; date; netstat -nibf inet > Tue Sep 2 08:40:26 PDT 2008 > Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll > em0 1500 172.24.24/22 172.24.24.91 16954669 - 3460328864 8173509 - 1440161156 - > lo0 16384 127 127.0.0.1 4283768 - 627953338 4283768 - 627953338 - > Tue Sep 2 08:40:36 PDT 2008 > Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll > em0 1500 172.24.24/22 172.24.24.91 16954688 - 3460330996 8173528 - 1440163696 - > lo0 16384 127 127.0.0.1 4283806 - 627956814 4283807 - 627957022 - > dwolf-bsd(6.3-S)[2] > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- - Charles From david at catwhisker.org Tue Sep 2 20:38:11 2008 From: david at catwhisker.org (David Wolfskill) Date: Tue Sep 2 20:39:24 2008 Subject: Obytes counter in netstat not incrementing In-Reply-To: References: <20080902154131.GH1089@bunrab.catwhisker.org> Message-ID: <20080902203809.GK1089@bunrab.catwhisker.org> On Tue, Sep 02, 2008 at 01:15:15PM -0700, Charles Beckham wrote: > sorry, heres a uname > x# uname -a > FreeBSD x.worxtech.net 6.3-STABLE FreeBSD 6.3-STABLE #1: Sun May 25 > 12:15:51 CDT 2008 worxtech@x.worxtech.net:/usr/obj/usr/src/sys/X > i386 > > also i should point out that this machine has ~ 100 alias addresses on > it, and the problem doesnt seem to appear with all of them, some > appear to have a proper counter. > ... > i'm not quite sure why this problem is persistent but could it be > related to my netmask address for the inet alias? > i did some research and it appears i should be using 0xffffffff for my > netmask for the alias interface? please let me know any thaughts you > may have. Ah. I recall that in older releases of FreeBSD, attempting to create such "alias" entries netmask specifications that amounted to having different "alias" specifications sharing a (sub)net generally failed to work, with the suggestion to use 0xffffffff as the netmask for all such alias specification being the usual suggestion. Somehow, I thought that someone had done some work on this, but on a 6.3-STABLE system built 25 August, I still see in ifconfig(1): alias Establish an additional network address for this interface. This is sometimes useful when changing network numbers, and one wishes to accept packets addressed to the old interface. If the address is on the same subnet as the first network address for this interface, a non-conflicting netmask must be given. Usually 0xffffffff is most appropriate. so unless there's some special reason you're using a different netmask for the alia entrie, I think I'd suggest switching to 0xffffffff. >.... Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080902/56708d68/attachment.pgp From cbeckham at gmail.com Wed Sep 3 00:22:13 2008 From: cbeckham at gmail.com (Charles Beckham) Date: Wed Sep 3 00:22:20 2008 Subject: Obytes counter in netstat not incrementing In-Reply-To: <20080902203809.GK1089@bunrab.catwhisker.org> References: <20080902154131.GH1089@bunrab.catwhisker.org> <20080902203809.GK1089@bunrab.catwhisker.org> Message-ID: i've already made the changes to rc.conf, but since its a shared machine and almost all addresses are in use, i'll have to schedule a reboot before i can make changes effective, i will post a follwup after i've made these changes. thanks for you assistance. On Tue, Sep 2, 2008 at 1:38 PM, David Wolfskill wrote: > On Tue, Sep 02, 2008 at 01:15:15PM -0700, Charles Beckham wrote: >> sorry, heres a uname >> x# uname -a >> FreeBSD x.worxtech.net 6.3-STABLE FreeBSD 6.3-STABLE #1: Sun May 25 >> 12:15:51 CDT 2008 worxtech@x.worxtech.net:/usr/obj/usr/src/sys/X >> i386 >> >> also i should point out that this machine has ~ 100 alias addresses on >> it, and the problem doesnt seem to appear with all of them, some >> appear to have a proper counter. >> ... >> i'm not quite sure why this problem is persistent but could it be >> related to my netmask address for the inet alias? >> i did some research and it appears i should be using 0xffffffff for my >> netmask for the alias interface? please let me know any thaughts you >> may have. > > Ah. I recall that in older releases of FreeBSD, attempting to create > such "alias" entries netmask specifications that amounted to having > different "alias" specifications sharing a (sub)net generally failed to > work, with the suggestion to use 0xffffffff as the netmask for all such > alias specification being the usual suggestion. > > Somehow, I thought that someone had done some work on this, but on a > 6.3-STABLE system built 25 August, I still see in ifconfig(1): > > alias Establish an additional network address for this interface. This > is sometimes useful when changing network numbers, and one wishes > to accept packets addressed to the old interface. If the address > is on the same subnet as the first network address for this > interface, a non-conflicting netmask must be given. Usually > 0xffffffff is most appropriate. > > so unless there's some special reason you're using a different netmask for > the alia entrie, I think I'd suggest switching to 0xffffffff. > >>.... > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > -- - Charles From kr.lekha at gmail.com Wed Sep 3 09:06:19 2008 From: kr.lekha at gmail.com (kr Lekha) Date: Wed Sep 3 09:06:26 2008 Subject: killing a kthread Message-ID: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> Hi, i wanted to kill a kthread created by my module, There is no actual kthread_kill to kill it hence I tried to send kill signal to thread psignal(p, SIGTERM); psignal(p, SIGKILL); killproc(p,"messeage"); and kthread_suspend() Nothing seems to be killing the kthread, I still see it [root@ /usr/src]# ps awx -l | grep kernel UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 1048 1 0 20 0 0 8 ktsusp DL ?? 0:00.01 [new_kernel_thread] I have noticed that generally if kernel module wanted to kill a thread then it calls { wakeup(p); msleep(p,0); /*or tsleep*/ } This puts the thread to sleep forever. However kthread_suspend also performs same actions. Does scheduler take care to killing it? I read that after 2 min scheduler wakes up the thread and eventually kills it, i see the same kthread suspended even after a day I would appreciate any thoughts in this reagard. Thanks, -lekha From rpaulo at FreeBSD.org Wed Sep 3 09:57:05 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Wed Sep 3 09:57:12 2008 Subject: killing a kthread In-Reply-To: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> References: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> Message-ID: <20080903095605.GB21178@alpha.local> On Wed, Sep 03, 2008 at 09:34:47AM +0100, kr Lekha wrote: > Hi, > i wanted to kill a kthread created by my module, There is no actual > kthread_kill to kill it > > hence I tried to send kill signal to thread > psignal(p, SIGTERM); > psignal(p, SIGKILL); > killproc(p,"messeage"); > and kthread_suspend() > > Nothing seems to be killing the kthread, I still see it > [root@ /usr/src]# ps awx -l | grep kernel > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 1048 1 0 20 0 0 8 ktsusp DL > ?? 0:00.01 [new_kernel_thread] > > > I have noticed that generally if kernel module wanted to kill a thread then > it calls > { > wakeup(p); > msleep(p,0); /*or tsleep*/ > } > > This puts the thread to sleep forever. However kthread_suspend also performs > same actions. > Does scheduler take care to killing it? > > I read that after 2 min scheduler wakes up the thread and > eventually kills it, > i see the same kthread suspended even after a day > > I would appreciate any thoughts in this reagard. > Thanks, When the thread finishes what it's doing, it should call kthread_exit(). Regards, -- Rui Paulo From guru at unixarea.de Wed Sep 3 11:31:34 2008 From: guru at unixarea.de (Matthias Apitz) Date: Wed Sep 3 11:31:43 2008 Subject: WPA && associating with unknown SSID Message-ID: <20080903113131.GA8697@rebelion.Sisis.de> Hello, I'm using WPA to connect to my various Wifi AP's (office, home, partner locations) and have them well configured in the wpa_supplicant.conf(5) file; from time to time at home I encounter that it is associating with an unknown AP of my neighbourhood: # ifconfig iwi0 iwi0: flags=8843 metric 0 mtu 1500 ether 00:13:ce:a1:e6:81 inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS roaming MANUAL # ifconfig iwi0 list scan SSID BSSID CHAN RATE S:N INT CAPS o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA the network with SSID 'o2DSL_kJaR' is not im my /etc/wpa_supplicant.conf; how this is possible and how can I prevent this? thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. From andrit at ukr.net Wed Sep 3 12:00:38 2008 From: andrit at ukr.net (Andriy Tkachuk) Date: Wed Sep 3 12:00:48 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <20080903113131.GA8697@rebelion.Sisis.de> References: <20080903113131.GA8697@rebelion.Sisis.de> Message-ID: <48BE7976.6090705@ukr.net> On 2008-09-03 14:31, Matthias Apitz wrote: > from time to time at home I encounter that it is associating with an > unknown AP of my neighbourhood: > > how this is possible and how can I prevent this? > Try to get wpa_supplicant log. Also you are welcome to write to hostap@lists.shmoo.com mail list about this problem (but specify there version of supplicant). Regards, Andriy From kr.lekha at gmail.com Wed Sep 3 12:16:27 2008 From: kr.lekha at gmail.com (kr Lekha) Date: Wed Sep 3 12:16:33 2008 Subject: killing a kthread In-Reply-To: <20080903095605.GB21178@alpha.local> References: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> <20080903095605.GB21178@alpha.local> Message-ID: <96b2ec350809030516y2d6f26d1h3cd7eb39231c4da0@mail.gmail.com> I understand when thread finishes it should call kthread_exit(). but if this thread was suspended before it finished, it might not be able to call kthread_exit(). Due to which we still see the thread suspended. I am unable to kill it even with killproc / psignal with in the kernel module. Thanks, Lekha On 9/3/08, Rui Paulo wrote: > > On Wed, Sep 03, 2008 at 09:34:47AM +0100, kr Lekha wrote: > > Hi, > > i wanted to kill a kthread created by my module, There is no actual > > kthread_kill to kill it > > > > hence I tried to send kill signal to thread > > psignal(p, SIGTERM); > > psignal(p, SIGKILL); > > killproc(p,"messeage"); > > and kthread_suspend() > > > > Nothing seems to be killing the kthread, I still see it > > [root@ /usr/src]# ps awx -l | grep kernel > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME > COMMAND > > 0 1048 1 0 20 0 0 8 ktsusp DL > > ?? 0:00.01 [new_kernel_thread] > > > > > > I have noticed that generally if kernel module wanted to kill a thread > then > > it calls > > { > > wakeup(p); > > msleep(p,0); /*or tsleep*/ > > } > > > > This puts the thread to sleep forever. However kthread_suspend also > performs > > same actions. > > Does scheduler take care to killing it? > > > > I read that after 2 min scheduler wakes up the thread and > > eventually kills it, > > i see the same kthread suspended even after a day > > > > I would appreciate any thoughts in this reagard. > > Thanks, > > When the thread finishes what it's doing, it should call kthread_exit(). > > Regards, > -- > Rui Paulo > From sam at freebsd.org Wed Sep 3 15:04:51 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Sep 3 15:04:57 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <20080903113131.GA8697@rebelion.Sisis.de> References: <20080903113131.GA8697@rebelion.Sisis.de> Message-ID: <48BEA791.6030406@freebsd.org> Matthias Apitz wrote: > Hello, > > I'm using WPA to connect to my various Wifi AP's (office, home, partner > locations) and have them well configured in the wpa_supplicant.conf(5) > file; > > from time to time at home I encounter that it is associating with an > unknown AP of my neighbourhood: > > > # ifconfig iwi0 > iwi0: flags=8843 metric 0 mtu 1500 > ether 00:13:ce:a1:e6:81 > inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 > media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > status: associated > ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 > authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 > scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 > roam:rate11g 5 protmode CTS roaming MANUAL > # ifconfig iwi0 list scan > SSID BSSID CHAN RATE S:N INT CAPS > o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP > xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA > > the network with SSID 'o2DSL_kJaR' is not im my > /etc/wpa_supplicant.conf; > > how this is possible and how can I prevent this? > You must have a wildcard entry in your wpa_supplicant.conf file (i.e. one w/o an ssid specified). Sam From gahr at FreeBSD.org Wed Sep 3 16:09:33 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Wed Sep 3 16:09:42 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <48BEA791.6030406@freebsd.org> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> Message-ID: <48BEB687.5050308@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sam Leffler wrote: | Matthias Apitz wrote: |> Hello, |> |> I'm using WPA to connect to my various Wifi AP's (office, home, partner |> locations) and have them well configured in the wpa_supplicant.conf(5) |> file; |> |> from time to time at home I encounter that it is associating with an |> unknown AP of my neighbourhood: |> |> |> # ifconfig iwi0 |> iwi0: flags=8843 metric 0 mtu |> 1500 |> ether 00:13:ce:a1:e6:81 |> inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 |> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) |> status: associated |> ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 |> authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 |> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 |> roam:rate11g 5 protmode CTS roaming MANUAL |> # ifconfig iwi0 list scan |> SSID BSSID CHAN RATE S:N INT CAPS |> o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP |> xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA |> |> the network with SSID 'o2DSL_kJaR' is not im my |> /etc/wpa_supplicant.conf; |> |> how this is possible and how can I prevent this? |> | You must have a wildcard entry in your wpa_supplicant.conf file (i.e. | one w/o an ssid specified). Not necessarily. If you bring up a wlan interface and don't specify anything, it will automatically associate with the first open AP it finds. I don't know if it's to be considered a feature or a bug. I've been worried by this sometimes, but honestly not enough to really care.. Anyway, it happens... | Sam - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAki+toYACgkQwMJqmJVx945SJwCeNc0z+Jb2Rqw6n06sPKLJcxmA jlMAn2ZEa/r40dDf5cgaUoeWiJYyCkLC =OxPp -----END PGP SIGNATURE----- From sam at freebsd.org Wed Sep 3 18:23:51 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Sep 3 18:23:58 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <48BEB687.5050308@FreeBSD.org> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> <48BEB687.5050308@FreeBSD.org> Message-ID: <48BED635.5010100@freebsd.org> Pietro Cerutti wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Sam Leffler wrote: > | Matthias Apitz wrote: > |> Hello, > |> > |> I'm using WPA to connect to my various Wifi AP's (office, home, > partner > |> locations) and have them well configured in the wpa_supplicant.conf(5) > |> file; > |> > |> from time to time at home I encounter that it is associating with an > |> unknown AP of my neighbourhood: > |> > |> > |> # ifconfig iwi0 > |> iwi0: flags=8843 metric 0 mtu > |> 1500 > |> ether 00:13:ce:a1:e6:81 > |> inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 > |> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > |> status: associated > |> ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid > 00:19:cb:86:b3:84 > |> authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 > |> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 > roam:rssi11g 7 > |> roam:rate11g 5 protmode CTS roaming MANUAL > |> # ifconfig iwi0 list scan > |> SSID BSSID CHAN RATE S:N INT CAPS > |> o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP > |> xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA > |> > |> the network with SSID 'o2DSL_kJaR' is not im my > |> /etc/wpa_supplicant.conf; > |> > |> how this is possible and how can I prevent this? > |> > | You must have a wildcard entry in your wpa_supplicant.conf file (i.e. > | one w/o an ssid specified). > > Not necessarily. If you bring up a wlan interface and don't specify > anything, it will automatically associate with the first open AP it > finds. > > I don't know if it's to be considered a feature or a bug. I've been > worried by this sometimes, but honestly not enough to really care.. > > Anyway, it happens... > He was talking about wpa_supplicant selecting an arbitrary AP. If you have a device marked up then the system will handle ap selection+join but if wpa_supplicant is running then it marks the interface in "manual roaming mode" which stops that behaviour. Sam From gahr at FreeBSD.org Wed Sep 3 18:50:38 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Wed Sep 3 18:50:45 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <48BED635.5010100@freebsd.org> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> <48BEB687.5050308@FreeBSD.org> <48BED635.5010100@freebsd.org> Message-ID: <48BEDC46.7090502@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Sam Leffler wrote: | Pietro Cerutti wrote: |> -----BEGIN PGP SIGNED MESSAGE----- |> Hash: SHA512 |> |> Sam Leffler wrote: |> | Matthias Apitz wrote: |> |> Hello, |> |> |> |> I'm using WPA to connect to my various Wifi AP's (office, home, |> partner |> |> locations) and have them well configured in the wpa_supplicant.conf(5) |> |> file; |> |> |> |> from time to time at home I encounter that it is associating with an |> |> unknown AP of my neighbourhood: |> |> |> |> |> |> # ifconfig iwi0 |> |> iwi0: flags=8843 metric 0 mtu |> |> 1500 |> |> ether 00:13:ce:a1:e6:81 |> |> inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 |> |> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) |> |> status: associated |> |> ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid |> 00:19:cb:86:b3:84 |> |> authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 |> |> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 |> roam:rssi11g 7 |> |> roam:rate11g 5 protmode CTS roaming MANUAL |> |> # ifconfig iwi0 list scan |> |> SSID BSSID CHAN RATE S:N INT CAPS |> |> o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP |> |> xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA |> |> |> |> the network with SSID 'o2DSL_kJaR' is not im my |> |> /etc/wpa_supplicant.conf; |> |> |> |> how this is possible and how can I prevent this? |> |> |> | You must have a wildcard entry in your wpa_supplicant.conf file (i.e. |> | one w/o an ssid specified). |> |> Not necessarily. If you bring up a wlan interface and don't specify |> anything, it will automatically associate with the first open AP it |> finds. |> |> I don't know if it's to be considered a feature or a bug. I've been |> worried by this sometimes, but honestly not enough to really care.. |> |> Anyway, it happens... |> | | He was talking about wpa_supplicant selecting an arbitrary AP. If you | have a device marked up then the system will handle ap selection+join | but if wpa_supplicant is running then it marks the interface in "manual | roaming mode" which stops that behaviour. What if you bring up a device with "WPA" in its rc.conf ifconfig line? | | Sam | - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAki+3EUACgkQwMJqmJVx944m6QCeK9yPcIjjHKx1b3sFDy0feHQd KCEAoJmUx9VEuKL/e+y69auTLhe8sei2 =TH4n -----END PGP SIGNATURE----- From guru at unixarea.de Wed Sep 3 19:04:58 2008 From: guru at unixarea.de (Matthias Apitz) Date: Wed Sep 3 19:05:29 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <48BEA791.6030406@freebsd.org> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> Message-ID: <20080903190032.GA2372@rebelion.Sisis.de> El d?a Wednesday, September 03, 2008 a las 08:04:49AM -0700, Sam Leffler escribi?: > Matthias Apitz wrote: > >Hello, > > > >I'm using WPA to connect to my various Wifi AP's (office, home, partner > >locations) and have them well configured in the wpa_supplicant.conf(5) > >file; > > > >from time to time at home I encounter that it is associating with an > >unknown AP of my neighbourhood: > > > > > ># ifconfig iwi0 > >iwi0: flags=8843 metric 0 mtu 1500 > > ether 00:13:ce:a1:e6:81 > > inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 > > media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > > status: associated > > ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 > > authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 > > scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 > > roam:rate11g 5 protmode CTS roaming MANUAL > ># ifconfig iwi0 list scan > >SSID BSSID CHAN RATE S:N INT CAPS > >o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP > >xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA > > > >the network with SSID 'o2DSL_kJaR' is not im my > >/etc/wpa_supplicant.conf; > > > >how this is possible and how can I prevent this? > > > You must have a wildcard entry in your wpa_supplicant.conf file (i.e. > one w/o an ssid specified). Thx for the idea, but I don't have any wildcard entry; I've checked the conf file and also wpa_cli says: > list_networks network id / ssid / bssid / flags 0 santaclara any 1 tarara any [CURRENT] 2 OCLCPICAUK any 3 board_room any 4 guagua any 5 OCN-LAN any 6 ConnectionPoint any and: # fgrep network= /etc/wpa_supplicant.conf | wc -l 7 # fgrep ssid=\" /etc/wpa_supplicant.conf ssid="santaclara" ssid="tarara" ssid="OCLCPICAUK" ssid="board_room" ssid="guagua" ssid="OCN-LAN" ssid="ConnectionPoint" matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. From sam at freebsd.org Wed Sep 3 19:37:31 2008 From: sam at freebsd.org (Sam Leffler) Date: Wed Sep 3 19:37:53 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <20080903190032.GA2372@rebelion.Sisis.de> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> <20080903190032.GA2372@rebelion.Sisis.de> Message-ID: <48BEE778.4000503@freebsd.org> Matthias Apitz wrote: > El d?a Wednesday, September 03, 2008 a las 08:04:49AM -0700, Sam Leffler escribi?: > > >> Matthias Apitz wrote: >> >>> Hello, >>> >>> I'm using WPA to connect to my various Wifi AP's (office, home, partner >>> locations) and have them well configured in the wpa_supplicant.conf(5) >>> file; >>> >>> >> >from time to time at home I encounter that it is associating with an >> >>> unknown AP of my neighbourhood: >>> >>> >>> # ifconfig iwi0 >>> iwi0: flags=8843 metric 0 mtu 1500 >>> ether 00:13:ce:a1:e6:81 >>> inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 >>> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) >>> status: associated >>> ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 >>> authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 >>> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 >>> roam:rate11g 5 protmode CTS roaming MANUAL >>> # ifconfig iwi0 list scan >>> SSID BSSID CHAN RATE S:N INT CAPS >>> o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP >>> xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA >>> >>> the network with SSID 'o2DSL_kJaR' is not im my >>> /etc/wpa_supplicant.conf; >>> >>> how this is possible and how can I prevent this? >>> >>> >> You must have a wildcard entry in your wpa_supplicant.conf file (i.e. >> one w/o an ssid specified). >> > > Thx for the idea, but I don't have any wildcard entry; I've checked the > conf file and also wpa_cli says: > > >> list_networks >> > network id / ssid / bssid / flags > 0 santaclara any > 1 tarara any [CURRENT] > 2 OCLCPICAUK any > 3 board_room any > 4 guagua any > 5 OCN-LAN any > 6 ConnectionPoint any > > and: > > # fgrep network= /etc/wpa_supplicant.conf | wc -l > 7 > # fgrep ssid=\" /etc/wpa_supplicant.conf > ssid="santaclara" > ssid="tarara" > ssid="OCLCPICAUK" > ssid="board_room" > ssid="guagua" > ssid="OCN-LAN" > ssid="ConnectionPoint" > > So far as I know this should not happen. It'd be useful to have a wpa_supplicant log that shows it associating to an ssid not listed in the config file. Sam From roland at micite.net Wed Sep 3 21:00:19 2008 From: roland at micite.net (Roland van Laar) Date: Wed Sep 3 21:00:26 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <48BEE778.4000503@freebsd.org> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> <20080903190032.GA2372@rebelion.Sisis.de> <48BEE778.4000503@freebsd.org> Message-ID: <20080903203306.GE33677@yttrium.micite.net> On Wed, Sep 03, 2008 at 12:37:28PM -0700, Sam Leffler wrote: > Matthias Apitz wrote: > >El d?a Wednesday, September 03, 2008 a las 08:04:49AM -0700, Sam Leffler > >escribi?: > > > > > >>Matthias Apitz wrote: > >> > >>>Hello, > >>> > >>>I'm using WPA to connect to my various Wifi AP's (office, home, partner > >>>locations) and have them well configured in the wpa_supplicant.conf(5) > >>>file; > >>> > >>> > >>>from time to time at home I encounter that it is associating with an > >> > >>>unknown AP of my neighbourhood: > >>> > >>> > >>># ifconfig iwi0 > >>>iwi0: flags=8843 metric 0 mtu > >>>1500 > >>> ether 00:13:ce:a1:e6:81 > >>> inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 > >>> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) > >>> status: associated > >>> ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 > >>> authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 > >>> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 > >>> roam:rate11g 5 protmode CTS roaming MANUAL > >>># ifconfig iwi0 list scan > >>>SSID BSSID CHAN RATE S:N INT CAPS > >>>o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP > >>>xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA > >>> > >>>the network with SSID 'o2DSL_kJaR' is not im my > >>>/etc/wpa_supplicant.conf; > >>> > >>>how this is possible and how can I prevent this? > >>> > >>> > >>You must have a wildcard entry in your wpa_supplicant.conf file (i.e. > >>one w/o an ssid specified). > >> > > > >Thx for the idea, but I don't have any wildcard entry; I've checked the > >conf file and also wpa_cli says: > > > > > >>list_networks > >> > >network id / ssid / bssid / flags > >0 santaclara any > >1 tarara any [CURRENT] > >2 OCLCPICAUK any > >3 board_room any > >4 guagua any > >5 OCN-LAN any > >6 ConnectionPoint any > > > >and: > > > ># fgrep network= /etc/wpa_supplicant.conf | wc -l > > 7 > ># fgrep ssid=\" /etc/wpa_supplicant.conf > > ssid="santaclara" > > ssid="tarara" > > ssid="OCLCPICAUK" > > ssid="board_room" > > ssid="guagua" > > ssid="OCN-LAN" > > ssid="ConnectionPoint" > > > > > So far as I know this should not happen. It'd be useful to have a > wpa_supplicant log that shows it associating to an ssid not listed in > the config file. > I encountered the same problem last week. I had a contrab which did an ifconfig ath0 down; ifconfig ath0 up This worked fine with WEP but wpa_supplicant exits when ath0 goes done. ath0 connects to the first open AP after it gets up again; not reconnecting to my WPA AP. Hope it helps, Roland van Laar From das at FreeBSD.ORG Wed Sep 3 21:40:02 2008 From: das at FreeBSD.ORG (David Schultz) Date: Wed Sep 3 21:40:08 2008 Subject: killing a kthread In-Reply-To: <96b2ec350809030516y2d6f26d1h3cd7eb39231c4da0@mail.gmail.com> References: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> <20080903095605.GB21178@alpha.local> <96b2ec350809030516y2d6f26d1h3cd7eb39231c4da0@mail.gmail.com> Message-ID: <20080903211459.GA60350@zim.MIT.EDU> On Wed, Sep 03, 2008, kr Lekha wrote: > I understand when thread finishes it should call kthread_exit(). > but if this thread was suspended before it finished, it might not be able to > call kthread_exit(). > > Due to which we still see the thread suspended. I am unable to kill it > even with killproc / psignal with in the kernel module. That's by design. Kernel threads can hold arbitrary kernel resources, and there's no mechanism to clean up after them automatically. They are expected to clean up after themselves and exit gracefully. In your case, you'll need to wake up the suspended thread and somehow notify it that you want it to terminate. From guru at unixarea.de Thu Sep 4 08:31:39 2008 From: guru at unixarea.de (Matthias Apitz) Date: Thu Sep 4 08:31:46 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <20080903203306.GE33677@yttrium.micite.net> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> <20080903190032.GA2372@rebelion.Sisis.de> <48BEE778.4000503@freebsd.org> <20080903203306.GE33677@yttrium.micite.net> Message-ID: <20080904083134.GA3606@rebelion.Sisis.de> El d?a Wednesday, September 03, 2008 a las 10:33:06PM +0200, Roland van Laar escribi?: > I encountered the same problem last week. I had a contrab which did an > ifconfig ath0 down; ifconfig ath0 up > This worked fine with WEP but wpa_supplicant exits when ath0 goes done. > ath0 connects to the first open AP after it gets up again; not reconnecting > to my WPA AP. In my case wpa_supplicant always was running; it is launched by /etc/rc.conf as: ifconfig_iwi0="WPA" at home where I have this problem the association is WEP based; >From time to time my AP seems to get stuck and in this case wpa_supplicant seems picking up the wrong foreign AP; it triggers even on LINK_UP via the devd(8) my script which I have to assign IP or do DHCP according the AP-location, which of course does not know this foreign AP and does nothing, but I see it in the log: Wed Sep 3 07:07:49 CEST 2008: /usr/local/etc/devd/iwi.sh iwi0 LINK_UP AP [00:19:cb:86:b3:84] not known in /usr/local/etc/devd/iwi.sh I will try to collect a debug-log of wpa_supplicant for such a situation; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. From nolis71cu at gmail.com Thu Sep 4 10:15:49 2008 From: nolis71cu at gmail.com (Manolo Valdes) Date: Thu Sep 4 10:16:01 2008 Subject: upgrade GDB-6.1.1 on the base System Message-ID: <200809040028.40979.nolis71cu@gmail.com> Hi Hackers reading a thread from this very list i solve my problem trying to debug user- land programs. the problem was gdb-6.1.1 , and the thread point me to use gdb-6.6 and all my pains went away. so my question is: will be GDB upgraded in the base system? or the buggy gdb-6.1.1 still be around? best regards Manolito From gabor at kovesdan.org Thu Sep 4 11:11:32 2008 From: gabor at kovesdan.org (Gabor Kovesdan) Date: Thu Sep 4 11:28:01 2008 Subject: CFT: BSD grep In-Reply-To: <20080827013221.GA82176@nagual.pp.ru> References: <48B44A7D.3070108@kovesdan.org> <20080827013221.GA82176@nagual.pp.ru> Message-ID: <48BFC257.2010000@kovesdan.org> Andrey Chernov ha scritto: > Just from quick looking at the sources... > > This code looks suspicious: > > wend = sscanf(&l->dat[pmatch.rm_eo], "%lc", &wend); > > Perhaps it should be > > if (sscanf(&l->dat[pmatch.rm_eo], "%lc", &wend) != 1) > r = REG_NOMATCH; > > The next thing is that perhaps each r = REG_NOMATCH; case should be > isolated from others in this block (with "else if"?) > F.e. failing mbstowcs() can leave buffer for sscanf() in junk. > > wbegin = grep_malloc(mbstowcs(NULL, l->dat, pmatch.rm_so)); > > grep_malloc() here could terminate program for invalid mbstowcs() > sequence, but really must set only r = REG_NOMATCH; > > Think about files which, for various reasons, may contain not only valid > MB sequences. > > fgrepcomp() uses toupper()/tolower() while should use wide chars analogs > (MB chars can be in the pattern too). There are also many other places > where pattern treated as single chars one, fastcomp() etc. grep_cmp() > compares single chars toupper(data[]) too. There must be no plain ctype > usage in the whole data _and_ pattern handling code. > Hello Andrey, thanks for the detailed description of the current deficiencies, I'll fix them soon. I've been busy with moving to another flat, that's why I haven't replied yet, sorry for that. G?bor From marc.loerner at hob.de Thu Sep 4 12:19:08 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Thu Sep 4 12:19:14 2008 Subject: question on asymmetric mtx_[un]lock_sleep Message-ID: <200809041400.04575.marc.loerner@hob.de> Hello, I just read through the code of mutexes and turnstiles and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep are some kind of asymmetric when turning SMP and adaptive mutexes on in kernel-configuration. On locking the mutex, we try to "quick" obtain the lock. If we can't do this, we look, whether some other thread, that's running, holds the lock and spin until either lock is freed or thread is not running anymore. In that case we try again to obtain the lock "quick". If the thread only stopped running but still holds the lock, we use turnstiles to wake us up, when the thread unlocks the mutex. => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! But if we're spinning and the other thread gave the mutex free, we quick-lock the mutex and don't set up a turnstile. Now on mtx_unlock_sleep: - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. => if turnstile_lookup return NULL we only released the lock quick. - But now, it's never tested if turnstile exists instead we broadcast/wakeup all threads pending on the turnstile. If this turnstile is NULL => we access wrong memory. Now my question is: Why can we be sure (in new source) that turnstile_lookup always returns a valid pointer to an turnstile and can use returned pointer to call turnstile_broadcast? Am I missing something? Because it seems that following scenario may occur: - on locking same scenario as above (=> thread1 now holds the lock) - thread1 is put off the runqueue - thread2 now tries to quick unlock mutex and sees that thread1 holds it => call to mtx_unlock_sleep - now we try to use turnstile-mechanism and call turnstile_lookup => returns NULL because no thread waits for wakeup => we call turnstile_broadcast and crash. Regards, Marc Loerner From jeremie at le-hen.org Thu Sep 4 13:14:04 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu Sep 4 13:14:12 2008 Subject: Creation of the NO_SSP build knob Message-ID: <20080904124653.GK72107@obiwan.tataz.chchile.org> Hello, There is currently a knob to enable/disable SSP: WITH_SSP or WITHOUT_SSP. WITH_SSP is the default on -CURRENT, so no one had to put WITH_SSP= in src.conf(5). This has hidden the following bug so far: When buildworld is run with WITH_SSP= on command-line or in src.conf(5), it fails immediately with the following message, because the toolchain is built with WITHOUT_SSP: % "/usr/src/share/mk/bsd.own.mk", line 365: WITH_SSP and WITHOUT_SSP can't both be set. My leaning is to create an additional knob NO_SSP, much like NO_CPU_CFLAGS, that could be set internally. However I'm not sure it complies with the src.conf(5) policy. Any objection to the patch below? Thank you! Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: NO_SSP.diff Type: text/x-diff Size: 11165 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080904/694d267d/NO_SSP.bin From rpaulo at FreeBSD.org Thu Sep 4 13:52:58 2008 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Sep 4 13:53:05 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080904124653.GK72107@obiwan.tataz.chchile.org> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> Message-ID: <20080904135200.GC31289@alpha.local> On Thu, Sep 04, 2008 at 02:46:53PM +0200, Jeremie Le Hen wrote: > Hello, > > There is currently a knob to enable/disable SSP: WITH_SSP or > WITHOUT_SSP. WITH_SSP is the default on -CURRENT, so no one had to put > WITH_SSP= in src.conf(5). This has hidden the following bug so far: > > When buildworld is run with WITH_SSP= on command-line or in src.conf(5), > it fails immediately with the following message, because the toolchain > is built with WITHOUT_SSP: > > % "/usr/src/share/mk/bsd.own.mk", line 365: WITH_SSP and WITHOUT_SSP can't both be set. > > My leaning is to create an additional knob NO_SSP, much like > NO_CPU_CFLAGS, that could be set internally. However I'm not sure it > complies with the src.conf(5) policy. Any objection to the patch below? We already have something like that. WITHOUT_SENDMAIL= is expanded to MK_SENDMAIL=no. You may want to do the same for SSP and keep the convention of the variable names. From des at des.no Thu Sep 4 13:57:21 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Sep 4 13:58:24 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080904135200.GC31289@alpha.local> (Rui Paulo's message of "Thu, 4 Sep 2008 14:52:00 +0100") References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> Message-ID: <86ljy857zz.fsf@ds4.des.no> Rui Paulo writes: > Jeremie Le Hen writes: > > My leaning is to create an additional knob NO_SSP, much like > > NO_CPU_CFLAGS, that could be set internally. However I'm not sure it > > complies with the src.conf(5) policy. Any objection to the patch below? > We already have something like that. > WITHOUT_SENDMAIL= is expanded to MK_SENDMAIL=no. > > You may want to do the same for SSP and keep the convention of the > variable names. It already exists. Read share/mk/bsd.own.mk. DES -- Dag-Erling Sm?rgrav - des@des.no From jeremie at le-hen.org Thu Sep 4 14:24:35 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu Sep 4 14:24:42 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <86ljy857zz.fsf@ds4.des.no> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> Message-ID: <20080904141705.GL72107@obiwan.tataz.chchile.org> On Thu, Sep 04, 2008 at 03:57:20PM +0200, Dag-Erling Sm?rgrav wrote: > Rui Paulo writes: > > Jeremie Le Hen writes: > > > My leaning is to create an additional knob NO_SSP, much like > > > NO_CPU_CFLAGS, that could be set internally. However I'm not sure it > > > complies with the src.conf(5) policy. Any objection to the patch below? > > We already have something like that. > > WITHOUT_SENDMAIL= is expanded to MK_SENDMAIL=no. > > > > You may want to do the same for SSP and keep the convention of the > > variable names. > > It already exists. Read share/mk/bsd.own.mk. I think I didn't explain the problem correctly, sorry. We indeed already have WITH_SSP/WITHOUT_SSP knob which is turned into MK_SSP="yes" or MK_SSP="no" respectively. The actual problem lies in Makefiles that define WITHOUT_SSP for some reason. For instance, in Makefile.inc1 the toolchain (namely bootstrap-tools, build-tools, cross-tools and a few other things) is built without SSP thanks to -DWITHOUT_SSP. For example: 224 BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \ 225 ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ 226 DESTDIR= \ 227 BOOTSTRAPPING=${OSRELDATE} \ 228 -DWITHOUT_SSP \ 229 -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ 230 -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED \ 231 -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF There is a problem is the user defines WITH_SSP in src.conf or on command-line. In this case, bsd.own.mk screams because both WITH_SSP and WITHOUT_SSP are defined. Try to make buildworld with -DWITH_SSP, and it won't even fill your terminal before breaking :). That's why my proposition was to introduce NO_SSP, that could be used from those Makefiles instead of WITHOUT_SSP to work around the bsd.own.mk checks. But there may be a wiser or neater solution I can't devise by myself, that's why I'm asking. Thanks for your help. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From des at des.no Thu Sep 4 14:48:29 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Sep 4 14:48:36 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080904141705.GL72107@obiwan.tataz.chchile.org> (Jeremie Le Hen's message of "Thu, 4 Sep 2008 16:17:05 +0200") References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> Message-ID: <86hc8w55mr.fsf@ds4.des.no> Jeremie Le Hen writes: > There is a problem is the user defines WITH_SSP in src.conf or on > command-line. In this case, bsd.own.mk screams because both WITH_SSP > and WITHOUT_SSP are defined. Try to make buildworld with -DWITH_SSP, > and it won't even fill your terminal before breaking :). bsd.own.mk: 184 # 185 # Supported NO_* options (if defined, MK_* will be forced to "no", 186 # regardless of user's setting). 187 # 188 .for var in \ 189 INSTALLLIB \ 190 MAN \ 191 PROFILE 192 .if defined(NO_${var}) 193 WITHOUT_${var}= 194 .endif 195 .endfor DES -- Dag-Erling Sm?rgrav - des@des.no From jeremie at le-hen.org Thu Sep 4 15:49:04 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu Sep 4 15:49:11 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <86hc8w55mr.fsf@ds4.des.no> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> Message-ID: <20080904154138.GM72107@obiwan.tataz.chchile.org> On Thu, Sep 04, 2008 at 04:48:28PM +0200, Dag-Erling Sm?rgrav wrote: > bsd.own.mk: > > 184 # > 185 # Supported NO_* options (if defined, MK_* will be forced to "no", > 186 # regardless of user's setting). > 187 # > 188 .for var in \ > 189 INSTALLLIB \ > 190 MAN \ > 191 PROFILE > 192 .if defined(NO_${var}) > 193 WITHOUT_${var}= > 194 .endif > 195 .endfor Ok, thank you Dag-Erling. I didn't understand what you meant the first time. If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP. But it will still not be possible to use WITH_SSP in src.conf or command-line. Does this mean that enforcing the default values with knobs is not supported? Or put differently, is it forbidden to use the opposite knobs of those documented in src.conf(5)? bsd.own.mk has the following test: 361 .if defined(WITH_${var}) && defined(WITHOUT_${var}) 362 .error WITH_${var} and WITHOUT_${var} can't both be set. 363 .endif So I would say that it is allowed to use WITH_SSP, even if it's the default. This can be a problem. Let's say a user has WITH_INFO= in src.conf for some reason. If WITHOUT_INFO= is used somewhere in the source tree, it will break with an error misleading for the user: WITH_INFO and WITHOUT_INFO can't be both set. Shouldn't we have a knob that overrides whatever the user says, only for internal use in the source tree? That was my original intent when asking if I could add NO_SSP. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From sam at freebsd.org Thu Sep 4 15:53:25 2008 From: sam at freebsd.org (Sam Leffler) Date: Thu Sep 4 15:53:32 2008 Subject: WPA && associating with unknown SSID In-Reply-To: <20080903203306.GE33677@yttrium.micite.net> References: <20080903113131.GA8697@rebelion.Sisis.de> <48BEA791.6030406@freebsd.org> <20080903190032.GA2372@rebelion.Sisis.de> <48BEE778.4000503@freebsd.org> <20080903203306.GE33677@yttrium.micite.net> Message-ID: <48C00473.8070908@freebsd.org> Roland van Laar wrote: > On Wed, Sep 03, 2008 at 12:37:28PM -0700, Sam Leffler wrote: > >> Matthias Apitz wrote: >> >>> El d?a Wednesday, September 03, 2008 a las 08:04:49AM -0700, Sam Leffler >>> escribi?: >>> >>> >>> >>>> Matthias Apitz wrote: >>>> >>>> >>>>> Hello, >>>>> >>>>> I'm using WPA to connect to my various Wifi AP's (office, home, partner >>>>> locations) and have them well configured in the wpa_supplicant.conf(5) >>>>> file; >>>>> >>>>> >>>>> >>>> >from time to time at home I encounter that it is associating with an >>>> >>>> >>>>> unknown AP of my neighbourhood: >>>>> >>>>> >>>>> # ifconfig iwi0 >>>>> iwi0: flags=8843 metric 0 mtu >>>>> 1500 >>>>> ether 00:13:ce:a1:e6:81 >>>>> inet 192.168.2.3 netmask 0xffffff00 broadcast 192.168.2.255 >>>>> media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) >>>>> status: associated >>>>> ssid o2DSL_kJaR channel 1 (2412 Mhz 11g) bssid 00:19:cb:86:b3:84 >>>>> authmode OPEN privacy ON deftxkey 1 wepkey 1:40-bit bmiss 10 >>>>> scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 >>>>> roam:rate11g 5 protmode CTS roaming MANUAL >>>>> # ifconfig iwi0 list scan >>>>> SSID BSSID CHAN RATE S:N INT CAPS >>>>> o2DSL_kJaR 00:19:cb:86:b3:84 1 54M 19:0 100 EP >>>>> xxxxxxxxxxxx 00:14:6c:44:aa:f6 11 54M 13:0 100 EP WPA >>>>> >>>>> the network with SSID 'o2DSL_kJaR' is not im my >>>>> /etc/wpa_supplicant.conf; >>>>> >>>>> how this is possible and how can I prevent this? >>>>> >>>>> >>>>> >>>> You must have a wildcard entry in your wpa_supplicant.conf file (i.e. >>>> one w/o an ssid specified). >>>> >>>> >>> Thx for the idea, but I don't have any wildcard entry; I've checked the >>> conf file and also wpa_cli says: >>> >>> >>> >>>> list_networks >>>> >>>> >>> network id / ssid / bssid / flags >>> 0 santaclara any >>> 1 tarara any [CURRENT] >>> 2 OCLCPICAUK any >>> 3 board_room any >>> 4 guagua any >>> 5 OCN-LAN any >>> 6 ConnectionPoint any >>> >>> and: >>> >>> # fgrep network= /etc/wpa_supplicant.conf | wc -l >>> 7 >>> # fgrep ssid=\" /etc/wpa_supplicant.conf >>> ssid="santaclara" >>> ssid="tarara" >>> ssid="OCLCPICAUK" >>> ssid="board_room" >>> ssid="guagua" >>> ssid="OCN-LAN" >>> ssid="ConnectionPoint" >>> >>> >>> >> So far as I know this should not happen. It'd be useful to have a >> wpa_supplicant log that shows it associating to an ssid not listed in >> the config file. >> >> > > I encountered the same problem last week. I had a contrab which did an > ifconfig ath0 down; ifconfig ath0 up > This worked fine with WEP but wpa_supplicant exits when ath0 goes done. > ath0 connects to the first open AP after it gets up again; not reconnecting > to my WPA AP. > > I believe this is how things work; wpa_supplicant is launched only when the device is discovered (e.g. at boot or card insert) and not when marked up. You need to do something like /etc/rc.d/netif start ath0 to bring the interface up. Not sure if this can be handled more transparently (e.g. via devd). Sam From des at des.no Thu Sep 4 19:26:31 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Sep 4 19:26:38 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080904154138.GM72107@obiwan.tataz.chchile.org> (Jeremie Le Hen's message of "Thu, 4 Sep 2008 17:41:38 +0200") References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> Message-ID: <8663pbzp97.fsf@ds4.des.no> Jeremie Le Hen writes: > If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP. > But it will still not be possible to use WITH_SSP in src.conf or > command-line. > [...] > Shouldn't we have a knob that overrides whatever the user says, only for > internal use in the source tree? That was my original intent when > asking if I could add NO_SSP. That's *exactly* what NO_* does. Just add SSP to that list and replace WITHOUT_SSP with NO_SSP wherever it occurs in Makefiles in the tree. DES -- Dag-Erling Sm?rgrav - des@des.no From jeremie at le-hen.org Fri Sep 5 07:07:54 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Sep 5 07:08:02 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <8663pbzp97.fsf@ds4.des.no> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> Message-ID: <20080905070028.GN72107@obiwan.tataz.chchile.org> Dag-Erling, On Thu, Sep 04, 2008 at 09:26:28PM +0200, Dag-Erling Sm?rgrav wrote: > Jeremie Le Hen writes: > > If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP. > > But it will still not be possible to use WITH_SSP in src.conf or > > command-line. > > [...] > > Shouldn't we have a knob that overrides whatever the user says, only for > > internal use in the source tree? That was my original intent when > > asking if I could add NO_SSP. > > That's *exactly* what NO_* does. Just add SSP to that list and replace > WITHOUT_SSP with NO_SSP wherever it occurs in Makefiles in the tree. I've just tested it with NO_SSP and I can confirm it doesn't work despite the explicit comment above stating otherwise. By the way, the code is nearly identical between the supported options and the compat ones, I don't see how it could override the user settings: 186 # 187 # Supported NO_* options (if defined, MK_* will be forced to "no", 188 # regardless of user's setting). 189 # 190 .for var in \ 191 INSTALLLIB \ 192 MAN \ 193 PROFILE \ 194 SSP 195 .if defined(NO_${var}) 196 WITHOUT_${var}= 197 .endif 198 .endfor 199 200 # 201 # Compat NO_* options (same as above, except their use is deprecated). 202 # 203 .if !defined(BURN_BRIDGES) 204 .for var in \ 205 ACPI \ [...] 267 WPA_SUPPLICANT_EAPOL 268 .if defined(NO_${var}) 269 #.warning NO_${var} is deprecated in favour of WITHOUT_${var}= 270 WITHOUT_${var}= 271 .endif 272 .endfor 273 .endif # !defined(BURN_BRIDGES) The attached patch implements a behaviour that seems more correct to me WRT the intent. What do you think of it? Thanks! -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: NO_FOO.diff Type: text/x-diff Size: 999 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080905/a1a93504/NO_FOO.bin From bra at fsn.hu Fri Sep 5 08:14:25 2008 From: bra at fsn.hu (Attila Nagy) Date: Fri Sep 5 08:14:33 2008 Subject: WITHOUT_CXX but with libstdc++ Message-ID: <48C0E634.70406@fsn.hu> Hello, I have some netbooted servers, which work off an NFS (master) server. Everything is built and installed on the master, so the netbooted "images" contain only what's really needed, so for example gcc is ripped out by WITHOUT_CPP=yes and WITHOUT_CXX=yes in the installworld phase. Unfortunately WITHOUT_CXX also disables the installation (given to installworld, of course if it's not built, it can't be installed) of libstdc++, which is needed for a lot of programs. Would it be possible to build CXX, but at installworld, install only the libraries (this is needed for runtime, so header files also won't be needed)? In src/gnu/lib/Makefile there is an MK_CXX test. With an OR MK_LIBCXX check (and defining WITH_LIBCXX as no by default) something similar could be done, with the limitation that at build time WITHOUT_CXX shouldn't be set and at install time, WITHOUT_CXX and WITH_LIBCXX should be yes. Any ideas about that (or a cleaner solution)? Thanks, From koitsu at FreeBSD.org Fri Sep 5 10:12:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 5 10:13:01 2008 Subject: Extending find(1) to support -printf Message-ID: <20080905101253.GA53396@icarus.home.lan> I've been working on $SUBJECT for the past few hours, and have managed to implement a very crude subset of GNU find's features: http://www.gnu.org/software/findutils/manual/html_node/find_html/Format-Directives.html#Format-Directives I've implemented %f and %p (which appear identical to GNU find), and some escaped characters. Things I need help with, as string parsing in C has never been my forte (which will become quite obvious): 1) Getting %h to behave like GNU find. The GNU find code is significantly different than ours. As it stands, %h is broken. 2) find . -printf '\' results in odd output (SHELL=/usr/local/bin/bash on my box). Not sure why this is happening, but it's a big concern. 3) Security issues. I believe use of a large number of formatting variables could exceed the calloc()'d buffer (of MAXPATHLEN), causing a segfault at bare minimum. I'm not sure how to work around this. Also, some folks on #bsdports asked why I was bothering with this in the first place: mutt supports backticks to run shell commands inside of a muttrc file. See "Building a list of mailboxes on the fly" below: http://wiki.mutt.org/?ConfigTricks Note the find ... -printf '%h ' method. I can accomplish (just about) the same using `echo $HOME/Maildir/*`, but if I want to exclude an entry, I can't use | grep -v, because mutt doesn't support pipes within backticks. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | diff -ruN find.orig/extern.h find/extern.h --- find.orig/extern.h 2006-05-14 13:23:00.000000000 -0700 +++ find/extern.h 2008-09-04 20:55:17.000000000 -0700 @@ -73,6 +73,7 @@ creat_f c_nouser; creat_f c_perm; creat_f c_print; +creat_f c_printf; creat_f c_regex; creat_f c_simple; creat_f c_size; @@ -107,6 +108,7 @@ exec_f f_perm; exec_f f_print; exec_f f_print0; +exec_f f_printf; exec_f f_prune; exec_f f_regex; exec_f f_size; diff -ruN find.orig/function.c find/function.c --- find.orig/function.c 2006-05-27 11:27:41.000000000 -0700 +++ find/function.c 2008-09-05 03:01:36.000000000 -0700 @@ -1272,6 +1272,86 @@ /* c_print0 is the same as c_print */ /* + * -printf functions -- + * + * Always true, manipulates output based on printf()-like + * formatting characters. + */ +int +f_printf(PLAN *plan, FTSENT *entry) +{ + char *scan; + char *outptr; + char *outidx; + + if ((outptr = calloc(MAXPATHLEN, 1)) == NULL) + err(1, NULL); + + outidx = outptr; + + for (scan = plan->c_data; *scan; scan++) { + if (*scan == '%') { + if (scan[1] == 0) { + errx(1, "missing format character"); + } + else if (scan[1] == '%') { + *outidx++ = '%'; + } + else if (scan[1] == 'f') { + strcpy(outidx, entry->fts_name); + outidx += entry->fts_namelen; + } + /* XXX - needs to behave like GNU find %h */ + /* + else if (scan[1] == 'h') { + strcpy(outidx, entry->fts_path); + outidx += entry->fts_pathlen; + } + */ + else if (scan[1] == 'p') { + strcpy(outidx, entry->fts_path); + outidx += entry->fts_pathlen; + } + scan++; + } + else if (*scan == '\\') { + if (scan[1] == '\\') { + *outidx++ = '\\'; + } + else if (scan[1] == 'n') { + *outidx++ = '\n'; + } + else if (scan[1] == 't') { + *outidx++ = '\t'; + } + scan++; + } + else { + *outidx++ = *scan; + } + } + + (void)printf(outptr); + free(outptr); + return 1; +} + +PLAN * +c_printf(OPTION *option, char ***argvp) +{ + char *argstring; + PLAN *new; + + argstring = nextarg(option, argvp); + ftsoptions &= ~FTS_NOSTAT; + isoutput = 1; + + new = palloc(option); + new->c_data = argstring; + return new; +} + +/* * -prune functions -- * * Prune a portion of the hierarchy. diff -ruN find.orig/option.c find/option.c --- find.orig/option.c 2006-04-05 16:06:11.000000000 -0700 +++ find/option.c 2008-09-04 20:48:18.000000000 -0700 @@ -128,6 +128,7 @@ { "-perm", c_perm, f_perm, 0 }, { "-print", c_print, f_print, 0 }, { "-print0", c_print, f_print0, 0 }, + { "-printf", c_printf, f_printf, 0 }, { "-prune", c_simple, f_prune, 0 }, { "-regex", c_regex, f_regex, 0 }, { "-size", c_size, f_size, 0 }, From xorquewasp at googlemail.com Fri Sep 5 12:30:16 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Sep 5 12:30:44 2008 Subject: upgrade GDB-6.1.1 on the base System In-Reply-To: <200809040028.40979.nolis71cu@gmail.com> References: <200809040028.40979.nolis71cu@gmail.com> Message-ID: <20080905115240.GA12137@logik.internal.network> On 20080904 00:28:40, Manolo Valdes wrote: > Hi Hackers > > reading a thread from this very list i solve my problem trying to debug user- > land programs. > > the problem was gdb-6.1.1 , and the thread point me to use gdb-6.6 > and all my pains went away. > > so my question is: > > will be GDB upgraded in the base system? or the buggy gdb-6.1.1 still be > around? > GDB 6.6 is in ports if you need a later version. I agree that the base gdb should be upgraded. On a related note, I've been using a manually compiled GDB 6.8 for Ada work on all my machines and haven't had any problems to date. xw From ticso at cicely7.cicely.de Fri Sep 5 14:17:55 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Fri Sep 5 14:18:12 2008 Subject: Obytes counter in netstat not incrementing In-Reply-To: References: <20080902154131.GH1089@bunrab.catwhisker.org> <20080902203809.GK1089@bunrab.catwhisker.org> Message-ID: <20080905141723.GI17711@cicely7.cicely.de> On Tue, Sep 02, 2008 at 05:22:10PM -0700, Charles Beckham wrote: > i've already made the changes to rc.conf, but since its a shared > machine and almost all addresses are in use, i'll have to schedule a > reboot before i can make changes effective, i will post a follwup > after i've made these changes. thanks for you assistance. Be carefull with the mask - the primary should match the network range. Just additional ones need to be /32. If you are using multiple network ranges then you need multiple primary ones. I'm not a friend of large aliases on Ethernet anyway, since it just creates large ARP tables and wastes addresses (broadcast, ...). What I normaly do is configuring additional addresses (not part of any LAN) on lo0. Then you just route those addresses to the host. Using LAN IPs is just a workaround when you can't route IPs or other special requirements exists. One of the special requirement might be that the clients are distributed on the same LAN, so you don't want to pass everything over a router. But the typical case for such a large number of addresses are internet services and in that case everything has to pass your router anyway. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From ru at FreeBSD.org Fri Sep 5 14:32:24 2008 From: ru at FreeBSD.org (Ruslan Ermilov) Date: Fri Sep 5 14:32:32 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080905070028.GN72107@obiwan.tataz.chchile.org> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> <20080905070028.GN72107@obiwan.tataz.chchile.org> Message-ID: <20080905140204.GA6498@edoofus.dev.vega.ru> On Fri, Sep 05, 2008 at 09:00:28AM +0200, Jeremie Le Hen wrote: > Dag-Erling, > > On Thu, Sep 04, 2008 at 09:26:28PM +0200, Dag-Erling Sm?rgrav wrote: > > Jeremie Le Hen writes: > > > If SSP belongs to this list, then NO_SSP is an alias for WITHOUT_SSP. > > > But it will still not be possible to use WITH_SSP in src.conf or > > > command-line. > > > [...] > > > Shouldn't we have a knob that overrides whatever the user says, only for > > > internal use in the source tree? That was my original intent when > > > asking if I could add NO_SSP. > > > > That's *exactly* what NO_* does. Just add SSP to that list and replace > > WITHOUT_SSP with NO_SSP wherever it occurs in Makefiles in the tree. > > I've just tested it with NO_SSP and I can confirm it doesn't work > despite the explicit comment above stating otherwise. By the way, the > code is nearly identical between the supported options and the compat > ones, I don't see how it could override the user settings: > This is not the way the things were designed to work. http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html WITH_*/WITHOUT_* are for users, and MK_* are for makefiles. NO_*'s are mainly for backwards compatibility and (to the lesser extent) to support some of the makefile buzzwords like NO_MAN. There's no possibility to easily make what you want, i.e., disable SSP for some parts of the tree. Doing it for particular makefiles OTOH should be pretty easy, by starting a makefile with the following two lines: .include MK_SSP=no bsd.own.mk will set MK_SSP as per default ("yes"), then possibly reset it to "no" if a user set WITHOUT_SSP (either on a command line, in /etc/make.conf, or in environment), and then the second line will unconditionally reset it to "no". This will work in the SSP case, but may not work in general because some options have dependencies. Fortunately, cases like this are rare. (There are several makefiles in the tree that already do this; "grep ^MK_" to see them.) Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From koitsu at FreeBSD.org Fri Sep 5 14:39:16 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 5 14:39:24 2008 Subject: Extending find(1) to support -printf In-Reply-To: <20080905101253.GA53396@icarus.home.lan> References: <20080905101253.GA53396@icarus.home.lan> Message-ID: <20080905143915.GA60002@icarus.home.lan> On Fri, Sep 05, 2008 at 03:12:53AM -0700, Jeremy Chadwick wrote: > Also, some folks on #bsdports asked why I was bothering with this in the > first place: mutt supports backticks to run shell commands inside of > a muttrc file. See "Building a list of mailboxes on the fly" below: > > http://wiki.mutt.org/?ConfigTricks > > Note the find ... -printf '%h ' method. I can accomplish (just > about) the same using `echo $HOME/Maildir/*`, but if I want to > exclude an entry, I can't use | grep -v, because mutt doesn't support > pipes within backticks. :-) Follow-up: mutt's backtick support does in fact respect pipes. My echo|grep -v was doing exactly what I requested: the grep -v was removing all output of the echo, since echo returned the results in a space-delimited format, not one per line. Hence, "mailboxes" was being executed without any arguments. Equally as frustrating, mutt's backtick support will only honour the first line of input. If a backticked command returns multiple lines, only the first is read; the rest are ignored. This makes using BSD find annoying, since find always outputs results terminated with a newline. One of my peers uses find | perl -ne 'chomp; print "=", $_, " "' to deal with this limit, which is quite disgusting. I realise there are workarounds for the dilemma (e.g. write a shell script that provides the exact output needed), but it seems like one could kill two birds with one stone by extending BSD find to support -printf, which does not output a newline unless \n is used within the output formatting. (This also explains why the Mutt Wiki entry uses -printf '%h ', note the space.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jonathan+freebsd-hackers at hst.org.za Fri Sep 5 16:42:03 2008 From: jonathan+freebsd-hackers at hst.org.za (Jonathan McKeown) Date: Fri Sep 5 16:42:12 2008 Subject: Extending find(1) to support -printf In-Reply-To: <20080905143915.GA60002@icarus.home.lan> References: <20080905101253.GA53396@icarus.home.lan> <20080905143915.GA60002@icarus.home.lan> Message-ID: <200809051846.09516.jonathan+freebsd-hackers@hst.org.za> On Friday 05 September 2008 16:39, Jeremy Chadwick wrote: > Equally as frustrating, mutt's backtick support will only honour the > first line of input. If a backticked command returns multiple lines, > only the first is read; the rest are ignored. This makes using BSD find > annoying, since find always outputs results terminated with a newline. > One of my peers uses find | perl -ne 'chomp; print "=", $_, " "' to deal > with this limit, which is quite disgusting. It is, especially when you consider find ... | xargs (or find ... -print0 | xargs -0 if your filenames might cause problems (embedded spaces etc)). Jonathan From jeremie at le-hen.org Fri Sep 5 18:24:02 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Fri Sep 5 18:24:10 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080905140204.GA6498@edoofus.dev.vega.ru> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> <20080905070028.GN72107@obiwan.tataz.chchile.org> <20080905140204.GA6498@edoofus.dev.vega.ru> Message-ID: <20080905181634.GC11644@obiwan.tataz.chchile.org> Hi Ruslan, On Fri, Sep 05, 2008 at 06:02:04PM +0400, Ruslan Ermilov wrote: > This is not the way the things were designed to work. > > http://lists.freebsd.org/pipermail/freebsd-current/2006-March/061725.html > > WITH_*/WITHOUT_* are for users, and MK_* are for makefiles. > > NO_*'s are mainly for backwards compatibility and (to the lesser > extent) to support some of the makefile buzzwords like NO_MAN. > > There's no possibility to easily make what you want, i.e., disable > SSP for some parts of the tree. Doing it for particular makefiles > OTOH should be pretty easy, by starting a makefile with the > following two lines: > > .include > MK_SSP=no > > bsd.own.mk will set MK_SSP as per default ("yes"), then possibly > reset it to "no" if a user set WITHOUT_SSP (either on a command > line, in /etc/make.conf, or in environment), and then the second > line will unconditionally reset it to "no". > > This will work in the SSP case, but may not work in general > because some options have dependencies. Fortunately, cases like > this are rare. (There are several makefiles in the tree that > already do this; "grep ^MK_" to see them.) Thank you for this clarification. Unfortunately, I can't use MK_SSP in Makefile.inc1. The only option I see is to override SSP_CFLAGS on ${BMAKE} and ${TMAKE} command-line. There is also a problem with some Makefile.inc containing NO_SSP. It's not possible to turn those to "MK_SSP= no" because bsd.init.mk includes ../Makefile.inc before bsd.own.mk. Would you agree with the attached patch? Or would you prefer to use SSP_CFLAGS everywhere? Thank you! -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: MK_SSP=no.diff Type: text/x-diff Size: 11575 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080905/ae6ae169/MK_SSPno.bin From is at rambler-co.ru Fri Sep 5 19:00:45 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Fri Sep 5 19:00:53 2008 Subject: opendir()/closedir() Message-ID: <20080905184032.GA71993@rambler-co.ru> Looking at opendir()/readdir()/closedir() sequence via ktrace, I've seen supposedly useless lseek() syscall just before close(). It's called from closedir(): _seekdir(dirp, dirp->dd_rewind); /* free seekdir storage */ It seems that free()ing libc seekdir storage should be done without calling lseek(). Other strange place for me is stat() before open() in opendir() /* * stat() before _open() because opening of special files may be * harmful. _fstat() after open because the file may have changed. */ What is the case when opening special file may be harmful ? -- Igor Sysoev http://sysoev.ru/en/ From kostikbel at gmail.com Fri Sep 5 19:48:52 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 5 19:48:59 2008 Subject: opendir()/closedir() In-Reply-To: <20080905184032.GA71993@rambler-co.ru> References: <20080905184032.GA71993@rambler-co.ru> Message-ID: <20080905194845.GV2038@deviant.kiev.zoral.com.ua> On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: > Looking at opendir()/readdir()/closedir() sequence via ktrace, > I've seen supposedly useless lseek() syscall just before close(). > It's called from closedir(): > > _seekdir(dirp, dirp->dd_rewind); /* free seekdir storage */ > > It seems that free()ing libc seekdir storage should be done without > calling lseek(). > > Other strange place for me is stat() before open() in opendir() > > /* > * stat() before _open() because opening of special files may be > * harmful. _fstat() after open because the file may have changed. > */ > > What is the case when opening special file may be harmful ? For instance, tape may be rewinded. The whole opendir/seekdir/telldir probably should be synced with OpenBSD version, at least due to SINGLEUSE. I made this conclusion when I merged the OpenBSD fix for seekdir several months ago. But I also decided then that I am not a volunteer. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080905/be1eff45/attachment.pgp From is at rambler-co.ru Fri Sep 5 20:42:21 2008 From: is at rambler-co.ru (Igor Sysoev) Date: Fri Sep 5 20:42:28 2008 Subject: opendir()/closedir() In-Reply-To: <20080905194845.GV2038@deviant.kiev.zoral.com.ua> References: <20080905184032.GA71993@rambler-co.ru> <20080905194845.GV2038@deviant.kiev.zoral.com.ua> Message-ID: <20080905204014.GB71993@rambler-co.ru> On Fri, Sep 05, 2008 at 10:48:45PM +0300, Kostik Belousov wrote: > On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: > > Looking at opendir()/readdir()/closedir() sequence via ktrace, > > I've seen supposedly useless lseek() syscall just before close(). > > It's called from closedir(): > > > > _seekdir(dirp, dirp->dd_rewind); /* free seekdir storage */ > > > > It seems that free()ing libc seekdir storage should be done without > > calling lseek(). > > > > Other strange place for me is stat() before open() in opendir() > > > > /* > > * stat() before _open() because opening of special files may be > > * harmful. _fstat() after open because the file may have changed. > > */ > > > > What is the case when opening special file may be harmful ? > > For instance, tape may be rewinded. > > The whole opendir/seekdir/telldir probably should be synced with OpenBSD > version, at least due to SINGLEUSE. I made this conclusion when I merged > the OpenBSD fix for seekdir several months ago. But I also decided then > that I am not a volunteer. BTW, OpenBSD does not worry about tapes :), they use open()/fstat() from the very start. And closedir() does not lseek() since OpenBSD 4.0. -- Igor Sysoev http://sysoev.ru/en/ From kostikbel at gmail.com Fri Sep 5 20:45:22 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 5 20:45:29 2008 Subject: opendir()/closedir() In-Reply-To: <20080905204014.GB71993@rambler-co.ru> References: <20080905184032.GA71993@rambler-co.ru> <20080905194845.GV2038@deviant.kiev.zoral.com.ua> <20080905204014.GB71993@rambler-co.ru> Message-ID: <20080905204458.GW2038@deviant.kiev.zoral.com.ua> On Sat, Sep 06, 2008 at 12:40:14AM +0400, Igor Sysoev wrote: > On Fri, Sep 05, 2008 at 10:48:45PM +0300, Kostik Belousov wrote: > > > On Fri, Sep 05, 2008 at 10:40:32PM +0400, Igor Sysoev wrote: > > > Looking at opendir()/readdir()/closedir() sequence via ktrace, > > > I've seen supposedly useless lseek() syscall just before close(). > > > It's called from closedir(): > > > > > > _seekdir(dirp, dirp->dd_rewind); /* free seekdir storage */ > > > > > > It seems that free()ing libc seekdir storage should be done without > > > calling lseek(). > > > > > > Other strange place for me is stat() before open() in opendir() > > > > > > /* > > > * stat() before _open() because opening of special files may be > > > * harmful. _fstat() after open because the file may have changed. > > > */ > > > > > > What is the case when opening special file may be harmful ? > > > > For instance, tape may be rewinded. > > > > The whole opendir/seekdir/telldir probably should be synced with OpenBSD > > version, at least due to SINGLEUSE. I made this conclusion when I merged > > the OpenBSD fix for seekdir several months ago. But I also decided then > > that I am not a volunteer. > > BTW, OpenBSD does not worry about tapes :), they use open()/fstat() from > the very start. And closedir() does not lseek() since OpenBSD 4.0. This was my point. They reworked the code, and it seems that rework brought in improvements, that are aligned with your observations. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080905/4ef68459/attachment.pgp From jpiccari at bblocked.org Sat Sep 6 03:12:02 2008 From: jpiccari at bblocked.org (Joshua Piccari) Date: Sat Sep 6 03:12:09 2008 Subject: Temp files in /etc Message-ID: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> Hi all, I am setting up a few jails and I want them all to use the same /etc files (with the exception of the files related to the password files and databases), so I mounted a shared /etc folder as a nullfs with read-only permissions. The problem is that using utilities like pw or chpass create temporary files in /etc and that file system is mounted read-only. So is there a way to force any utilities that create temp files in /etc to use another location, something like /usr/local/etc for example? ~Joshua From koitsu at FreeBSD.org Sat Sep 6 03:41:40 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Sep 6 03:41:47 2008 Subject: Temp files in /etc In-Reply-To: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> References: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> Message-ID: <20080906033135.GA73919@icarus.home.lan> On Fri, Sep 05, 2008 at 07:40:13PM -0700, Joshua Piccari wrote: > Hi all, > I am setting up a few jails and I want them all to use the same /etc files > (with the exception of the files related to the password files and > databases), so I mounted a shared /etc folder as a nullfs with read-only > permissions. The problem is that using utilities like pw or chpass create > temporary files in /etc and that file system is mounted read-only. > So is there a way to force any utilities that create temp files in /etc to > use another location, something like /usr/local/etc for example? It depends entirely on how each individual program makes temporary files; there is no "standard". libc offers a many different methods of creating temporary files: tmpfile(3), tmpnam(3), tempnam(3), mktemp(3), and mkstemp(3). You can read the manpages to get an idea of how chaotic the situation is. Other programs may implement their own temporary file creation methods entirely, and may/may not support TMPDIR. I would try export TMPDIR="/some/place" and then attempt using pw and chpass, and see what happens. If they still attempt to use /tmp, said programs could probably be modified to support TMPDIR. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Sat Sep 6 06:12:46 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Sep 6 06:12:52 2008 Subject: Temp files in /etc In-Reply-To: <20080906033135.GA73919@icarus.home.lan> References: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> <20080906033135.GA73919@icarus.home.lan> Message-ID: <20080906061243.GA77307@icarus.home.lan> On Fri, Sep 05, 2008 at 08:31:35PM -0700, Jeremy Chadwick wrote: > ... > If they still attempt to use /tmp, said programs could probably be > modified to support TMPDIR. This should have read /etc, not /tmp. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Sat Sep 6 06:31:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Sep 6 06:31:22 2008 Subject: Temp files in /etc In-Reply-To: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> References: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> Message-ID: <20080906063113.GB77307@icarus.home.lan> On Fri, Sep 05, 2008 at 07:40:13PM -0700, Joshua Piccari wrote: > Hi all, > I am setting up a few jails and I want them all to use the same /etc files > (with the exception of the files related to the password files and > databases), so I mounted a shared /etc folder as a nullfs with read-only > permissions. The problem is that using utilities like pw or chpass create > temporary files in /etc and that file system is mounted read-only. > So is there a way to force any utilities that create temp files in /etc to > use another location, something like /usr/local/etc for example? I've had a chat with another user off-list about this, and the conclusion reached is that your mounting of /etc read-only is a bad idea, for many different reasons. Let's step through things slowly, so that hopefully it'll make sense. Foremost, /etc is mounted read-only, so what purpose does it serve to be using passwd or group-editing utilities on that system? You'd need r/w access to be able to accomplish that. Secondly, utilities like vipw(8), chpass(1), pw(8), and many others all create temporary files in /etc for security reasons: the temporary files *must* be on the same filesystem. In your case, /etc is its own filesystem, mounted read-only. So, placing the temporary files (e.g. /etc/pw.XXXXXX when using vipw(8)) on a separate filesystem or separate location is not plausible. Regarding the security implications, others will have to chime in here. Thirdly, some (but not all) of the utilities support command-line flags that allow an alternative directory to /etc: pw(8) -V flag vipw(8) -d flag pwd_mkdb(8) -d flag chpass(1) no support passwd(1) no support rmuser(8) no support adduser(8) no support Fourthly, there are periodic(8) scripts which explicitly refer to /etc/master.passwd and do not support an alternative directory. Those scripts will break, and disabling them is not recommended. Finally, some other caveats/situations which will likely arise: - The administrator (you) will have to remember to use the above flags every time they use said utilities; chances are you'll forget, especially since the flags aren't all the same, - A user of your jail may become very surprised when they find passwd, group, or other files missing from /etc, - Third-party software which reads /etc/passwd or related files will fail since you'd be using an alternative /etc directory. I'm pretty sure we have some ports which use rmuser/adduser (meaning the software itself, not necessarily the port installation part). Hope this sheds some light on things. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jpiccari at bblocked.org Sat Sep 6 06:49:34 2008 From: jpiccari at bblocked.org (Joshua Piccari) Date: Sat Sep 6 06:49:41 2008 Subject: Temp files in /etc In-Reply-To: <20080906063113.GB77307@icarus.home.lan> References: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> <20080906063113.GB77307@icarus.home.lan> Message-ID: <15d3bc360809052349t4e90e719tf82c5002a2d9e2d@mail.gmail.com> On Fri, Sep 5, 2008 at 11:31 PM, Jeremy Chadwick wrote: > On Fri, Sep 05, 2008 at 07:40:13PM -0700, Joshua Piccari wrote: > > Hi all, > > I am setting up a few jails and I want them all to use the same /etc > files > > (with the exception of the files related to the password files and > > databases), so I mounted a shared /etc folder as a nullfs with read-only > > permissions. The problem is that using utilities like pw or chpass create > > temporary files in /etc and that file system is mounted read-only. > > So is there a way to force any utilities that create temp files in /etc > to > > use another location, something like /usr/local/etc for example? > > I've had a chat with another user off-list about this, and the > conclusion reached is that your mounting of /etc read-only is a bad > idea, for many different reasons. Let's step through things slowly, so > that hopefully it'll make sense. > > Foremost, /etc is mounted read-only, so what purpose does it serve to be > using passwd or group-editing utilities on that system? You'd need r/w > access to be able to accomplish that. > > Secondly, utilities like vipw(8), chpass(1), pw(8), and many others all > create temporary files in /etc for security reasons: the temporary files > *must* be on the same filesystem. In your case, /etc is its own > filesystem, mounted read-only. So, placing the temporary files (e.g. > /etc/pw.XXXXXX when using vipw(8)) on a separate filesystem or separate > location is not plausible. Regarding the security implications, others > will have to chime in here. > > Thirdly, some (but not all) of the utilities support command-line flags > that allow an alternative directory to /etc: > > pw(8) -V flag > vipw(8) -d flag > pwd_mkdb(8) -d flag > chpass(1) no support > passwd(1) no support > rmuser(8) no support > adduser(8) no support > > Fourthly, there are periodic(8) scripts which explicitly refer to > /etc/master.passwd and do not support an alternative directory. Those > scripts will break, and disabling them is not recommended. > > Finally, some other caveats/situations which will likely arise: > > - The administrator (you) will have to remember to use the above flags > every time they use said utilities; chances are you'll forget, > especially since the flags aren't all the same, > - A user of your jail may become very surprised when they find > passwd, group, or other files missing from /etc, > - Third-party software which reads /etc/passwd or related files will > fail since you'd be using an alternative /etc directory. I'm > pretty sure we have some ports which use rmuser/adduser (meaning > the software itself, not necessarily the port installation part). > > Hope this sheds some light on things. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Thanks so much Jeremy. You sure did give out lots of information. Unfortunately none that I can really use. Let me explain my situation a bit more. I have a shared /etc folder that is mounted read-only to the different jails that share it. Some of the configuration files which need to be dynamic from jail to jail are replaced with symbolic links to the jails /usr/local/etc folder. The reason for mount /etc as read-only is to ensure that none of the jails accidentally modify the configurations for all the jails sharing these configurations. However, there is an issue with creating temp files on a read-only system which means I will have to work around this somehow. I thought about setting the schg flag on all the files in the shared /etc folder but I don't want one jail to be able to add a rc.d script for every jail. Anyways, hope that helps clarify things. Also, is there a way to just move the password files/databases to /usr/local/etc instead, I vaguely remember something in one of the man pages about alternate passwd/master.passwd locations, probably the flags you noted above. I'll check that out more tomorrow after some good sleep. :) ~Joshua From ed at 80386.nl Sat Sep 6 08:10:41 2008 From: ed at 80386.nl (Ed Schouten) Date: Sat Sep 6 08:11:12 2008 Subject: Temp files in /etc In-Reply-To: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> References: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> Message-ID: <20080906074554.GB99951@hoeg.nl> * Joshua Piccari wrote: > Hi all, > I am setting up a few jails and I want them all to use the same /etc files > (with the exception of the files related to the password files and > databases), so I mounted a shared /etc folder as a nullfs with read-only > permissions. The problem is that using utilities like pw or chpass create > temporary files in /etc and that file system is mounted read-only. > So is there a way to force any utilities that create temp files in /etc to > use another location, something like /usr/local/etc for example? You could mount a unionfs on top. If the bottom mount is read-only, it will store modifications on the top mount. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080906/52026148/attachment.pgp From m.seaman at infracaninophile.co.uk Sat Sep 6 11:19:02 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Sat Sep 6 11:19:09 2008 Subject: Temp files in /etc In-Reply-To: <15d3bc360809052349t4e90e719tf82c5002a2d9e2d@mail.gmail.com> References: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> <20080906063113.GB77307@icarus.home.lan> <15d3bc360809052349t4e90e719tf82c5002a2d9e2d@mail.gmail.com> Message-ID: <48C2670A.9000808@infracaninophile.co.uk> Joshua Piccari wrote: > I have a shared /etc folder that is mounted read-only to the different jails > that share it. Some of the configuration files which need to be dynamic from > jail to jail are replaced with symbolic links to the jails /usr/local/etc > folder. The reason for mount /etc as read-only is to ensure that none of the > jails accidentally modify the configurations for all the jails sharing these > configurations. However, there is an issue with creating temp files on a > read-only system which means I will have to work around this somehow. I > thought about setting the schg flag on all the files in the shared /etc > folder but I don't want one jail to be able to add a rc.d script for every > jail. Can't you use a unionfs to achieve what you want? Abstract out all the common data to filesystem that you mount read-only, and then use unionfs to mount a per-jail read/write overlay on top of that? Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080906/d6f7b9ea/signature.pgp From subs at arpanet.ru Sat Sep 6 18:41:05 2008 From: subs at arpanet.ru (Alexander Sizov) Date: Sat Sep 6 18:41:15 2008 Subject: Possible bug (amd64/i386) Message-ID: <48C2CA14.1090304@arpanet.ru> Hello, world! I don't speak English, but try to explain what I got. Server #1 (p4, i386-7.0-RELEASE, GENERIC): ------------------------------------------------------------------------------- CUT Sep 5 00:34:38 test kernel: Waiting (max 60 seconds) for system process `vnlru' to stop...done Sep 5 00:34:38 test kernel: Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Sep 5 00:34:38 test kernel: Waiting (max 60 Sep 5 00:34:38 test kernel: seScyonncdisn)g fdoirs kssy,s tvenmo dperso creesmsa i`nsiynngc.e.r.' to3 stop...0 0 done Sep 5 00:34:38 test kernel: All buffers synced. ------------------------------------------------------------------------------- CUT Server #2 (core2quad, amd64-7.0-RELEASE, GENERIC): ... same picture ... , 6.* hasn't problems. dmesg server #1 (by 6.3): ------------------------------------------------------------------------------- CUT Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE-p3 #2: Tue Sep 2 16:48:58 MSD 2008 root@afina.arpanet.ru:/usr/obj/usr/src/sys/AFINA ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.12-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 Logical CPUs per core: 2 real memory = 3211657216 (3062 MB) avail memory = 3147747328 (3001 MB) ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 0.0 on pci1 pci2: on pcib2 amr0: mem 0xd0000000-0xd000ffff irq 24 at device 1.0 on pci2 amr0: delete logical drives supported by controller amr0: Firmware 713N, BIOS G119, 64MB RAM pci0: at device 2.0 (no driver attached) pcib3: irq 16 at device 28.0 on pci0 pci3: on pcib3 bge0: mem 0xd0300000-0xd030ffff irq 16 at device 0.0 on pci3 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:30:48:84:bc:7c pcib4: irq 17 at device 28.1 on pci0 pci4: on pcib4 bge1: mem 0xd0400000-0xd040ffff irq 17 at device 0.0 on pci4 miibus1: on bge1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:30:48:84:bc:7d uhci0: port 0xe100-0xe11f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe200-0xe21f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe300-0xe31f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xe400-0xe41f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd05c0000-0xd05c03ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pci5: on pcib5 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 3000121462 Hz quality 800 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging disabled acd0: CDROM at ata0-master UDMA33 amr0: delete logical drives supported by controller amrd0: on amr0 amrd0: 953870MB (1953525760 sectors) RAID 1 (optimal) hwpmc: TSC/1/0x20 P4/18/0xfff Trying to mount root from ufs:/dev/amrd0s1a bge0: link state changed to UP ------------------------------------------------------------------------------- CUT WBR! From asmodai at in-nomine.org Sat Sep 6 20:05:20 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Sat Sep 6 20:05:27 2008 Subject: Possible bug (amd64/i386) In-Reply-To: <48C2CA14.1090304@arpanet.ru> References: <48C2CA14.1090304@arpanet.ru> Message-ID: <20080906200516.GN34564@nexus.in-nomine.org> -On [20080906 20:41], Alexander Sizov (subs@arpanet.ru) wrote: >Sep 5 00:34:38 test kernel: seScyonncdisn)g fdoirs kssy,s tvenmo >dperso creesmsa i`nsiynngc.e.r.' to3 stop...0 0 done On my AMD64 box (using 32 bit FreeBSD due to the Nvidia drivers) my 7-STABLE is also showing this garbled text from time to time. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B I accept that some things will never change, I've let your tiny minds magnify my agony... From jimmy at mammothcheese.ca Sat Sep 6 20:58:27 2008 From: jimmy at mammothcheese.ca (James Bailie) Date: Sat Sep 6 20:58:34 2008 Subject: Possible bug (amd64/i386) In-Reply-To: <20080906200516.GN34564@nexus.in-nomine.org> References: <48C2CA14.1090304@arpanet.ru> <20080906200516.GN34564@nexus.in-nomine.org> Message-ID: <48C2E8B0.6090000@mammothcheese.ca> This is merely two processes writing to the console at the same time. Their output is being mixed together. Jeroen Ruigrok van der Werven wrote: > -On [20080906 20:41], Alexander Sizov (subs@arpanet.ru) wrote: >> Sep 5 00:34:38 test kernel: seScyonncdisn)g fdoirs kssy,s tvenmo >> dperso creesmsa i`nsiynngc.e.r.' to3 stop...0 0 done > > On my AMD64 box (using 32 bit FreeBSD due to the Nvidia drivers) my 7-STABLE > is also showing this garbled text from time to time. > -- James Bailie http://www.mammothcheese.ca From igor at hybrid-lab.co.uk Sat Sep 6 21:11:13 2008 From: igor at hybrid-lab.co.uk (Igor Mozolevsky) Date: Sat Sep 6 21:12:57 2008 Subject: Possible bug (amd64/i386) In-Reply-To: <20080906200516.GN34564@nexus.in-nomine.org> References: <48C2CA14.1090304@arpanet.ru> <20080906200516.GN34564@nexus.in-nomine.org> Message-ID: 2008/9/6 Jeroen Ruigrok van der Werven : > -On [20080906 20:41], Alexander Sizov (subs@arpanet.ru) wrote: >>Sep 5 00:34:38 test kernel: seScyonncdisn)g fdoirs kssy,s tvenmo >>dperso creesmsa i`nsiynngc.e.r.' to3 stop...0 0 done > > On my AMD64 box (using 32 bit FreeBSD due to the Nvidia drivers) my 7-STABLE > is also showing this garbled text from time to time. I get that too on various SMP boxes. -- Igor From lfrigault at agneau.org Sat Sep 6 22:21:56 2008 From: lfrigault at agneau.org (Laurent Frigault) Date: Sat Sep 6 22:22:04 2008 Subject: how to compute vm.pmap.pv_entry_count from procstat ? Message-ID: <20080906220448.GA78044@obelix.bergerie.agneau.org> Hi, On a 7.0-STABLE i386 web server, I got kernel messages reporting problems with PV entries: Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max tunable. This server (DELL poweredge R200 quad core 4G RAM) is having random hang every few weeks (need power off/on cycle, IPMI not responding any more with those hangs) , but I don't know if the hangs are related to a PV entries problem. Before increasing blindly vm.pmap.shpgperproc , I would like to evaluate a good value for vm.pmap.shpgperproc (default 200) because I remember reading somewhere that increasing too much shpgperproc could result in panic at boot time or later. If I guess correctly (I did not find any understandable by me documentation on vm.pmap.*) vm.pmap.pv_entry_count is the value of currently used PV entries . My idea was to use procstat -av output to compute some statistics about the number of PV entries needed by various kind of process (apache, ...) It should be possible to compute a good evaluation of vm.pmap.pv_entry_count by adding some combination of RES,PRES, SHD columns. When I add RES,PRES, SHD values, the result is bigger than pv_entry_count. What is the formula to retrieve pv_entry_count from procstat output or in other words, how to compute the number of PV entries used by a process ? Regards, -- Laurent Frigault | From rink at FreeBSD.org Sat Sep 6 23:17:17 2008 From: rink at FreeBSD.org (Rink Springer) Date: Sat Sep 6 23:17:24 2008 Subject: Possible bug (amd64/i386) In-Reply-To: References: <48C2CA14.1090304@arpanet.ru> <20080906200516.GN34564@nexus.in-nomine.org> Message-ID: <20080906231901.GA56244@rink.nu> On Sat, Sep 06, 2008 at 09:48:59PM +0100, Igor Mozolevsky wrote: > I get that too on various SMP boxes. This is a known issue - look at http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues (search for 'Scrambled or garbled kernel output') for more information. Regards, -- Rink P.W. Springer - http://rink.nu "Anyway boys, this is America. Just because you get more votes doesn't mean you win." - Fox Mulder From toyj at union.edu Sat Sep 6 23:46:33 2008 From: toyj at union.edu (jT) Date: Sat Sep 6 23:46:40 2008 Subject: 256-byte inode support Message-ID: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> hackers, since tytso had updated ext3 -- i've noticed that i can't use my 265-byte inode ext3 drives -- is there any effort to update it? If not -- if you know where i should attempt to start please let me know so i can start working on support (i have a few other people i know interested in this) -- thanks and hope everyone is well respectfully, /jT From wxs at FreeBSD.org Sun Sep 7 15:21:53 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Sun Sep 7 15:22:00 2008 Subject: 256-byte inode support In-Reply-To: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> Message-ID: <20080907150747.GB62357@atarininja.org> On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > hackers, > > since tytso had updated ext3 -- i've noticed that i can't use my > 265-byte inode ext3 drives -- is there any effort to update it? If > not -- if you know where i should attempt to start please let me know > so i can start working on support (i have a few other people i know > interested in this) -- thanks and hope everyone is well There was a PR submitted for it and eventually a patch added to the PR. I've tested the patch given in the URL at the port and it works. We will start to see more of this as the newer version becomes more common in the wild. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 Would be nice to see this fixed in 7.1 but it may be too late for that. -- WXS From chuckr at telenix.org Sun Sep 7 19:44:17 2008 From: chuckr at telenix.org (Chuck Robey) Date: Sun Sep 7 19:44:25 2008 Subject: keyboard questions Message-ID: <48C42EC5.9040201@telenix.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have gotten my project, which was to make an Xorg driver for my ultra-cheapy UC-Logic graphic tablet working to a great extent, including scaling the cursor movement both with and without the optional function key areas that rim the tablet area. So, my next job is to figure out how, on FreeBSD, should I configure and dispatch these things. They AREN'T to be limited, at all, to being function keys, I want them even to include the possibility of kicking off programs (or maybe shell scripts?). So, knowing absolutely zero about interfacing keyboards on FreeBSD, could I get a VERY minimal description, enough so that I could begin reading all of the man pages (and include files) involved, and get this last part going? Thanks -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjELsUACgkQz62J6PPcoOnOnQCfWE6Sr7x6gaN8C28HO5/a7tOP JCIAn2abiL5Q/whTM+bHCx3E0FWWpHF1 =JDfG -----END PGP SIGNATURE----- From darrenr at freebsd.org Mon Sep 8 08:30:59 2008 From: darrenr at freebsd.org (Darren Reed) Date: Mon Sep 8 08:31:05 2008 Subject: the future of sun4v In-Reply-To: <20080822201603.GA14444@alchemy.franken.de> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> Message-ID: <48C4DEEF.7070201@freebsd.org> Marius Strobl wrote: > On Fri, Aug 22, 2008 at 01:44:25PM +0200, Kris Kennaway wrote: > > Peter Jeremy wrote: > > >[Replies re-directed to freebsd-sun4v] > > > > > >On 2008-Aug-21 14:42:55 -0700, Kip Macy wrote: > > >>I believe that there is a general expectation by freebsd users and > > >>developers that unsupported code should not be in CVS. Although sun4v > > >>is a very interesting platform for developers doing SMP work, I simply > > >>do not have the time or energy to maintain it. If someone else would > > >>like to step up and try his hand I would be supportive of his efforts. > > >>In the likely event that no one steps forward by the time that 7.1 is > > >>released I will ask that it be moved to the Attic. > > > > > >Since there are no other current SPARC CPUs that FreeBSD can run on > > >(the US-II has been obsolete for about 6 years and FreeBSD won't run > > >on any more recent sun4u chips), that will also remove the > > >justification for maintaining a SPARC64 port. > > > > > >I don't have the knowledge or available time to maintain the sun4v > > >port by myself but would be happy to be part of a team doing so. One > > >impediment I have is that I don't have a T-1 or T-2 system that I can > > >dedicate to FreeBSD. I could work on FreeBSD in a guest domain - but > > >since FreeBSD doesn't support either the virtual disk or virtual > > >network, actually getting FreeBSD running there presents somewhat of a > > >challenge. > > > > > > > There are two t1000 systems in the freebsd.org cluster that are > > available for people to work on. Rink Springer has also expressed > > interest in this. > > > > Perhaps Kip can explain some more about what things he looked at, but > > the most serious bugs might be in pmap or perhaps trap handling. > > Operationally, things like buildworld -jN die quickly with random > > signals, kernel traps, etc. > > > > Kris > > > > P.S. It looks like marius has made progress on US III but sun4u is still > > an architectural dead end. > > Well, let's see what architecture the upcoming Rock CPUs are; > judging their feature list they appear to be a continuation of > the Fujitsu sun4u line rather than a successor of UST1/2 :) > That's inaccurate. Rock is meant to be very compatible with sun4v, although I don't know if uname will say "sun4v" or something else...but you will need a bug-free sun4v operating system to run them (which is to say that various bugs in the solaris sun4v support needed to get fixed rather than left...) The critical issue for freebsd (and any operating system for that matter) on rock is how well does the kernel scale to a system with that many concurrent threads? Darren From des at des.no Mon Sep 8 11:16:18 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 8 11:16:24 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <20080905140204.GA6498@edoofus.dev.vega.ru> (Ruslan Ermilov's message of "Fri, 5 Sep 2008 18:02:04 +0400") References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> <20080905070028.GN72107@obiwan.tataz.chchile.org> <20080905140204.GA6498@edoofus.dev.vega.ru> Message-ID: <86r67uevlr.fsf@ds4.des.no> Ruslan Ermilov writes: > There's no possibility to easily make what you want, i.e., disable > SSP for some parts of the tree. Doing it for particular makefiles > OTOH should be pretty easy, by starting a makefile with the > following two lines: That's not "what Jeremie wants", that's what the Makefiles already do. Parts of the tree *can't* be built with SSP enabled, and the Makefiles set WITHOUT_SSP to disable it. DES -- Dag-Erling Sm?rgrav - des@des.no From jeremie at le-hen.org Mon Sep 8 13:08:34 2008 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Mon Sep 8 13:08:41 2008 Subject: Creation of the NO_SSP build knob In-Reply-To: <86r67uevlr.fsf@ds4.des.no> References: <20080904124653.GK72107@obiwan.tataz.chchile.org> <20080904135200.GC31289@alpha.local> <86ljy857zz.fsf@ds4.des.no> <20080904141705.GL72107@obiwan.tataz.chchile.org> <86hc8w55mr.fsf@ds4.des.no> <20080904154138.GM72107@obiwan.tataz.chchile.org> <8663pbzp97.fsf@ds4.des.no> <20080905070028.GN72107@obiwan.tataz.chchile.org> <20080905140204.GA6498@edoofus.dev.vega.ru> <86r67uevlr.fsf@ds4.des.no> Message-ID: <20080908130059.GA55001@obiwan.tataz.chchile.org> Hello Dag-Erling, On Mon, Sep 08, 2008 at 01:16:16PM +0200, Dag-Erling Sm?rgrav wrote: > Ruslan Ermilov writes: > > There's no possibility to easily make what you want, i.e., disable > > SSP for some parts of the tree. Doing it for particular makefiles > > OTOH should be pretty easy, by starting a makefile with the > > following two lines: > > That's not "what Jeremie wants", that's what the Makefiles already do. > Parts of the tree *can't* be built with SSP enabled, and the Makefiles > set WITHOUT_SSP to disable it. That's what the Makefiles already do indeed. Please excuse me if my english wasn't good enough to express it correctly. You are right to say that parts of the tree can't be build with SSP enabled. IMHO, the problem lies in the way it's enforced: using WITH_SSP shouldn't lead to a build error. The patch I sent along my reply to Ruslan corrects this. By the way, I think WITH_*/WITHOUT_* options should be user-only options and shouldn't be used in the source tree. This would avoid this kind of problem. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From olli at lurza.secnetix.de Mon Sep 8 13:47:23 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 8 13:47:30 2008 Subject: Extending find(1) to support -printf In-Reply-To: <20080905143915.GA60002@icarus.home.lan> Message-ID: <200809081347.m88DlK8T074926@lurza.secnetix.de> Jeremy Chadwick wrote: > On Fri, Sep 05, 2008 at 03:12:53AM -0700, Jeremy Chadwick wrote: > > Also, some folks on #bsdports asked why I was bothering with this in the > > first place: mutt supports backticks to run shell commands inside of > > a muttrc file. See "Building a list of mailboxes on the fly" below: > > > > http://wiki.mutt.org/?ConfigTricks > > > > Note the find ... -printf '%h ' method. I can accomplish (just > > about) the same using `echo $HOME/Maildir/*`, but if I want to > > exclude an entry, I can't use | grep -v, because mutt doesn't support > > pipes within backticks. :-) > > Follow-up: > > mutt's backtick support does in fact respect pipes. My echo|grep -v was > doing exactly what I requested: the grep -v was removing all output of > the echo, since echo returned the results in a space-delimited format, > not one per line. Hence, "mailboxes" was being executed without any > arguments. > > Equally as frustrating, mutt's backtick support will only honour the > first line of input. If a backticked command returns multiple lines, > only the first is read; the rest are ignored. Well, you can convert back and forth between spaces and newlines with tr(1): echo * | tr ' ' '\n' | grep -v whatever | tr '\n' ' ' It's not pretty, but it should work. Note that ls(1) prints one file name per line, so you can simplify the above line like this: ls | grep -v whatever | tr '\n' ' ' By the way, I often use zsh in such cases. It supports "extended globbing", for example, the wildcard expression *~*.(gz|bz2) matches all files _except_ the ones that end with .gz or .bz2. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Perl is worse than Python because people wanted it worse. -- Larry Wall From olli at lurza.secnetix.de Mon Sep 8 15:49:36 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 8 15:49:43 2008 Subject: Temp files in /etc In-Reply-To: <15d3bc360809051940t70f0b884mb9a80132acc50b45@mail.gmail.com> Message-ID: <200809081549.m88FnTX9080209@lurza.secnetix.de> Joshua Piccari wrote: > I am setting up a few jails and I want them all to use the same /etc files > (with the exception of the files related to the password files and > databases), so I mounted a shared /etc folder as a nullfs with read-only > permissions. The problem is that using utilities like pw or chpass create > temporary files in /etc and that file system is mounted read-only. > So is there a way to force any utilities that create temp files in /etc to > use another location, something like /usr/local/etc for example? I had exactly the same problem. I wrote a small patch that solves it: http://www.secnetix.de/olli/FreeBSD/jail-passwd/ Please read the "instructions.txt" file first, then download the appropriate patch file. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd With Perl you can manipulate text, interact with programs, talk over networks, drive Web pages, perform arbitrary precision arithmetic, and write programs that look like Snoopy swearing. From danm at prime.gushi.org Mon Sep 8 17:55:54 2008 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Mon Sep 8 18:13:50 2008 Subject: IPFW uid logging... Message-ID: Hey all, I have the following rule set up in ipfw to limit the exposure of bad php scripts and trojans that try to send mail directly. allow tcp from any to any dst-port 25 uid root deny log tcp from any to any dst-port 25 out However, the log messages I get look like this: Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58131 209.85.133.27:25 out via em0 Sep 8 13:21:28 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:32 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58131 209.85.133.27:25 out via em0 Sep 8 13:22:45 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:45 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:46 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Sep 8 13:22:49 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:65313 64.202.166.12:25 out via em0 Which is to say, they don't include the UID -- and I have several hundred sites, each with its own UID. Yes, I could go ahead and set up a thousand "deny" rules, one for each UID -- but being able to log this info (since it IS being checked) would be great. Thoughts? -Dan Mahoney -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From dnelson at allantgroup.com Mon Sep 8 19:41:50 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Mon Sep 8 19:41:56 2008 Subject: IPFW uid logging... In-Reply-To: References: Message-ID: <20080908185106.GB6629@dan.emsphone.com> In the last episode (Sep 08), Dan Mahoney, System Admin said: > I have the following rule set up in ipfw to limit the exposure of bad > php scripts and trojans that try to send mail directly. > > allow tcp from any to any dst-port 25 uid root > deny log tcp from any to any dst-port 25 out > > However, the log messages I get look like this: > > Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 > Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 > > Which is to say, they don't include the UID -- and I have several hundred > sites, each with its own UID. > > Yes, I could go ahead and set up a thousand "deny" rules, one for > each UID -- but being able to log this info (since it IS being > checked) would be great. It should be possible to add a couple more arguments to ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of that struct if ugid_lookup==1. That would result in the logging of uid for any failed packet that had to go through a uid check on the way to the deny rule. -- Dan Nelson dnelson@allantgroup.com From peterjeremy at optushome.com.au Mon Sep 8 19:55:01 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Mon Sep 8 19:55:08 2008 Subject: the future of sun4v In-Reply-To: <48C4DEEF.7070201@freebsd.org> References: <3c1674c90808211442t707966fq29997b53a70ed2f7@mail.gmail.com> <20080822113317.GD32539@server.vk2pj.dyndns.org> <48AEA699.10903@FreeBSD.org> <20080822201603.GA14444@alchemy.franken.de> <48C4DEEF.7070201@freebsd.org> Message-ID: <20080908195457.GD15376@server.vk2pj.dyndns.org> [cc list trimmed] On 2008-Sep-08 01:14:39 -0700, Darren Reed wrote: >The critical issue for freebsd (and any operating system for >that matter) on rock is how well does the kernel scale to a >system with that many concurrent threads? Right now it doesn't. And based on some previous threads, there is a lot of redesign to do before it can. But stability needs to come before scalability. There's no point in FreeBSD pretending it can support some arbitrary number of CPUs when it panics due to races in one of the CPU subsystems - which is my understanding of the current sun4v state. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080908/de5ce14c/attachment.pgp From danm at prime.gushi.org Mon Sep 8 20:04:01 2008 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Mon Sep 8 20:17:02 2008 Subject: IPFW uid logging... In-Reply-To: <20080908185106.GB6629@dan.emsphone.com> References: <20080908185106.GB6629@dan.emsphone.com> Message-ID: On Mon, 8 Sep 2008, Dan Nelson wrote: > In the last episode (Sep 08), Dan Mahoney, System Admin said: >> I have the following rule set up in ipfw to limit the exposure of bad >> php scripts and trojans that try to send mail directly. >> >> allow tcp from any to any dst-port 25 uid root >> deny log tcp from any to any dst-port 25 out >> >> However, the log messages I get look like this: >> >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 >> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 >> >> Which is to say, they don't include the UID -- and I have several hundred >> sites, each with its own UID. >> >> Yes, I could go ahead and set up a thousand "deny" rules, one for >> each UID -- but being able to log this info (since it IS being >> checked) would be great. > > It should be possible to add a couple more arguments to ipfw_log() so > that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the > fw_ugid_cache struct. Then you can edit ipfw_log to print the contents > of that struct if ugid_lookup==1. That would result in the logging of > uid for any failed packet that had to go through a uid check on the way > to the deny rule. Okay, so if it's fairly easy to do, the question would be "since I don't feel right hacking in this change myself -- how could I propose this as a feature?" It's not a BUG per-se, but I think it could be useful to others as well. -Dan -- Pika Pika Pika! -Pikachu, of Pokemon fame. --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From gballet at gmail.com Mon Sep 8 21:23:52 2008 From: gballet at gmail.com (Guillaume Ballet) Date: Mon Sep 8 21:24:01 2008 Subject: [PATCH] Extending the ddb command set Message-ID: Hello hackers, I sent a patch some time ago, allowing modules to extend the ddb command set. I just realized the link I provided then was in French so that might have discouraged people from going any further. I have therefore posted it here. Also, since I would like this patch to be committed at some point, I have written a man page that I also enclosed. Comments are welcome. The man page: .Dd August 27, 2008 .Dt DB_COMMAND 9 .Os .Sh NAME .Nm DB_COMMAND , .Nm DB_SHOW_COMMAND , .Nm DB_SHOW_ALL_COMMAND .Nd Extends the ddb command set. .Sh SYNOPSIS .In ddb/ddb.h .Fo DB_COMMAND .Fa command_name .Fa command_function .Fc .Fn DB_SHOW_COMMAND "command_name" "command_function" .Fn DB_SHOW_ALL_COMMAND "command_name" "command_function" .Sh DESCRIPTION .Pp The .Fn DB_COMMAND macro adds .Fa command_name to the list of top-level commands. Invoking .Fa command_name from ddb will call .Fa command_function . .Pp The .Fn DB_SHOW_COMMAND and .Fn DB_SHOW_ALL_COMMAND are roughly equivalent to .Fn DB_COMMAND but in these cases, .Fa command_name is a sub-command of the ddb .Sy show command and .Sy show all command, respectively. .Pp The general command syntax: .Cm command Ns Op Li \&/ Ns Ar modifier .Ar address Ns Op Li , Ns Ar count , translates into the following parameters for .Fa command_function : .Bl -tag .It Fa addr The address passed to the command as an argument. .It Fa have_addr A boolean value that is true if the addr field is valid. .It Fa count The number of quad words starting at offset .Fa addr that the command must process. .It Fa modif A pointer to the string of modifiers. That is, a series of symbols used to pass some options to the command. For example, the .Sy examine command will display words in decimal form if it is passed the modifier "d". .El .Sh EXAMPLE In your module, the command is declared as: .Pp .Bd -literal DB_COMMAND(mycmd, my_cmd_func) { if (have_addr) db_printf("Calling my command with address %p\\n", addr); } .Ed .Pp Then, when in ddb: .Pp .Bd -literal .Bf Sy db> mycmd 0x1000 Calling my command with address 0x1000 db> .Ef .Ed .Sh "SEE ALSO" .Xr ddb 4 .Sh AUTHOR This manual page was written by .An Guillaume Ballet Aq gballet@gmail.com . And the patch: --- ./ddb/db_command.c.orig 2008-08-19 00:56:41.000000000 +0200 +++ ./ddb/db_command.c 2008-08-24 20:59:41.000000000 +0200 @@ -45,6 +45,7 @@ #include #include #include +#include #include #include @@ -76,78 +77,68 @@ static db_cmdfcn_t db_watchdog; /* + * Array containing all command 'tables'. See ddb.h. + */ +static struct command_table db_command_tables[DB_COMMAND_TABLES_SIZE] = { + STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_DEFAULT]), + STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW]), + STAILQ_HEAD_INITIALIZER(db_command_tables[DB_COMMAND_TABLES_SHOW_ALL]) +}; + +/* * 'show' commands */ static struct command db_show_all_cmds[] = { - { "procs", db_ps, 0, 0 }, - { (char *)0 } -}; - -static struct command_table db_show_all_table = { - db_show_all_cmds + { { NULL }, "procs", db_ps, 0, 0 } }; static struct command db_show_cmds[] = { - { "all", 0, 0, &db_show_all_table }, - { "registers", db_show_regs, 0, 0 }, - { "breaks", db_listbreak_cmd, 0, 0 }, - { "threads", db_show_threads, 0, 0 }, - { (char *)0, } + { { NULL }, "all", 0, 0, &db_command_tables[DB_COMMAND_TABLES_SHOW_ALL] }, + { { NULL }, "registers", db_show_regs, 0, 0 }, + { { NULL }, "breaks", db_listbreak_cmd, 0, 0 }, + { { NULL }, "threads", db_show_threads, 0, 0 } }; -static struct command_table db_show_table = { - db_show_cmds, - SET_BEGIN(db_show_cmd_set), - SET_LIMIT(db_show_cmd_set) -}; - static struct command db_commands[] = { - { "print", db_print_cmd, 0, 0 }, - { "p", db_print_cmd, 0, 0 }, - { "examine", db_examine_cmd, CS_SET_DOT, 0 }, - { "x", db_examine_cmd, CS_SET_DOT, 0 }, - { "search", db_search_cmd, CS_OWN|CS_SET_DOT, 0 }, - { "set", db_set_cmd, CS_OWN, 0 }, - { "write", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, - { "w", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, - { "delete", db_delete_cmd, 0, 0 }, - { "d", db_delete_cmd, 0, 0 }, - { "break", db_breakpoint_cmd, 0, 0 }, - { "b", db_breakpoint_cmd, 0, 0 }, - { "dwatch", db_deletewatch_cmd, 0, 0 }, - { "watch", db_watchpoint_cmd, CS_MORE,0 }, - { "dhwatch", db_deletehwatch_cmd, 0, 0 }, - { "hwatch", db_hwatchpoint_cmd, 0, 0 }, - { "step", db_single_step_cmd, 0, 0 }, - { "s", db_single_step_cmd, 0, 0 }, - { "continue", db_continue_cmd, 0, 0 }, - { "c", db_continue_cmd, 0, 0 }, - { "until", db_trace_until_call_cmd,0, 0 }, - { "next", db_trace_until_matching_cmd,0, 0 }, - { "match", db_trace_until_matching_cmd,0, 0 }, - { "trace", db_stack_trace, CS_OWN, 0 }, - { "t", db_stack_trace, CS_OWN, 0 }, - { "alltrace", db_stack_trace_all, 0, 0 }, - { "where", db_stack_trace, CS_OWN, 0 }, - { "bt", db_stack_trace, CS_OWN, 0 }, - { "call", db_fncall, CS_OWN, 0 }, - { "show", 0, 0, &db_show_table }, - { "ps", db_ps, 0, 0 }, - { "gdb", db_gdb, 0, 0 }, - { "halt", db_halt, 0, 0 }, - { "reboot", db_reset, 0, 0 }, - { "reset", db_reset, 0, 0 }, - { "kill", db_kill, CS_OWN, 0 }, - { "watchdog", db_watchdog, 0, 0 }, - { "thread", db_set_thread, CS_OWN, 0 }, - { (char *)0, } -}; - -static struct command_table db_command_table = { - db_commands, - SET_BEGIN(db_cmd_set), - SET_LIMIT(db_cmd_set) + { { NULL }, "print", db_print_cmd, 0, 0 }, + { { NULL }, "p", db_print_cmd, 0, 0 }, + { { NULL }, "examine", db_examine_cmd, CS_SET_DOT, 0 }, + { { NULL }, "x", db_examine_cmd, CS_SET_DOT, 0 }, + { { NULL }, "search", db_search_cmd, CS_OWN|CS_SET_DOT, 0 }, + { { NULL }, "set", db_set_cmd, CS_OWN, 0 }, + { { NULL }, "write", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, + { { NULL }, "w", db_write_cmd, CS_MORE|CS_SET_DOT, 0 }, + { { NULL }, "delete", db_delete_cmd, 0, 0 }, + { { NULL }, "d", db_delete_cmd, 0, 0 }, + { { NULL }, "break", db_breakpoint_cmd, 0, 0 }, + { { NULL }, "b", db_breakpoint_cmd, 0, 0 }, + { { NULL }, "dwatch", db_deletewatch_cmd, 0, 0 }, + { { NULL }, "watch", db_watchpoint_cmd, CS_MORE,0 }, + { { NULL }, "dhwatch", db_deletehwatch_cmd, 0, 0 }, + { { NULL }, "hwatch", db_hwatchpoint_cmd, 0, 0 }, + { { NULL }, "step", db_single_step_cmd, 0, 0 }, + { { NULL }, "s", db_single_step_cmd, 0, 0 }, + { { NULL }, "continue", db_continue_cmd, 0, 0 }, + { { NULL }, "c", db_continue_cmd, 0, 0 }, + { { NULL }, "until", db_trace_until_call_cmd,0, 0 }, + { { NULL }, "next", db_trace_until_matching_cmd,0, 0 }, + { { NULL }, "match", db_trace_until_matching_cmd,0, 0 }, + { { NULL }, "trace", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "t", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "alltrace", db_stack_trace_all, 0, 0 }, + { { NULL }, "where", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "bt", db_stack_trace, CS_OWN, 0 }, + { { NULL }, "call", db_fncall, CS_OWN, 0 }, + { { NULL }, "show", 0, 0, &db_command_tables[DB_COMMAND_TABLES_SHOW] }, + { { NULL }, "ps", db_ps, 0, 0 }, + { { NULL }, "gdb", db_gdb, 0, 0 }, + { { NULL }, "halt", db_halt, 0, 0 }, + { { NULL }, "reboot", db_reset, 0, 0 }, + { { NULL }, "reset", db_reset, 0, 0 }, + { { NULL }, "kill", db_kill, CS_OWN, 0 }, + { { NULL }, "watchdog", db_watchdog, 0, 0 }, + { { NULL }, "thread", db_set_thread, CS_OWN, 0 } }; static struct command *db_last_command = 0; @@ -189,6 +180,73 @@ struct command_table *cmd_table); /* + * Initialize command tables using the commands declared above. + */ +void +db_cmd_init() +{ + int cnt; + + for (cnt=0; cnt<(sizeof(db_commands) / sizeof(struct command)); cnt++) + STAILQ_INSERT_TAIL(&db_command_tables[DB_COMMAND_TABLES_DEFAULT], + &(db_commands[cnt]), + next); + for (cnt=0; cnt<(sizeof(db_show_cmds) / sizeof(struct command)); cnt++) + STAILQ_INSERT_TAIL(&db_command_tables[DB_COMMAND_TABLES_SHOW], + &(db_show_cmds[cnt]), + next); + for (cnt=0; cnt<(sizeof(db_show_all_cmds) / sizeof(struct command)); cnt++) + STAILQ_INSERT_TAIL(&db_command_tables[DB_COMMAND_TABLES_SHOW_ALL], + &(db_show_all_cmds[cnt]), + next); +} + +/* + * Called by modules through SYSINIT to extend the command set. + */ +void db_command_register(list_index, cmd) + int list_index; + struct command *cmd; +{ + if (list_index >= DB_COMMAND_TABLES_SIZE) + panic("Attempting to add a debugger command to an invalid list!"); + +#if 0 + /* Check that the command is not already present. */ + struct command *scmd; + STAILQ_FOREACH(scmd, &(db_command_tables[list_index]), next) { + if (!strcmp(cmd->name, scmd->name)) + panic("The command %s already exists!", cmd->name); + } +#endif + + if (cmd != NULL) { + STAILQ_INSERT_TAIL(&(db_command_tables[list_index]), + cmd, next); + } +} + +/* + * Called by SYSUNINIT. Revert what has been done above. + */ +void db_command_unregister(table_index, command_name) + int table_index; + char *command_name; +{ + struct command *cmd; + + STAILQ_FOREACH(cmd, &(db_command_tables[table_index]), next) { + if (!strcmp(command_name,cmd->name)) { + STAILQ_REMOVE(&(db_command_tables[table_index]), + cmd, + command, + next); + break; + } + } +} + +/* * Helper function to match a single command. */ static void @@ -236,23 +294,15 @@ struct command_table *table; struct command **cmdp; /* out */ { - struct command *cmd; - struct command **aux_cmdp; - int result = CMD_NONE; + struct command *cmd; + int result = CMD_NONE; - for (cmd = table->table; cmd->name != 0; cmd++) { - db_cmd_match(name, cmd, cmdp, &result); + STAILQ_FOREACH(cmd,table,next) { + db_cmd_match(name,cmd,cmdp,&result); if (result == CMD_UNIQUE) - return (CMD_UNIQUE); + break; } - if (table->aux_tablep != NULL) - for (aux_cmdp = table->aux_tablep; - aux_cmdp < table->aux_tablep_end; - aux_cmdp++) { - db_cmd_match(name, *aux_cmdp, cmdp, &result); - if (result == CMD_UNIQUE) - return (CMD_UNIQUE); - } + if (result == CMD_NONE) { /* check for 'help' */ if (name[0] == 'h' && name[1] == 'e' @@ -266,19 +316,11 @@ db_cmd_list(table) struct command_table *table; { - register struct command *cmd; - register struct command **aux_cmdp; + register struct command *cmd; - for (cmd = table->table; cmd->name != 0; cmd++) { - db_printf("%-12s", cmd->name); - db_end_line(12); - } - if (table->aux_tablep == NULL) - return; - for (aux_cmdp = table->aux_tablep; aux_cmdp < table->aux_tablep_end; - aux_cmdp++) { - db_printf("%-12s", (*aux_cmdp)->name); - db_end_line(12); + STAILQ_FOREACH(cmd, table, next) { + db_printf("%-12s", cmd->name); + db_end_line(12); } } @@ -287,7 +329,7 @@ struct command **last_cmdp; /* IN_OUT */ struct command_table *cmd_table; { - struct command *cmd; + struct command *cmd = NULL; int t; char modif[TOK_STRING_SIZE]; db_expr_t addr, count; @@ -450,7 +492,7 @@ db_printf("db> "); (void) db_read_line(); - db_command(&db_last_command, &db_command_table); + db_command(&db_last_command, &(db_command_tables[DB_COMMAND_TABLES_DEFAULT])); } } --- ./ddb/ddb.h.orig 2008-08-19 01:04:24.000000000 +0200 +++ ./ddb/ddb.h 2008-08-23 21:53:28.000000000 +0200 @@ -39,6 +39,9 @@ #include /* type definitions */ +#include /* STAILQ_* */ +#include /* SYSINIT */ + #ifndef DB_MAXARGS #define DB_MAXARGS 10 #endif @@ -53,23 +56,38 @@ char *modif); #define DB_COMMAND(cmd_name, func_name) \ - DB_FUNC(cmd_name, func_name, db_cmd_set, 0, NULL) + DB_FUNC(cmd_name, func_name, DB_COMMAND_TABLES_DEFAULT, 0, NULL) #define DB_SHOW_COMMAND(cmd_name, func_name) \ - DB_FUNC(cmd_name, func_name, db_show_cmd_set, 0, NULL) + DB_FUNC(cmd_name, func_name, DB_COMMAND_TABLES_SHOW, 0, NULL) +#define DB_SHOW_ALL_COMMAND(cmd_name, func_name) \ + DB_FUNC(cmd_name, func_name, DB_COMMAND_TABLES_SHOW_ALL, 0, NULL) -#define DB_SET(cmd_name, func_name, set, flag, more) \ -static const struct command __CONCAT(cmd_name,_cmd) = { \ - __STRING(cmd_name), \ - func_name, \ - flag, \ - more \ -}; \ -TEXT_SET(set, __CONCAT(cmd_name,_cmd)) +/* + * At the moment, there are three command "tables" on the system: + * - One for simple commands, whose list one can get by typing 'help' + * at debugger prompt. + * - One for sub-commands of 'show'. + * - The last one for sub-commands of 'show all'. + * All these tables are stored in an array, and the constants defined + * hereafter give the offset in the array at which the head for each + * table can be found. + */ +enum { + DB_COMMAND_TABLES_DEFAULT, + DB_COMMAND_TABLES_SHOW, + DB_COMMAND_TABLES_SHOW_ALL, + DB_COMMAND_TABLES_SIZE +}; + +struct command; -#define DB_FUNC(cmd_name, func_name, set, flag, more) \ +/* + * Declare the function func_name, which is handling db command + * cmd_name) + */ +#define DB_FUNC(cmd_name, func_name, list, flag, more) \ static db_cmdfcn_t func_name; \ - \ -DB_SET(cmd_name, func_name, set, flag, more); \ +DB_SET(cmd_name, func_name, list, flag, more); \ \ static void \ func_name(addr, have_addr, count, modif) \ @@ -78,6 +96,35 @@ db_expr_t count; \ char *modif; +/* + * Add command 'cmd_name' to the command table, along + * with the SYSINIT functions to load and unload it. + */ +#define DB_SET(cmd_name, func_name, list, flag, more) \ +static struct command __CONCAT(cmd_name,_cmd) = { \ + { NULL }, \ + __STRING(cmd_name), \ + func_name, \ + flag, \ + more \ +}; \ + \ +static void __CONCAT(cmd_name,_db_cmd_add)(void*); \ +static void __CONCAT(cmd_name,_db_cmd_rm)(void*); \ + \ +static void __CONCAT(cmd_name,_db_cmd_add)(void *arg __unused) \ +{ \ + db_command_register(list, &__CONCAT(cmd_name,_cmd)); \ +} \ + \ +static void __CONCAT(cmd_name,_db_cmd_rm)(void *arg __unused) \ +{ \ + db_command_unregister(list,__STRING(cmd_name)); \ +} \ + \ +SYSINIT(cmd_name, SI_SUB_KLD, SI_ORDER_ANY, __CONCAT(cmd_name,_db_cmd_add), NULL); \ +SYSUNINIT(cmd_name, SI_SUB_KLD, SI_ORDER_ANY, __CONCAT(cmd_name,_db_cmd_rm), NULL); + extern db_expr_t db_maxoff; extern int db_indent; extern int db_inst_count; @@ -124,6 +171,9 @@ int db_trace_thread(struct thread *, int); int db_value_of_name(const char *name, db_expr_t *valuep); int db_write_bytes(vm_offset_t addr, size_t size, char *data); +void db_cmd_init(void); +void db_command_register(int, struct command *); +void db_command_unregister(int, char *); db_cmdfcn_t db_breakpoint_cmd; db_cmdfcn_t db_continue_cmd; @@ -147,17 +197,17 @@ db_cmdfcn_t db_write_cmd; /* - * Command table. + * Declare command table type. It is actually a linked list, so + * as to allow for runtime extensions to the table. */ -struct command; - -struct command_table { - struct command *table; - struct command **aux_tablep; - struct command **aux_tablep_end; -}; +STAILQ_HEAD(command_table, command); +/* + * Command table entry. + */ struct command { + STAILQ_ENTRY(command) /* Pointer to the next entry in the */ + next; /* command table */ char * name; /* command name */ db_cmdfcn_t *fcn; /* function to call */ int flag; /* extra info: */ --- ./ddb/db_main.c.orig 2008-08-20 00:35:51.000000000 +0200 +++ ./ddb/db_main.c 2008-08-20 00:36:37.000000000 +0200 @@ -182,6 +182,8 @@ } } db_add_symbol_table(NULL, NULL, "kld", NULL); + + db_cmd_init(); return (1); /* We're the default debugger. */ } --- ./dev/aic7xxx/aic79xx_osm.c.orig 2008-08-21 02:42:04.000000000 +0200 +++ ./dev/aic7xxx/aic79xx_osm.c 2008-08-21 02:42:33.000000000 +0200 @@ -1423,7 +1423,7 @@ } } -DB_FUNC(ahd_out, ahd_ddb_out, db_cmd_set, CS_MORE, NULL) +DB_FUNC(ahd_out, ahd_ddb_out, DB_COMMAND_TABLES_DEFAULT, CS_MORE, NULL) { db_expr_t old_value; db_expr_t new_value; --- ./gnu/fs/xfs/FreeBSD/support/kdb.c.orig 2008-08-24 16:47:00.000000000 +0200 +++ ./gnu/fs/xfs/FreeBSD/support/kdb.c 2008-08-24 16:47:30.000000000 +0200 @@ -12,7 +12,7 @@ #include #ifdef DDB -DB_FUNC(xfs, xfs_ddb_cmd, db_cmd_set, CS_MORE, NULL) +DB_FUNC(xfs, xfs_ddb_cmd, DB_COMMAND_TABLES_DEFAULT, CS_MORE, NULL) { db_error("No commands registered.\n"); } --- ./kern/subr_sleepqueue.c.orig 2008-08-23 15:54:34.000000000 +0200 +++ ./kern/subr_sleepqueue.c 2008-08-21 21:49:13.000000000 +0200 @@ -983,5 +983,5 @@ } /* Alias 'show sleepqueue' to 'show sleepq'. */ -DB_SET(sleepqueue, db_show_sleepqueue, db_show_cmd_set, 0, NULL); +DB_SET(sleepqueue, db_show_sleepqueue, DB_COMMAND_TABLES_SHOW, 0, NULL); #endif From killing at multiplay.co.uk Mon Sep 8 22:46:48 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Mon Sep 8 22:46:59 2008 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade Message-ID: I've been trying to install FreeBSD 7.0-RELEASE amd64 on a Dell M600 Blade but it hangs just after initialising the isa bus. I've tried a number of things and the only thing that I can get to work is the i386 build which boots into the installer without issue. Has anyone had any experience with the Dell M600 blade on amd64 or had the amd64 build hang at this point before. I don't have access to the machines to try new things with ATM as we needed them in production so was forced to install ubuntu to get then live but I should get them back for more testing next week some time so wanted to see if anyone had any experience with this or a similar issue? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From koitsu at FreeBSD.org Tue Sep 9 00:58:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 9 00:58:49 2008 Subject: IPFW uid logging... In-Reply-To: References: <20080908185106.GB6629@dan.emsphone.com> Message-ID: <20080909004239.GA82283@icarus.home.lan> On Mon, Sep 08, 2008 at 04:03:29PM -0400, Dan Mahoney, System Admin wrote: > On Mon, 8 Sep 2008, Dan Nelson wrote: > >> In the last episode (Sep 08), Dan Mahoney, System Admin said: >>> I have the following rule set up in ipfw to limit the exposure of bad >>> php scripts and trojans that try to send mail directly. >>> >>> allow tcp from any to any dst-port 25 uid root >>> deny log tcp from any to any dst-port 25 out >>> >>> However, the log messages I get look like this: >>> >>> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 >>> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 >>> >>> Which is to say, they don't include the UID -- and I have several hundred >>> sites, each with its own UID. >>> >>> Yes, I could go ahead and set up a thousand "deny" rules, one for >>> each UID -- but being able to log this info (since it IS being >>> checked) would be great. >> >> It should be possible to add a couple more arguments to ipfw_log() so >> that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the >> fw_ugid_cache struct. Then you can edit ipfw_log to print the contents >> of that struct if ugid_lookup==1. That would result in the logging of >> uid for any failed packet that had to go through a uid check on the way >> to the deny rule. > > Okay, so if it's fairly easy to do, the question would be "since I don't > feel right hacking in this change myself -- how could I propose this as a > feature?" It's not a BUG per-se, but I think it could be useful to > others as well. send-pr it. Category=kern, Class=change-request. Reference this thread in the Fix section: http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025920.html FWIW, I think it's also a good idea. The output formatting of the log line might need to be adjusted "carefully" though, since any programs which grep on a very strict regex will start failing. I'm inclined to recommend the string ", UID xxx" be appended to the existing string, e.g. Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0, UID 6592 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From Daan at vehosting.nl Tue Sep 9 00:43:46 2008 From: Daan at vehosting.nl (Daan Vreeken) Date: Tue Sep 9 01:20:57 2008 Subject: IPFW uid logging... In-Reply-To: References: <20080908185106.GB6629@dan.emsphone.com> Message-ID: <200809090223.46472.Daan@vehosting.nl> Hi Dan, Dan and the list, On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > On Mon, 8 Sep 2008, Dan Nelson wrote: > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > >> I have the following rule set up in ipfw to limit the exposure of bad > >> php scripts and trojans that try to send mail directly. > >> > >> allow tcp from any to any dst-port 25 uid root > >> deny log tcp from any to any dst-port 25 out > >> > >> However, the log messages I get look like this: > >> > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > >> 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 > >> prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 > >> 202.12.31.144:25 out via em0 > >> > >> Which is to say, they don't include the UID -- and I have several > >> hundred sites, each with its own UID. > >> > >> Yes, I could go ahead and set up a thousand "deny" rules, one for > >> each UID -- but being able to log this info (since it IS being > >> checked) would be great. > > > > It should be possible to add a couple more arguments to ipfw_log() so > > that ipfw_chk() can pass it the ugid_lookup flag and a pointer to the > > fw_ugid_cache struct. Then you can edit ipfw_log to print the contents > > of that struct if ugid_lookup==1. That would result in the logging of > > uid for any failed packet that had to go through a uid check on the way > > to the deny rule. > > Okay, so if it's fairly easy to do, the question would be "since I don't > feel right hacking in this change myself -- how could I propose this as a > feature?" It's not a BUG per-se, but I think it could be useful to others > as well. I own a webhosting company and here too every domain gets it's own user, so I like this proposal. I've hacked together a first try, which seems to be working. A patch (against -HEAD) can be found here : http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff Improvements / tips / comments are welcome ;-) -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From dnelson at allantgroup.com Tue Sep 9 05:42:01 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Tue Sep 9 05:42:08 2008 Subject: IPFW uid logging... In-Reply-To: <200809090223.46472.Daan@vehosting.nl> References: <20080908185106.GB6629@dan.emsphone.com> <200809090223.46472.Daan@vehosting.nl> Message-ID: <20080909045037.GC6629@dan.emsphone.com> In the last episode (Sep 09), Daan Vreeken said: > On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > > On Mon, 8 Sep 2008, Dan Nelson wrote: > > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > > >> I have the following rule set up in ipfw to limit the exposure > > >> of bad php scripts and trojans that try to send mail directly. > > >> > > >> allow tcp from any to any dst-port 25 uid root > > >> deny log tcp from any to any dst-port 25 out > > >> > > >> However, the log messages I get look like this: > > >> > > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:58117 209.85.133.114:25 out via em0 > > >> Sep 8 13:21:16 prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 202.12.31.144:25 out via em0 > > >> > > >> Which is to say, they don't include the UID -- and I have > > >> several hundred sites, each with its own UID. > > >> > > >> Yes, I could go ahead and set up a thousand "deny" rules, one > > >> for each UID -- but being able to log this info (since it IS > > >> being checked) would be great. > > > > > > It should be possible to add a couple more arguments to > > > ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag > > > and a pointer to the fw_ugid_cache struct. Then you can edit > > > ipfw_log to print the contents of that struct if ugid_lookup==1. > > > That would result in the logging of uid for any failed packet > > > that had to go through a uid check on the way to the deny rule. > > > > Okay, so if it's fairly easy to do, the question would be "since I > > don't feel right hacking in this change myself -- how could I > > propose this as a feature?" It's not a BUG per-se, but I think it > > could be useful to others as well. > > Hi Dan, Dan and the list, > > I own a webhosting company and here too every domain gets it's own > user, so I like this proposal. I've hacked together a first try, > which seems to be working. A patch (against -HEAD) can be found here: > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > Improvements / tips / comments are welcome ;-) I like it. Maybe print gid as well, since there's an ipfw rule for that too. -- Dan Nelson dnelson@allantgroup.com From Daan at vehosting.nl Tue Sep 9 07:58:52 2008 From: Daan at vehosting.nl (Daan Vreeken) Date: Tue Sep 9 07:59:00 2008 Subject: IPFW uid logging... In-Reply-To: <20080909045037.GC6629@dan.emsphone.com> References: <200809090223.46472.Daan@vehosting.nl> <20080909045037.GC6629@dan.emsphone.com> Message-ID: <200809090958.35448.Daan@vehosting.nl> On Tuesday 09 September 2008 06:50:37 Dan Nelson wrote: > In the last episode (Sep 09), Daan Vreeken said: > > On Monday 08 September 2008 22:03:29 Dan Mahoney, System Admin wrote: > > > On Mon, 8 Sep 2008, Dan Nelson wrote: > > > > In the last episode (Sep 08), Dan Mahoney, System Admin said: > > > >> I have the following rule set up in ipfw to limit the exposure > > > >> of bad php scripts and trojans that try to send mail directly. > > > >> > > > >> allow tcp from any to any dst-port 25 uid root > > > >> deny log tcp from any to any dst-port 25 out > > > >> > > > >> However, the log messages I get look like this: > > > >> > > > >> Sep 8 13:21:11 prime kernel: ipfw: 610 Deny TCP > > > >> 72.9.101.130:58117 209.85.133.114:25 out via em0 Sep 8 13:21:16 > > > >> prime kernel: ipfw: 610 Deny TCP 72.9.101.130:56672 > > > >> 202.12.31.144:25 out via em0 > > > >> > > > >> Which is to say, they don't include the UID -- and I have > > > >> several hundred sites, each with its own UID. > > > >> > > > >> Yes, I could go ahead and set up a thousand "deny" rules, one > > > >> for each UID -- but being able to log this info (since it IS > > > >> being checked) would be great. > > > > > > > > It should be possible to add a couple more arguments to > > > > ipfw_log() so that ipfw_chk() can pass it the ugid_lookup flag > > > > and a pointer to the fw_ugid_cache struct. Then you can edit > > > > ipfw_log to print the contents of that struct if ugid_lookup==1. > > > > That would result in the logging of uid for any failed packet > > > > that had to go through a uid check on the way to the deny rule. > > > > > > Okay, so if it's fairly easy to do, the question would be "since I > > > don't feel right hacking in this change myself -- how could I > > > propose this as a feature?" It's not a BUG per-se, but I think it > > > could be useful to others as well. > > > > Hi Dan, Dan and the list, > > > > I own a webhosting company and here too every domain gets it's own > > user, so I like this proposal. I've hacked together a first try, > > which seems to be working. A patch (against -HEAD) can be found here: > > > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > > > Improvements / tips / comments are welcome ;-) > > I like it. Maybe print gid as well, since there's an ipfw rule for > that too. I intentionally left printing the gid out, since a user can be in up to NGROUPS_MAX groups. We could of course only show the one gid that matched... The following (only compile-tested) patch tries to implement that : http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09_2.diff I'm not really sure which patch I liked best. The first patch missed a check against (ugid_lookup == -1) though. -- Daan Vreeken VEHosting http://VEHosting.nl tel: +31-(0)40-7113050 / +31-(0)6-46210825 KvK nr: 17174380 From rwatson at FreeBSD.org Tue Sep 9 08:34:14 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Sep 9 08:34:26 2008 Subject: IPFW uid logging... In-Reply-To: <200809090223.46472.Daan@vehosting.nl> References: <20080908185106.GB6629@dan.emsphone.com> <200809090223.46472.Daan@vehosting.nl> Message-ID: On Tue, 9 Sep 2008, Daan Vreeken wrote: >>>> Which is to say, they don't include the UID -- and I have several hundred >>>> sites, each with its own UID. >>>> >>>> Yes, I could go ahead and set up a thousand "deny" rules, one for each >>>> UID -- but being able to log this info (since it IS being checked) would >>>> be great. >>> >>> It should be possible to add a couple more arguments to ipfw_log() so that >>> ipfw_chk() can pass it the ugid_lookup flag and a pointer to the >>> fw_ugid_cache struct. Then you can edit ipfw_log to print the contents of >>> that struct if ugid_lookup==1. That would result in the logging of uid >>> for any failed packet that had to go through a uid check on the way to the >>> deny rule. >> >> Okay, so if it's fairly easy to do, the question would be "since I don't >> feel right hacking in this change myself -- how could I propose this as a >> feature?" It's not a BUG per-se, but I think it could be useful to others >> as well. > > I own a webhosting company and here too every domain gets it's own user, so > I like this proposal. I've hacked together a first try, which seems to be > working. A patch (against -HEAD) can be found here : > > http://vehosting.nl/pub_diffs/ip_fw2.c_uid_2008_09_09.diff > > Improvements / tips / comments are welcome ;-) A few observations generally about the use of connection credential data in the firewall: (1) UID lookups on connections from the firewall are inherently race-prone and unreliable; the stack layering violation means that locks may be acquired independently for the connection lookup at the firewall and socket layers. This non-atomicity may be fairly acceptable in the event that there aren't significant delays in processing, but if you also have DUMMYNET pipes in use then these races may mean significant gaps in time between when a socket is looked up for check vs. use. (2) The performance hit of connection lookups in order to find credentials for received packets may (should) be massive: the input path will look up the connection for each packet multiple times, acquiring contended locks, etc. (3) It's currently not possible to look up the connection associated with several sorts of packets, including ICMP (such as used with PMTU). Note that all of these problems apply to existing uid/gid/jail credential rules, which are considered unreliable and non-performant for the same reasons. Looking at your patch specifically, it seems you don't force the lookup of credential information if it hasn't already being looked up for a credential rule. This should mean that the known problems of (1), (2), and (3) shouldn't be worse than they were before. Robert N M Watson Computer Laboratory University of Cambridge From kostikbel at gmail.com Tue Sep 9 11:54:03 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Sep 9 11:54:10 2008 Subject: 256-byte inode support In-Reply-To: <20080907150747.GB62357@atarininja.org> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> Message-ID: <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > hackers, > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > 265-byte inode ext3 drives -- is there any effort to update it? If > > not -- if you know where i should attempt to start please let me know > > so i can start working on support (i have a few other people i know > > interested in this) -- thanks and hope everyone is well > > There was a PR submitted for it and eventually a patch added to the PR. > I've tested the patch given in the URL at the port and it works. We > will start to see more of this as the newer version becomes more common > in the wild. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 > > Would be nice to see this fixed in 7.1 but it may be too late for that. What was the reason for increasing inode size ? I think it is rather pointless to increase the size without using newly added space for some data. Is inode format the same for the first 128 bytes, and does data at the second 128 bytes should be used to correctly interpret inode ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080909/8829e62d/attachment.pgp From wxs at FreeBSD.org Tue Sep 9 12:29:11 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Tue Sep 9 12:29:18 2008 Subject: 256-byte inode support In-Reply-To: <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> Message-ID: <20080909122917.GK62357@atarininja.org> On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > > hackers, > > > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > > 265-byte inode ext3 drives -- is there any effort to update it? If > > > not -- if you know where i should attempt to start please let me know > > > so i can start working on support (i have a few other people i know > > > interested in this) -- thanks and hope everyone is well > > > > There was a PR submitted for it and eventually a patch added to the PR. > > I've tested the patch given in the URL at the port and it works. We > > will start to see more of this as the newer version becomes more common > > in the wild. > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 > > > > Would be nice to see this fixed in 7.1 but it may be too late for that. > > What was the reason for increasing inode size ? I think it is rather > pointless to increase the size without using newly added space for some > data. Is inode format the same for the first 128 bytes, and does data > at the second 128 bytes should be used to correctly interpret inode ? I honestly don't know the answer. Though I do agree that it is pointless to increase the size without using the new space. All I know is that I was unable to read an ext filesystem made with -I 256 (which is the default when using the most recent sysutils/e2fsprogs). wxs@ack ~ % truncate -s 1G ext-128 wxs@ack ~ % truncate -s 1G ext-256 wxs@ack ~ % sudo mdconfig -a -t vnode -f ext-128 -s 1G md0 wxs@ack ~ % sudo mdconfig -a -t vnode -f ext-256 -s 1G md1 wxs@ack ~ % sudo kldload ext2fs wxs@ack ~ % mke2fs -I 128 /dev/md0 mke2fs 1.41.0 (10-Jul-2008) mke2fs: Permission denied while trying to determine filesystem size wxs@ack ~ % sudo mke2fs -I 128 /dev/md0 mke2fs 1.41.0 (10-Jul-2008) Filesystem label= OS type: FreeBSD Block size=4096 (log=2) Fragment size=4096 (log=2) 65536 inodes, 262144 blocks 13107 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=268435456 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 27 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. wxs@ack ~ % sudo mke2fs /dev/md1 mke2fs 1.41.0 (10-Jul-2008) Filesystem label= OS type: FreeBSD Block size=4096 (log=2) Fragment size=4096 (log=2) 65536 inodes, 262144 blocks 13107 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=268435456 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Writing inode tables: done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 37 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. wxs@ack ~ % sudo mount -t ext2fs /dev/md0 /mnt/ext2-128 wxs@ack ~ % sudo mount -t ext2fs /dev/md1 /mnt/ext2-256 wxs@ack ~ % ls /mnt/ext2-128 lost+found/ wxs@ack ~ % ls /mnt/ext2-256 ls: /mnt/ext2-256: Bad file descriptor wxs@ack ~ % -- WXS From kostikbel at gmail.com Tue Sep 9 12:38:03 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Sep 9 12:38:10 2008 Subject: 256-byte inode support In-Reply-To: <20080909122917.GK62357@atarininja.org> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> <20080909122917.GK62357@atarininja.org> Message-ID: <20080909123746.GK39652@deviant.kiev.zoral.com.ua> On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote: > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > > > hackers, > > > > > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > > > 265-byte inode ext3 drives -- is there any effort to update it? If > > > > not -- if you know where i should attempt to start please let me know > > > > so i can start working on support (i have a few other people i know > > > > interested in this) -- thanks and hope everyone is well > > > > > > There was a PR submitted for it and eventually a patch added to the PR. > > > I've tested the patch given in the URL at the port and it works. We > > > will start to see more of this as the newer version becomes more common > > > in the wild. > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 > > > > > > Would be nice to see this fixed in 7.1 but it may be too late for that. > > > > What was the reason for increasing inode size ? I think it is rather > > pointless to increase the size without using newly added space for some > > data. Is inode format the same for the first 128 bytes, and does data > > at the second 128 bytes should be used to correctly interpret inode ? > > I honestly don't know the answer. Though I do agree that it is > pointless to increase the size without using the new space. > > All I know is that I was unable to read an ext filesystem made with -I > 256 (which is the default when using the most recent > sysutils/e2fsprogs). I think it is too dangerous for the user data to commit this patch, without investigating this first. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080909/adb24c73/attachment.pgp From kr.lekha at gmail.com Tue Sep 9 12:53:59 2008 From: kr.lekha at gmail.com (kr Lekha) Date: Tue Sep 9 12:54:06 2008 Subject: killing a kthread In-Reply-To: <20080903211459.GA60350@zim.MIT.EDU> References: <96b2ec350809030134j73a61369m35395391a1218975@mail.gmail.com> <20080903095605.GB21178@alpha.local> <96b2ec350809030516y2d6f26d1h3cd7eb39231c4da0@mail.gmail.com> <20080903211459.GA60350@zim.MIT.EDU> Message-ID: <96b2ec350809090553q3ba36125nd3da14129da0f2b3@mail.gmail.com> Hi all, thanks very much for your valuable inputs. I found out the way to exit the thread. Problem was psignal(p, SIGKILL); , the p->p_siglist was being reset after propagating this signal to threads associated with this proc. Hence i could poll once in a way if any unhandled signals were in curthread->td_siglist. I am not sure if this is the optimal solution. Please do sugest if you have a better solution Why cant we have signal handlers for kernel threads? when i tried to register one, sigaction returned value 14 and signal handler didnt get registered. Thanks, lekha On Wed, Sep 3, 2008 at 10:14 PM, David Schultz wrote: > On Wed, Sep 03, 2008, kr Lekha wrote: > > I understand when thread finishes it should call kthread_exit(). > > but if this thread was suspended before it finished, it might not be able > to > > call kthread_exit(). > > > > Due to which we still see the thread suspended. I am unable to kill it > > even with killproc / psignal with in the kernel module. > > That's by design. Kernel threads can hold arbitrary kernel > resources, and there's no mechanism to clean up after them > automatically. They are expected to clean up after themselves and > exit gracefully. In your case, you'll need to wake up the > suspended thread and somehow notify it that you want it to > terminate. > From wxs at FreeBSD.org Tue Sep 9 13:14:35 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Tue Sep 9 13:14:42 2008 Subject: 256-byte inode support In-Reply-To: <20080909123746.GK39652@deviant.kiev.zoral.com.ua> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> <20080909122917.GK62357@atarininja.org> <20080909123746.GK39652@deviant.kiev.zoral.com.ua> Message-ID: <20080909131442.GL62357@atarininja.org> On Tue, Sep 09, 2008 at 03:37:47PM +0300, Kostik Belousov wrote: > On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote: > > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: > > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: > > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: > > > > > hackers, > > > > > > > > > > since tytso had updated ext3 -- i've noticed that i can't use my > > > > > 265-byte inode ext3 drives -- is there any effort to update it? If > > > > > not -- if you know where i should attempt to start please let me know > > > > > so i can start working on support (i have a few other people i know > > > > > interested in this) -- thanks and hope everyone is well > > > > > > > > There was a PR submitted for it and eventually a patch added to the PR. > > > > I've tested the patch given in the URL at the port and it works. We > > > > will start to see more of this as the newer version becomes more common > > > > in the wild. > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 > > > > > > > > Would be nice to see this fixed in 7.1 but it may be too late for that. > > > > > > What was the reason for increasing inode size ? I think it is rather > > > pointless to increase the size without using newly added space for some > > > data. Is inode format the same for the first 128 bytes, and does data > > > at the second 128 bytes should be used to correctly interpret inode ? > > > > I honestly don't know the answer. Though I do agree that it is > > pointless to increase the size without using the new space. > > > > All I know is that I was unable to read an ext filesystem made with -I > > 256 (which is the default when using the most recent > > sysutils/e2fsprogs). > > I think it is too dangerous for the user data to commit this patch, > without investigating this first. I think that's a fair assessment to make. The patch is certainly simple enough but I'm not familiar with what it's doing to make an accurate assessment. I know it worked for the simple test case I provided in my previous message. If I can be of any further assistance please let me know. -- WXS From jhb at freebsd.org Tue Sep 9 21:04:44 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 9 21:04:55 2008 Subject: question on asymmetric mtx_[un]lock_sleep In-Reply-To: <200809041400.04575.marc.loerner@hob.de> References: <200809041400.04575.marc.loerner@hob.de> Message-ID: <200809091538.08716.jhb@freebsd.org> On Thursday 04 September 2008 08:00:04 am Marc L?rner wrote: > Hello, > I just read through the code of mutexes and turnstiles > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > are some kind of asymmetric when turning SMP and adaptive mutexes > on in kernel-configuration. > > On locking the mutex, we try to "quick" obtain the lock. > If we can't do this, we look, whether some other thread, that's running, > holds the lock and spin until either lock is freed or thread is not running > anymore. In that case we try again to obtain the lock "quick". > If the thread only stopped running but still holds the lock, we use turnstiles > to wake us up, when the thread unlocks the mutex. > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > But if we're spinning and the other thread gave the mutex free, > we quick-lock the mutex and don't set up a turnstile. > > Now on mtx_unlock_sleep: > - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. > => if turnstile_lookup return NULL we only released the lock quick. > > - But now, it's never tested if turnstile exists instead we broadcast/wakeup > all threads pending on the turnstile. If this turnstile is NULL => we access > wrong memory. > > Now my question is: Why can we be sure (in new source) that turnstile_lookup > always returns a valid pointer to an turnstile and can use returned pointer > to call turnstile_broadcast? Am I missing something? > > Because it seems that following scenario may occur: > - on locking same scenario as above (=> thread1 now holds the lock) > - thread1 is put off the runqueue > - thread2 now tries to quick unlock mutex and sees that thread1 holds it => > call to mtx_unlock_sleep > - now we try to use turnstile-mechanism and call turnstile_lookup => returns > NULL because no thread waits for wakeup => we call turnstile_broadcast and > crash. Newer locks don't set the CONTESTED flag unless they are actually going to go to sleep. If they succeed in setting CONTESTED or it is already set when they test for it, then they will block on the turnstile. The turnstile chain lock will prevent a concurrent unlock from grabbing the turnstile until the blocking thread is fully asleep. -- John Baldwin From marc.loerner at hob.de Wed Sep 10 08:35:48 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Wed Sep 10 08:35:55 2008 Subject: question on asymmetric mtx_[un]lock_sleep In-Reply-To: <200809091538.08716.jhb@freebsd.org> References: <200809041400.04575.marc.loerner@hob.de> <200809091538.08716.jhb@freebsd.org> Message-ID: <200809101019.30453.marc.loerner@hob.de> On Tuesday 09 September 2008 21:38, John Baldwin wrote: > On Thursday 04 September 2008 08:00:04 am Marc L?rner wrote: > > Hello, > > I just read through the code of mutexes and turnstiles > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > are some kind of asymmetric when turning SMP and adaptive mutexes > > on in kernel-configuration. > > > > On locking the mutex, we try to "quick" obtain the lock. > > If we can't do this, we look, whether some other thread, that's running, > > holds the lock and spin until either lock is freed or thread is not > > running anymore. In that case we try again to obtain the lock "quick". > > If the thread only stopped running but still holds the lock, we use > > turnstiles > > > to wake us up, when the thread unlocks the mutex. > > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > > > But if we're spinning and the other thread gave the mutex free, > > we quick-lock the mutex and don't set up a turnstile. > > > > Now on mtx_unlock_sleep: > > - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. > > => if turnstile_lookup return NULL we only released the lock quick. > > > > - But now, it's never tested if turnstile exists instead we > > broadcast/wakeup all threads pending on the turnstile. If this turnstile > > is NULL => we > > access > > > wrong memory. > > > > Now my question is: Why can we be sure (in new source) that > > turnstile_lookup always returns a valid pointer to an turnstile and can > > use returned pointer to call turnstile_broadcast? Am I missing something? > > > > Because it seems that following scenario may occur: > > - on locking same scenario as above (=> thread1 now holds the lock) > > - thread1 is put off the runqueue > > - thread2 now tries to quick unlock mutex and sees that thread1 holds it > > => call to mtx_unlock_sleep > > - now we try to use turnstile-mechanism and call turnstile_lookup => > > returns NULL because no thread waits for wakeup => we call > > turnstile_broadcast and crash. > > Newer locks don't set the CONTESTED flag unless they are actually going to > go to sleep. If they succeed in setting CONTESTED or it is already set > when they test for it, then they will block on the turnstile. The > turnstile chain lock will prevent a concurrent unlock from grabbing the > turnstile until the blocking thread is fully asleep. I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! But there is still the possibility that mtx_lock_sleep "just" obtains the lock and doesn't set contested-bit! See described case above (we reach first continue in mtx_lock_sleep and test on obtain_lock ends while-loop). Why is this bit not tested in mtx_unlock_sleep? I think, it's still possible that turnstile_lookup returns NULL. And we still have "MPASS(ts != NULL);" in mtx_unlock_sleep that is not turned on for GENERIC-kernel (no INVARIANTS support). And I'm still wondering why the former test on "ts != NULL" went away? Regards, Marc Loerner From jhb at freebsd.org Wed Sep 10 19:07:43 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 10 19:07:49 2008 Subject: question on asymmetric mtx_[un]lock_sleep In-Reply-To: <200809101019.30453.marc.loerner@hob.de> References: <200809041400.04575.marc.loerner@hob.de> <200809091538.08716.jhb@freebsd.org> <200809101019.30453.marc.loerner@hob.de> Message-ID: <200809101409.49145.jhb@freebsd.org> On Wednesday 10 September 2008 04:19:30 am Marc L?rner wrote: > On Tuesday 09 September 2008 21:38, John Baldwin wrote: > > On Thursday 04 September 2008 08:00:04 am Marc L?rner wrote: > > > Hello, > > > I just read through the code of mutexes and turnstiles > > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > > are some kind of asymmetric when turning SMP and adaptive mutexes > > > on in kernel-configuration. > > > > > > On locking the mutex, we try to "quick" obtain the lock. > > > If we can't do this, we look, whether some other thread, that's running, > > > holds the lock and spin until either lock is freed or thread is not > > > running anymore. In that case we try again to obtain the lock "quick". > > > If the thread only stopped running but still holds the lock, we use > > > > turnstiles > > > > > to wake us up, when the thread unlocks the mutex. > > > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > > > > > But if we're spinning and the other thread gave the mutex free, > > > we quick-lock the mutex and don't set up a turnstile. > > > > > > Now on mtx_unlock_sleep: > > > - in FreeBSD6/until revision 1.200 turnstiles were tested on existence. > > > => if turnstile_lookup return NULL we only released the lock quick. > > > > > > - But now, it's never tested if turnstile exists instead we > > > broadcast/wakeup all threads pending on the turnstile. If this turnstile > > > is NULL => we > > > > access > > > > > wrong memory. > > > > > > Now my question is: Why can we be sure (in new source) that > > > turnstile_lookup always returns a valid pointer to an turnstile and can > > > use returned pointer to call turnstile_broadcast? Am I missing something? > > > > > > Because it seems that following scenario may occur: > > > - on locking same scenario as above (=> thread1 now holds the lock) > > > - thread1 is put off the runqueue > > > - thread2 now tries to quick unlock mutex and sees that thread1 holds it > > > => call to mtx_unlock_sleep > > > - now we try to use turnstile-mechanism and call turnstile_lookup => > > > returns NULL because no thread waits for wakeup => we call > > > turnstile_broadcast and crash. > > > > Newer locks don't set the CONTESTED flag unless they are actually going to > > go to sleep. If they succeed in setting CONTESTED or it is already set > > when they test for it, then they will block on the turnstile. The > > turnstile chain lock will prevent a concurrent unlock from grabbing the > > turnstile until the blocking thread is fully asleep. > > I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! > But there is still the possibility that mtx_lock_sleep "just" obtains the lock > and doesn't set contested-bit! See described case above (we reach first > continue in mtx_lock_sleep and test on obtain_lock ends while-loop). In that case the lock won't have a turnstile, so mtx_unlock_sleep() will never be called. > Why is this bit not tested in mtx_unlock_sleep? If the bit is clear the first attempt to unlock the mutex will succeed, and mtx_unlock_sleep() won't be called. > I think, it's still possible that turnstile_lookup returns NULL. > And we still have "MPASS(ts != NULL);" in mtx_unlock_sleep that is not > turned on for GENERIC-kernel (no INVARIANTS support). It won't return NULL. > And I'm still wondering why the former test on "ts != NULL" went away? As I mentioned, previously when a thread used to do an adaptive spin, it would set the CONTESTED flag before spinning. This could result in the case that a mutex would have CONTESTED set, but not have an associated turnstile. Now that the adaptive spinning happens earlier before setting CONTESTED, mutexes can no longer get into that state. That is, if CONTESTED is set, the mutex always has an assigned turnstile. If CONTESTED isn't set, then the first attempt to unlock a mutex will succeed, and mtx_unlock_sleep() won't be called at all. -- John Baldwin From fbsdlist at src.cx Wed Sep 10 23:37:30 2008 From: fbsdlist at src.cx (Artem Belevich) Date: Wed Sep 10 23:37:37 2008 Subject: Increasing KVM on amd64 Message-ID: Alan, Thanks a lot for the patch. I've applied it to RELENG_7 and it seems to work great - "make -j8 buildworld" succeeds, linux emulation seems to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is bigger, too. So far I didn't see any ZFS-related KVM shortages either. The only problem is that everything is fine as long as vm.kmem_size is set to less or equal to 4096M. As soon as I set it to 4100M or anything larger, kernel crashes on startup. I'm unable to capture exact crash messages as they keep scrolling really fast on the screen for a few seconds until the box reboots. Unfortunately the box does not have built-in serial ports, so the messages are gone before I can see them. :-( Is there a way to bump up KVM size even further - beyond 6GB? I've got a box with 8GB or RAM and would like let ZFS ARC use most of it which would require pretty large vm.kmem_max to fit it in. Thanks, --Artem From koitsu at FreeBSD.org Thu Sep 11 04:28:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 11 04:28:10 2008 Subject: Increasing KVM on amd64 In-Reply-To: References: Message-ID: <20080911042801.GA19245@icarus.home.lan> On Wed, Sep 10, 2008 at 04:12:25PM -0700, Artem Belevich wrote: > Alan, > > Thanks a lot for the patch. I've applied it to RELENG_7 and it seems > to work great - "make -j8 buildworld" succeeds, linux emulation seems > to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is > bigger, too. So far I didn't see any ZFS-related KVM shortages either. > > The only problem is that everything is fine as long as vm.kmem_size is > set to less or equal to 4096M. As soon as I set it to 4100M or > anything larger, kernel crashes on startup. I'm unable to capture > exact crash messages as they keep scrolling really fast on the screen > for a few seconds until the box reboots. Unfortunately the box does > not have built-in serial ports, so the messages are gone before I can > see them. :-( > > Is there a way to bump up KVM size even further - beyond 6GB? I've got > a box with 8GB or RAM and would like let ZFS ARC use most of it which > would require pretty large vm.kmem_max to fit it in. I was told fairly recently (a few days ago) that the 6GB limit was increased to 512GB on HEAD/CURRENT. The 6GB limit was during a "transitional" phase of addressing the problem. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From fbsdlist at src.cx Thu Sep 11 05:24:50 2008 From: fbsdlist at src.cx (Artem Belevich) Date: Thu Sep 11 05:24:57 2008 Subject: Increasing KVM on amd64 In-Reply-To: <48C8A78C.6070608@cs.rice.edu> References: <48C8A78C.6070608@cs.rice.edu> Message-ID: > SVN rev 180308 on 2008-07-05 19:34:33Z by alc > > Enable the creation of a kmem map larger than 4GB. > Submitted by: Tz-Huan Huang > > Make several variables related to kmem map auto-sizing static. > Found by: CScout I did apply Tz-Huan Huang's patch that he pointed to shortly after you've announced your patch. As far as I can tell it's identical to SVN rev 180308 changes. > Second, there is no room for a kmem map greater than 4GB unless the overall > KVM size is greater than 6GB. Specifically, a >4GB kmem map isn't possible > with 6GB KVM because the kmem map would overlap the kernel's code, data, and > bss segment. > > If you're able to apply the above kern_malloc.c change to your kernel, then > I should be able to describe how to increase your KVM beyond 6GB. I'd be glad to give it a try. -- --Artem From alc at cs.rice.edu Thu Sep 11 05:25:42 2008 From: alc at cs.rice.edu (Alan Cox) Date: Thu Sep 11 05:25:49 2008 Subject: Increasing KVM on amd64 In-Reply-To: References: Message-ID: <48C8A78C.6070608@cs.rice.edu> Artem Belevich wrote: >Alan, > >Thanks a lot for the patch. I've applied it to RELENG_7 and it seems >to work great - "make -j8 buildworld" succeeds, linux emulation seems >to work well enough to run linux-sun-jdk14 binaries, ZFS ARC size is >bigger, too. So far I didn't see any ZFS-related KVM shortages either. > >The only problem is that everything is fine as long as vm.kmem_size is >set to less or equal to 4096M. As soon as I set it to 4100M or >anything larger, kernel crashes on startup. I'm unable to capture >exact crash messages as they keep scrolling really fast on the screen >for a few seconds until the box reboots. Unfortunately the box does >not have built-in serial ports, so the messages are gone before I can >see them. :-( > > > There are two underlying causes. First, the size of the kmem map, which holds the kernel's heap, is recorded in a 32-bit int. So, setting vm.kmem_size to 4100M is leading to integer overflow. The following change addresses this issue: sys/kern/kern_malloc.c Revision *1.167*: download - view: text , markup , annotated - select for diffs /Sat Jul 5 19:34:33 2008 UTC/ (2 months ago) by /alc/ Branches: MAIN CVS tags: HEAD Diff to: previous 1.166: preferred , colored Changes since revision 1.166: +11 -11 lines SVN rev 180308 on 2008-07-05 19:34:33Z by alc Enable the creation of a kmem map larger than 4GB. Submitted by: Tz-Huan Huang Make several variables related to kmem map auto-sizing static. Found by: CScout Second, there is no room for a kmem map greater than 4GB unless the overall KVM size is greater than 6GB. Specifically, a >4GB kmem map isn't possible with 6GB KVM because the kmem map would overlap the kernel's code, data, and bss segment. If you're able to apply the above kern_malloc.c change to your kernel, then I should be able to describe how to increase your KVM beyond 6GB. Regards, Alan From rkramer at mweb.com Thu Sep 11 07:39:20 2008 From: rkramer at mweb.com (Rudi Kramer - MWEB) Date: Thu Sep 11 07:39:27 2008 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade References: Message-ID: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> > Steven Hartland: > > Sent: Tuesday, September 09, 2008 12:28 AM > To: freebsd-hackers@freebsd.org > Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade > > I've been trying to install FreeBSD 7.0-RELEASE amd64 on > a Dell M600 Blade but it hangs just after initialising > the isa bus. > > I've tried a number of things and the only thing that I > can get to work is the i386 build which boots into the > installer without issue. > > Has anyone had any experience with the Dell M600 blade > on amd64 or had the amd64 build hang at this point > before. Hi Steven, We recently purchased a few M600's but haven't got around to loading FBSD on them, we should start installing next week and I will let you know if we run in to any problems. Regards Rudi From titanandrews at gmail.com Thu Sep 11 19:35:50 2008 From: titanandrews at gmail.com (Barry Andrews) Date: Thu Sep 11 19:35:56 2008 Subject: loading multi threaded library into executable enabled for single thread Message-ID: Hi All, I have a multi-threaded library that is linked against libpthread. When I load this lib into a tclsh process on FreeBSD, I get this error, "Recurse on private mutex". and crash. I understand that I can have this issue when the executable is not linked against libpthread but one of the loaded libs is. Basically, it thinks it's in single threaded mode. I can get around this issue, by doing export LD_PRELOAD=libpthread.so.1, however this is a hack at best. Is there any other way to get around this issue other than linking tclsh with libpthread ( because that's not an option) I thought of re-building libpthread with the offending code commented out, and that did work, however I ran into other issues, so I think it's not a very "safe" option. My feeling is that this is a FreeBSD issue because it's not happening on other platforms, Linux, Solaris. Any suggestions are welcome. Many thanks! -B * * From brooks at freebsd.org Thu Sep 11 19:56:05 2008 From: brooks at freebsd.org (Brooks Davis) Date: Thu Sep 11 19:56:12 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: References: Message-ID: <20080911195653.GA53111@lor.one-eyed-alien.net> On Thu, Sep 11, 2008 at 03:06:35PM -0400, Barry Andrews wrote: > Hi All, > > I have a multi-threaded library that is linked against libpthread. When I > load this lib into a tclsh process on FreeBSD, I get this error, "Recurse on > private mutex". and crash. I understand that I can have this issue when the > executable is not linked against libpthread but one of the loaded libs is. > Basically, it thinks it's in single threaded mode. > > I can get around this issue, by doing export LD_PRELOAD=libpthread.so.1, > however this is a hack at best. Is there any other way to get around this > issue other than linking tclsh with libpthread ( because that's not an > option) > > I thought of re-building libpthread with the offending code commented out, > and that did work, however I ran into other issues, so I think it's not a > very "safe" option. > > My feeling is that this is a FreeBSD issue because it's not happening on > other platforms, Linux, Solaris. > > Any suggestions are welcome. Many thanks! It would be helpful if you could provide: - your FreeBSD version - the output of "ldd libyourlib.so" - the output of "ldd yourprogram" I wouldn't be supprised to find that the program and library are linked against different threading libraries. If so, one of them will need to be relinked or you will need to use libmap.conf to cause it to use the other one. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080911/d9e23228/attachment.pgp From jille at quis.cx Thu Sep 11 19:56:31 2008 From: jille at quis.cx (Jille Timmermans) Date: Thu Sep 11 19:56:39 2008 Subject: readdir(somefile) returing inconsistent errors Message-ID: <48C971AC.6080001@quis.cx> Hello, I was looking through some vop_readdir()'s, and noticed an inconsistency between (at least) xfs and unionfs. sys/fs/unionfs/union_vnops.c:1410: if(ap->a_vp->v_type != VDIR) return (ENOTDIR); sys/fs/xfs/FreeBSD/xfs_vnops.c:1001: if(vp->v_type != VDIR) return (EPERM); A little userland script gave me a ENOTDIR when trying to opendir(somefile) (userspace opendir() calling kernelspace readdir()). So I assume the check is made earlier, but shouldn't the xfs code return ENOTDIR in this case ? due to the if-clause above it, you'd say ENOTDIR seems better than EPERM. -- Jille From jille at quis.cx Thu Sep 11 19:59:56 2008 From: jille at quis.cx (Jille Timmermans) Date: Thu Sep 11 20:00:07 2008 Subject: Filtering items in readdir() with own fs Message-ID: <48C978B7.3000803@quis.cx> Hello all, I am trying to create a filesystem that works exactly like nullfs, but hides all .svn dirs (and contents) (Yes, I started with svn cp). I've got it working so far that it denies that the dirs and contents exist (grep isn't complaining; so I can finally grep -r through the source). But it would be nice if I can also hide the .svn dirs in dir listings. I have been looking through a few existing filesystems (unionfs, fdescfs, xfs, devfs). None gave me a good way for hiding specific entries in the listing. With some help of unionfs I have created a direct-pass-through using VOP_READDIR(), but I can't filter it with that. I tried using some xfs code, but didn't get any result with that. Can anyone give me a hint on where to start looking for code that could be used with filtering functionality ? Any file or function ? Thanks in advance, -- Jille From llc2w at virginia.edu Thu Sep 11 20:31:36 2008 From: llc2w at virginia.edu (L Campbell) Date: Thu Sep 11 20:31:42 2008 Subject: Filtering items in readdir() with own fs In-Reply-To: <48C978B7.3000803@quis.cx> References: <48C978B7.3000803@quis.cx> Message-ID: <792298050809111305s5a4d4cbcxb56d7756b5af8879@mail.gmail.com> Just as a random comment, if you wanted to grep over a svn-managed directory hierarchy, you could simply do -- find . \! -ipath '*/.svn*' | xargs grep -H search_string On Thu, Sep 11, 2008 at 3:59 PM, Jille Timmermans wrote: > Hello all, > > > I am trying to create a filesystem that works exactly like nullfs, but > hides all .svn dirs (and contents) (Yes, I started with svn cp). > I've got it working so far that it denies that the dirs and contents > exist (grep isn't complaining; so I can finally grep -r through the source). > But it would be nice if I can also hide the .svn dirs in dir listings. > > > > I have been looking through a few existing filesystems (unionfs, > fdescfs, xfs, devfs). > None gave me a good way for hiding specific entries in the listing. > With some help of unionfs I have created a direct-pass-through using > VOP_READDIR(), but I can't filter it with that. > I tried using some xfs code, but didn't get any result with that. > > > > Can anyone give me a hint on where to start looking for code that could > be used with filtering functionality ? > Any file or function ? > > > Thanks in advance, > -- Jille > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From deischen at freebsd.org Thu Sep 11 20:42:49 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Sep 11 20:42:56 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: References: Message-ID: On Thu, 11 Sep 2008, Barry Andrews wrote: > Hi All, > > I have a multi-threaded library that is linked against libpthread. When I > load this lib into a tclsh process on FreeBSD, I get this error, "Recurse on > private mutex". and crash. I understand that I can have this issue when the > executable is not linked against libpthread but one of the loaded libs is. > Basically, it thinks it's in single threaded mode. This must be an older version of FreeBSD. I think you must link your application (tclsh or whatever) against libpthread in order for this to work. The libc functions won't get properly overloaded by their equivalents in libpthread unless you do this. -- DE From killing at multiplay.co.uk Thu Sep 11 23:12:22 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Thu Sep 11 23:12:29 2008 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Message-ID: Thanks Rudi, would really like to get is sorted as they would make ideal app servers. ----- Original Message ----- From: "Rudi Kramer - MWEB" Hi Steven, We recently purchased a few M600's but haven't got around to loading FBSD on them, we should start installing next week and I will let you know if we run in to any problems. ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From titanandrews at gmail.com Fri Sep 12 00:13:26 2008 From: titanandrews at gmail.com (Barry Andrews) Date: Fri Sep 12 00:13:38 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <20080911195653.GA53111@lor.one-eyed-alien.net> References: <20080911195653.GA53111@lor.one-eyed-alien.net> Message-ID: FreeBSD version 5.5 output of ldd for my lib is: libbase.so: libutils.so => ./libutils.so (0x287e0000) libACE.so.5.5.6 => ./libACE.so.5.5.6 (0x2882d000) libxerces-c.so.27 => ./libxerces-c.so.27 (0x28976000) libsqlite3.so.8 => ./libsqlite3.so.8 (0x28d23000) libboost_regex-gcc40-mt-d-1_34.so.1.34.0 => ./libboost_regex-gcc40-mt-d-1_34.so.1.34.0 (0x28d76000) libstdc++.so.6 => ./libstdc++.so.6 (0x28e82000) libm.so.3 => /lib/libm.so.3 (0x28f53000) libgcc_s.so.1 => ./libgcc_s.so.1 (0x28f6e000) libpthread.so.1 => /usr/lib/libpthread.so.1 (0x28f78000) libc.so.5 => /lib/libc.so.5 (0x28079000) output of ldd for tclsh is: libtcl84.so.1 => /usr/local/lib/libtcl84.so.1 (0x28076000) libm.so.3 => /lib/libm.so.3 (0x28114000) libc.so.5 => /lib/libc.so.5 (0x2812f000) On Thu, Sep 11, 2008 at 3:56 PM, Brooks Davis wrote: > On Thu, Sep 11, 2008 at 03:06:35PM -0400, Barry Andrews wrote: > > Hi All, > > > > I have a multi-threaded library that is linked against libpthread. When I > > load this lib into a tclsh process on FreeBSD, I get this error, "Recurse > on > > private mutex". and crash. I understand that I can have this issue when > the > > executable is not linked against libpthread but one of the loaded libs > is. > > Basically, it thinks it's in single threaded mode. > > > > I can get around this issue, by doing export LD_PRELOAD=libpthread.so.1, > > however this is a hack at best. Is there any other way to get around this > > issue other than linking tclsh with libpthread ( because that's not an > > option) > > > > I thought of re-building libpthread with the offending code commented > out, > > and that did work, however I ran into other issues, so I think it's not a > > very "safe" option. > > > > My feeling is that this is a FreeBSD issue because it's not happening on > > other platforms, Linux, Solaris. > > > > Any suggestions are welcome. Many thanks! > > It would be helpful if you could provide: > - your FreeBSD version > - the output of "ldd libyourlib.so" > - the output of "ldd yourprogram" > > I wouldn't be supprised to find that the program and library are linked > against > different threading libraries. If so, one of them will need to be relinked > or > you will need to use libmap.conf to cause it to use the other one. > > -- Brooks > From kmf at fischer.org.za Fri Sep 12 06:26:20 2008 From: kmf at fischer.org.za (Karl Fischer) Date: Fri Sep 12 06:26:51 2008 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade In-Reply-To: References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Message-ID: On Fri, Sep 12, 2008 at 01:00, Steven Hartland wrote: > Thanks Rudi, would really like to get is sorted as they would make > ideal app servers. > > ----- Original Message ----- From: "Rudi Kramer - MWEB" > > > Hi Steven, > > We recently purchased a few M600's but haven't got around to loading > FBSD on them, we should start installing next week and I will let you > know if we run in to any problems. I have the same problem on my M600 Blades has anyone tested the 7.1 Beta and I'm about to purchase more of them. Karl -- -------------------------------------------------- Karl Fischer |_|0|_| "Absence of evidence |_|_|0| is not evidence of absence" |0|0|0| Carl Sagan - http://fischer.org.za - -------------------------------------------------- From kpielorz_lst at tdx.co.uk Fri Sep 12 09:59:04 2008 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Fri Sep 12 09:59:11 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? Message-ID: Hi, Recently, a ZFS pool on my FreeBSD box started showing lots of errors on one drive in a mirrored pair. The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on each controller). One of the drives started picking up a lot of errors (by the end of things it was returning errors pretty much for any reads/writes issued) - and taking ages to complete the I/O's. However, ZFS kept trying to use the drive - e.g. as I attached another drive to the remaining 'good' drive in the mirrored pair, ZFS was still trying to read data off the failed drive (and remaining good one) in order to complete it's re-silver to the newly attached drive. Having posted on the Open Solaris ZFS list - it appears, under Solaris there's an 'FMA Engine' which communicates drive failures and the like to ZFS - advising ZFS when a drive should be marked as 'failed'. Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything on the system tell ZFS "This drives experiencing failures" rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears to be the case). In the end, the failing drive was timing out literally every I/O - I did recover the situation by detaching it from the pool (which hung the machine - probably caused by ZFS having to update the meta-data on all drives, including the failed one). A reboot bought the pool back, minus the 'failed' drive, so enough of the 'detach' must have completed. The newly attached drive completed the re-silver in half an hour (as opposed to an estimated 755 hours and climbing with the other drive still in the pool, limping along). -Kp From titanandrews at gmail.com Fri Sep 12 11:40:56 2008 From: titanandrews at gmail.com (Barry Andrews) Date: Fri Sep 12 11:41:03 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: References: Message-ID: <48CA555A.4050104@gmail.com> Do you know if this is documented in Release Notes or Known Issues or somewhere? thanks, B Daniel Eischen wrote: > On Thu, 11 Sep 2008, Barry Andrews wrote: > >> Hi All, >> >> I have a multi-threaded library that is linked against libpthread. >> When I >> load this lib into a tclsh process on FreeBSD, I get this error, >> "Recurse on >> private mutex". and crash. I understand that I can have this issue >> when the >> executable is not linked against libpthread but one of the loaded >> libs is. >> Basically, it thinks it's in single threaded mode. > > This must be an older version of FreeBSD. I think you must > link your application (tclsh or whatever) against libpthread > in order for this to work. The libc functions won't get properly > overloaded by their equivalents in libpthread unless you do > this. > From koitsu at FreeBSD.org Fri Sep 12 13:10:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 13:10:56 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <48CA555A.4050104@gmail.com> References: <48CA555A.4050104@gmail.com> Message-ID: <20080912131045.GA56923@icarus.home.lan> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > Do you know if this is documented in Release Notes or Known Issues or > somewhere? Why would it be an "issue"? gcc -pthread and libpthread linking is documented pretty much everywhere on the web. There isn't anything broken about it, it's how it's done on older FreeBSD. Note that all of this has significantly changed in later FreeBSD versions, and that the 5.x series was deprecated a very long time ago. >> On Thu, 11 Sep 2008, Barry Andrews wrote: >> >>> Hi All, >>> >>> I have a multi-threaded library that is linked against libpthread. >>> When I >>> load this lib into a tclsh process on FreeBSD, I get this error, >>> "Recurse on >>> private mutex". and crash. I understand that I can have this issue >>> when the >>> executable is not linked against libpthread but one of the loaded >>> libs is. >>> Basically, it thinks it's in single threaded mode. >> >> This must be an older version of FreeBSD. I think you must >> link your application (tclsh or whatever) against libpthread >> in order for this to work. The libc functions won't get properly >> overloaded by their equivalents in libpthread unless you do >> this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Sep 12 13:21:04 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 13:21:11 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: References: Message-ID: <20080912132102.GB56923@icarus.home.lan> On Fri, Sep 12, 2008 at 10:45:24AM +0100, Karl Pielorz wrote: > Recently, a ZFS pool on my FreeBSD box started showing lots of errors on > one drive in a mirrored pair. > > The pool consists of around 14 drives (as 7 mirrored pairs), hung off of > a couple of SuperMicro 8 port SATA controllers (1 drive of each pair is > on each controller). > > One of the drives started picking up a lot of errors (by the end of > things it was returning errors pretty much for any reads/writes issued) - > and taking ages to complete the I/O's. > > However, ZFS kept trying to use the drive - e.g. as I attached another > drive to the remaining 'good' drive in the mirrored pair, ZFS was still > trying to read data off the failed drive (and remaining good one) in > order to complete it's re-silver to the newly attached drive. > > Having posted on the Open Solaris ZFS list - it appears, under Solaris > there's an 'FMA Engine' which communicates drive failures and the like to > ZFS - advising ZFS when a drive should be marked as 'failed'. > > Is there anything similar to this on FreeBSD yet? - i.e. Does/can > anything on the system tell ZFS "This drives experiencing failures" > rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears > to be the case). As far as I know, there is no such "standard" mechanism in FreeBSD. If the drive falls off the bus entirely (e.g. detached), I would hope ZFS would notice that. I can imagine it (might) also depend on if the disk subsystem you're using is utilising CAM or not (e.g. disks should be daX not adX); Scott Long might know if something like this is implemented in CAM. I'm fairly certain nothing like this is implemented in ata(4). Ideally, it would be the job of the controller and controller driver to announce to underlying I/O operations fail/success. Do you agree? I hope this "FMA Engine" on Solaris only *tells* underlying pieces of I/O errors, rather than acting on them (e.g. automatically yanking the disk off the bus for you). I'm in no way shunning Solaris, I'm simply saying such a mechanism could be as risky/deadly as it could be useful. > In the end, the failing drive was timing out literally every I/O - I did > recover the situation by detaching it from the pool (which hung the > machine - probably caused by ZFS having to update the meta-data on all > drives, including the failed one). A reboot bought the pool back, minus > the 'failed' drive, so enough of the 'detach' must have completed. > > The newly attached drive completed the re-silver in half an hour (as > opposed to an estimated 755 hours and climbing with the other drive still > in the pool, limping along). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From titanandrews at gmail.com Fri Sep 12 13:26:40 2008 From: titanandrews at gmail.com (Barry Andrews) Date: Fri Sep 12 13:26:47 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <20080912131045.GA56923@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> Message-ID: I don't understand. If it was not broken, then why did it change in later FreeBSD versions? On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > > Do you know if this is documented in Release Notes or Known Issues or > > somewhere? > > Why would it be an "issue"? gcc -pthread and libpthread linking is > documented pretty much everywhere on the web. There isn't anything > broken about it, it's how it's done on older FreeBSD. > > Note that all of this has significantly changed in later FreeBSD > versions, and that the 5.x series was deprecated a very long time ago. > > >> On Thu, 11 Sep 2008, Barry Andrews wrote: > >> > >>> Hi All, > >>> > >>> I have a multi-threaded library that is linked against libpthread. > >>> When I > >>> load this lib into a tclsh process on FreeBSD, I get this error, > >>> "Recurse on > >>> private mutex". and crash. I understand that I can have this issue > >>> when the > >>> executable is not linked against libpthread but one of the loaded > >>> libs is. > >>> Basically, it thinks it's in single threaded mode. > >> > >> This must be an older version of FreeBSD. I think you must > >> link your application (tclsh or whatever) against libpthread > >> in order for this to work. The libc functions won't get properly > >> overloaded by their equivalents in libpthread unless you do > >> this. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From koitsu at FreeBSD.org Fri Sep 12 13:51:14 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 13:51:21 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> Message-ID: <20080912135110.GA57637@icarus.home.lan> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > I don't understand. If it was not broken, then why did it change in later > FreeBSD versions? I should be more explicit: the threading library and implementations have changed over time. There was libc_r, then there was libthr, then there was libkse. This is what we call "evolution". :-) http://www.unobvious.com/bsd/freebsd-threads.html http://kerneltrap.org/node/624 http://www.freebsd.org/kse/ The gcc -pthread flag is still there on present-day FreeBSD (6 through HEAD), and *should* be used. You can choose not to use it but you must ensure during linktime that you explicitly link to -lpthread. > On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: > > > On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > > > Do you know if this is documented in Release Notes or Known Issues or > > > somewhere? > > > > Why would it be an "issue"? gcc -pthread and libpthread linking is > > documented pretty much everywhere on the web. There isn't anything > > broken about it, it's how it's done on older FreeBSD. > > > > Note that all of this has significantly changed in later FreeBSD > > versions, and that the 5.x series was deprecated a very long time ago. > > > > >> On Thu, 11 Sep 2008, Barry Andrews wrote: > > >> > > >>> Hi All, > > >>> > > >>> I have a multi-threaded library that is linked against libpthread. > > >>> When I > > >>> load this lib into a tclsh process on FreeBSD, I get this error, > > >>> "Recurse on > > >>> private mutex". and crash. I understand that I can have this issue > > >>> when the > > >>> executable is not linked against libpthread but one of the loaded > > >>> libs is. > > >>> Basically, it thinks it's in single threaded mode. > > >> > > >> This must be an older version of FreeBSD. I think you must > > >> link your application (tclsh or whatever) against libpthread > > >> in order for this to work. The libc functions won't get properly > > >> overloaded by their equivalents in libpthread unless you do > > >> this. > > > > -- > > | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kpielorz_lst at tdx.co.uk Fri Sep 12 14:37:05 2008 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Fri Sep 12 14:37:12 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080912132102.GB56923@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> Message-ID: <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> --On 12 September 2008 06:21 -0700 Jeremy Chadwick wrote: > As far as I know, there is no such "standard" mechanism in FreeBSD. If > the drive falls off the bus entirely (e.g. detached), I would hope ZFS > would notice that. I can imagine it (might) also depend on if the disk > subsystem you're using is utilising CAM or not (e.g. disks should be daX > not adX); Scott Long might know if something like this is implemented in > CAM. I'm fairly certain nothing like this is implemented in ata(4). For ATA, at the moment - I don't think it'll notice even if a drive detaches. I think like my system the other day, it'll just keep issuing I/O commands to the drive, even if it's disappeared (it might get much 'quicker failures' if the device has 'gone' to the point of FreeBSD just quickly returning 'fail' for every request). > Ideally, it would be the job of the controller and controller driver to > announce to underlying I/O operations fail/success. Do you agree? > > I hope this "FMA Engine" on Solaris only *tells* underlying pieces of > I/O errors, rather than acting on them (e.g. automatically yanking the > disk off the bus for you). I'm in no way shunning Solaris, I'm simply > saying such a mechanism could be as risky/deadly as it could be useful. Yeah, I guess so - I think the way it's meant to happen (and this is only AFAIK) is that FMA 'detects' a failing drive by applying some configurable policy to it. That policy would also include notifying ZFS, so that ZFS could then decide to stop issuing I/O commands to that device. None of this seems to be in place, at least for ATA under FreeBSD - when a drive goes bad, you can just end up with 'hours' worth of I/O timeouts, until someone intervenes. I did enquire on the Open Solaris list about setting limits for 'errors' in ZFS, which netted me a reply that it's FMA (at least in Solaris) that's responsible for this - it just then informs ZFS of the condition. We don't appear (again at least for ATA) to have anything similar for FreeBSD yet :( -Kp From titanandrews at gmail.com Fri Sep 12 15:00:23 2008 From: titanandrews at gmail.com (Barry Andrews) Date: Fri Sep 12 15:00:30 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <20080912135110.GA57637@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> Message-ID: <48CA8402.5040207@gmail.com> Thanks for the links! But I'm not sure what any of this has to do with this particular issue. I have an exe that does not use threads that loads a lib that is linked with libpthread. Why does different threading implementations affect what I am seeing here? Is there no way for this to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or better? thanks, B Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > >> I don't understand. If it was not broken, then why did it change in later >> FreeBSD versions? >> > > I should be more explicit: the threading library and implementations > have changed over time. There was libc_r, then there was libthr, then > there was libkse. This is what we call "evolution". :-) > > http://www.unobvious.com/bsd/freebsd-threads.html > http://kerneltrap.org/node/624 > http://www.freebsd.org/kse/ > > The gcc -pthread flag is still there on present-day FreeBSD (6 through > HEAD), and *should* be used. You can choose not to use it but you must > ensure during linktime that you explicitly link to -lpthread. > > >> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: >> >> >>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: >>> >>>> Do you know if this is documented in Release Notes or Known Issues or >>>> somewhere? >>>> >>> Why would it be an "issue"? gcc -pthread and libpthread linking is >>> documented pretty much everywhere on the web. There isn't anything >>> broken about it, it's how it's done on older FreeBSD. >>> >>> Note that all of this has significantly changed in later FreeBSD >>> versions, and that the 5.x series was deprecated a very long time ago. >>> >>> >>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: >>>>> >>>>> >>>>>> Hi All, >>>>>> >>>>>> I have a multi-threaded library that is linked against libpthread. >>>>>> When I >>>>>> load this lib into a tclsh process on FreeBSD, I get this error, >>>>>> "Recurse on >>>>>> private mutex". and crash. I understand that I can have this issue >>>>>> when the >>>>>> executable is not linked against libpthread but one of the loaded >>>>>> libs is. >>>>>> Basically, it thinks it's in single threaded mode. >>>>>> >>>>> This must be an older version of FreeBSD. I think you must >>>>> link your application (tclsh or whatever) against libpthread >>>>> in order for this to work. The libc functions won't get properly >>>>> overloaded by their equivalents in libpthread unless you do >>>>> this. >>>>> >>> -- >>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> > > From olli at lurza.secnetix.de Fri Sep 12 15:44:30 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Sep 12 15:44:37 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: Message-ID: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> Karl Pielorz wrote: > Recently, a ZFS pool on my FreeBSD box started showing lots of errors on > one drive in a mirrored pair. > > The pool consists of around 14 drives (as 7 mirrored pairs), hung off of a > couple of SuperMicro 8 port SATA controllers (1 drive of each pair is on > each controller). > > One of the drives started picking up a lot of errors (by the end of things > it was returning errors pretty much for any reads/writes issued) - and > taking ages to complete the I/O's. > > However, ZFS kept trying to use the drive - e.g. as I attached another > drive to the remaining 'good' drive in the mirrored pair, ZFS was still > trying to read data off the failed drive (and remaining good one) in order > to complete it's re-silver to the newly attached drive. > > Having posted on the Open Solaris ZFS list - it appears, under Solaris > there's an 'FMA Engine' which communicates drive failures and the like to > ZFS - advising ZFS when a drive should be marked as 'failed'. > > Is there anything similar to this on FreeBSD yet? - i.e. Does/can anything > on the system tell ZFS "This drives experiencing failures" rather than ZFS > just seeing lots of timed out I/O 'errors'? (as appears to be the case). > > In the end, the failing drive was timing out literally every I/O - I did > recover the situation by detaching it from the pool (which hung the machine > - probably caused by ZFS having to update the meta-data on all drives, > including the failed one). A reboot bought the pool back, minus the > 'failed' drive, so enough of the 'detach' must have completed. Did you try "atacontrol detach" to remove the disk from the bus? I haven't tried that with ZFS, but gmirror automatically detects when a disk has gone away, and doesn't try to do anything with it anymore. It certainly should not hang the machine. After all, what's the purpose of a RAID when you have to reboot upon drive failure. ;-) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is over-complicated nonsense. And Bjorn Shoestrap's book a danger to public health. I tried reading it once, I was in recovery for months." -- Cliff Sarginson From koitsu at FreeBSD.org Fri Sep 12 15:45:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 15:45:30 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <48CA8402.5040207@gmail.com> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> Message-ID: <20080912154520.GA60094@icarus.home.lan> On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > Thanks for the links! But I'm not sure what any of this has to do with > this particular issue. I have an exe that does not use threads that > loads a lib that is linked with libpthread. Why does different threading > implementations affect what I am seeing here? Is there no way for this > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > better? You're confusing me. Earlier you said: >>>>>>> I have a multi-threaded library that is linked against libpthread. >>>>>>> When I >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, So what is "the exe?" Are you referring to tclsh? If so, you need to rebuild tclsh from source to link with libpthread. If not, you need to contact whoever provided the binary and ask them to rebuild it from source. Additionally, please ensure that the tclsh binary is linked to the same version of libpthread library as your own library. You want to make sure they're both built and linked on the same machine (from the same source code) if possible; the simple ".so.X" versioning method works great for major changes, but there are often minor changes that don't result in "X" being increased. I'm getting the impression that the tclsh binary you have was not built on the same machine / from the same source as what your library (the one linked with libpthread) was. > Jeremy Chadwick wrote: >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: >> >>> I don't understand. If it was not broken, then why did it change in later >>> FreeBSD versions? >>> >> >> I should be more explicit: the threading library and implementations >> have changed over time. There was libc_r, then there was libthr, then >> there was libkse. This is what we call "evolution". :-) >> >> http://www.unobvious.com/bsd/freebsd-threads.html >> http://kerneltrap.org/node/624 >> http://www.freebsd.org/kse/ >> >> The gcc -pthread flag is still there on present-day FreeBSD (6 through >> HEAD), and *should* be used. You can choose not to use it but you must >> ensure during linktime that you explicitly link to -lpthread. >> >> >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick wrote: >>> >>> >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: >>>> >>>>> Do you know if this is documented in Release Notes or Known Issues or >>>>> somewhere? >>>>> >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is >>>> documented pretty much everywhere on the web. There isn't anything >>>> broken about it, it's how it's done on older FreeBSD. >>>> >>>> Note that all of this has significantly changed in later FreeBSD >>>> versions, and that the 5.x series was deprecated a very long time ago. >>>> >>>> >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: >>>>>> >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> I have a multi-threaded library that is linked against libpthread. >>>>>>> When I >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, >>>>>>> "Recurse on >>>>>>> private mutex". and crash. I understand that I can have this issue >>>>>>> when the >>>>>>> executable is not linked against libpthread but one of the loaded >>>>>>> libs is. >>>>>>> Basically, it thinks it's in single threaded mode. >>>>>>> >>>>>> This must be an older version of FreeBSD. I think you must >>>>>> link your application (tclsh or whatever) against libpthread >>>>>> in order for this to work. The libc functions won't get properly >>>>>> overloaded by their equivalents in libpthread unless you do >>>>>> this. >>>>>> >>>> -- >>>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >>> >> >> > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From titanandrews at gmail.com Fri Sep 12 15:55:03 2008 From: titanandrews at gmail.com (Barry Andrews) Date: Fri Sep 12 15:55:11 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <20080912154520.GA60094@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> Message-ID: Yes, the exe is tclsh. I understand that linking tclsh with libpthread is what would work. However this is very impractical. A user of my library shouldn't have to rebuild their tclsh to match my library specs. Another option would be to ship tclsh with my lib, but that also is a little weird. It seems like the only somewhat practical option I have is to use LD_PRELOAD, which is also weird but better than nothing. On Fri, Sep 12, 2008 at 11:45 AM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > > Thanks for the links! But I'm not sure what any of this has to do with > > this particular issue. I have an exe that does not use threads that > > loads a lib that is linked with libpthread. Why does different threading > > implementations affect what I am seeing here? Is there no way for this > > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > > better? > > You're confusing me. Earlier you said: > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > >>>>>>> When I > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > So what is "the exe?" Are you referring to tclsh? If so, you need to > rebuild tclsh from source to link with libpthread. If not, you need to > contact whoever provided the binary and ask them to rebuild it from > source. > > Additionally, please ensure that the tclsh binary is linked to the same > version of libpthread library as your own library. You want to make > sure they're both built and linked on the same machine (from the same > source code) if possible; the simple ".so.X" versioning method works > great for major changes, but there are often minor changes that don't > result in "X" being increased. > > I'm getting the impression that the tclsh binary you have was not built > on the same machine / from the same source as what your library (the one > linked with libpthread) was. > > > Jeremy Chadwick wrote: > >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > >> > >>> I don't understand. If it was not broken, then why did it change in > later > >>> FreeBSD versions? > >>> > >> > >> I should be more explicit: the threading library and implementations > >> have changed over time. There was libc_r, then there was libthr, then > >> there was libkse. This is what we call "evolution". :-) > >> > >> http://www.unobvious.com/bsd/freebsd-threads.html > >> http://kerneltrap.org/node/624 > >> http://www.freebsd.org/kse/ > >> > >> The gcc -pthread flag is still there on present-day FreeBSD (6 through > >> HEAD), and *should* be used. You can choose not to use it but you must > >> ensure during linktime that you explicitly link to -lpthread. > >> > >> > >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick > wrote: > >>> > >>> > >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > >>>> > >>>>> Do you know if this is documented in Release Notes or Known Issues or > >>>>> somewhere? > >>>>> > >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is > >>>> documented pretty much everywhere on the web. There isn't anything > >>>> broken about it, it's how it's done on older FreeBSD. > >>>> > >>>> Note that all of this has significantly changed in later FreeBSD > >>>> versions, and that the 5.x series was deprecated a very long time ago. > >>>> > >>>> > >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: > >>>>>> > >>>>>> > >>>>>>> Hi All, > >>>>>>> > >>>>>>> I have a multi-threaded library that is linked against libpthread. > >>>>>>> When I > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > >>>>>>> "Recurse on > >>>>>>> private mutex". and crash. I understand that I can have this issue > >>>>>>> when the > >>>>>>> executable is not linked against libpthread but one of the loaded > >>>>>>> libs is. > >>>>>>> Basically, it thinks it's in single threaded mode. > >>>>>>> > >>>>>> This must be an older version of FreeBSD. I think you must > >>>>>> link your application (tclsh or whatever) against libpthread > >>>>>> in order for this to work. The libc functions won't get properly > >>>>>> overloaded by their equivalents in libpthread unless you do > >>>>>> this. > >>>>>> > >>>> -- > >>>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > >>> To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > >>> > >> > >> > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From fjwcash at gmail.com Fri Sep 12 15:59:09 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Sep 12 15:59:15 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: References: Message-ID: <200809120833.28233.fjwcash@gmail.com> On September 12, 2008 02:45 am Karl Pielorz wrote: > Recently, a ZFS pool on my FreeBSD box started showing lots of errors > on one drive in a mirrored pair. > > The pool consists of around 14 drives (as 7 mirrored pairs), hung off > of a couple of SuperMicro 8 port SATA controllers (1 drive of each pair > is on each controller). > > One of the drives started picking up a lot of errors (by the end of > things it was returning errors pretty much for any reads/writes issued) > - and taking ages to complete the I/O's. > > However, ZFS kept trying to use the drive - e.g. as I attached another > drive to the remaining 'good' drive in the mirrored pair, ZFS was still > trying to read data off the failed drive (and remaining good one) in > order to complete it's re-silver to the newly attached drive. For the one time I've had a drive fail, and the three times I've replaced drives for larger ones, the process used was: zpool offline zpool replace For one machine, I had to shut it off after the offline, as it didn't have hot-swappable drive bays. For the other machine, it did everything while online and running. IOW, the old device never had a chance to interfere with anything. Same process we've used with hardware RAID setups in the past. > Is there anything similar to this on FreeBSD yet? - i.e. Does/can > anything on the system tell ZFS "This drives experiencing failures" > rather than ZFS just seeing lots of timed out I/O 'errors'? (as appears > to be the case). Beyond the periodic script that checks for things like this, and sends root an e-mail, I haven't seen anything. -- Freddie Cash fjwcash@gmail.com From koitsu at FreeBSD.org Fri Sep 12 16:04:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 16:04:38 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> Message-ID: <20080912160422.GB60094@icarus.home.lan> On Fri, Sep 12, 2008 at 03:34:30PM +0100, Karl Pielorz wrote: > --On 12 September 2008 06:21 -0700 Jeremy Chadwick > wrote: > >> As far as I know, there is no such "standard" mechanism in FreeBSD. If >> the drive falls off the bus entirely (e.g. detached), I would hope ZFS >> would notice that. I can imagine it (might) also depend on if the disk >> subsystem you're using is utilising CAM or not (e.g. disks should be daX >> not adX); Scott Long might know if something like this is implemented in >> CAM. I'm fairly certain nothing like this is implemented in ata(4). > > For ATA, at the moment - I don't think it'll notice even if a drive > detaches. I think like my system the other day, it'll just keep issuing > I/O commands to the drive, even if it's disappeared (it might get much > 'quicker failures' if the device has 'gone' to the point of FreeBSD just > quickly returning 'fail' for every request). I know ATA will notice a detached channel, because I myself have done it: administratively, that is -- atacontrol detach ataX. But the only time that can happen "automatically" is if the actual controller does so itself, or if FreeBSD is told to do it administratively. What this does to other parts of the kernel and userland applications is something I haven't tested. I *can* tell you that there are major, major problems with detach/reattach/reinit on ata(4) causing kernel panics and other such things. I've documented this quite thoroughly in my "Common FreeBSD issues" wiki: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues I am also very curious to know the exact brand/model of 8-port SATA controller from Supermicro you are using, *especially* if it uses ata(4) rather than CAM and da(4). Such Supermicro controllers were recently discussed on freebsd-stable (or was it -hardware?), and no one was able to come to a concise decision as to whether or not they were decent or even remotely trusted. Supermicro provides a few different SATA HBAs. >> Ideally, it would be the job of the controller and controller driver to >> announce to underlying I/O operations fail/success. Do you agree? >> >> I hope this "FMA Engine" on Solaris only *tells* underlying pieces of >> I/O errors, rather than acting on them (e.g. automatically yanking the >> disk off the bus for you). I'm in no way shunning Solaris, I'm simply >> saying such a mechanism could be as risky/deadly as it could be useful. > > Yeah, I guess so - I think the way it's meant to happen (and this is only > AFAIK) is that FMA 'detects' a failing drive by applying some > configurable policy to it. That policy would also include notifying ZFS, > so that ZFS could then decide to stop issuing I/O commands to that > device. It sounds like that is done very differently than on FreeBSD. If such a condition happens on FreeBSD (disk errors scrolling by, etc.), the only way I know of to get FreeBSD to stop sending commands through the ATA subsystem is to detach the channel (atacontrol detach ataX). > None of this seems to be in place, at least for ATA under FreeBSD - when > a drive goes bad, you can just end up with 'hours' worth of I/O timeouts, > until someone intervenes. I can see the usefulness in Solaris's FMA thing. My big concern is whether or not FMA actually pulls the disk off the channel, or if it just leaves the disk/channel connected and simply informs kernel pieces not to use it. If it pulls the disk off the channel, I have serious qualms with it. There are also chips on SATA and SCSI controllers which can cause chaos as well -- specifically, SES/SES2 chips (I'm looking at you, QLogic). These are supposed to be "smart chips" that detect when there are a large number of transport or hardware errors (implying cabling issues, etc.) and *automatically* yank the disk off the bus. Sounds great on paper, but in the field, I see these chips start pulling disks off the bus, changing SCSI IDs on devices, or induce what appear to be full SCSI subsystem timeouts (e.g. the SES/SES2 chip has locked up/crashed in some way, and now your entire bus is dead in the water). I have seen all of the above bugs with onboard Adaptec 320 controllers, the systems running Solaris 8, 9, and OpenSolaris. Most times it turns out to be the SES/SES2 chip getting in the way. > I did enquire on the Open Solaris list about setting limits for 'errors' > in ZFS, which netted me a reply that it's FMA (at least in Solaris) > that's responsible for this - it just then informs ZFS of the condition. > We don't appear (again at least for ATA) to have anything similar for > FreeBSD yet :( My recommendation to people these days is to avoid ata(4) on FreeBSD at all costs if they expect to encounter disk or hardware failures. The ata(4) layer is in no way shape or form reliable in the case of transport or disk failures, and even sometimes in the case of hot- swapping. Try your hardest to find a physical controller that supports SATA disks and uses CAM/da(4), which WILL provide that reliability. I know Areca controllers do this, and Areca is very FreeBSD-friendly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From zbeeble at gmail.com Fri Sep 12 16:04:30 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Fri Sep 12 16:04:38 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> Message-ID: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> On Fri, Sep 12, 2008 at 11:44 AM, Oliver Fromme wrote: > Did you try "atacontrol detach" to remove the disk from > the bus? I haven't tried that with ZFS, but gmirror > automatically detects when a disk has gone away, and > doesn't try to do anything with it anymore. It certainly > should not hang the machine. After all, what's the > purpose of a RAID when you have to reboot upon drive > failure. ;-) To be fair, many "home" users run RAID without the expectation of being able to hot swap the drives. While RAID can provide high availability, but it can also provide simple data security. In my home environment, I have a number of machines running. I have a few things on non-redundant disks --- mostly operating systems or local archives of internet data (like a cvsup server, for instance). Those disks can be lost, and while it's a nuisance, it's not catastrophic. Other things (from family photos to mp3s to other media) I keep on home RAID arrays. They're not hot swap... but I've had quite a few disks go bad over the years. I actually welcome ZFS for this --- the idea that checksums are kepts makes me feel a lot more secure about my data. I have observed some bitrot over time on some data. To your point... I suppose you have to reboot at some point after the drive failure, but my experience has been that the reboot has been under my control some time after the failure (usually when I have the replacement drive). For the home user, this can be quite inexpensive, too. I've found a case that can take 19 drives internally (and has good cooling for about $125). If you used some of the 5-to-3 drive bays, that number would increase to 25. About the only real improvement I'd like to see in this setup is the ability to spin down idle drives. That would be an ideal setup for the home RAID array. From koitsu at FreeBSD.org Fri Sep 12 16:09:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 16:09:10 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> Message-ID: <20080912160900.GC60094@icarus.home.lan> On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote: > Yes, the exe is tclsh. I understand that linking tclsh with libpthread is > what would work. However this is very impractical. A user of my library > shouldn't have to rebuild their tclsh to match my library specs. Another > option would be to ship tclsh with my lib, but that also is a little weird. > It seems like the only somewhat practical option I have is to use > LD_PRELOAD, which is also weird but better than nothing. This really isn't a "FreeBSD problem", as the same sort of issue plagues other operating systems. When it comes to threading, you want *everything* threaded as much as possible -- mix-matching usually does not work. The only OS I have seen where that kind of environment works reliably is Solaris. I still feel threading is "too new" of a technology on UNIX. Your options as I see them: 1) Require your users to ensure they have a threaded TCL installation, and do not promise support in the case they try to use your library on a non-threaded installation, 1) Provide two versions of your library -- a threaded and non-threaded version. This may be impractical for performance reasons, 3) Require LD_PRELOAD, which is ugly, agreed. I think those are pretty much the only options you have at this point. Not a great set, I know, but it's reality. > On Fri, Sep 12, 2008 at 11:45 AM, Jeremy Chadwick wrote: > > > On Fri, Sep 12, 2008 at 11:00:18AM -0400, Barry Andrews wrote: > > > Thanks for the links! But I'm not sure what any of this has to do with > > > this particular issue. I have an exe that does not use threads that > > > loads a lib that is linked with libpthread. Why does different threading > > > implementations affect what I am seeing here? Is there no way for this > > > to work in FreeBSD v5.5? Why would this go away if I upgraded to 6.x or > > > better? > > > > You're confusing me. Earlier you said: > > > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > > >>>>>>> When I > > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > > > So what is "the exe?" Are you referring to tclsh? If so, you need to > > rebuild tclsh from source to link with libpthread. If not, you need to > > contact whoever provided the binary and ask them to rebuild it from > > source. > > > > Additionally, please ensure that the tclsh binary is linked to the same > > version of libpthread library as your own library. You want to make > > sure they're both built and linked on the same machine (from the same > > source code) if possible; the simple ".so.X" versioning method works > > great for major changes, but there are often minor changes that don't > > result in "X" being increased. > > > > I'm getting the impression that the tclsh binary you have was not built > > on the same machine / from the same source as what your library (the one > > linked with libpthread) was. > > > > > Jeremy Chadwick wrote: > > >> On Fri, Sep 12, 2008 at 09:26:37AM -0400, Barry Andrews wrote: > > >> > > >>> I don't understand. If it was not broken, then why did it change in > > later > > >>> FreeBSD versions? > > >>> > > >> > > >> I should be more explicit: the threading library and implementations > > >> have changed over time. There was libc_r, then there was libthr, then > > >> there was libkse. This is what we call "evolution". :-) > > >> > > >> http://www.unobvious.com/bsd/freebsd-threads.html > > >> http://kerneltrap.org/node/624 > > >> http://www.freebsd.org/kse/ > > >> > > >> The gcc -pthread flag is still there on present-day FreeBSD (6 through > > >> HEAD), and *should* be used. You can choose not to use it but you must > > >> ensure during linktime that you explicitly link to -lpthread. > > >> > > >> > > >>> On Fri, Sep 12, 2008 at 9:10 AM, Jeremy Chadwick > > wrote: > > >>> > > >>> > > >>>> On Fri, Sep 12, 2008 at 07:41:14AM -0400, Barry Andrews wrote: > > >>>> > > >>>>> Do you know if this is documented in Release Notes or Known Issues or > > >>>>> somewhere? > > >>>>> > > >>>> Why would it be an "issue"? gcc -pthread and libpthread linking is > > >>>> documented pretty much everywhere on the web. There isn't anything > > >>>> broken about it, it's how it's done on older FreeBSD. > > >>>> > > >>>> Note that all of this has significantly changed in later FreeBSD > > >>>> versions, and that the 5.x series was deprecated a very long time ago. > > >>>> > > >>>> > > >>>>>> On Thu, 11 Sep 2008, Barry Andrews wrote: > > >>>>>> > > >>>>>> > > >>>>>>> Hi All, > > >>>>>>> > > >>>>>>> I have a multi-threaded library that is linked against libpthread. > > >>>>>>> When I > > >>>>>>> load this lib into a tclsh process on FreeBSD, I get this error, > > >>>>>>> "Recurse on > > >>>>>>> private mutex". and crash. I understand that I can have this issue > > >>>>>>> when the > > >>>>>>> executable is not linked against libpthread but one of the loaded > > >>>>>>> libs is. > > >>>>>>> Basically, it thinks it's in single threaded mode. > > >>>>>>> > > >>>>>> This must be an older version of FreeBSD. I think you must > > >>>>>> link your application (tclsh or whatever) against libpthread > > >>>>>> in order for this to work. The libc functions won't get properly > > >>>>>> overloaded by their equivalents in libpthread unless you do > > >>>>>> this. > > >>>>>> > > >>>> -- > > >>>> | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > >>> To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > >>> > > >> > > >> > > > > > > _______________________________________________ > > > freebsd-hackers@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > > To unsubscribe, send any mail to " > > freebsd-hackers-unsubscribe@freebsd.org" > > > > -- > > | Jeremy Chadwick jdc at 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-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Fri Sep 12 16:10:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 16:11:01 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080912160422.GB60094@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> <20080912160422.GB60094@icarus.home.lan> Message-ID: <20080912161052.GD60094@icarus.home.lan> On Fri, Sep 12, 2008 at 09:04:22AM -0700, Jeremy Chadwick wrote: > What this does to other parts of the kernel and userland applications is > something I haven't tested. I *can* tell you that there are major, > major problems with detach/reattach/reinit on ata(4) causing kernel > panics and other such things. I've documented this quite thoroughly in > my "Common FreeBSD issues" wiki: > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues This should have read: "... in my ATA/SATA issues and troubleshooting methods page": http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kostikbel at gmail.com Fri Sep 12 16:12:04 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Sep 12 16:12:11 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <20080912160900.GC60094@icarus.home.lan> References: <48CA555A.4050104@gmail.com> <20080912131045.GA56923@icarus.home.lan> <20080912135110.GA57637@icarus.home.lan> <48CA8402.5040207@gmail.com> <20080912154520.GA60094@icarus.home.lan> <20080912160900.GC60094@icarus.home.lan> Message-ID: <20080912161158.GL39652@deviant.kiev.zoral.com.ua> On Fri, Sep 12, 2008 at 09:09:00AM -0700, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 11:55:01AM -0400, Barry Andrews wrote: > > Yes, the exe is tclsh. I understand that linking tclsh with libpthread is > > what would work. However this is very impractical. A user of my library > > shouldn't have to rebuild their tclsh to match my library specs. Another > > option would be to ship tclsh with my lib, but that also is a little weird. > > It seems like the only somewhat practical option I have is to use > > LD_PRELOAD, which is also weird but better than nothing. > > This really isn't a "FreeBSD problem", as the same sort of issue plagues > other operating systems. When it comes to threading, you want > *everything* threaded as much as possible -- mix-matching usually does > not work. The only OS I have seen where that kind of environment works > reliably is Solaris. I still feel threading is "too new" of a Yeah, they merged libpthread and libc some time ago, AFAIR :). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080912/289bb112/attachment.pgp From zbeeble at gmail.com Fri Sep 12 16:16:10 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Fri Sep 12 16:16:18 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> Message-ID: <5f67a8c40809120850u60c23fc4m7c4c1341fb2c4966@mail.gmail.com> On Fri, Sep 12, 2008 at 10:34 AM, Karl Pielorz wrote: > --On 12 September 2008 06:21 -0700 Jeremy Chadwick > wrote: > > As far as I know, there is no such "standard" mechanism in FreeBSD. If >> the drive falls off the bus entirely (e.g. detached), I would hope ZFS >> would notice that. I can imagine it (might) also depend on if the disk >> subsystem you're using is utilising CAM or not (e.g. disks should be daX >> not adX); Scott Long might know if something like this is implemented in >> CAM. I'm fairly certain nothing like this is implemented in ata(4). >> > > For ATA, at the moment - I don't think it'll notice even if a drive > detaches. I think like my system the other day, it'll just keep issuing I/O > commands to the drive, even if it's disappeared (it might get much 'quicker > failures' if the device has 'gone' to the point of FreeBSD just quickly > returning 'fail' for every request). Since I had the opportunity, I tested this recently for both CAM and ATA. Now the RAID engine was gmirror in both cases (my production hardware doesn't do ZFS yet), but I expect the reaction to be somewhat the same. Both systems were Dell 1U's. One, an R200, had SATA disks attached to a plain SATA controller. I believe it may have supported RAID1, but I didn't use that functionality. When a drive was removed from it, it stalled for some time (30 minutes?) and then resumed working. by the time I could type on the machine again, gmirror had decided that the drive was gone and marked the mirror as degraded. The other system was a 1950-III with a SCSI SAS controller attached to an SAS hot-swap backplane. The drives themselves were 750G SATA drives. Yanking one of them resulted in about 5 seconds of disruption followed by gmirror realizing the problem and marking the mirror degraded. Neither system was heavily loaded during the test. From koitsu at FreeBSD.org Fri Sep 12 16:32:10 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 16:32:17 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> Message-ID: <20080912163207.GE60094@icarus.home.lan> On Fri, Sep 12, 2008 at 12:04:27PM -0400, Zaphod Beeblebrox wrote: > On Fri, Sep 12, 2008 at 11:44 AM, Oliver Fromme wrote: > > Did you try "atacontrol detach" to remove the disk from > > the bus? I haven't tried that with ZFS, but gmirror > > automatically detects when a disk has gone away, and > > doesn't try to do anything with it anymore. It certainly > > should not hang the machine. After all, what's the > > purpose of a RAID when you have to reboot upon drive > > failure. ;-) > > To be fair, many "home" users run RAID without the expectation of being able > to hot swap the drives. While RAID can provide high availability, but it > can also provide simple data security. RAID only ensures a very, very tiny part of "data security", and it depends greatly on what RAID implementation you use. No RAID implementation I know of provides against transparent data corruption ("bit-rot"), and many RAID controllers and RAID drivers have bugs that induce corruption (to date, that's (very old ATA) Highpoint chips, nVidia/nForce chips, JMicron or Silicon Image chips -- all of these are used on consumer boards). A big problem is also that end-users *still* think RAID is a replacement for doing backups. :-( > To your point... I suppose you have to reboot at some point after the drive > failure, but my experience has been that the reboot has been under my > control some time after the failure (usually when I have the replacement > drive). For home use, sure. Since most home/consumer systems do not include hot-swappable drive bays, rebooting is required. Although more and more consumer motherboards are offering AHCI -- which is the only reliable way you'll get that capability with SATA. In my case with servers in a co-lo, it's not acceptable. Our systems contain SATA backplanes that support hot-swapping, and it works how it should (yank the disk, replace with a new one) on Linux -- there is no need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that hoopla, also take the risk of inducing a kernel panic. That risk does not sit well with me, but thankfully I've only been in that situation (replacing a bad disk + using hot-swapping) once -- and it did work. At my home, I have a pseudo-NAS system running FreeBSD. The case is from Supermicro, a mid-tower, and has a SATA backplane that supports hot-swapping. I use ZFS on this system, sporting 3 disks and one (non-ZFS) for boot/OS. But because I'm using ata(4) -- see above. Individuals on -stable and other lists using ZFS have posted their experiences with disk failures. I believe to date I've seen one which worked flawlessly, and the others reporting strange issues with resilvering, or in a couple cases, lost all their zpools permanently. Of course, it's very rare in this day and age for people to mail a mailing list reporting *successes* with something -- people usually only mail if something *fails*. :-) That said, pjd@'s dedication to getting ZFS working reliably on FreeBSD is outstanding. It's a great filesystem replacement, and even the Linux folks are a bit jealous over how simple and painless it is. I can share their jealousy -- I've looked at the LVM docs... never again. > About the only real improvement I'd like to see in this setup is the ability > to spin down idle drives. That would be an ideal setup for the home RAID > array. There is a FreeBSD port which handles this, although such a feature should ideally be part of the ata(4) system (as should TCQ/NCQ and a slew of other things -- some of those are being worked on). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From deischen at freebsd.org Fri Sep 12 16:44:28 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Fri Sep 12 16:44:41 2008 Subject: loading multi threaded library into executable enabled for single thread In-Reply-To: <48CA555A.4050104@gmail.com> References: <48CA555A.4050104@gmail.com> Message-ID: On Fri, 12 Sep 2008, Barry Andrews wrote: > Do you know if this is documented in Release Notes or Known Issues or > somewhere? No, but it's certainly in the -threads or -ports mailing list archives from a few years ago ;-) -- DE From zbeeble at gmail.com Fri Sep 12 16:47:23 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Fri Sep 12 16:47:29 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080912163207.GE60094@icarus.home.lan> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> Message-ID: <5f67a8c40809120947u2bbeb03cnb20618e1d9ddf6b8@mail.gmail.com> On Fri, Sep 12, 2008 at 12:32 PM, Jeremy Chadwick wrote: > On Fri, Sep 12, 2008 at 12:04:27PM -0400, Zaphod Beeblebrox wrote: > > On Fri, Sep 12, 2008 at 11:44 AM, Oliver Fromme >wrote: > > > Did you try "atacontrol detach" to remove the disk from > > > the bus? I haven't tried that with ZFS, but gmirror > > > automatically detects when a disk has gone away, and > > > doesn't try to do anything with it anymore. It certainly > > > should not hang the machine. After all, what's the > > > purpose of a RAID when you have to reboot upon drive > > > failure. ;-) > > > > To be fair, many "home" users run RAID without the expectation of being > able > > to hot swap the drives. While RAID can provide high availability, but it > > can also provide simple data security. > > RAID only ensures a very, very tiny part of "data security", and it > depends greatly on what RAID implementation you use. No RAID > implementation I know of provides against transparent data corruption > ("bit-rot"), and many RAID controllers and RAID drivers have bugs that Well... this is/was a thread about ZFS. ZFS does detect that bitrot _and_ correct it if it is possible. > A big problem is also that end-users *still* think RAID is a replacement > for doing backups Well... this comment seems a bit off topic, but maybe (in some cases) RAID is a substitute for doing backups. I suppose it depends on your tolerance and data value. The sheer size of some datasets these days makes backup prohibitively time consuming and/or expensive. Then again (this is a ZFS thread), ZFS helps with this: the ability to export snapshots to other spinning spool makes a lot of sense. From fjwcash at gmail.com Fri Sep 12 17:12:31 2008 From: fjwcash at gmail.com (Freddie Cash) Date: Fri Sep 12 17:12:37 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080912163207.GE60094@icarus.home.lan> References: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> Message-ID: <200809121012.10195.fjwcash@gmail.com> On September 12, 2008 09:32 am Jeremy Chadwick wrote: > For home use, sure. Since most home/consumer systems do not include > hot-swappable drive bays, rebooting is required. Although more and > more consumer motherboards are offering AHCI -- which is the only > reliable way you'll get that capability with SATA. > > In my case with servers in a co-lo, it's not acceptable. Our systems > contain SATA backplanes that support hot-swapping, and it works how it > should (yank the disk, replace with a new one) on Linux -- there is no > need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that > hoopla, also take the risk of inducing a kernel panic. That risk does > not sit well with me, but thankfully I've only been in that situation > (replacing a bad disk + using hot-swapping) once -- and it did work. Hrm, is this with software RAID or hardware RAID? With our hardware RAID systems, the process has always been the same, regardless of which OS (Windows 2003 Servers, Debian Linux, FreeBSD) is on the system: - go into RAID management GUI, remove drive - pull dead drive from system - insert new drive into system - go into RAID management GUI, make sure it picked up new drive and started the rebuild We've been lucky so far, and not had to do any drive replacements on our non-ZFS software RAID systems (md on Debian, gmirror on FreeBSD). I'm not looking forward to a drive failing, as these systems have non-hot-pluggable SATA setups. On the ZFS systems, we just "zpool offline" the drive, physically replace the drive, and "zpool replace" the drive. On one system, this was done via hot-pluggable SATA backplane, on another, it required a reboot. -- Freddie Cash fjwcash@gmail.com From koitsu at FreeBSD.org Fri Sep 12 18:22:37 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 12 18:22:44 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <200809121012.10195.fjwcash@gmail.com> References: <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <200809121012.10195.fjwcash@gmail.com> Message-ID: <20080912182235.GA62771@icarus.home.lan> On Fri, Sep 12, 2008 at 10:12:09AM -0700, Freddie Cash wrote: > On September 12, 2008 09:32 am Jeremy Chadwick wrote: > > For home use, sure. Since most home/consumer systems do not include > > hot-swappable drive bays, rebooting is required. Although more and > > more consumer motherboards are offering AHCI -- which is the only > > reliable way you'll get that capability with SATA. > > > > In my case with servers in a co-lo, it's not acceptable. Our systems > > contain SATA backplanes that support hot-swapping, and it works how it > > should (yank the disk, replace with a new one) on Linux -- there is no > > need to do a bunch of hoopla like on FreeBSD. On FreeBSD, with that > > hoopla, also take the risk of inducing a kernel panic. That risk does > > not sit well with me, but thankfully I've only been in that situation > > (replacing a bad disk + using hot-swapping) once -- and it did work. > > Hrm, is this with software RAID or hardware RAID? I do not use either, but have tried software RAID (Intel MatrixRAID) in the past (and major, MAJOR bugs are why I do not any longer). Speaking (mostly) strictly of FreeBSD, let me list off the problems with both: Software RAID: 1) Buggy as hell. Using Intel MatrixRAID as an example, even with RAID 1, due to ata(4) driver bugs, you are practically guaranteed to lose your data, 3) Limited userland interface to RAID BIOS; many operations do not work with atacontrol, requiring a system reboot + entering BIOS to do things like add/remove disks or rebuild an array 3) SMART monitoring lost; if the card or BIOS supports passthrough (basically ATA version of pass(4)), FreeBSD will see the disks natively (e.g. arX for the RAID, ad4 and ad8 for the disks), and you can use smartmontools. Otherwise, you're screwed 4) Support is questionable; numerous mainstream chips unsupported, including Adaptec HostRAID Hardware RAID: 1) You are "locked in" to that controller. Your data is at the mercy of the company who makes the HBA; if your controller dies and is no longer made, your data is dead in the water. Chances are a newer model/revision of controller will not understand the the disk metadata from the previous controller 2) Performance problems as a result of excessive caching levels; onboard hardware cache vs. system memory cache vs. disk layer cache in OS vs. other kernel caching mechanisms 3) Controller firmware upgrades are risky -- 3Ware has a very nasty history of this, for sake of example. I've heard of some upgrades changing the metadata format, requiring complete array re-creation I can pull Ade Lovett into this conversation if you think any of the above is exaggerated. :-) The only hardware RAID controller I'd trust at this point would be Areca -- but hardware RAID is not what I want. On the other hand, I really want Areca to make a standard 4 or 8-port SATA controller -- no RAID, but full driver support under arcmsr(4) (which uses CAM and da(4)). This would be perfect. > With our hardware RAID systems, the process has always been the same, > regardless of which OS (Windows 2003 Servers, Debian Linux, FreeBSD) is > on the system: > - go into RAID management GUI, remove drive > - pull dead drive from system > - insert new drive into system > - go into RAID management GUI, make sure it picked up new drive and > started the rebuild The simplicity there is correct -- that's really how simple it should be. But a GUI? What card is this that requires a GUI? Does it require a reboot? No command-line support? > We've been lucky so far, and not had to do any drive replacements on our > non-ZFS software RAID systems (md on Debian, gmirror on FreeBSD). I'm > not looking forward to a drive failing, as these systems have > non-hot-pluggable SATA setups. I'm hearing you loud and clear. :-) > On the ZFS systems, we just "zpool offline" the drive, physically replace > the drive, and "zpool replace" the drive. On one system, this was done > via hot-pluggable SATA backplane, on another, it required a reboot. If this was done on the hardware RAID controller (presuming it uses CAM and da(4)), I'm not surprised it worked perfectly. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From kpielorz_lst at tdx.co.uk Fri Sep 12 19:45:55 2008 From: kpielorz_lst at tdx.co.uk (Karl Pielorz) Date: Fri Sep 12 19:46:05 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080912160422.GB60094@icarus.home.lan> References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> <20080912160422.GB60094@icarus.home.lan> Message-ID: --On 12 September 2008 09:04 -0700 Jeremy Chadwick wrote: > I know ATA will notice a detached channel, because I myself have done > it: administratively, that is -- atacontrol detach ataX. But the only > time that can happen "automatically" is if the actual controller does > so itself, or if FreeBSD is told to do it administratively. I think the problem at the moment is, ZFS "doesn't care" - it's deliberately remote from things like drivers, and drives - and at the moment, there's no 'middle layer' or way for at least the ATA drivers to communicate to ZFS that a drive 'has failed' (I mean, for starters, you've got the problem of "what's a failed drive" - presumably a drive that's operating outside a set of limits? - The first probably being 'is it still attached?' :) That was a thread recently on the Open Solaris ZFS forum - and discussed at length... > I am also very curious to know the exact brand/model of 8-port SATA > controller from Supermicro you are using, *especially* if it uses ata(4) > rather than CAM and da(4). The controllers ID as: Marvell 88SX6081 SATA300 controller They're SuperMicro 8 PORT PCI-X SATA controllers, 'AOC-SAT2-MV8' - and they definitely show as 'adX' > Such Supermicro controllers were recently > discussed on freebsd-stable (or was it -hardware?), and no one was able > to come to a concise decision as to whether or not they were decent or > even remotely trusted. Supermicro provides a few different SATA HBAs. Well, I've tested these cards for a number of months now, and they seem fine here - at least with the WD drives I'm currently running (not saying they're 'perfect' - but for my setup, I've not seen any issues). I didn't notice any 'bad behaviour' when testing them under UFS, and when running under ZFS they've picked up no checksum errors (or console messages) for the duration the box has been running. > I can see the usefulness in Solaris's FMA thing. My big concern is > whether or not FMA actually pulls the disk off the channel, or if it > just leaves the disk/channel connected and simply informs kernel pieces > not to use it. If it pulls the disk off the channel, I have serious > qualms with it. I don't think it pulls it - I think it's looks at it's policies, and does what they say, which would seem to be the equivalent of 'zpool offline dev' by default (which, again doesn't pull it off any busses - it just notifies ZFS not to send I/O to that device). I'll have to do a test using da / CAM driven disks (or ask someone who worked on the port ;) - but I'd guess, unless there's something been added to CAM to tell ZFS to offline the disk, it'll do the same - i.e. ZFS will continue to issue I/O requests to disks as it needs - as at least in Open Solaris, it's deemed *not* to be ZFS's job to detect failed disks, or do anything about them - other than what it's told. ZFS under FreeBSD still works despite this (and works wonderfully well) - it just means if any of your drives 'go out to lunch' - unless they fail in such a way that the I/O requests are returned immediately as 'failed' (i.e. I guess if the device node has gone) - ZFS will keep issuing (and potentially pausing) waiting for I/O requests to failed drives, because it doesn't know, doesn't care - and hasn't been told to do otherwise. -Kp From fbsdlist at src.cx Sat Sep 13 05:28:05 2008 From: fbsdlist at src.cx (Artem Belevich) Date: Sat Sep 13 05:28:12 2008 Subject: Increasing KVM on amd64 In-Reply-To: References: <48C8A78C.6070608@cs.rice.edu> Message-ID: By the way, this part of Alan's patch fixes a bug in RELENG7 where mapbase is passed to vm_map_find uninitialized. -CURRENT already has this change applied. Perhaps it's worth committing in RELENG7, too. --- ./kern/link_elf_obj.c.orig 2008-09-01 11:06:44.000000000 -0700 +++ ./kern/link_elf_obj.c 2008-09-10 13:07:54.793310216 -0700 @@ -667,6 +667,7 @@ goto out; } ef->address = (caddr_t) vm_map_min(kernel_map); + mapbase = KERNBASE; error = vm_map_find(kernel_map, ef->object, 0, &mapbase, round_page(mapsize), TRUE, VM_PROT_ALL, VM_PROT_ALL, FALSE); if (error) { --Artem From uspoerlein at gmail.com Sat Sep 13 12:23:20 2008 From: uspoerlein at gmail.com (Ulrich Spoerlein) Date: Sat Sep 13 12:23:27 2008 Subject: Extending find(1) to support -printf In-Reply-To: <200809081347.m88DlK8T074926@lurza.secnetix.de> References: <20080905143915.GA60002@icarus.home.lan> <200809081347.m88DlK8T074926@lurza.secnetix.de> Message-ID: <20080913115122.GK76117@roadrunner.spoerlein.net> Pretty late to the game, but ... On Mon, 08.09.2008 at 15:47:20 +0200, Oliver Fromme wrote: > Jeremy Chadwick wrote: > > Equally as frustrating, mutt's backtick support will only honour the > > first line of input. If a backticked command returns multiple lines, > > only the first is read; the rest are ignored. > > Well, you can convert back and forth between spaces > and newlines with tr(1): > > echo * | tr ' ' '\n' | grep -v whatever | tr '\n' ' ' If your data is not very large, you can also fool xargs(1) into doing the conversion for you $ echo * | xargs -n1 and $ ls -1 | xargs > It's not pretty, but it should work. Note that ls(1) > prints one file name per line, so you can simplify the > above line like this: > > ls | grep -v whatever | tr '\n' ' ' > > By the way, I often use zsh in such cases. It supports > "extended globbing", for example, the wildcard expression > *~*.(gz|bz2) matches all files _except_ the ones that end > with .gz or .bz2. Indeed much more useful than fighting with find(1) and passing the file lists around. Cheers, Ulrich Spoerlein -- It is better to remain silent and be thought a fool, than to speak, and remove all doubt. From nhoyle at hoyletech.com Sat Sep 13 20:53:04 2008 From: nhoyle at hoyletech.com (Nathanael Hoyle) Date: Sat Sep 13 20:53:11 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: References: <20080912132102.GB56923@icarus.home.lan> <3BE629D093001F6BA2C6791C@Slim64.dmpriest.net.uk> <20080912160422.GB60094@icarus.home.lan> Message-ID: <1221338401.18959.7.camel@localhost> On Fri, 2008-09-12 at 20:31 +0100, Karl Pielorz wrote: > > --On 12 September 2008 09:04 -0700 Jeremy Chadwick > wrote: > > > I know ATA will notice a detached channel, because I myself have done > > it: administratively, that is -- atacontrol detach ataX. But the only > > time that can happen "automatically" is if the actual controller does > > so itself, or if FreeBSD is told to do it administratively. > > I think the problem at the moment is, ZFS "doesn't care" - it's > deliberately remote from things like drivers, and drives - and at the > moment, there's no 'middle layer' or way for at least the ATA drivers to > communicate to ZFS that a drive 'has failed' (I mean, for starters, you've > got the problem of "what's a failed drive" - presumably a drive that's > operating outside a set of limits? - The first probably being 'is it still > attached?' :) > > That was a thread recently on the Open Solaris ZFS forum - and discussed at > length... > > > I am also very curious to know the exact brand/model of 8-port SATA > > controller from Supermicro you are using, *especially* if it uses ata(4) > > rather than CAM and da(4). > > The controllers ID as: > > Marvell 88SX6081 SATA300 controller > > They're SuperMicro 8 PORT PCI-X SATA controllers, 'AOC-SAT2-MV8' - and they > definitely show as 'adX' > > > Such Supermicro controllers were recently > > discussed on freebsd-stable (or was it -hardware?), and no one was able > > to come to a concise decision as to whether or not they were decent or > > even remotely trusted. Supermicro provides a few different SATA HBAs. > > Well, I've tested these cards for a number of months now, and they seem > fine here - at least with the WD drives I'm currently running (not saying > they're 'perfect' - but for my setup, I've not seen any issues). I didn't > notice any 'bad behaviour' when testing them under UFS, and when running > under ZFS they've picked up no checksum errors (or console messages) for > the duration the box has been running. > > > I can see the usefulness in Solaris's FMA thing. My big concern is > > whether or not FMA actually pulls the disk off the channel, or if it > > just leaves the disk/channel connected and simply informs kernel pieces > > not to use it. If it pulls the disk off the channel, I have serious > > qualms with it. > > I don't think it pulls it - I think it's looks at it's policies, and does > what they say, which would seem to be the equivalent of 'zpool offline dev' > by default (which, again doesn't pull it off any busses - it just notifies > ZFS not to send I/O to that device). > This is consistent with my understanding of the behavior under Solaris, and is similar to how Sun Solstice Disksuite has worked for years... the drive will get "kicked out" of the array, but will remain attached to the bus and fully visible to the system. The array gets marked as degraded and no further I/O is performed against the "submirror" until it is either manually re-synced or replaced and resynced. Occassionally, disksuite is somewhat overly aggressive about this, but the box stays responsive and resilient when a drive goes down. > I'll have to do a test using da / CAM driven disks (or ask someone who > worked on the port ;) - but I'd guess, unless there's something been added > to CAM to tell ZFS to offline the disk, it'll do the same - i.e. ZFS will > continue to issue I/O requests to disks as it needs - as at least in Open > Solaris, it's deemed *not* to be ZFS's job to detect failed disks, or do > anything about them - other than what it's told. > > ZFS under FreeBSD still works despite this (and works wonderfully well) - > it just means if any of your drives 'go out to lunch' - unless they fail in > such a way that the I/O requests are returned immediately as 'failed' (i.e. > I guess if the device node has gone) - ZFS will keep issuing (and > potentially pausing) waiting for I/O requests to failed drives, because it > doesn't know, doesn't care - and hasn't been told to do otherwise. > Unfortunately this means that a single failed/failing drive can make the entire i/o subsystem (and likely the machine with it) nonresponsive and fails badly at high-availability. There probably needs to be some sort of "middleware" that can monitor the responses from the commands to the individual drives and configurably take action to offline the drive from the zpool in order to attain high availability. -Nathanael > -Kp > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From toyj at union.edu Sat Sep 13 23:57:30 2008 From: toyj at union.edu (jT) Date: Sat Sep 13 23:57:37 2008 Subject: 256-byte inode support In-Reply-To: <20080909131442.GL62357@atarininja.org> References: <9f8af95f0809061626q22bc8f60i48fd95b32cef3d04@mail.gmail.com> <20080907150747.GB62357@atarininja.org> <20080909115351.GJ39652@deviant.kiev.zoral.com.ua> <20080909122917.GK62357@atarininja.org> <20080909123746.GK39652@deviant.kiev.zoral.com.ua> <20080909131442.GL62357@atarininja.org> Message-ID: <9f8af95f0809131657q6c3e2339uebc2a9a4b2e2f5de@mail.gmail.com> Kostik, Wesley, I've been using this patch since Wesley made me aware of it -- it has been 100% fine for me atm -- there are a few small modifications to it and it applies cleanly to -CURRENT -- a bunch of my friends who run all linux boxen (and i'm changing their minds about that slowly but surely) use it and I have also _not_ heard a peep from them about any failures / weirdness -- and most of their data exists on ext2fs :) -- so thats a good sign -- i've attached the updated patch --- ./ext2_fs.h.orig 2008-09-13 23:25:32.000000000 +0100 +++ ./ext2_fs.h 2008-09-13 23:25:45.000000000 +0100 @@ -150,7 +150,7 @@ #else /* !notyet */ #define EXT2_INODES_PER_BLOCK(s) ((s)->s_inodes_per_block) /* Should be sizeof(struct ext2_inode): */ -#define EXT2_INODE_SIZE 128 +#define EXT2_INODE_SIZE(s) ((s)->s_es->s_inode_size) #define EXT2_FIRST_INO 11 #endif /* notyet */ --- ./ext2_inode.c.orig 2008-09-13 23:25:53.000000000 +0100 +++ ./ext2_inode.c 2008-09-13 23:26:06.000000000 +0100 @@ -91,7 +91,7 @@ return (error); } ext2_i2ei(ip, (struct ext2_inode *)((char *)bp->b_data + - EXT2_INODE_SIZE * ino_to_fsbo(fs, ip->i_number))); + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip->i_number))); if (waitfor && (vp->v_mount->mnt_kern_flag & MNTK_ASYNC) == 0) return (bwrite(bp)); else { --- ./ext2_vfsops.c.orig 2008-09-13 23:26:13.000000000 +0100 +++ ./ext2_vfsops.c 2008-09-13 23:26:55.000000000 +0100 @@ -424,7 +424,7 @@ V(s_frags_per_group) fs->s_inodes_per_group = es->s_inodes_per_group; V(s_inodes_per_group) - fs->s_inodes_per_block = fs->s_blocksize / EXT2_INODE_SIZE; + fs->s_inodes_per_block = fs->s_blocksize / EXT2_INODE_SIZE(fs); V(s_inodes_per_block) fs->s_itb_per_group = fs->s_inodes_per_group /fs->s_inodes_per_block; V(s_itb_per_group) @@ -578,7 +578,7 @@ return (error); } ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + - EXT2_INODE_SIZE * ino_to_fsbo(fs, ip->i_number)), ip); + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ip->i_number)), ip); brelse(bp); VOP_UNLOCK(vp, 0); vrele(vp); @@ -1013,7 +1013,7 @@ return (error); } /* convert ext2 inode to dinode */ - ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + EXT2_INODE_SIZE * + ext2_ei2i((struct ext2_inode *) ((char *)bp->b_data + EXT2_INODE_SIZE(fs) * ino_to_fsbo(fs, ino)), ip); ip->i_block_group = ino_to_cg(fs, ino); ip->i_next_alloc_block = 0; /jT http://git.zen-sources.org/?p=kernel/zenmm.git;a=summary On Tue, Sep 9, 2008 at 9:14 AM, Wesley Shields wrote: > On Tue, Sep 09, 2008 at 03:37:47PM +0300, Kostik Belousov wrote: >> On Tue, Sep 09, 2008 at 08:29:17AM -0400, Wesley Shields wrote: >> > On Tue, Sep 09, 2008 at 02:53:51PM +0300, Kostik Belousov wrote: >> > > On Sun, Sep 07, 2008 at 11:07:47AM -0400, Wesley Shields wrote: >> > > > On Sat, Sep 06, 2008 at 07:26:27PM -0400, jT wrote: >> > > > > hackers, >> > > > > >> > > > > since tytso had updated ext3 -- i've noticed that i can't use my >> > > > > 265-byte inode ext3 drives -- is there any effort to update it? If >> > > > > not -- if you know where i should attempt to start please let me know >> > > > > so i can start working on support (i have a few other people i know >> > > > > interested in this) -- thanks and hope everyone is well >> > > > >> > > > There was a PR submitted for it and eventually a patch added to the PR. >> > > > I've tested the patch given in the URL at the port and it works. We >> > > > will start to see more of this as the newer version becomes more common >> > > > in the wild. >> > > > >> > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/124621 >> > > > >> > > > Would be nice to see this fixed in 7.1 but it may be too late for that. >> > > >> > > What was the reason for increasing inode size ? I think it is rather >> > > pointless to increase the size without using newly added space for some >> > > data. Is inode format the same for the first 128 bytes, and does data >> > > at the second 128 bytes should be used to correctly interpret inode ? >> > >> > I honestly don't know the answer. Though I do agree that it is >> > pointless to increase the size without using the new space. >> > >> > All I know is that I was unable to read an ext filesystem made with -I >> > 256 (which is the default when using the most recent >> > sysutils/e2fsprogs). >> >> I think it is too dangerous for the user data to commit this patch, >> without investigating this first. > > I think that's a fair assessment to make. The patch is certainly simple > enough but I'm not familiar with what it's doing to make an accurate > assessment. I know it worked for the simple test case I provided in my > previous message. If I can be of any further assistance please let me > know. > > -- WXS > From marcel at e-soul.co.za Sun Sep 14 09:35:44 2008 From: marcel at e-soul.co.za (Marcel Grandemange) Date: Sun Sep 14 09:36:01 2008 Subject: Error: Can't find libjava.so Message-ID: <015001c9164a$a3a4b040$eaee10c0$@co.za> I do realize this is probably better suited for freebsd-questions , however haven't received any response and was simply hoping someone would be kind enough. I recently obtained a very decent ups, however it is not supported by NUT. It does however come with winpower software that does run on FreeBSD. However it rewuired java. So installed from ports And was presented with following error: Error: can't find libjava.so This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so Help?! _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" __________ NOD32 3439 (20080912) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com

Views expressed in this e-mail are to be deemed to be of a personal nature and may not necessarily be those of e-Soul, in which event e-Soul cannot accept any responsibility or liability arising from contents reflected through e-mail. E-Soul accepts no responsibility for loss or damages which may arise from the use of e-mail as a means of communication.

From thavinci at thavinci.za.net Sun Sep 14 09:35:44 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Sun Sep 14 12:19:23 2008 Subject: Error: Can't find libjava.so Message-ID: <015101c9164a$f3f12d30$dbd38790$@za.net> I do realize this is probably better suited for freebsd-questions , however haven't received any response and was simply hoping someone would be kind enough. I recently obtained a very decent ups, however it is not supported by NUT. It does however come with winpower software that does run on FreeBSD. However it rewuired java. So installed from ports And was presented with following error: Error: can't find libjava.so This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so Help?! _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" __________ NOD32 3439 (20080912) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From dnelson at allantgroup.com Sun Sep 14 23:01:09 2008 From: dnelson at allantgroup.com (Dan Nelson) Date: Sun Sep 14 23:01:16 2008 Subject: Error: Can't find libjava.so In-Reply-To: <015101c9164a$f3f12d30$dbd38790$@za.net> References: <015101c9164a$f3f12d30$dbd38790$@za.net> Message-ID: <20080914230105.GD3188@dan.emsphone.com> In the last episode (Sep 14), Marcel Grandemange said: > I do realize this is probably better suited for freebsd-questions , > however haven't received any response and was simply hoping someone > would be kind enough. > > I recently obtained a very decent ups, however it is not supported by > NUT. > > It does however come with winpower software that does run on FreeBSD. > > However it rewuired java. > > So installed from ports > > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so Are you running an amd64 winpower binary? If not, you'll probably need to install an x86 java. You can't mix libraries for different architectures. -- Dan Nelson dnelson@allantgroup.com From alex.wilkinson at dsto.defence.gov.au Mon Sep 15 03:05:56 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Mon Sep 15 03:06:03 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080912163207.GE60094@icarus.home.lan> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> Message-ID: <20080915023717.GF39765@stlux503.dsto.defence.gov.au> 0n Fri, Sep 12, 2008 at 09:32:07AM -0700, Jeremy Chadwick wrote: >> About the only real improvement I'd like to see in this setup is the ability >> to spin down idle drives. That would be an ideal setup for the home RAID >> array. > >There is a FreeBSD port which handles this, although such a feature >should ideally be part of the ata(4) system (as should TCQ/NCQ and a >slew of other things -- some of those are being worked on). And the port is ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From unixmania at gmail.com Mon Sep 15 03:26:29 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Mon Sep 15 03:26:36 2008 Subject: Error: Can't find libjava.so In-Reply-To: <015101c9164a$f3f12d30$dbd38790$@za.net> References: <015101c9164a$f3f12d30$dbd38790$@za.net> Message-ID: On Sun, Sep 14, 2008 at 6:19 AM, Marcel Grandemange wrote: > I do realize this is probably better suited for freebsd-questions , however > haven't received any response and was simply hoping someone would be kind > enough. > > I recently obtained a very decent ups, however it is not supported by NUT. > It does however come with winpower software that does run on FreeBSD. > However it required java. So installed from ports > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so Do you mean this software? http://www.ups-software-download.com/winpower.htm I looked at the installation script and found that it fails to find the installes JRE. Try this: ./setup.bin LAX_VM "/usr/local/Diablo-jre1.6.0/jre/bin/java Please notice that this will just run the installer. I did *not * install the software because I don't have a password. Anyway, unless you have a version newer than the one I tested, it will unlikely run on a recent FreeBSD/amd64 because it is for FreeBSD 4.6/i386: FreeBSD/resource/jre/bin/i386/green_threads/java: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 4.6 (460102), dynamically linked (uses shared libs), FreeBSD-style, not stripped -- cd /usr/ports/sysutils/life make clean From koitsu at FreeBSD.org Mon Sep 15 04:28:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 15 04:28:38 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080915023717.GF39765@stlux503.dsto.defence.gov.au> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <20080915023717.GF39765@stlux503.dsto.defence.gov.au> Message-ID: <20080915042828.GA27658@icarus.home.lan> On Mon, Sep 15, 2008 at 10:37:18AM +0800, Wilkinson, Alex wrote: > 0n Fri, Sep 12, 2008 at 09:32:07AM -0700, Jeremy Chadwick wrote: > > >> About the only real improvement I'd like to see in this setup is the ability > >> to spin down idle drives. That would be an ideal setup for the home RAID > >> array. > > > >There is a FreeBSD port which handles this, although such a feature > >should ideally be part of the ata(4) system (as should TCQ/NCQ and a > >slew of other things -- some of those are being worked on). > > And the port is ? Is it that hard to use 'make search' or grep? :-) sysutils/ataidle -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From alex.wilkinson at dsto.defence.gov.au Mon Sep 15 05:25:00 2008 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Mon Sep 15 05:25:07 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080915042828.GA27658@icarus.home.lan> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <20080915023717.GF39765@stlux503.dsto.defence.gov.au> <20080915042828.GA27658@icarus.home.lan> Message-ID: <20080915052339.GG39765@stlux503.dsto.defence.gov.au> 0n Sun, Sep 14, 2008 at 09:28:28PM -0700, Jeremy Chadwick wrote: >On Mon, Sep 15, 2008 at 10:37:18AM +0800, Wilkinson, Alex wrote: >> 0n Fri, Sep 12, 2008 at 09:32:07AM -0700, Jeremy Chadwick wrote: >> >> >> About the only real improvement I'd like to see in this setup is the ability >> >> to spin down idle drives. That would be an ideal setup for the home RAID >> >> array. >> > >> >There is a FreeBSD port which handles this, although such a feature >> >should ideally be part of the ata(4) system (as should TCQ/NCQ and a >> >slew of other things -- some of those are being worked on). >> >> And the port is ? > >Is it that hard to use 'make search' or grep? :-) sysutils/ataidle When you dont know the string to search on ... yes. -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From koitsu at FreeBSD.org Mon Sep 15 05:30:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 15 05:31:06 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080915052339.GG39765@stlux503.dsto.defence.gov.au> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <20080915023717.GF39765@stlux503.dsto.defence.gov.au> <20080915042828.GA27658@icarus.home.lan> <20080915052339.GG39765@stlux503.dsto.defence.gov.au> Message-ID: <20080915053053.GA28815@icarus.home.lan> On Mon, Sep 15, 2008 at 01:23:39PM +0800, Wilkinson, Alex wrote: > 0n Sun, Sep 14, 2008 at 09:28:28PM -0700, Jeremy Chadwick wrote: > > >On Mon, Sep 15, 2008 at 10:37:18AM +0800, Wilkinson, Alex wrote: > >> 0n Fri, Sep 12, 2008 at 09:32:07AM -0700, Jeremy Chadwick wrote: > >> > >> >> About the only real improvement I'd like to see in this setup is the ability > >> >> to spin down idle drives. That would be an ideal setup for the home RAID > >> >> array. > >> > > >> >There is a FreeBSD port which handles this, although such a feature > >> >should ideally be part of the ata(4) system (as should TCQ/NCQ and a > >> >slew of other things -- some of those are being worked on). > >> > >> And the port is ? > > > >Is it that hard to use 'make search' or grep? :-) sysutils/ataidle > > When you dont know the string to search on ... yes. Give me a break. :-) idle|sleep|suspend|spin -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From steve at stevehodgson.co.uk Mon Sep 15 09:04:38 2008 From: steve at stevehodgson.co.uk (Steve Hodgson) Date: Mon Sep 15 09:04:46 2008 Subject: Error: Can't find libjava.so In-Reply-To: <015101c9164a$f3f12d30$dbd38790$@za.net> References: <015101c9164a$f3f12d30$dbd38790$@za.net> Message-ID: <48CE2172.3090505@stevehodgson.co.uk> Marcel Grandemange wrote: > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so > Do you have /proc mounted? Try unmounting it and retrying. Steve From koitsu at FreeBSD.org Mon Sep 15 09:38:22 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 15 09:38:32 2008 Subject: Error: Can't find libjava.so In-Reply-To: <015101c9164a$f3f12d30$dbd38790$@za.net> References: <015101c9164a$f3f12d30$dbd38790$@za.net> Message-ID: <20080915093815.GA33139@icarus.home.lan> On Sun, Sep 14, 2008 at 11:19:13AM +0200, Marcel Grandemange wrote: > I do realize this is probably better suited for freebsd-questions , however > haven't received any response and was simply hoping someone would be kind > enough. > > I recently obtained a very decent ups, however it is not supported by NUT. > > It does however come with winpower software that does run on FreeBSD. > > However it rewuired java. > > So installed from ports > > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so Can you provide the output of "ldconfig -r" from that box? I have a feeling the ld.so pathing hints might lack a directory or two. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From guru at unixarea.de Mon Sep 15 11:08:47 2008 From: guru at unixarea.de (Matthias Apitz) Date: Mon Sep 15 11:08:56 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 Message-ID: <20080915110838.GA5258@rebelion.Sisis.de> Hello, I'm booting my laptop 3 times a day: in the morning at home (WEP area), when I arrive in my office (WPA area) and in the evening at home (again); the sequence is always the same: booting, login into console, startx which launches via ~/.xinitrc the KDE; in about 1 of 2-3 cases and only in the office(!) the system panics when KDE comes up, at the end of the KDE booting and the jingle already played; today it crashed again and again and after switching off the Wifi radio on the laptop it came finally up fine; I did this (Wifi off) because I'm assuming somehow a relation with http://www.freebsd.org/cgi/query-pr.cgi?pr=122331 where my laptop as well only panic'ed in WPA mode (i.e. in the office) and with 'bgscan' active; which I now have deactivated; all these panics look in the debugger more or less like this one: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc0788b98 stack pointer = 0x28:0xe6960acc frame pointer = 0x28:0xe6960c50 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1426 (kdeinit) trap number = 12 panic: page fault cpuid = 0 Uptime: 1m36s Physical memory: 1009 MB Dumping 129 MB: 114 98 82 66 50 34 18 2 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:812 #5 0xc0a49c8c in trap (frame=0xe6960a8c) at /usr/src/sys/i386/i386/trap.c:490 #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) at /usr/src/sys/kern/sys_generic.c:663 #9 0xc0a49635 in syscall (frame=0xe6960d38) at /usr/src/sys/i386/i386/trap.c:1035 #10 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 #11 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) the 'current process' (kdeinit in the above crash) changes, but is always one of the KDE parts; of course the problem is not KDE related, it is just that the system comes under heavy usage in that moment; I already run 'memtest 128' for some hours without any noted problem in memory; test are just passing fine; the same problem is with 7.0-RELEASE as with RELENG_7; what can I do to nail this down? it sucks somehow seeing it crashing on startup in the morning in the office :-(( thx matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From thavinci at thavinci.za.net Mon Sep 15 06:32:15 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Mon Sep 15 11:24:55 2008 Subject: Error: Can't find libjava.so In-Reply-To: References: <015101c9164a$f3f12d30$dbd38790$@za.net> Message-ID: <003e01c916fc$b4507070$1cf15150$@za.net> > I do realize this is probably better suited for freebsd-questions , however > haven't received any response and was simply hoping someone would be kind > enough. > > I recently obtained a very decent ups, however it is not supported by NUT. > It does however come with winpower software that does run on FreeBSD. > However it required java. So installed from ports > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so >Do you mean this software? > http://www.ups-software-download.com/winpower.htm Yes >I looked at the installation script and found that it fails to find >the installes JRE. Try this: > ./setup.bin LAX_VM "/usr/local/Diablo-jre1.6.0/jre/bin/java Worked!!! >Please notice that this will just run the installer. I did *not * >install the software because I don't have a password. Anyway, unless >you have a version newer than the one I tested, it will unlikely run >on a recent FreeBSD/amd64 because it is for FreeBSD 4.6/i386: Yeh I know, but don't have a choice but to try as NUT doesn't support this UPS. :/ It actually installed successfully, but canot start it because of same error: ./agent start LAX_VM "/usr/local/Diablo-jre1.6.0/bin/java" Starting agent: Error: Can't find libjava.so Done >FreeBSD/resource/jre/bin/i386/green_threads/java: ELF 32-bit LSB >executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 4.6 >(460102), dynamically linked (uses shared libs), FreeBSD-style, not >stripped Realize im taking a chance.... But Thank You ! -- cd /usr/ports/sysutils/life make clean __________ NOD32 3441 (20080915) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From thavinci at thavinci.za.net Mon Sep 15 06:34:38 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Mon Sep 15 11:25:04 2008 Subject: Error: Can't find libjava.so In-Reply-To: <20080914230105.GD3188@dan.emsphone.com> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <20080914230105.GD3188@dan.emsphone.com> Message-ID: <003f01c916fd$0a6ad400$1f407c00$@za.net> > I do realize this is probably better suited for freebsd-questions , > however haven't received any response and was simply hoping someone > would be kind enough. > > I recently obtained a very decent ups, however it is not supported by > NUT. > > It does however come with winpower software that does run on FreeBSD. > > However it rewuired java. > > So installed from ports > > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so >Are you running an amd64 winpower binary? If not, you'll probably need >to install an x86 java. You can't mix libraries for different >architectures. No I am not running amd64 binary, don't think they have such a thing :p As for java, I must have installed amd64 as did it from ports. Isn't java supposed to be transparent to what's running on it? Excuse my ignorance..... Thanks. :> -- Dan Nelson dnelson@allantgroup.com __________ NOD32 3440 (20080913) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From thavinci at thavinci.za.net Mon Sep 15 13:28:25 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Mon Sep 15 14:10:22 2008 Subject: Error: Can't find libjava.so In-Reply-To: <48CE2172.3090505@stevehodgson.co.uk> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <48CE2172.3090505@stevehodgson.co.uk> Message-ID: <001e01c91736$d47b4110$7d71c330$@za.net> > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so > >Do you have /proc mounted? Try unmounting it and retrying. No, I do not. Thanks From thavinci at thavinci.za.net Mon Sep 15 13:30:49 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Mon Sep 15 14:10:36 2008 Subject: Error: Can't find libjava.so In-Reply-To: <20080915093815.GA33139@icarus.home.lan> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <20080915093815.GA33139@icarus.home.lan> Message-ID: <002b01c91737$2af8ac30$80ea0490$@za.net> > I do realize this is probably better suited for freebsd-questions , however > haven't received any response and was simply hoping someone would be kind > enough. > > I recently obtained a very decent ups, however it is not supported by NUT. > > It does however come with winpower software that does run on FreeBSD. > > However it rewuired java. > > So installed from ports > > And was presented with following error: > > Error: can't find libjava.so > > This is on system in folder "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so >Can you provide the output of "ldconfig -r" from that box? I have >a feeling the ld.so pathing hints might lack a directory or two. /var/run/ld-elf.so.hints: search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib 0:-lc.7 => /lib/libc.so.7 1:-lcrypt.4 => /lib/libcrypt.so.4 2:-lkvm.4 => /lib/libkvm.so.4 3:-lm.5 => /lib/libm.so.5 4:-lmd.4 => /lib/libmd.so.4 5:-lncurses.7 => /lib/libncurses.so.7 6:-lncursesw.7 => /lib/libncursesw.so.7 7:-lsbuf.4 => /lib/libsbuf.so.4 8:-lutil.7 => /lib/libutil.so.7 9:-lalias.6 => /lib/libalias.so.6 10:-lbegemot.3 => /lib/libbegemot.so.3 11:-lbsnmp.4 => /lib/libbsnmp.so.4 12:-lcam.4 => /lib/libcam.so.4 13:-ldevstat.6 => /lib/libdevstat.so.6 14:-ledit.6 => /lib/libedit.so.6 15:-lbsdxml.3 => /lib/libbsdxml.so.3 16:-lgeom.4 => /lib/libgeom.so.4 17:-lipsec.3 => /lib/libipsec.so.3 18:-lipx.4 => /lib/libipx.so.4 19:-lkiconv.3 => /lib/libkiconv.so.3 20:-lpcap.5 => /lib/libpcap.so.5 21:-lthr.3 => /lib/libthr.so.3 22:-lufs.4 => /lib/libufs.so.4 23:-lz.4 => /lib/libz.so.4 24:-lavl.1 => /lib/libavl.so.1 25:-lnvpair.1 => /lib/libnvpair.so.1 26:-lumem.1 => /lib/libumem.so.1 27:-luutil.1 => /lib/libuutil.so.1 28:-lzfs.1 => /lib/libzfs.so.1 29:-lzpool.1 => /lib/libzpool.so.1 30:-lgcc_s.1 => /lib/libgcc_s.so.1 31:-lreadline.7 => /lib/libreadline.so.7 32:-lssp.0 => /lib/libssp.so.0 33:-lcrypto.5 => /lib/libcrypto.so.5 34:-lbsm.2 => /usr/lib/libbsm.so.2 35:-lcom_err.4 => /usr/lib/libcom_err.so.4 36:-lelf.1 => /usr/lib/libelf.so.1 37:-lform.4 => /usr/lib/libform.so.4 38:-lmenu.4 => /usr/lib/libmenu.so.4 39:-lpanel.4 => /usr/lib/libpanel.so.4 40:-lformw.4 => /usr/lib/libformw.so.4 41:-lmenuw.4 => /usr/lib/libmenuw.so.4 42:-lpanelw.4 => /usr/lib/libpanelw.so.4 43:-lnetgraph.3 => /usr/lib/libnetgraph.so.3 44:-lradius.3 => /usr/lib/libradius.so.3 45:-lrpcsvc.4 => /usr/lib/librpcsvc.so.4 46:-ltacplus.3 => /usr/lib/libtacplus.so.3 47:-lypclnt.3 => /usr/lib/libypclnt.so.3 48:-larchive.4 => /usr/lib/libarchive.so.4 49:-lbluetooth.3 => /usr/lib/libbluetooth.so.3 50:-lbz2.3 => /usr/lib/libbz2.so.3 51:-lcalendar.4 => /usr/lib/libcalendar.so.4 52:-ldevinfo.4 => /usr/lib/libdevinfo.so.4 53:-lfetch.5 => /usr/lib/libfetch.so.5 54:-lftpio.7 => /usr/lib/libftpio.so.7 55:-lgpib.2 => /usr/lib/libgpib.so.2 56:-lgssapi.9 => /usr/lib/libgssapi.so.9 57:-lmagic.3 => /usr/lib/libmagic.so.3 58:-lmemstat.2 => /usr/lib/libmemstat.so.2 59:-lmilter.4 => /usr/lib/libmilter.so.4 60:-lmp.6 => /usr/lib/libmp.so.6 61:-lncp.3 => /usr/lib/libncp.so.3 62:-lngatm.3 => /usr/lib/libngatm.so.3 63:-lopie.5 => /usr/lib/libopie.so.5 64:-lpam.4 => /usr/lib/libpam.so.4 65:-lpmc.4 => /usr/lib/libpmc.so.4 66:-lkse.3 => /usr/lib/libkse.so.3 67:-lrt.1 => /usr/lib/librt.so.1 68:-lsdp.3 => /usr/lib/libsdp.so.3 69:-lsmb.3 => /usr/lib/libsmb.so.3 70:-lthread_db.3 => /usr/lib/libthread_db.so.3 71:-lugidfw.3 => /usr/lib/libugidfw.so.3 72:-lusbhid.3 => /usr/lib/libusbhid.so.3 73:-lwrap.5 => /usr/lib/libwrap.so.5 74:-llwres.30 => /usr/lib/liblwres.so.30 75:-ldialog.6 => /usr/lib/libdialog.so.6 76:-lgomp.1 => /usr/lib/libgomp.so.1 77:-lgnuregex.4 => /usr/lib/libgnuregex.so.4 78:-lhistory.7 => /usr/lib/libhistory.so.7 79:-lstdc++.6 => /usr/lib/libstdc++.so.6 80:-lobjc.3 => /usr/lib/libobjc.so.3 81:-lasn1.9 => /usr/lib/libasn1.so.9 82:-lgssapi_krb5.9 => /usr/lib/libgssapi_krb5.so.9 83:-lhdb.9 => /usr/lib/libhdb.so.9 84:-lkadm5clnt.9 => /usr/lib/libkadm5clnt.so.9 85:-lkadm5srv.9 => /usr/lib/libkadm5srv.so.9 86:-lkafs5.9 => /usr/lib/libkafs5.so.9 87:-lkrb5.9 => /usr/lib/libkrb5.so.9 88:-lroken.9 => /usr/lib/libroken.so.9 89:-lssl.5 => /usr/lib/libssl.so.5 90:-lssh.4 => /usr/lib/libssh.so.4 91:-lcharset.1 => /usr/local/lib/libcharset.so.1 92:-liconv.3 => /usr/local/lib/libiconv.so.3 93:-lintl.8 => /usr/local/lib/libintl.so.8 94:-lasprintf.0 => /usr/local/lib/libasprintf.so.0 95:-lgettextpo.3 => /usr/local/lib/libgettextpo.so.3 96:-lusb-0.1.8 => /usr/local/lib/libusb-0.1.so.8 97:-lusbpp-0.1.8 => /usr/local/lib/libusbpp-0.1.so.8 98:-lupsclient.1 => /usr/local/lib/libupsclient.so.1 99:-lXau.6 => /usr/local/lib/libXau.so.6 100:-lXau.0 => /usr/local/lib/libXau.so.0 101:-lXdmcp.6 => /usr/local/lib/libXdmcp.so.6 102:-lX11.6 => /usr/local/lib/libX11.so.6 103:-lXext.6 => /usr/local/lib/libXext.so.6 104:-lXi.6 => /usr/local/lib/libXi.so.6 105:-lXp.6 => /usr/local/lib/libXp.so.6 106:-lICE.6 => /usr/local/lib/libICE.so.6 107:-lSM.6 => /usr/local/lib/libSM.so.6 108:-lXt.6 => /usr/local/lib/libXt.so.6 109:-lXtst.6 => /usr/local/lib/libXtst.so.6 Thank You For Help So Far! From freebsd-listen at fabiankeil.de Mon Sep 15 15:16:48 2008 From: freebsd-listen at fabiankeil.de (Fabian Keil) Date: Mon Sep 15 15:16:55 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080915042828.GA27658@icarus.home.lan> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <20080915023717.GF39765@stlux503.dsto.defence.gov.au> <20080915042828.GA27658@icarus.home.lan> Message-ID: <20080915170239.7ab656ec@fabiankeil.de> Jeremy Chadwick wrote: > On Mon, Sep 15, 2008 at 10:37:18AM +0800, Wilkinson, Alex wrote: > > 0n Fri, Sep 12, 2008 at 09:32:07AM -0700, Jeremy Chadwick wrote: > > > > >> About the only real improvement I'd like to see in this setup > > >> is the ability to spin down idle drives. That would be an > > >> ideal setup for the home RAID array. > > > > > >There is a FreeBSD port which handles this, although such a > > >feature should ideally be part of the ata(4) system (as should > > >TCQ/NCQ and a slew of other things -- some of those are being > > >worked on). > > > > And the port is ? > > Is it that hard to use 'make search' or grep? :-) sysutils/ataidle You also might want to have a look at atacontrol(8)'s spindown command. Fabian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080915/d0775ba8/signature.pgp From koitsu at FreeBSD.org Mon Sep 15 15:26:34 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 15 15:26:43 2008 Subject: Error: Can't find libjava.so In-Reply-To: <002b01c91737$2af8ac30$80ea0490$@za.net> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <20080915093815.GA33139@icarus.home.lan> <002b01c91737$2af8ac30$80ea0490$@za.net> Message-ID: <20080915152631.GA39924@icarus.home.lan> On Mon, Sep 15, 2008 at 03:30:06PM +0200, Marcel Grandemange wrote: > > I do realize this is probably better suited for freebsd-questions , > however > > haven't received any response and was simply hoping someone would be kind > > enough. > > > > I recently obtained a very decent ups, however it is not supported by NUT. > > > > It does however come with winpower software that does run on FreeBSD. > > > > However it rewuired java. > > > > So installed from ports > > > > And was presented with following error: > > > > Error: can't find libjava.so > > > > This is on system in folder > "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so > > >Can you provide the output of "ldconfig -r" from that box? I have > >a feeling the ld.so pathing hints might lack a directory or two. > > > /var/run/ld-elf.so.hints: > search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib This is the problem as I see it. ld.so, which is used for finding and loading shared libraries, is not configured to look in /usr/local/Diablo-jre1.6.0/lib/amd64 for libraries. I'd like to know which port you installed, and how you installed it. Based on the above, it appears to me the port itself may/does have a bug -- it should be updating the hints path to include that directory, but does/is not. Please note I am in no way shape or form familiar with Java or this port. I do not know if this is specific to your machine or not -- however, this is the first time I've seen it mentioned, and I quite active with freebsd-ports. (I'm subscribed to 15 separate FreeBSD mailing lists, and I read/follow them all) Regarding the problem itself: there are ways to work around this by using the environment variable LD_LIBRARY_PATH. I do not recommend this, though -- properly configuring the ld.so search path when a program (or port) is installed is the proper method. Cross-posting to multiple lists is generally shunned upon, so answers to the above questions will help determine if the discussion should be moved to freebsd-ports@ or not. I've a feeling it should be. Thanks! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon Sep 15 15:29:41 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 15 15:29:48 2008 Subject: ZFS w/failing drives - any equivalent of Solaris FMA? In-Reply-To: <20080915170239.7ab656ec@fabiankeil.de> References: <200809121544.m8CFiRHQ099725@lurza.secnetix.de> <5f67a8c40809120904o49b6e410l5b65a20f5216202@mail.gmail.com> <20080912163207.GE60094@icarus.home.lan> <20080915023717.GF39765@stlux503.dsto.defence.gov.au> <20080915042828.GA27658@icarus.home.lan> <20080915170239.7ab656ec@fabiankeil.de> Message-ID: <20080915152939.GA40157@icarus.home.lan> On Mon, Sep 15, 2008 at 05:02:39PM +0200, Fabian Keil wrote: > Jeremy Chadwick wrote: > > > On Mon, Sep 15, 2008 at 10:37:18AM +0800, Wilkinson, Alex wrote: > > > 0n Fri, Sep 12, 2008 at 09:32:07AM -0700, Jeremy Chadwick wrote: > > > > > > >> About the only real improvement I'd like to see in this setup > > > >> is the ability to spin down idle drives. That would be an > > > >> ideal setup for the home RAID array. > > > > > > > >There is a FreeBSD port which handles this, although such a > > > >feature should ideally be part of the ata(4) system (as should > > > >TCQ/NCQ and a slew of other things -- some of those are being > > > >worked on). > > > > > > And the port is ? > > > > Is it that hard to use 'make search' or grep? :-) sysutils/ataidle > > You also might want to have a look at atacontrol(8)'s spindown command. The appropriate ata(4) changes and extension of atacontrol(8) to support "spindown" was MFC'd (to RELENG_7) only 5 weeks ago. It's fairly unlikely that most users know this feature was MFC'd (case in point, I was not). http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c has the details, see Revision 1.43.2.2. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jhb at freebsd.org Mon Sep 15 19:28:55 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 19:29:01 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <20080915110838.GA5258@rebelion.Sisis.de> References: <20080915110838.GA5258@rebelion.Sisis.de> Message-ID: <200809151448.06105.jhb@freebsd.org> On Monday 15 September 2008 07:08:38 am Matthias Apitz wrote: > > Hello, > > I'm booting my laptop 3 times a day: in the morning at home (WEP area), > when I arrive in my office (WPA area) and in the evening at home > (again); > > the sequence is always the same: booting, login into console, startx > which launches via ~/.xinitrc the KDE; > > in about 1 of 2-3 cases and only in the office(!) the system panics when > KDE comes up, at the end of the KDE booting and the jingle already > played; today it crashed again and again and after switching off the > Wifi radio on the laptop it came finally up fine; > > I did this (Wifi off) because I'm assuming somehow a relation with > http://www.freebsd.org/cgi/query-pr.cgi?pr=122331 > where my laptop as well only panic'ed in WPA mode (i.e. in the office) > and with 'bgscan' active; which I now have deactivated; > > all these panics look in the debugger more or less like this one: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xc > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0788b98 > stack pointer = 0x28:0xe6960acc > frame pointer = 0x28:0xe6960c50 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1426 (kdeinit) > trap number = 12 > panic: page fault > cpuid = 0 > Uptime: 1m36s > Physical memory: 1009 MB > Dumping 129 MB: 114 98 82 66 50 34 18 2 > > #0 doadump () at pcpu.h:195 > 195 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:563 > #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) at /usr/src/sys/i386/i386/trap.c:899 > #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) > at /usr/src/sys/i386/i386/trap.c:812 > #5 0xc0a49c8c in trap (frame=0xe6960a8c) at /usr/src/sys/i386/i386/trap.c:490 > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, > fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) at /usr/src/sys/kern/sys_generic.c:663 > #9 0xc0a49635 in syscall (frame=0xe6960d38) at /usr/src/sys/i386/i386/trap.c:1035 > #10 0xc0a2fc70 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196 > #11 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > the 'current process' (kdeinit in the above crash) changes, but is > always one of the KDE parts; of course the problem is not KDE related, > it is just that the system comes under heavy usage in that moment; > > I already run 'memtest 128' for some hours without any noted problem in > memory; test are just passing fine; > > the same problem is with 7.0-RELEASE as with RELENG_7; > > what can I do to nail this down? it sucks somehow seeing it crashing on > startup in the morning in the office :-(( Can you go to frame 7 in kgdb and 'p *fdp'? -- John Baldwin From thavinci at thavinci.za.net Mon Sep 15 19:35:26 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Mon Sep 15 19:35:40 2008 Subject: Error: Can't find libjava.so In-Reply-To: <20080915152631.GA39924@icarus.home.lan> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <20080915093815.GA33139@icarus.home.lan> <002b01c91737$2af8ac30$80ea0490$@za.net> <20080915152631.GA39924@icarus.home.lan> Message-ID: <00be01c9176a$182f3910$488dab30$@za.net> > > I do realize this is probably better suited for freebsd-questions , > however > > haven't received any response and was simply hoping someone would be kind > > enough. > > > > I recently obtained a very decent ups, however it is not supported by NUT. > > > > It does however come with winpower software that does run on FreeBSD. > > > > However it rewuired java. > > > > So installed from ports > > > > And was presented with following error: > > > > Error: can't find libjava.so > > > > This is on system in folder > "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so > > >Can you provide the output of "ldconfig -r" from that box? I have > >a feeling the ld.so pathing hints might lack a directory or two. > > > /var/run/ld-elf.so.hints: > search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib >This is the problem as I see it. ld.so, which is used for finding and >loading shared libraries, is not configured to look in >/usr/local/Diablo-jre1.6.0/lib/amd64 for libraries. >I'd like to know which port you installed, and how you installed it. I did a cvsup on ports to update to latest on FreeBSD7.0 release amd64 Used port /usr/ports/java/Diablo-jre16 Simply did Make Make install Make clean Nothing Fancy... >Based on the above, it appears to me the port itself may/does have a bug >-- it should be updating the hints path to include that directory, but >does/is not. Please note I am in no way shape or form familiar with >Java or this port. Would make sense! >I do not know if this is specific to your machine or not -- however, >this is the first time I've seen it mentioned, and I quite active with >freebsd-ports. (I'm subscribed to 15 separate FreeBSD mailing lists, >and I read/follow them all) I have not tested this on any other machine, was doing this in a virtual machine to test ups software before deploying... >Regarding the problem itself: there are ways to work around this by >using the environment variable LD_LIBRARY_PATH. I do not recommend >this, though -- properly configuring the ld.so search path when a >program (or port) is installed is the proper method. Could you advise me how to do this? Hope you don't mind! >Cross-posting to multiple lists is generally shunned upon, so answers to >the above questions will help determine if the discussion should be >moved to freebsd-ports@ or not. I've a feeling it should be. >Thanks! Fare Enough! Thank You! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | __________ NOD32 3443 (20080915) Information __________ This message was checked by NOD32 antivirus system. http://www.eset.com From guru at unixarea.de Mon Sep 15 19:55:22 2008 From: guru at unixarea.de (Matthias Apitz) Date: Mon Sep 15 19:55:58 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <200809151448.06105.jhb@freebsd.org> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151448.06105.jhb@freebsd.org> Message-ID: <20080915194853.GA8365@rebelion.Sisis.de> El d?a Monday, September 15, 2008 a las 02:48:05PM -0400, John Baldwin escribi?: > > #0 doadump () at pcpu.h:195 > > 195 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) bt > > #0 doadump () at pcpu.h:195 > > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) > at /usr/src/sys/kern/kern_shutdown.c:563 > > #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) > at /usr/src/sys/i386/i386/trap.c:899 > > #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) > > at /usr/src/sys/i386/i386/trap.c:812 > > #5 0xc0a49c8c in trap (frame=0xe6960a8c) > at /usr/src/sys/i386/i386/trap.c:490 > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > fd_ou=0x298ad9c4, > > fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) > at /usr/src/sys/kern/sys_generic.c:663 > > #9 0xc0a49635 in syscall (frame=0xe6960d38) > at /usr/src/sys/i386/i386/trap.c:1035 > > #10 0xc0a2fc70 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:196 > > #11 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > ... > Can you go to frame 7 in kgdb and 'p *fdp'? (kgdb) frame 7 #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); (kgdb) p *fdp Variable "fdp" is not available. (kgdb) perhaps I do something wrong? matthias From netslists at gmail.com Mon Sep 15 20:46:22 2008 From: netslists at gmail.com (Sten Daniel Soersdal) Date: Mon Sep 15 20:46:29 2008 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade In-Reply-To: References: <39DC135F7F0571489196E0B6F5D58B4A03B460D0@MWBEXCH.mweb.com> Message-ID: <48CEC231.1070304@gmail.com> Karl Fischer wrote: > On Fri, Sep 12, 2008 at 01:00, Steven Hartland wrote: >> Thanks Rudi, would really like to get is sorted as they would make >> ideal app servers. >> >> ----- Original Message ----- From: "Rudi Kramer - MWEB" >> >> >> Hi Steven, >> >> We recently purchased a few M600's but haven't got around to loading >> FBSD on them, we should start installing next week and I will let you >> know if we run in to any problems. > > I have the same problem on my M600 Blades has anyone tested the 7.1 Beta and > I'm about to purchase more of them. (just a "me too") I'm about to receive 16 x M600 so I'm really anxious too. I was planning on AMD64 7.0-RELEASE (or newer) too. Please keep me on CC: no matter how trivial. :) -- Sten Daniel Soersdal From jhb at freebsd.org Mon Sep 15 20:49:49 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 15 20:50:12 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <20080915194853.GA8365@rebelion.Sisis.de> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151448.06105.jhb@freebsd.org> <20080915194853.GA8365@rebelion.Sisis.de> Message-ID: <200809151608.06738.jhb@freebsd.org> On Monday 15 September 2008 03:48:53 pm Matthias Apitz wrote: > El d?a Monday, September 15, 2008 a las 02:48:05PM -0400, John Baldwin escribi?: > > > > #0 doadump () at pcpu.h:195 > > > 195 pcpu.h: No such file or directory. > > > in pcpu.h > > > (kgdb) bt > > > #0 doadump () at pcpu.h:195 > > > #1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > > > #2 0xc0754719 in panic (fmt=Variable "fmt" is not available.) > > at /usr/src/sys/kern/kern_shutdown.c:563 > > > #3 0xc0a4905c in trap_fatal (frame=0xe6960a8c, eva=12) > > at /usr/src/sys/i386/i386/trap.c:899 > > > #4 0xc0a492e0 in trap_pfault (frame=0xe6960a8c, usermode=0, eva=12) > > > at /usr/src/sys/i386/i386/trap.c:812 > > > #5 0xc0a49c8c in trap (frame=0xe6960a8c) > > at /usr/src/sys/i386/i386/trap.c:490 > > > #6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139 > > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > > fd_ou=0x298ad9c4, > > > fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > > #8 0xc07890de in select (td=0xc49d5630, uap=0xe6960cfc) > > at /usr/src/sys/kern/sys_generic.c:663 > > > #9 0xc0a49635 in syscall (frame=0xe6960d38) > > at /usr/src/sys/i386/i386/trap.c:1035 > > > #10 0xc0a2fc70 in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:196 > > > #11 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > (kgdb) > > > > ... > > Can you go to frame 7 in kgdb and 'p *fdp'? > > (kgdb) frame 7 > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); > (kgdb) p *fdp > Variable "fdp" is not available. > (kgdb) If 'td' is available then you can do 'p *td->td_proc->p_fd' -- John Baldwin From guru at unixarea.de Mon Sep 15 22:24:37 2008 From: guru at unixarea.de (Matthias Apitz) Date: Mon Sep 15 22:24:50 2008 Subject: panic's on KDE-launches (but only in WPA Wifi area) / kern/122331 In-Reply-To: <200809151608.06738.jhb@freebsd.org> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151448.06105.jhb@freebsd.org> <20080915194853.GA8365@rebelion.Sisis.de> <200809151608.06738.jhb@freebsd.org> Message-ID: <20080915222414.GA12474@rebelion.Sisis.de> El d?a Monday, September 15, 2008 a las 04:08:06PM -0400, John Baldwin escribi?: > > > Can you go to frame 7 in kgdb and 'p *fdp'? > > > > (kgdb) frame 7 > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); > > (kgdb) p *fdp > > Variable "fdp" is not available. > > (kgdb) > > If 'td' is available then you can do 'p *td->td_proc->p_fd' (kgdb) frame 7 #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 136 return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); (kgdb) p td $7 = (struct thread *) 0xc49d5630 (kgdb) p *td->td_proc->p_fd $8 = {fd_ofiles = 0x0, fd_ofileflags = 0x0, fd_cdir = 0x0, fd_rdir = 0xc42f3a00, fd_jdir = 0x0, fd_nfiles = 20, fd_map = 0xc49db8b4, fd_lastfile = 9, fd_freefile = 10, fd_cmask = 18, fd_refcnt = 1, fd_holdcnt = 1, fd_sx = {lock_object = { lo_name = 0xc0ad3cbe "filedesc structure", lo_type = 0xc0ad3cbe "filedesc structure", lo_flags = 37421056, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 17, sx_recurse = 0}, fd_kqlist = {slh_first = 0x0}, fd_holdleaderscount = 0, fd_holdleaderswakeup = 0} (kgdb) matthias From koitsu at FreeBSD.org Tue Sep 16 04:33:25 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 16 04:33:33 2008 Subject: Error: Can't find libjava.so In-Reply-To: <00be01c9176a$182f3910$488dab30$@za.net> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <20080915093815.GA33139@icarus.home.lan> <002b01c91737$2af8ac30$80ea0490$@za.net> <20080915152631.GA39924@icarus.home.lan> <00be01c9176a$182f3910$488dab30$@za.net> Message-ID: <20080916043322.GA54034@icarus.home.lan> On Mon, Sep 15, 2008 at 09:34:39PM +0200, Marcel Grandemange wrote: > > > I do realize this is probably better suited for freebsd-questions , > > however > > > haven't received any response and was simply hoping someone would be > kind > > > enough. > > > > > > I recently obtained a very decent ups, however it is not supported by > NUT. > > > > > > It does however come with winpower software that does run on FreeBSD. > > > > > > However it rewuired java. > > > > > > So installed from ports > > > > > > And was presented with following error: > > > > > > Error: can't find libjava.so > > > > > > This is on system in folder > > "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so > > > > >Can you provide the output of "ldconfig -r" from that box? I have > > >a feeling the ld.so pathing hints might lack a directory or two. > > > > > > /var/run/ld-elf.so.hints: > > search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib > > >This is the problem as I see it. ld.so, which is used for finding and > >loading shared libraries, is not configured to look in > >/usr/local/Diablo-jre1.6.0/lib/amd64 for libraries. > > >I'd like to know which port you installed, and how you installed it. > > I did a cvsup on ports to update to latest on FreeBSD7.0 release amd64 > Used port /usr/ports/java/Diablo-jre16 > Simply did > Make > Make install > Make clean > Can you please apply the below patch and tell me if it solves your problem? Proper procedure should be: # cd /usr/ports/java/diablo-jre16 # patch < /wherever/the/patch/is # make clean # make # make deinstall # make install After this is done, use "ldconfig -r" and look at the search path shown at the top; hopefully /usr/local/diablo-jre1.6.0/lib/amd64 will be there, and libjava.so should be found (hopefully). > >Regarding the problem itself: there are ways to work around this by > >using the environment variable LD_LIBRARY_PATH. I do not recommend > >this, though -- properly configuring the ld.so search path when a > >program (or port) is installed is the proper method. > > Could you advise me how to do this? Hope you don't mind! Set the LD_LIBRARY_PATH environment variable to the search paths you desire. Colon-delimited, and it overrides the defaults. E.g. export LD_LIBRARY_PATH="/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/diablo-jre1.6.0/lib/amd64" But the below patch, assuming it works (and I got the paths right), should not require you to do that. LD_LIBRARY_PATH is somewhat evil, and it's not recommended you use it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | Index: Makefile =================================================================== RCS file: /home/pcvs/ports/java/diablo-jre16/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile 20 Aug 2008 04:13:02 -0000 1.3 +++ Makefile 16 Sep 2008 04:24:27 -0000 @@ -43,6 +43,8 @@ INSTALL_DIR= ${PREFIX}/${PKGNAMEPREFIX}jre${JRE_VERSION} +USE_LDCONFIG= ${PREFIX}/${PKGNAMEPREFIX}jre${JRE_VERSION}/lib/${ARCH} + .include .if ${OSVERSION} >= 700000 From thavinci at thavinci.za.net Tue Sep 16 09:47:10 2008 From: thavinci at thavinci.za.net (Marcel Grandemange) Date: Tue Sep 16 09:47:24 2008 Subject: Error: Can't find libjava.so In-Reply-To: <20080916043322.GA54034@icarus.home.lan> References: <015101c9164a$f3f12d30$dbd38790$@za.net> <20080915093815.GA33139@icarus.home.lan> <002b01c91737$2af8ac30$80ea0490$@za.net> <20080915152631.GA39924@icarus.home.lan> <00be01c9176a$182f3910$488dab30$@za.net> <20080916043322.GA54034@icarus.home.lan> Message-ID: <018f01c917e1$0e250f40$2a6f2dc0$@za.net> > > > I do realize this is probably better suited for freebsd-questions , > > however > > > haven't received any response and was simply hoping someone would be > kind > > > enough. > > > > > > I recently obtained a very decent ups, however it is not supported by > NUT. > > > > > > It does however come with winpower software that does run on FreeBSD. > > > > > > However it rewuired java. > > > > > > So installed from ports > > > > > > And was presented with following error: > > > > > > Error: can't find libjava.so > > > > > > This is on system in folder > > "/usr/local/Diablo-jre1.6.0/lib/amd64/libjava.so > > > > >Can you provide the output of "ldconfig -r" from that box? I have > > >a feeling the ld.so pathing hints might lack a directory or two. > > > > > > /var/run/ld-elf.so.hints: > > search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib > > >This is the problem as I see it. ld.so, which is used for finding and > >loading shared libraries, is not configured to look in > >/usr/local/Diablo-jre1.6.0/lib/amd64 for libraries. > > >I'd like to know which port you installed, and how you installed it. > > I did a cvsup on ports to update to latest on FreeBSD7.0 release amd64 > Used port /usr/ports/java/Diablo-jre16 > Simply did > Make > Make install > Make clean > >Can you please apply the below patch and tell me if it solves your >problem? Proper procedure should be: ># cd /usr/ports/java/diablo-jre16 ># patch < /wherever/the/patch/is ># make clean ># make ># make deinstall ># make install This went through successfully. >After this is done, use "ldconfig -r" and look at the search path >shown at the top; hopefully /usr/local/diablo-jre1.6.0/lib/amd64 >will be there, and libjava.so should be found (hopefully). The Results.... /var/run/ld-elf.so.hints: search directories: /lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/diablo-jre1.6.0/lib/ amd64 0:-lc.7 => /lib/libc.so.7 1:-lcrypt.4 => /lib/libcrypt.so.4 2:-lkvm.4 => /lib/libkvm.so.4 3:-lm.5 => /lib/libm.so.5 4:-lmd.4 => /lib/libmd.so.4 5:-lncurses.7 => /lib/libncurses.so.7 6:-lncursesw.7 => /lib/libncursesw.so.7 7:-lsbuf.4 => /lib/libsbuf.so.4 8:-lutil.7 => /lib/libutil.so.7 9:-lalias.6 => /lib/libalias.so.6 10:-lbegemot.3 => /lib/libbegemot.so.3 11:-lbsnmp.4 => /lib/libbsnmp.so.4 12:-lcam.4 => /lib/libcam.so.4 13:-ldevstat.6 => /lib/libdevstat.so.6 14:-ledit.6 => /lib/libedit.so.6 15:-lbsdxml.3 => /lib/libbsdxml.so.3 16:-lgeom.4 => /lib/libgeom.so.4 17:-lipsec.3 => /lib/libipsec.so.3 18:-lipx.4 => /lib/libipx.so.4 19:-lkiconv.3 => /lib/libkiconv.so.3 20:-lpcap.5 => /lib/libpcap.so.5 21:-lthr.3 => /lib/libthr.so.3 22:-lufs.4 => /lib/libufs.so.4 23:-lz.4 => /lib/libz.so.4 24:-lavl.1 => /lib/libavl.so.1 25:-lnvpair.1 => /lib/libnvpair.so.1 26:-lumem.1 => /lib/libumem.so.1 27:-luutil.1 => /lib/libuutil.so.1 28:-lzfs.1 => /lib/libzfs.so.1 29:-lzpool.1 => /lib/libzpool.so.1 30:-lgcc_s.1 => /lib/libgcc_s.so.1 31:-lreadline.7 => /lib/libreadline.so.7 32:-lssp.0 => /lib/libssp.so.0 33:-lcrypto.5 => /lib/libcrypto.so.5 34:-lbsm.2 => /usr/lib/libbsm.so.2 35:-lcom_err.4 => /usr/lib/libcom_err.so.4 36:-lelf.1 => /usr/lib/libelf.so.1 37:-lform.4 => /usr/lib/libform.so.4 38:-lmenu.4 => /usr/lib/libmenu.so.4 39:-lpanel.4 => /usr/lib/libpanel.so.4 40:-lformw.4 => /usr/lib/libformw.so.4 41:-lmenuw.4 => /usr/lib/libmenuw.so.4 42:-lpanelw.4 => /usr/lib/libpanelw.so.4 43:-lnetgraph.3 => /usr/lib/libnetgraph.so.3 44:-lradius.3 => /usr/lib/libradius.so.3 45:-lrpcsvc.4 => /usr/lib/librpcsvc.so.4 46:-ltacplus.3 => /usr/lib/libtacplus.so.3 47:-lypclnt.3 => /usr/lib/libypclnt.so.3 48:-larchive.4 => /usr/lib/libarchive.so.4 49:-lbluetooth.3 => /usr/lib/libbluetooth.so.3 50:-lbz2.3 => /usr/lib/libbz2.so.3 51:-lcalendar.4 => /usr/lib/libcalendar.so.4 52:-ldevinfo.4 => /usr/lib/libdevinfo.so.4 53:-lfetch.5 => /usr/lib/libfetch.so.5 54:-lftpio.7 => /usr/lib/libftpio.so.7 55:-lgpib.2 => /usr/lib/libgpib.so.2 56:-lgssapi.9 => /usr/lib/libgssapi.so.9 57:-lmagic.3 => /usr/lib/libmagic.so.3 58:-lmemstat.2 => /usr/lib/libmemstat.so.2 59:-lmilter.4 => /usr/lib/libmilter.so.4 60:-lmp.6 => /usr/lib/libmp.so.6 61:-lncp.3 => /usr/lib/libncp.so.3 62:-lngatm.3 => /usr/lib/libngatm.so.3 63:-lopie.5 => /usr/lib/libopie.so.5 64:-lpam.4 => /usr/lib/libpam.so.4 65:-lpmc.4 => /usr/lib/libpmc.so.4 66:-lkse.3 => /usr/lib/libkse.so.3 67:-lrt.1 => /usr/lib/librt.so.1 68:-lsdp.3 => /usr/lib/libsdp.so.3 69:-lsmb.3 => /usr/lib/libsmb.so.3 70:-lthread_db.3 => /usr/lib/libthread_db.so.3 71:-lugidfw.3 => /usr/lib/libugidfw.so.3 72:-lusbhid.3 => /usr/lib/libusbhid.so.3 73:-lwrap.5 => /usr/lib/libwrap.so.5 74:-llwres.30 => /usr/lib/liblwres.so.30 75:-ldialog.6 => /usr/lib/libdialog.so.6 76:-lgomp.1 => /usr/lib/libgomp.so.1 77:-lgnuregex.4 => /usr/lib/libgnuregex.so.4 78:-lhistory.7 => /usr/lib/libhistory.so.7 79:-lstdc++.6 => /usr/lib/libstdc++.so.6 80:-lobjc.3 => /usr/lib/libobjc.so.3 81:-lasn1.9 => /usr/lib/libasn1.so.9 82:-lgssapi_krb5.9 => /usr/lib/libgssapi_krb5.so.9 83:-lhdb.9 => /usr/lib/libhdb.so.9 84:-lkadm5clnt.9 => /usr/lib/libkadm5clnt.so.9 85:-lkadm5srv.9 => /usr/lib/libkadm5srv.so.9 86:-lkafs5.9 => /usr/lib/libkafs5.so.9 87:-lkrb5.9 => /usr/lib/libkrb5.so.9 88:-lroken.9 => /usr/lib/libroken.so.9 89:-lssl.5 => /usr/lib/libssl.so.5 90:-lssh.4 => /usr/lib/libssh.so.4 91:-lcharset.1 => /usr/local/lib/libcharset.so.1 92:-liconv.3 => /usr/local/lib/libiconv.so.3 93:-lintl.8 => /usr/local/lib/libintl.so.8 94:-lasprintf.0 => /usr/local/lib/libasprintf.so.0 95:-lgettextpo.3 => /usr/local/lib/libgettextpo.so.3 96:-lusb-0.1.8 => /usr/local/lib/libusb-0.1.so.8 97:-lusbpp-0.1.8 => /usr/local/lib/libusbpp-0.1.so.8 98:-lupsclient.1 => /usr/local/lib/libupsclient.so.1 99:-lXau.6 => /usr/local/lib/libXau.so.6 100:-lXau.0 => /usr/local/lib/libXau.so.0 101:-lXdmcp.6 => /usr/local/lib/libXdmcp.so.6 102:-lX11.6 => /usr/local/lib/libX11.so.6 103:-lXext.6 => /usr/local/lib/libXext.so.6 104:-lXi.6 => /usr/local/lib/libXi.so.6 105:-lXp.6 => /usr/local/lib/libXp.so.6 106:-lICE.6 => /usr/local/lib/libICE.so.6 107:-lSM.6 => /usr/local/lib/libSM.so.6 108:-lXt.6 => /usr/local/lib/libXt.so.6 109:-lXtst.6 => /usr/local/lib/libXtst.so.6 > >Regarding the problem itself: there are ways to work around this by > >using the environment variable LD_LIBRARY_PATH. I do not recommend > >this, though -- properly configuring the ld.so search path when a > >program (or port) is installed is the proper method. > > Could you advise me how to do this? Hope you don't mind! >Set the LD_LIBRARY_PATH environment variable to the search paths >you desire. Colon-delimited, and it overrides the defaults. E.g. >export LD_LIBRARY_PATH="/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/dia blo-jre1.6.0/lib/amd64" >But the below patch, assuming it works (and I got the paths right), >should not require you to do that. LD_LIBRARY_PATH is somewhat evil, >and it's not recommended you use it. Yup worked flawlessly on that part, but this always helps in the learning process ;> However even after that I was still presented with a...... [root@testvmbsd /opt/MonitorSoftware]# ./agent start Starting Agent: Error: can't find libjava.so. Done [root@testvmbsd /opt/MonitorSoftware]# -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | Index: Makefile =================================================================== RCS file: /home/pcvs/ports/java/diablo-jre16/Makefile,v retrieving revision 1.3 diff -u -r1.3 Makefile --- Makefile 20 Aug 2008 04:13:02 -0000 1.3 +++ Makefile 16 Sep 2008 04:24:27 -0000 @@ -43,6 +43,8 @@ INSTALL_DIR= ${PREFIX}/${PKGNAMEPREFIX}jre${JRE_VERSION} +USE_LDCONFIG= ${PREFIX}/${PKGNAMEPREFIX}jre${JRE_VERSION}/lib/${ARCH} + .include .if ${OSVERSION} >= 700000 From lulf at stud.ntnu.no Tue Sep 16 11:00:46 2008 From: lulf at stud.ntnu.no (Ulf Lilleengen) Date: Tue Sep 16 11:03:19 2008 Subject: [PATCH] New patch for cvsmode in csup Message-ID: <20080916110346.GA12643@carrot.studby.ntnu.no> Hello, Time again for a csup patch. There have been many improvements to make it behave like cvsup in most circumstanses. A few notes: * Fixed a "bug" where csup would crash if the diff was not applied correctly, requiring changing the procedure on how diffs are applied within csup. * Fix so files added/removed to/from Attic will actually get removed from the client, making it work equally to csup. * Fix so the checkouts/status-file is mostly correctly updated, but this does only matter a little if one mixes usage with csup/cvsup. * Note that updating of CVSROOT-* might take longer time than cvsup, because cvsup supports rsync algorithm, which fits those files better. * A lot of cleanups to the code, making it ready for review. Thanks to kris@ for helping out with testing. If anyone would like to review this patch, that would be nice. The patch can be found here: http://people.freebsd.org/~lulf/patches/csup/csup_09_16_2008.diff -- Ulf Lilleengen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080916/e975004a/attachment.pgp From jhb at freebsd.org Tue Sep 16 19:49:22 2008 From: jhb at freebsd.org (John Baldwin) Date: Tue Sep 16 19:52:15 2008 Subject: kern/122331: panic's on KDE-launches (but only in WPA Wifi area) In-Reply-To: <20080915222414.GA12474@rebelion.Sisis.de> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151608.06738.jhb@freebsd.org> <20080915222414.GA12474@rebelion.Sisis.de> Message-ID: <200809161125.45034.jhb@freebsd.org> On Monday 15 September 2008 06:24:14 pm Matthias Apitz wrote: > El d?a Monday, September 15, 2008 a las 04:08:06PM -0400, John Baldwin escribi?: > > > > > Can you go to frame 7 in kgdb and 'p *fdp'? > > > > > > (kgdb) frame 7 > > > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > > > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > > > return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : fdp->fd_ofiles[fd]); > > > (kgdb) p *fdp > > > Variable "fdp" is not available. > > > (kgdb) > > > > If 'td' is available then you can do 'p *td->td_proc->p_fd' > > (kgdb) frame 7 > #7 0xc0788b98 in kern_select (td=0xc49d5630, nd=9, fd_in=0x298ad840, > fd_ou=0x298ad9c4, fd_ex=0x298adb48, tvp=0x0) at filedesc.h:136 > 136 return (fd < 0 || fd >= fdp->fd_nfiles ? NULL : > fdp->fd_ofiles[fd]); > (kgdb) p td > $7 = (struct thread *) 0xc49d5630 > (kgdb) p *td->td_proc->p_fd > $8 = {fd_ofiles = 0x0, fd_ofileflags = 0x0, fd_cdir = 0x0, Well, fd_ofiles being NULL here is really odd. It's also odd that you have no current directory. Because fd_nfiles is 20, fd_ofiles should be pointing to the static file descriptor array. Off the top of my head I don't see how this is happening. It might help if you can narrow down exactly what WPA operation you are doing that causes the panic. -- John Baldwin From nparhar at gmail.com Tue Sep 16 20:31:35 2008 From: nparhar at gmail.com (Navdeep Parhar) Date: Tue Sep 16 20:35:33 2008 Subject: kgdb's add-kld broken on amd64 Message-ID: Hello everyone, The add-kld command in kgdb does not work as expected on amd64 (I'm using a recent HEAD, problem may affect others too). It uses the same address for all sections: (kgdb) add-kld if_cxgb.ko add symbol table from file "/boot/kernel/if_cxgb.ko" at .text_addr = 0xffffffff81022000 .rodata_addr = 0xffffffff81022000 .rodata.str1.8_addr = 0xffffffff81022000 .rodata.str1.1_addr = 0xffffffff81022000 set_modmetadata_set_addr = 0xffffffff81022000 set_sysctl_set_addr = 0xffffffff81022000 set_sysinit_set_addr = 0xffffffff81022000 set_sysuninit_set_addr = 0xffffffff81022000 .data_addr = 0xffffffff81022000 .bss_addr = 0xffffffff81022000 (y or n) This is not correct. The .text section's address is OK but the others are not. The problem seems to be that all amd64 kernel objects have VMA set to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c uses this VMA to adjust the address of the section: address = asi->base_addr + bfd_get_section_vma(bfd, sect); objdump -h shows that the userland objects on amd64 and all objects (kernel + userland) on i386 set VMA. It is only the kernel objects on amd64 that have VMA = 0. (sample output from amd64 and i386 machines appended at the end) For the time being I've patched kgdb to consider the file offset and not the VMA while calculating the section address. It seems to work but is probably not the right way to fix the problem. Any thoughts? Regards, Navdeep -------------------------------------------------------------------------- amd64# objdump -h /boot/kernel/if_cxgb.ko /boot/kernel/if_cxgb.ko: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .text 0001c444 0000000000000000 0000000000000000 00000040 2**4 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .rodata 00000d91 0000000000000000 0000000000000000 0001c4a0 2**5 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 2 .rodata.str1.8 000018fa 0000000000000000 0000000000000000 0001d238 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .rodata.str1.1 00001b94 0000000000000000 0000000000000000 0001eb32 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA -------------------------------------------------------------------------- amd64# objdump -h /bin/ls /bin/ls: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000015 00000000004001c8 00000000004001c8 000001c8 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000018 00000000004001e0 00000000004001e0 000001e0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00000274 00000000004001f8 00000000004001f8 000001f8 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 00000840 0000000000400470 0000000000400470 00000470 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA -------------------------------------------------------------------------- i386# objdump -h /boot/kernel/if_cxgb.ko /boot/kernel/if_cxgb.ko: file format elf32-i386-freebsd Sections: Idx Name Size VMA LMA File off Algn 0 .hash 0000064c 00000094 00000094 00000094 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .dynsym 00000cc0 000006e0 000006e0 000006e0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynstr 00000a5e 000013a0 000013a0 000013a0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA -------------------------------------------------------------------------- i386# objdump -h /bin/ls /bin/ls: file format elf32-i386-freebsd Sections: Idx Name Size VMA LMA File off Algn 0 .interp 00000015 08048114 08048114 00000114 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .note.ABI-tag 00000018 0804812c 0804812c 0000012c 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .hash 00000264 08048144 08048144 00000144 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynsym 00000540 080483a8 080483a8 000003a8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA -------------------------------------------------------------------------- From guru at unixarea.de Wed Sep 17 07:28:03 2008 From: guru at unixarea.de (Matthias Apitz) Date: Wed Sep 17 07:28:20 2008 Subject: kern/122331: panic's on KDE-launches (but only in WPA Wifi area) In-Reply-To: <200809161125.45034.jhb@freebsd.org> References: <20080915110838.GA5258@rebelion.Sisis.de> <200809151608.06738.jhb@freebsd.org> <20080915222414.GA12474@rebelion.Sisis.de> <200809161125.45034.jhb@freebsd.org> Message-ID: <20080917072747.GA2738@rebelion.Sisis.de> El d?a Tuesday, September 16, 2008 a las 11:25:44AM -0400, John Baldwin escribi?: > Well, fd_ofiles being NULL here is really odd. It's also odd that you have no > current directory. Because fd_nfiles is 20, fd_ofiles should be pointing to > the static file descriptor array. Off the top of my head I don't see how > this is happening. It might help if you can narrow down exactly what WPA > operation you are doing that causes the panic. I'm doing nothing by my own with WPA; the wpa_supplicant is launched at boot time via /etc/rc.conf entry as: ifconfig_iwi0="WPA" i.e. in the moment when I launch the X11+KDE with 'startx' is already running, iwi0 is associated with the AP and IP/routing is up in the interface (I've checked this always with 'ifconfig iwi0'); the difference between my home and the office is WEP (at home where I don't face that problem) and WPA in the office; yesterday and today morning KDE booted fine without causing this panic; could the reason be some inconsistency in the file system? but in this case as well I don't know where this could come from; I have always clean shutdowns before moving from my home to the office: matthias -- Matthias Apitz A computer is like an air conditioner, it stops working when you open Windows Una computadora es como aire acondicionado, deja de funcionar si abres Windows From marc.loerner at hob.de Wed Sep 17 13:05:54 2008 From: marc.loerner at hob.de (Marc =?iso-8859-1?q?L=F6rner?=) Date: Wed Sep 17 13:06:01 2008 Subject: question on asymmetric mtx_[un]lock_sleep In-Reply-To: <200809101409.49145.jhb@freebsd.org> References: <200809041400.04575.marc.loerner@hob.de> <200809101019.30453.marc.loerner@hob.de> <200809101409.49145.jhb@freebsd.org> Message-ID: <200809171439.37151.marc.loerner@hob.de> On Wednesday 10 September 2008 20:09, John Baldwin wrote: > On Wednesday 10 September 2008 04:19:30 am Marc L?rner wrote: > > On Tuesday 09 September 2008 21:38, John Baldwin wrote: > > > On Thursday 04 September 2008 08:00:04 am Marc L?rner wrote: > > > > Hello, > > > > I just read through the code of mutexes and turnstiles > > > > and it seems to me that _mtx_lock_sleep and _mtx_unlock_sleep > > > > are some kind of asymmetric when turning SMP and adaptive mutexes > > > > on in kernel-configuration. > > > > > > > > On locking the mutex, we try to "quick" obtain the lock. > > > > If we can't do this, we look, whether some other thread, that's > > > > running, holds the lock and spin until either lock is freed or thread > > > > is not running anymore. In that case we try again to obtain the lock > > > > "quick". If the thread only stopped running but still holds the lock, > > > > we use > > > > > > turnstiles > > > > > > > to wake us up, when the thread unlocks the mutex. > > > > => That seems to be fine and quite symmetric with _mtx_unlock_sleep!! > > > > > > > > But if we're spinning and the other thread gave the mutex free, > > > > we quick-lock the mutex and don't set up a turnstile. > > > > > > > > Now on mtx_unlock_sleep: > > > > - in FreeBSD6/until revision 1.200 turnstiles were tested on > > > > existence. => if turnstile_lookup return NULL we only released the > > > > lock quick. > > > > > > > > - But now, it's never tested if turnstile exists instead we > > > > broadcast/wakeup all threads pending on the turnstile. If this > > > > turnstile is NULL => we > > > > > > access > > > > > > > wrong memory. > > > > > > > > Now my question is: Why can we be sure (in new source) that > > > > turnstile_lookup always returns a valid pointer to an turnstile and > > > > can use returned pointer to call turnstile_broadcast? Am I missing > > something? > > > > > Because it seems that following scenario may occur: > > > > - on locking same scenario as above (=> thread1 now holds the lock) > > > > - thread1 is put off the runqueue > > > > - thread2 now tries to quick unlock mutex and sees that thread1 holds > > > > it => call to mtx_unlock_sleep > > > > - now we try to use turnstile-mechanism and call turnstile_lookup => > > > > returns NULL because no thread waits for wakeup => we call > > > > turnstile_broadcast and crash. > > > > > > Newer locks don't set the CONTESTED flag unless they are actually going > > > to go to sleep. If they succeed in setting CONTESTED or it is already > > > set when they test for it, then they will block on the turnstile. The > > > turnstile chain lock will prevent a concurrent unlock from grabbing the > > > turnstile until the blocking thread is fully asleep. > > > > I see the setting of CONTESTED in case of sleeping in mtx_lock_sleep! > > But there is still the possibility that mtx_lock_sleep "just" obtains the > > lock > > > and doesn't set contested-bit! See described case above (we reach first > > continue in mtx_lock_sleep and test on obtain_lock ends while-loop). > > In that case the lock won't have a turnstile, so mtx_unlock_sleep() will > never be called. > > > Why is this bit not tested in mtx_unlock_sleep? > > If the bit is clear the first attempt to unlock the mutex will succeed, and > mtx_unlock_sleep() won't be called. > > > I think, it's still possible that turnstile_lookup returns NULL. > > And we still have "MPASS(ts != NULL);" in mtx_unlock_sleep that is not > > turned on for GENERIC-kernel (no INVARIANTS support). > > It won't return NULL. > > > And I'm still wondering why the former test on "ts != NULL" went away? > > As I mentioned, previously when a thread used to do an adaptive spin, it > would set the CONTESTED flag before spinning. This could result in the > case that a mutex would have CONTESTED set, but not have an associated > turnstile. Now that the adaptive spinning happens earlier before setting > CONTESTED, mutexes can no longer get into that state. That is, if > CONTESTED is set, the mutex always has an assigned turnstile. If CONTESTED > isn't set, then the first attempt to unlock a mutex will succeed, and > mtx_unlock_sleep() won't be called at all. I got an Page-Not-Present fault on my itanium machine and thought this error is coming from the mutex and turnstile functions. Because when checking on NULL in mtx_unlock_sleep the fault went away. But I was wrong. A little more research resulted in the error lying in the architecture-dependent part of the pcpu.h-macros. So after a thread switched cores he may use the old address of pcpu and curthread that now doesn't hold the right tid anymore. Thanks for your explanations and sorry for the noise! Marc Loerner From defan at zenon.net Wed Sep 17 14:51:26 2008 From: defan at zenon.net (Andrew N. Below) Date: Wed Sep 17 14:51:33 2008 Subject: amd64, COMPAT_IA32 & syscall diverts Message-ID: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> Hi all. We have loadable kernel module with several syscall intercepting functions (e.g., sysent[SYS___sysctl].sy_call). Earlier, this module was built and used on i386 platform, now we have to run it on amd64. For some reasons we have to enable COMPAT_IA32 option in kernel. Our syscall wrapper sucessfully receiving syscalls from amd64 binaries, but we have nothing from old i386 binaries. Seems like these calls are made bypassing our kernel module. Is there any way to handle them? OS is freebsd 6.3-stable. Thanks, -- Andrew From fluxboxtremist at gmail.com Wed Sep 17 15:30:04 2008 From: fluxboxtremist at gmail.com (Andres Chavez) Date: Wed Sep 17 15:30:18 2008 Subject: Auto Connect After Connection Fails Message-ID: <2de331130809170806v9ee6c58t23386fbef6873078@mail.gmail.com> Hi Hackers, im wondering if its posible somehow to auto reconnect after a connection fails. This is because from time to time my ISP while renews the ip address the connection just freezes and i have to manually use dhclient -u {if} to get the new address or even when there is no ip change by my ISP i still get this problem sometimes. Any help? -- Visit http://www.noixe.net Electronic Music 24/7 From jhb at freebsd.org Wed Sep 17 15:31:57 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 15:32:08 2008 Subject: kgdb's add-kld broken on amd64 In-Reply-To: References: Message-ID: <200809171131.30819.jhb@freebsd.org> On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote: > Hello everyone, > > The add-kld command in kgdb does not work as expected on amd64 > (I'm using a recent HEAD, problem may affect others too). It uses > the same address for all sections: > > (kgdb) add-kld if_cxgb.ko > add symbol table from file "/boot/kernel/if_cxgb.ko" at > .text_addr = 0xffffffff81022000 > .rodata_addr = 0xffffffff81022000 > .rodata.str1.8_addr = 0xffffffff81022000 > .rodata.str1.1_addr = 0xffffffff81022000 > set_modmetadata_set_addr = 0xffffffff81022000 > set_sysctl_set_addr = 0xffffffff81022000 > set_sysinit_set_addr = 0xffffffff81022000 > set_sysuninit_set_addr = 0xffffffff81022000 > .data_addr = 0xffffffff81022000 > .bss_addr = 0xffffffff81022000 > (y or n) > > This is not correct. The .text section's address is OK but the > others are not. > > The problem seems to be that all amd64 kernel objects have VMA set > to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c > uses this VMA to adjust the address of the section: > > address = asi->base_addr + bfd_get_section_vma(bfd, sect); > > objdump -h shows that the userland objects on amd64 and all > objects (kernel + userland) on i386 set VMA. It is only the > kernel objects on amd64 that have VMA = 0. (sample output from > amd64 and i386 machines appended at the end) > > For the time being I've patched kgdb to consider the file offset > and not the VMA while calculating the section address. It seems > to work but is probably not the right way to fix the problem. > > Any thoughts? Hmm, I wonder if this is because on amd64 modules are .o's rather than .so's. It is. File offset isn't quite right. Instead, the way sys/kern/link_elf_obj.c works is that it just loads the PROGBITS (text, code, etc.) and NOBITS (bss) sections in the order they are in the file and concatenates them. So, the relocation logic in kgdb will need to be updated to recognize a .o vs .so and apply that algorithm for .o files. Actually, what I've done is to replace the home-rolled section relocation stuff with the gdb primitives that the solib code in gdb uses. It works here on i386, and hopefully this will fix this as this is how the sharedlibrary kld stuff is doing the relocations: --- //depot/vendor/freebsd/src/gnu/usr.bin/gdb/kgdb/kld.c 2008/04/29 20:41:02 +++ //depot/user/jhb/kgdb/gnu/usr.bin/gdb/kgdb/kld.c 2008/09/17 15:27:25 @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include @@ -196,39 +197,14 @@ return (0); } -struct add_section_info { - struct section_addr_info *section_addrs; - int sect_index; - CORE_ADDR base_addr; -}; - -static void -add_section (bfd *bfd, asection *sect, void *arg) -{ - struct add_section_info *asi = arg; - CORE_ADDR address; - char *name; - - /* Ignore non-resident sections. */ - if ((bfd_get_section_flags(bfd, sect) & (SEC_ALLOC | SEC_LOAD)) == 0) - return; - - name = xstrdup(bfd_get_section_name(bfd, sect)); - make_cleanup(xfree, name); - address = asi->base_addr + bfd_get_section_vma(bfd, sect); - asi->section_addrs->other[asi->sect_index].name = name; - asi->section_addrs->other[asi->sect_index].addr = address; - asi->section_addrs->other[asi->sect_index].sectindex = sect->index; - printf_unfiltered("\t%s_addr = %s\n", name, local_hex_string(address)); - asi->sect_index++; -} - static void load_kld (char *path, CORE_ADDR base_addr, int from_tty) { - struct add_section_info asi; + struct section_addr_info *sap; + struct section_table *sections, *sections_end, *s; struct cleanup *cleanup; bfd *bfd; + int i; /* Open the kld. */ bfd = bfd_openr(path, gnutarget); @@ -244,19 +220,30 @@ if (bfd_get_section_by_name (bfd, ".text") == NULL) error("\"%s\": can't find text section", path); + /* Build a section table from the bfd and relocate the sections. */ + if (build_section_table (bfd, §ions, §ions_end)) + error("\"%s\": can't find file sections", path); + cleanup = make_cleanup(xfree, sections); + for (s = sections; s < sections_end; s++) { + s->addr += base_addr; + s->endaddr += base_addr; + } + + /* Build a section addr info to pass to symbol_file_add(). */ + sap = build_section_addr_info_from_section_table (sections, + sections_end); + cleanup = make_cleanup((make_cleanup_ftype *)free_section_addr_info, + sap); + printf_unfiltered("add symbol table from file \"%s\" at\n", path); - - /* Build a section table for symbol_file_add() from the bfd sections. */ - asi.section_addrs = alloc_section_addr_info(bfd_count_sections(bfd)); - cleanup = make_cleanup(xfree, asi.section_addrs); - asi.sect_index = 0; - asi.base_addr = base_addr; - bfd_map_over_sections(bfd, add_section, &asi); + for (i = 0; i < sap->num_sections; i++) + printf_unfiltered("\t%s_addr = %s\n", sap->other[i].name, + local_hex_string(sap->other[i].addr)); if (from_tty && (!query("%s", ""))) error("Not confirmed."); - symbol_file_add(path, from_tty, asi.section_addrs, 0, OBJF_USERLOADED); + symbol_file_add(path, from_tty, sap, 0, OBJF_USERLOADED); do_cleanups(cleanup); } -- John Baldwin From julian at elischer.org Wed Sep 17 15:36:01 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 17 15:36:08 2008 Subject: amd64, COMPAT_IA32 & syscall diverts In-Reply-To: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> References: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> Message-ID: <48D123DD.2030701@elischer.org> Andrew N. Below wrote: > Hi all. > > We have loadable kernel module with > several syscall intercepting functions > (e.g., sysent[SYS___sysctl].sy_call). > Earlier, this module was built and used > on i386 platform, now we have to run it > on amd64. For some reasons we have to > enable COMPAT_IA32 option in kernel. > > Our syscall wrapper sucessfully receiving > syscalls from amd64 binaries, but we have > nothing from old i386 binaries. > > Seems like these calls are made bypassing > our kernel module. x86 binaries use a separate syscall table, so you need to patch both tables. > > Is there any way to handle them? > > OS is freebsd 6.3-stable. > > Thanks, > -- > Andrew > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From andymac at bullseye.apana.org.au Wed Sep 17 16:20:02 2008 From: andymac at bullseye.apana.org.au (Andrew MacIntyre) Date: Wed Sep 17 16:20:23 2008 Subject: unexpected behaviour of malloc() on 7.0/amd64 Message-ID: <48D12AD4.1000806@bullseye.andymac.org> [If this is not an appropriate forum for this query, please suggest a more appropriate one] In investigating a Python 2.6rc1 regression test failure on FreeBSD 7.0/amd64, as far as I can tell, malloc() does not return NULL when available memory (including swap) is exhausted - the process just gets KILLed. Using ulimit -v to set a virtual memory use limit below the available memory does result in malloc() returning NULL when the limit is hit. The Python regression test concerned does not fail on FreeBSD 7.0/i386, however the C program below exhibits the unexpected behaviour on both 7.0/amd64 and 7.0/i386. The C program below does behave as expected on FreeBSD 6.3/i386; I cannot currently test its behaviour on FreeBSD 6.3/amd64. I can't see this behaviour documented in the malloc() man page. I attempted to search the gnats database but the only mention of "malloc" is not related to this issue and doesn't involve this architecture. Is this the intended behaviour? ---8<---8<---8<--- #include #include #include #define CHUNK_SIZE 1024*1024 int main(void) { char* t; char buffer[256]; int i = 0; while (1) { if ((t = malloc(CHUNK_SIZE)) == NULL) { sprintf(buffer, "chunks allocated: %d\n", i); printf(buffer); break; } memset(t, 0, CHUNK_SIZE); ++i; } return 0; } ---8<---8<---8<--- Thanks, Andrew. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From defan at zenon.net Wed Sep 17 16:29:07 2008 From: defan at zenon.net (Andrew N. Below) Date: Wed Sep 17 16:29:17 2008 Subject: amd64, COMPAT_IA32 & syscall diverts References: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> <48D123DD.2030701@elischer.org> Message-ID: <064901c918e2$803df770$970da8c0@jam.zenon.net> > Andrew N. Below wrote: > > Hi all. > > > > We have loadable kernel module with > > several syscall intercepting functions > > (e.g., sysent[SYS___sysctl].sy_call). > > Earlier, this module was built and used > > on i386 platform, now we have to run it > > on amd64. For some reasons we have to > > enable COMPAT_IA32 option in kernel. > > > > Our syscall wrapper sucessfully receiving > > syscalls from amd64 binaries, but we have > > nothing from old i386 binaries. > > > > Seems like these calls are made bypassing > > our kernel module. > > x86 binaries use a separate syscall table, so you need to patch > both tables. Where can I find something about that table? Nothing interesting in sysent.h/syscall.h... -- Andrew From gahr at FreeBSD.org Wed Sep 17 16:56:11 2008 From: gahr at FreeBSD.org (Pietro Cerutti) Date: Wed Sep 17 16:56:24 2008 Subject: unexpected behaviour of malloc() on 7.0/amd64 In-Reply-To: <48D12AD4.1000806@bullseye.andymac.org> References: <48D12AD4.1000806@bullseye.andymac.org> Message-ID: <48D13695.2070000@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Andrew MacIntyre wrote: [snip] | In investigating a Python 2.6rc1 regression test failure on FreeBSD | 7.0/amd64, as far as I can tell, malloc() does not return NULL when | available memory (including swap) is exhausted - the process just gets | KILLed. [snip] | The Python regression test concerned does not fail on FreeBSD 7.0/i386, | however the C program below exhibits the unexpected behaviour on both | 7.0/amd64 and 7.0/i386. The C program below does behave as | expected on FreeBSD 6.3/i386; I cannot currently test its behaviour on | FreeBSD 6.3/amd64. [snip] | Is this the intended behaviour? I can confirm something strange happening on i386/7.0-RELEASE: | ./malloc Killed | While on i386/8.0-CURRENT the behavior is as expected: | ./malloc_test chunks allocated: 2936 | [snip] | | Thanks, | Andrew. | - -- Pietro Cerutti gahr@FreeBSD.org PGP Public Key: http://gahr.ch/pgp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREKAAYFAkjRNpQACgkQwMJqmJVx946uhQCfcWVVNnIXOIZ5PrmnenEjgLcT gQYAoNpwNxsW94EnOpMHQoit+OOgNd02 =mGSL -----END PGP SIGNATURE----- From defan at zenon.net Wed Sep 17 17:26:33 2008 From: defan at zenon.net (Andrew N. Below) Date: Wed Sep 17 17:26:40 2008 Subject: amd64, COMPAT_IA32 & syscall diverts References: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> <48D123DD.2030701@elischer.org> Message-ID: <06f401c918ea$866268e0$970da8c0@jam.zenon.net> > x86 binaries use a separate syscall table, so you need to patch > both tables. Ooops, sorry, I found it. Thanks! -- Andrew From jasone at FreeBSD.org Wed Sep 17 17:31:55 2008 From: jasone at FreeBSD.org (Jason Evans) Date: Wed Sep 17 17:32:04 2008 Subject: unexpected behaviour of malloc() on 7.0/amd64 In-Reply-To: <48D12AD4.1000806@bullseye.andymac.org> References: <48D12AD4.1000806@bullseye.andymac.org> Message-ID: <48D13784.2090701@FreeBSD.org> Andrew MacIntyre wrote: > In investigating a Python 2.6rc1 regression test failure on FreeBSD > 7.0/amd64, as far as I can tell, malloc() does not return NULL when > available memory (including swap) is exhausted - the process just gets > KILLed. > > Using ulimit -v to set a virtual memory use limit below the available > memory does result in malloc() returning NULL when the limit is hit. > > The Python regression test concerned does not fail on FreeBSD 7.0/i386, > however the C program below exhibits the unexpected behaviour on both > 7.0/amd64 and 7.0/i386. The C program below does behave as > expected on FreeBSD 6.3/i386; I cannot currently test its behaviour on > FreeBSD 6.3/amd64. > > I can't see this behaviour documented in the malloc() man page. From malloc(3): === IMPLEMENTATION NOTES Traditionally, allocators have used sbrk(2) to obtain memory, which is suboptimal for several reasons, including race conditions, increased fragmentation, and artificial limitations on maximum usable memory. This allocator uses both sbrk(2) and mmap(2) by default, but it can be configured at run time to use only one or the other. If resource limits are not a primary concern, the preferred configuration is MALLOC_OPTIONS=dM or MALLOC_OPTIONS=DM. When so configured, the datasize resource limit has little practical effect for typical applications; use MALLOC_OPTIONS=Dm if that is a concern. Regardless of allocator configuration, the vmemoryuse resource limit can be used to bound the total virtual memory used by a process, as described in limits(1). === If you want a custom python binary that does not use mmap, you can define _malloc_options to "d", or just use MALLOC_OPTIONS in the environment. Jason From jhb at freebsd.org Wed Sep 17 17:43:28 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 17:43:34 2008 Subject: amd64, COMPAT_IA32 & syscall diverts In-Reply-To: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> References: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> Message-ID: <200809171136.24300.jhb@freebsd.org> On Wednesday 17 September 2008 09:51:22 am Andrew N. Below wrote: > Hi all. > > We have loadable kernel module with > several syscall intercepting functions > (e.g., sysent[SYS___sysctl].sy_call). > Earlier, this module was built and used > on i386 platform, now we have to run it > on amd64. For some reasons we have to > enable COMPAT_IA32 option in kernel. > > Our syscall wrapper sucessfully receiving > syscalls from amd64 binaries, but we have > nothing from old i386 binaries. > > Seems like these calls are made bypassing > our kernel module. > > Is there any way to handle them? > > OS is freebsd 6.3-stable. You have to patch the sysent[] array in the compat/freebsd. There currently isn't a really clean way of doing this (and there really should be). -- John Baldwin From maksim.yevmenkin at gmail.com Wed Sep 17 18:15:13 2008 From: maksim.yevmenkin at gmail.com (Maksim Yevmenkin) Date: Wed Sep 17 18:15:19 2008 Subject: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c In-Reply-To: References: <20080917161633.9E2F717101@shadow.codelabs.ru> Message-ID: On 9/17/08, Eygene Ryabinkin wrote: > Maxim, good day. > > Cc'ing this discuission to hackers@ -- I was just going to write > the separate letter on this topic to the list. > > Wed, Sep 17, 2008 at 09:56:14AM -0700, Maksim Yevmenkin wrote: > > have you tried to simply set KBDMUX_LOCK/UNLOCK() to > > mtx_lock/unlock(&Giant) ? > > Since kbdmux callout is initialized as non-MPSAFE, this will result in > double locking the Giant (at least I see it from the code). I am not > sure that this is very good -- had not yet verified that Giant is > recursive. yes, giant is recursive. i think it should be fine for now (and yes, i agree, its not very clean) > Can try it tomorrow. thanks > Since you had written the code and #if 0'ed the locking part, may I ask, > why? Are there any known issues or it was just not very good to > introduce locking at that time (rev. 1.1, 3 years ago)? because i did not want to touch every single keyboard driver, keyboard subsystem and syscons :) back then. since kbdmux is pretty much keyboard driver it was easier to leave it under giant locking. thanks, max From julian at elischer.org Wed Sep 17 18:30:17 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 17 18:30:23 2008 Subject: amd64, COMPAT_IA32 & syscall diverts In-Reply-To: <064901c918e2$803df770$970da8c0@jam.zenon.net> References: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> <48D123DD.2030701@elischer.org> <064901c918e2$803df770$970da8c0@jam.zenon.net> Message-ID: <48D14CB8.5080002@elischer.org> Andrew N. Below wrote: >> Andrew N. Below wrote: >>> Hi all. >>> >>> We have loadable kernel module with >>> several syscall intercepting functions >>> (e.g., sysent[SYS___sysctl].sy_call). >>> Earlier, this module was built and used >>> on i386 platform, now we have to run it >>> on amd64. For some reasons we have to >>> enable COMPAT_IA32 option in kernel. >>> >>> Our syscall wrapper sucessfully receiving >>> syscalls from amd64 binaries, but we have >>> nothing from old i386 binaries. >>> >>> Seems like these calls are made bypassing >>> our kernel module. >> x86 binaries use a separate syscall table, so you need to patch >> both tables. > > Where can I find something about that table? the compat stuff is in /sys/compat/ia32/ So I would start there and follow the logic. > > Nothing interesting in sysent.h/syscall.h... > > -- > Andrew > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From nparhar at gmail.com Wed Sep 17 19:51:04 2008 From: nparhar at gmail.com (Navdeep Parhar) Date: Wed Sep 17 19:51:11 2008 Subject: kgdb's add-kld broken on amd64 In-Reply-To: <200809171131.30819.jhb@freebsd.org> References: <200809171131.30819.jhb@freebsd.org> Message-ID: Hello John, The patch did NOT fix the problem. Read on for more.... On Wed, Sep 17, 2008 at 8:31 AM, John Baldwin wrote: > On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote: >> Hello everyone, >> >> The add-kld command in kgdb does not work as expected on amd64 >> (I'm using a recent HEAD, problem may affect others too). It uses >> the same address for all sections: >> >> (kgdb) add-kld if_cxgb.ko >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> .text_addr = 0xffffffff81022000 >> .rodata_addr = 0xffffffff81022000 >> .rodata.str1.8_addr = 0xffffffff81022000 >> .rodata.str1.1_addr = 0xffffffff81022000 >> set_modmetadata_set_addr = 0xffffffff81022000 >> set_sysctl_set_addr = 0xffffffff81022000 >> set_sysinit_set_addr = 0xffffffff81022000 >> set_sysuninit_set_addr = 0xffffffff81022000 >> .data_addr = 0xffffffff81022000 >> .bss_addr = 0xffffffff81022000 >> (y or n) >> >> This is not correct. The .text section's address is OK but the >> others are not. >> >> The problem seems to be that all amd64 kernel objects have VMA set >> to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c >> uses this VMA to adjust the address of the section: >> >> address = asi->base_addr + bfd_get_section_vma(bfd, sect); >> >> objdump -h shows that the userland objects on amd64 and all >> objects (kernel + userland) on i386 set VMA. It is only the >> kernel objects on amd64 that have VMA = 0. (sample output from >> amd64 and i386 machines appended at the end) >> >> For the time being I've patched kgdb to consider the file offset >> and not the VMA while calculating the section address. It seems >> to work but is probably not the right way to fix the problem. >> >> Any thoughts? > > Hmm, I wonder if this is because on amd64 modules are .o's rather than .so's. > It is. File offset isn't quite right. Instead, the way > sys/kern/link_elf_obj.c works is that it just loads the PROGBITS (text, code, > etc.) and NOBITS (bss) sections in the order they are in the file and > concatenates them. So, the relocation logic in kgdb will need to be updated > to recognize a .o vs .so and apply that algorithm for .o files. > > Actually, what I've done is to replace the home-rolled section relocation > stuff with the gdb primitives that the solib code in gdb uses. It works here > on i386, and hopefully this will fix this as this is how the sharedlibrary > kld stuff is doing the relocations: I had to modify the patch a bit as add-kld -> build_section_table() -> xfree() was a bad free and led to bus errors or segv: - struct section_table *sections, *sections_end, *s; + struct section_table *sections = NULL, *sections_end = NULL, *s; After fixing that, add-kld still wouldn't pick up the correct addresses: (kgdb) add-kld if_cxgb.ko add symbol table from file "/boot/kernel/if_cxgb.ko" at .text_addr = 0xffffffff81022000 .rodata_addr = 0xffffffff81022000 .rodata.str1.8_addr = 0xffffffff81022000 .rodata.str1.1_addr = 0xffffffff81022000 set_modmetadata_set_addr = 0xffffffff81022000 set_sysctl_set_addr = 0xffffffff81022000 set_sysinit_set_addr = 0xffffffff81022000 set_sysuninit_set_addr = 0xffffffff81022000 .data_addr = 0xffffffff81022000 .bss_addr = 0xffffffff81022000 With the patch the section relocation is still taking place based on the VMA (which is 0 for amd64 modules as I pointed out earlier). So the behaviour is no different than before. If I read the code right, each section's addr is calculated as: load_kld -> build_section_table -> add_to_section_table This sets it to bfd_section_vma(abfd, asect), which is no good for amd64 kernel modules. Regards, Navdeep > > --- //depot/vendor/freebsd/src/gnu/usr.bin/gdb/kgdb/kld.c 2008/04/29 20:41:02 > +++ //depot/user/jhb/kgdb/gnu/usr.bin/gdb/kgdb/kld.c 2008/09/17 15:27:25 > @@ -37,6 +37,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -196,39 +197,14 @@ > return (0); > } > > -struct add_section_info { > - struct section_addr_info *section_addrs; > - int sect_index; > - CORE_ADDR base_addr; > -}; > - > -static void > -add_section (bfd *bfd, asection *sect, void *arg) > -{ > - struct add_section_info *asi = arg; > - CORE_ADDR address; > - char *name; > - > - /* Ignore non-resident sections. */ > - if ((bfd_get_section_flags(bfd, sect) & (SEC_ALLOC | SEC_LOAD)) == 0) > - return; > - > - name = xstrdup(bfd_get_section_name(bfd, sect)); > - make_cleanup(xfree, name); > - address = asi->base_addr + bfd_get_section_vma(bfd, sect); > - asi->section_addrs->other[asi->sect_index].name = name; > - asi->section_addrs->other[asi->sect_index].addr = address; > - asi->section_addrs->other[asi->sect_index].sectindex = sect->index; > - printf_unfiltered("\t%s_addr = %s\n", name, local_hex_string(address)); > - asi->sect_index++; > -} > - > static void > load_kld (char *path, CORE_ADDR base_addr, int from_tty) > { > - struct add_section_info asi; > + struct section_addr_info *sap; > + struct section_table *sections, *sections_end, *s; > struct cleanup *cleanup; > bfd *bfd; > + int i; > > /* Open the kld. */ > bfd = bfd_openr(path, gnutarget); > @@ -244,19 +220,30 @@ > if (bfd_get_section_by_name (bfd, ".text") == NULL) > error("\"%s\": can't find text section", path); > > + /* Build a section table from the bfd and relocate the sections. */ > + if (build_section_table (bfd, §ions, §ions_end)) > + error("\"%s\": can't find file sections", path); > + cleanup = make_cleanup(xfree, sections); > + for (s = sections; s < sections_end; s++) { > + s->addr += base_addr; > + s->endaddr += base_addr; > + } > + > + /* Build a section addr info to pass to symbol_file_add(). */ > + sap = build_section_addr_info_from_section_table (sections, > + sections_end); > + cleanup = make_cleanup((make_cleanup_ftype *)free_section_addr_info, > + sap); > + > printf_unfiltered("add symbol table from file \"%s\" at\n", path); > - > - /* Build a section table for symbol_file_add() from the bfd sections. */ > - asi.section_addrs = alloc_section_addr_info(bfd_count_sections(bfd)); > - cleanup = make_cleanup(xfree, asi.section_addrs); > - asi.sect_index = 0; > - asi.base_addr = base_addr; > - bfd_map_over_sections(bfd, add_section, &asi); > + for (i = 0; i < sap->num_sections; i++) > + printf_unfiltered("\t%s_addr = %s\n", sap->other[i].name, > + local_hex_string(sap->other[i].addr)); > > if (from_tty && (!query("%s", ""))) > error("Not confirmed."); > > - symbol_file_add(path, from_tty, asi.section_addrs, 0, OBJF_USERLOADED); > + symbol_file_add(path, from_tty, sap, 0, OBJF_USERLOADED); > > do_cleanups(cleanup); > } > > -- > John Baldwin > From rea-fbsd at codelabs.ru Wed Sep 17 17:53:23 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Sep 17 19:57:25 2008 Subject: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c In-Reply-To: References: <20080917161633.9E2F717101@shadow.codelabs.ru> Message-ID: Maxim, good day. Cc'ing this discuission to hackers@ -- I was just going to write the separate letter on this topic to the list. Wed, Sep 17, 2008 at 09:56:14AM -0700, Maksim Yevmenkin wrote: > have you tried to simply set KBDMUX_LOCK/UNLOCK() to > mtx_lock/unlock(&Giant) ? Since kbdmux callout is initialized as non-MPSAFE, this will result in double locking the Giant (at least I see it from the code). I am not sure that this is very good -- had not yet verified that Giant is recursive. Can try it tomorrow. Since you had written the code and #if 0'ed the locking part, may I ask, why? Are there any known issues or it was just not very good to introduce locking at that time (rev. 1.1, 3 years ago)? Thanks! > On Wed, Sep 17, 2008 at 9:16 AM, Eygene Ryabinkin wrote: > >>Number: 127446 > >>Category: kern > >>Synopsis: [patch] fix race in sys/dev/kbdmux/kbdmux.c > >>Confidential: no > >>Severity: critical > >>Priority: high > >>Responsible: freebsd-bugs > >>State: open > >>Quarter: > >>Keywords: > >>Date-Required: > >>Class: sw-bug > >>Submitter-Id: current-users > >>Arrival-Date: Wed Sep 17 16:20:02 UTC 2008 > >>Closed-Date: > >>Last-Modified: > >>Originator: Eygene Ryabinkin > >>Release: FreeBSD 7.1-PRERELEASE amd64 > >>Organization: > > Code Labs > >>Environment: > > > > System: FreeBSD XXX 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #55: Wed Sep 17 19:57:25 MSD 2008 root@XXX:/usr/src/sys/amd64/compile/XXX amd64 > > > > CVSupped system yesterday late at the evening (aroung 17:00 UTC). > > > >>Description: > > > > Since kbdmux(4) is not MPSAFE now, its interrupt routines are running > > under Giant. But there is kbdmux_read_char() routine that runs unlocked > > and can race with the interrupt handler. When there is no input data > > in the keyboard queue and kbdmux(4) is in the POLLING mode, routine will > > try to poll each mux member for the scancode. And if user presses the > > key at that time, KBDMUX_READ_CHAR() can race with the interrupt handler > > kbdmux_kbd_event() since we don't lock polling loop. > > > >>How-To-Repeat: > > > > I see this on my laptop: sometimes during boot, when system asks me for > > the password of geli(8)-encrypted volume, it doubles the symbols or even > > panics. I don't see this on the other systems, so perhaps my laptop is > > just so lucky ;)) > > > > But one can try to enable echoing of the input symbols during the geli's > > bootup password dialog (setting g_eli_visible_passphrase to 1 > > unconditionally) and maybe symbols will be doubled. I see this issue > > only during boot-up phase, but I feel that this is due to the fact that > > for the rest of the system's operation only interrupt handler is > > working, at least I see it from the debug printf()s. > > > >>Fix: > > > > The following patch fixes the things for me. It just acquires Giant for > > the time of polling. I did a limited testing at my systems and there > > were no signs of regressions yet. > > > > Seems like in the properly locked situation (with non-dummy KBDMUX_LOCK > > and KBDMUX_UNLOCK) this issue will vanish, so I had conditionalized > > Giant grabbing. > > > > --- kbdmux-read-race.patch begins here --- > > --- sys/dev/kbdmux/kbdmux.c.orig 2008-09-17 10:41:00.000000000 +0400 > > +++ sys/dev/kbdmux/kbdmux.c 2008-09-17 19:52:00.000000000 +0400 > > @@ -79,6 +79,10 @@ > > */ > > > > #if 0 /* not yet */ > > +#define KBDMUX_LOCK_POLLER(dummy) > > + > > +#define KBDMUX_UNLOCK_POLLER(dummy) > > + > > #define KBDMUX_LOCK_DECL_GLOBAL \ > > struct mtx ks_lock > > #define KBDMUX_LOCK_INIT(s) \ > > @@ -98,6 +102,10 @@ > > #define KBDMUX_QUEUE_INTR(s) \ > > taskqueue_enqueue(taskqueue_swi_giant, &(s)->ks_task) > > #else > > +#define KBDMUX_LOCK_POLLER(dummy) \ > > + mtx_lock(&Giant) > > +#define KBDMUX_UNLOCK_POLLER(dummy) \ > > + mtx_unlock(&Giant) > > #define KBDMUX_LOCK_DECL_GLOBAL > > > > #define KBDMUX_LOCK_INIT(s) > > @@ -661,6 +669,14 @@ > > if (state->ks_flags & POLLING) { > > kbdmux_kbd_t *k; > > > > + /* > > + * Grab Giant: we don't want to race with > > + * the keyboard interrupt handler. And this > > + * can happen, because when a key will be > > + * pressed, our READ_CHAR will be competing > > + * with the kbdmux_kbd_event()'s one. > > + */ > > + KBDMUX_LOCK_POLLER(); > > SLIST_FOREACH(k, &state->ks_kbds, next) { > > while (KBDMUX_CHECK_CHAR(k->kbd)) { > > scancode = KBDMUX_READ_CHAR(k->kbd, 0); > > @@ -674,6 +690,7 @@ > > putc(scancode, &state->ks_inq); > > } > > } > > + KBDMUX_UNLOCK_POLLER(); > > > > if (state->ks_inq.c_cc > 0) > > goto next_code; > > --- kbdmux-read-race.patch ends here --- -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080917/4b1eb4b8/attachment.pgp From defan at zenon.net Wed Sep 17 20:39:44 2008 From: defan at zenon.net (Andrew N. Below) Date: Wed Sep 17 20:39:51 2008 Subject: amd64, COMPAT_IA32 & syscall diverts In-Reply-To: <48D14CB8.5080002@elischer.org> References: <046601c918cc$786cc8c0$970da8c0@jam.zenon.net> <48D123DD.2030701@elischer.org> <064901c918e2$803df770$970da8c0@jam.zenon.net> <48D14CB8.5080002@elischer.org> Message-ID: On Wed, 17 Sep 2008, Julian Elischer wrote: >>>> Seems like these calls are made bypassing >>>> our kernel module. >>> x86 binaries use a separate syscall table, so you need to patch >>> both tables. >> Where can I find something about that table? > the compat stuff is in /sys/compat/ia32/ > So I would start there and follow the logic. Thanks, extern struct sysent freebsd32_sysent[] is what I need. The final problem I have to solve is to find a way to determine where exactly syscall called from (64bit or compat)... -- Andrew From jhb at freebsd.org Wed Sep 17 21:18:34 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 17 21:18:47 2008 Subject: kgdb's add-kld broken on amd64 In-Reply-To: References: <200809171131.30819.jhb@freebsd.org> Message-ID: <200809171628.52406.jhb@freebsd.org> On Wednesday 17 September 2008 03:51:02 pm Navdeep Parhar wrote: > Hello John, > > The patch did NOT fix the problem. Read on for more.... > > On Wed, Sep 17, 2008 at 8:31 AM, John Baldwin wrote: > > On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote: > >> Hello everyone, > >> > >> The add-kld command in kgdb does not work as expected on amd64 > >> (I'm using a recent HEAD, problem may affect others too). It uses > >> the same address for all sections: > >> > >> (kgdb) add-kld if_cxgb.ko > >> add symbol table from file "/boot/kernel/if_cxgb.ko" at > >> .text_addr = 0xffffffff81022000 > >> .rodata_addr = 0xffffffff81022000 > >> .rodata.str1.8_addr = 0xffffffff81022000 > >> .rodata.str1.1_addr = 0xffffffff81022000 > >> set_modmetadata_set_addr = 0xffffffff81022000 > >> set_sysctl_set_addr = 0xffffffff81022000 > >> set_sysinit_set_addr = 0xffffffff81022000 > >> set_sysuninit_set_addr = 0xffffffff81022000 > >> .data_addr = 0xffffffff81022000 > >> .bss_addr = 0xffffffff81022000 > >> (y or n) > >> > >> This is not correct. The .text section's address is OK but the > >> others are not. > >> > >> The problem seems to be that all amd64 kernel objects have VMA set > >> to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c > >> uses this VMA to adjust the address of the section: > >> > >> address = asi->base_addr + bfd_get_section_vma(bfd, sect); > >> > >> objdump -h shows that the userland objects on amd64 and all > >> objects (kernel + userland) on i386 set VMA. It is only the > >> kernel objects on amd64 that have VMA = 0. (sample output from > >> amd64 and i386 machines appended at the end) > >> > >> For the time being I've patched kgdb to consider the file offset > >> and not the VMA while calculating the section address. It seems > >> to work but is probably not the right way to fix the problem. > >> > >> Any thoughts? > > > > Hmm, I wonder if this is because on amd64 modules are .o's rather than .so's. > > It is. File offset isn't quite right. Instead, the way > > sys/kern/link_elf_obj.c works is that it just loads the PROGBITS (text, code, > > etc.) and NOBITS (bss) sections in the order they are in the file and > > concatenates them. So, the relocation logic in kgdb will need to be updated > > to recognize a .o vs .so and apply that algorithm for .o files. > > > > Actually, what I've done is to replace the home-rolled section relocation > > stuff with the gdb primitives that the solib code in gdb uses. It works here > > on i386, and hopefully this will fix this as this is how the sharedlibrary > > kld stuff is doing the relocations: > > I had to modify the patch a bit as add-kld -> build_section_table() -> xfree() > was a bad free and led to bus errors or segv: > > - struct section_table *sections, *sections_end, *s; > + struct section_table *sections = NULL, *sections_end = NULL, *s; > > After fixing that, add-kld still wouldn't pick up the correct > addresses: > > (kgdb) add-kld if_cxgb.ko > add symbol table from file "/boot/kernel/if_cxgb.ko" at > .text_addr = 0xffffffff81022000 > .rodata_addr = 0xffffffff81022000 > .rodata.str1.8_addr = 0xffffffff81022000 > .rodata.str1.1_addr = 0xffffffff81022000 > set_modmetadata_set_addr = 0xffffffff81022000 > set_sysctl_set_addr = 0xffffffff81022000 > set_sysinit_set_addr = 0xffffffff81022000 > set_sysuninit_set_addr = 0xffffffff81022000 > .data_addr = 0xffffffff81022000 > .bss_addr = 0xffffffff81022000 > > With the patch the section relocation is still taking place based > on the VMA (which is 0 for amd64 modules as I pointed out > earlier). So the behaviour is no different than before. If I > read the code right, each section's addr is calculated as: > > load_kld -> build_section_table -> add_to_section_table > > This sets it to bfd_section_vma(abfd, asect), which is no good > for amd64 kernel modules. Well, this means gdb can't handle loading .o's, though I guess that is to be expected. :( Even if I fix add-kld there's probably no way I can easily fix the sharedlibrary stuff w/o ripping gdb itself up a bunch. -- John Baldwin From thiagojruiz at gmail.com Wed Sep 17 22:55:33 2008 From: thiagojruiz at gmail.com (Thiago J. Ruiz) Date: Wed Sep 17 22:55:42 2008 Subject: Auto Connect After Connection Fails In-Reply-To: <2de331130809170806v9ee6c58t23386fbef6873078@mail.gmail.com> References: <2de331130809170806v9ee6c58t23386fbef6873078@mail.gmail.com> Message-ID: <895f139b0809171529u6ac851fem57d7370baf2569a1@mail.gmail.com> may you could use ifstated, it is a FSM (finit state machine) may could help http://www.openbsd.org/cgi-bin/man.cgi?query=ifstated&sektion=8 cheers 2008/9/17, Andres Chavez : > Hi Hackers, im wondering if its posible somehow to auto reconnect after a > connection fails. This is because from time to time my ISP while renews the > ip address the connection just freezes and i have to manually use dhclient > -u {if} to get the new address or even when there is no ip change by my ISP > i still get this problem sometimes. Any help? > > > > -- > Visit http://www.noixe.net Electronic Music 24/7 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- Thiago J. Ruiz SysAdmin/NetAdmin Cisco CCNA - Loading. http://thiagoruiz.blogspot.com From andymac at bullseye.apana.org.au Thu Sep 18 03:16:24 2008 From: andymac at bullseye.apana.org.au (Andrew MacIntyre) Date: Thu Sep 18 03:16:32 2008 Subject: unexpected behaviour of malloc() on 7.0/amd64 In-Reply-To: <48D13784.2090701@FreeBSD.org> References: <48D12AD4.1000806@bullseye.andymac.org> <48D13784.2090701@FreeBSD.org> Message-ID: <48D1C83A.1010204@bullseye.andymac.org> Jason Evans wrote: > Andrew MacIntyre wrote: >> In investigating a Python 2.6rc1 regression test failure on FreeBSD >> 7.0/amd64, as far as I can tell, malloc() does not return NULL when >> available memory (including swap) is exhausted - the process just gets >> KILLed. >> >> Using ulimit -v to set a virtual memory use limit below the available >> memory does result in malloc() returning NULL when the limit is hit. >> >> The Python regression test concerned does not fail on FreeBSD 7.0/i386, >> however the C program below exhibits the unexpected behaviour on both >> 7.0/amd64 and 7.0/i386. The C program below does behave as >> expected on FreeBSD 6.3/i386; I cannot currently test its behaviour on >> FreeBSD 6.3/amd64. >> >> I can't see this behaviour documented in the malloc() man page. > > From malloc(3): > > === > > IMPLEMENTATION NOTES > Traditionally, allocators have used sbrk(2) to obtain memory, which > is suboptimal for several reasons, including race conditions, increased > fragmentation, and artificial limitations on maximum usable memory. > This allocator uses both sbrk(2) and mmap(2) by default, but it can be > configured at run time to use only one or the other. If resource limits > are not a primary concern, the preferred configuration is > MALLOC_OPTIONS=dM or MALLOC_OPTIONS=DM. When so configured, the > datasize resource limit has little practical effect for typical > applications; use MALLOC_OPTIONS=Dm if that is a concern. Regardless of > allocator configuration, the vmemoryuse resource limit can be used to > bound the total virtual memory used by a process, as described in > limits(1). > > === > > If you want a custom python binary that does not use mmap, you can > define _malloc_options to "d", or just use MALLOC_OPTIONS in the > environment. Thanks for the reply. The malloc(3) man page for 7.0 doesn't include this information, and says sbrk() is only used on i386. From the 7-stable version of the man page, which appears to match your quote above, I infer that these changes will be in 7.1. However my reading of the updated man page suggests that the malloc options string should be "Dm" or "m" to turn off mmap() and only use sbrk() - could you clarify why "d"? Thanks, Andrew. -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From jasone at FreeBSD.org Thu Sep 18 04:32:52 2008 From: jasone at FreeBSD.org (Jason Evans) Date: Thu Sep 18 04:32:58 2008 Subject: unexpected behaviour of malloc() on 7.0/amd64 In-Reply-To: <48D1C83A.1010204@bullseye.andymac.org> References: <48D12AD4.1000806@bullseye.andymac.org> <48D13784.2090701@FreeBSD.org> <48D1C83A.1010204@bullseye.andymac.org> Message-ID: <48D1D9F3.8090807@FreeBSD.org> Andrew MacIntyre wrote: > However my reading of the updated man page suggests that the malloc > options string should be "Dm" or "m" to turn off mmap() and only use > sbrk() - could you clarify why "d"? Whoops, I meant "m", not "d". Jason From rea-fbsd at codelabs.ru Thu Sep 18 07:10:22 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Sep 18 07:10:29 2008 Subject: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c In-Reply-To: References: <20080917161633.9E2F717101@shadow.codelabs.ru> Message-ID: Maksim, good day. Wed, Sep 17, 2008 at 10:52:15AM -0700, Maksim Yevmenkin wrote: > yes, giant is recursive. i think it should be fine for now (and yes, i > agree, its not very clean) OK, I had tried substituting KBDMUX_LOCK/UNLOCK with Giant operations -- it works as expected. I am sligtly concerned with the fact that, for example, kbdmux_kbd_event() will grab Giant for some more time than the initial version that protects only polling loop. Probably it is not a big concern: the call chain from syscons's cngetc() (via cncheckc(), syscons->cn_getc() == sc_cngetc(), sccngetch(), scgetc() and kbd_read_char()) to the kbdmux_read_char() is the only code path that is not protected by Giant, being called from the kernel directly: - user-level code is notified about key presses by syscons that signals tty layer about key press from sckbdevent(); - no other kbdmux routine seem to be called without being Giant-protected (at least, I see no parts that can race with the low-level keyboard events). So the typical overhead of mangling with Giant at KBDMUX_{LOCK,UNLOCK} is only in extra calls to the _mtx_lock_flags/_mtx_unlock_flags. The only extra code that will hold Giant for a longer time is the kernel's interactive input routines, but their performance is user-bounded ;)) There is one interesting question: I assume that clock interrupts are lost when Giant is hold? If so, then holding Giant for some extra time upon system's initialization when kernel waits for user input will enable the system to drop bigger amounts of clock interrupts -- I assume that the code in kbdmux_read_char() that translates the scancode takes the biggest amount of run-time compared to the polling loop. Sure, the overhead will be added just for the typed characters -- when there is no input, overhead is rather small. May be this will not lead to any bad (or visible/measurable) consequences -- can't tell now. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080918/c1219d15/attachment.pgp From rea-fbsd at codelabs.ru Thu Sep 18 09:15:15 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Sep 18 09:15:22 2008 Subject: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c In-Reply-To: References: <20080917161633.9E2F717101@shadow.codelabs.ru> Message-ID: Me again. Thu, Sep 18, 2008 at 11:10:17AM +0400, Eygene Ryabinkin wrote: > OK, I had tried substituting KBDMUX_LOCK/UNLOCK with Giant operations -- > it works as expected. Tried my initial patch on some 7.0-PRERELEASE -- it locks keyboard when geli asks for the password. Had not much time to dig it out, will try to do it as soon as I can. Substituting KBDMUX_LOCK/UNLOCK with Giant locking helps even on this FreeBSD version. More testing needed, may be there are some other issues that aren't revealing themselves... -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080918/6c4238bd/attachment.pgp From christom_12 at yahoo.com Thu Sep 18 13:16:46 2008 From: christom_12 at yahoo.com (christom) Date: Thu Sep 18 13:20:50 2008 Subject: kern/127446: [patch] fix race in sys/dev/kbdmux/kbdmux.c In-Reply-To: References: Message-ID: <19552647.post@talk.nabble.com> hello man, i only need a good hacker that can hack for uk bank log in for me i need that if you can do that for me i will be very grateful....cos have been try to to train to do this work i did not true with it.... Maksim Yevmenkin-2 wrote: > > On 9/17/08, Eygene Ryabinkin wrote: >> Maxim, good day. >> >> Cc'ing this discuission to hackers@ -- I was just going to write >> the separate letter on this topic to the list. >> >> Wed, Sep 17, 2008 at 09:56:14AM -0700, Maksim Yevmenkin wrote: >> > have you tried to simply set KBDMUX_LOCK/UNLOCK() to >> > mtx_lock/unlock(&Giant) ? >> >> Since kbdmux callout is initialized as non-MPSAFE, this will result in >> double locking the Giant (at least I see it from the code). I am not >> sure that this is very good -- had not yet verified that Giant is >> recursive. > > yes, giant is recursive. i think it should be fine for now (and yes, i > agree, its not very clean) > >> Can try it tomorrow. > > thanks > >> Since you had written the code and #if 0'ed the locking part, may I ask, >> why? Are there any known issues or it was just not very good to >> introduce locking at that time (rev. 1.1, 3 years ago)? > > because i did not want to touch every single keyboard driver, keyboard > subsystem and syscons :) back then. since kbdmux is pretty much > keyboard driver it was easier to leave it under giant locking. > > thanks, > max > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > -- View this message in context: http://www.nabble.com/Re%3A-kern-127446%3A--patch--fix-race-in-sys-dev-kbdmux-kbdmux.c-tp19539858p19552647.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From christom_12 at yahoo.com Thu Sep 18 13:16:46 2008 From: christom_12 at yahoo.com (christom) Date: Thu Sep 18 13:20:59 2008 Subject: FreeBSD 7.0-RELEASE amd64 on Dell M600 Blade In-Reply-To: References: Message-ID: <19552398.post@talk.nabble.com> hello man, i only need a good hacker that can hack for uk bank log in for me i need that if you can do that for me i will be very grateful.... Steven Hartland wrote: > > I've been trying to install FreeBSD 7.0-RELEASE amd64 on > a Dell M600 Blade but it hangs just after initialising > the isa bus. > > I've tried a number of things and the only thing that I > can get to work is the i386 build which boots into the > installer without issue. > > Has anyone had any experience with the Dell M600 blade > on amd64 or had the amd64 build hang at this point > before. > > I don't have access to the machines to try new things > with ATM as we needed them in production so was forced > to install ubuntu to get then live but I should get > them back for more testing next week some time so wanted > to see if anyone had any experience with this or a > similar issue? > > Regards > Steve > > ================================================ > This e.mail is private and confidential between Multiplay (UK) Ltd. and > the person or entity to whom it is addressed. In the event of > misdirection, the recipient is prohibited from using, copying, printing or > otherwise disseminating it or any information contained in it. > > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > -- View this message in context: http://www.nabble.com/FreeBSD-7.0-RELEASE-amd64-on-Dell-M600-Blade-tp19382794p19552398.html Sent from the freebsd-hackers mailing list archive at Nabble.com. From stevefranks at ieee.org Thu Sep 18 18:04:32 2008 From: stevefranks at ieee.org (Steve Franks) Date: Thu Sep 18 18:04:38 2008 Subject: proper types for printf()-ing pointers on amd64 that won't break i386? Message-ID: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> Hi, I'm trying to correct some warnings in a port marked ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume is a 64-bit unsigned) to "unsigned int" which is apparently 32 bits? I sort of thought int was supposed to be the atomic register size, but no doubt that would break more than it would help, so it's 32-bits. Anyways, what's the right way to fix this? The port actually works fine as-is on amd64, so I can only assume something was fixed for 7.1, or someone was being extra cautious with the i386 tag. The code: typedef unsigned int cardinal; ... fprintf(stderr, "Mode Table Offset: $C0000 + $%x\n", ((cardinal)map->mode_table) - ((cardinal)map->bios_ptr)); Can I just ditch the cast+%x and use %p? I don't have an i386 system to test on, and I don't want to break anything if I submit a patch... Thanks, Steve From koitsu at FreeBSD.org Thu Sep 18 18:14:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Sep 18 18:15:00 2008 Subject: proper types for printf()-ing pointers on amd64 that won't break i386? In-Reply-To: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> References: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> Message-ID: <20080918181450.GA24440@icarus.home.lan> On Thu, Sep 18, 2008 at 10:41:42AM -0700, Steve Franks wrote: > I'm trying to correct some warnings in a port marked > ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume > is a 64-bit unsigned) to "unsigned int" which is apparently 32 bits? > I sort of thought int was supposed to be the atomic register size, but > no doubt that would break more than it would help, so it's 32-bits. > Anyways, what's the right way to fix this? The port actually works > fine as-is on amd64, so I can only assume something was fixed for 7.1, > or someone was being extra cautious with the i386 tag. > > The code: > > typedef unsigned int cardinal; > ... > fprintf(stderr, "Mode Table Offset: $C0000 + $%x\n", > ((cardinal)map->mode_table) - ((cardinal)map->bios_ptr)); > > Can I just ditch the cast+%x and use %p? I don't have an i386 system > to test on, and I don't want to break anything if I submit a patch... Yes, use %p! It works fine on all platforms. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd-bugs at be-well.ilk.org Thu Sep 18 18:45:45 2008 From: freebsd-bugs at be-well.ilk.org (Lowell Gilbert) Date: Thu Sep 18 18:50:15 2008 Subject: proper types for printf()-ing pointers on amd64 that won't break In-Reply-To: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> (Steve Franks's message of "Thu\, 18 Sep 2008 10\:41\:42 -0700") References: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> Message-ID: <448wtpb98s.fsf@be-well.ilk.org> "Steve Franks" writes: > Hi, > > I'm trying to correct some warnings in a port marked > ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume > is a 64-bit unsigned) to "unsigned int" which is apparently 32 bits? > I sort of thought int was supposed to be the atomic register size, but > no doubt that would break more than it would help, so it's 32-bits. > Anyways, what's the right way to fix this? The port actually works > fine as-is on amd64, so I can only assume something was fixed for 7.1, > or someone was being extra cautious with the i386 tag. > > The code: > > typedef unsigned int cardinal; > ... > fprintf(stderr, "Mode Table Offset: $C0000 + $%x\n", > ((cardinal)map->mode_table) - ((cardinal)map->bios_ptr)); > > Can I just ditch the cast+%x and use %p? I don't have an i386 system > to test on, and I don't want to break anything if I submit a patch... What is actually being printed isn't a pointer, but the difference between two pointers (I assume from your comments; the code included isn't enough to show where they come from). That means the correct type of what's being printed is size_t, which our printf seems to support with a "z" modifier. Removing the explicit casts or (if necessary), replacing them with something that is big enough will also be needed. From jhb at freebsd.org Thu Sep 18 21:37:56 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 18 21:38:03 2008 Subject: proper types for printf()-ing pointers on amd64 that won't break i386? In-Reply-To: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> References: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> Message-ID: <200809181444.26895.jhb@freebsd.org> On Thursday 18 September 2008 01:41:42 pm Steve Franks wrote: > Hi, > > I'm trying to correct some warnings in a port marked > ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume > is a 64-bit unsigned) to "unsigned int" which is apparently 32 bits? > I sort of thought int was supposed to be the atomic register size, but > no doubt that would break more than it would help, so it's 32-bits. > Anyways, what's the right way to fix this? The port actually works > fine as-is on amd64, so I can only assume something was fixed for 7.1, > or someone was being extra cautious with the i386 tag. > > The code: > > typedef unsigned int cardinal; > ... > fprintf(stderr, "Mode Table Offset: $C0000 + $%x\n", > ((cardinal)map->mode_table) - ((cardinal)map->bios_ptr)); > > Can I just ditch the cast+%x and use %p? I don't have an i386 system > to test on, and I don't want to break anything if I submit a patch... If mode_table and bios_ptr are pointers, then their difference is not a pointer, but a ptrdiff_t. You can use %tx to print one of those in hex. Note, however, that subtracting pointers only works if they are of the same type, and it will return different results in this case unless they are char * pointers. Probably better is to do something like this: fprintf(stderr, "Mode Table Offset: $C0000 + $%x\n", (int)((uintptr_t)map->mode_table - (uintptr_t)map->bios_ptr)); Note that %p will include a '0x' prefix for non-NULL pointers which you probably don't want. -- John Baldwin From jhb at freebsd.org Thu Sep 18 21:39:03 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 18 21:39:10 2008 Subject: proper types for printf()-ing pointers on amd64 that won't break In-Reply-To: <448wtpb98s.fsf@be-well.ilk.org> References: <539c60b90809181041n658d2823y89e42bb0ccfa6d06@mail.gmail.com> <448wtpb98s.fsf@be-well.ilk.org> Message-ID: <200809181738.47248.jhb@freebsd.org> On Thursday 18 September 2008 02:26:59 pm Lowell Gilbert wrote: > "Steve Franks" writes: > > > Hi, > > > > I'm trying to correct some warnings in a port marked > > ONLY_FOR_ARCHS=i386. They stem from casting a pointer (which I assume > > is a 64-bit unsigned) to "unsigned int" which is apparently 32 bits? > > I sort of thought int was supposed to be the atomic register size, but > > no doubt that would break more than it would help, so it's 32-bits. > > Anyways, what's the right way to fix this? The port actually works > > fine as-is on amd64, so I can only assume something was fixed for 7.1, > > or someone was being extra cautious with the i386 tag. > > > > The code: > > > > typedef unsigned int cardinal; > > ... > > fprintf(stderr, "Mode Table Offset: $C0000 + $%x\n", > > ((cardinal)map->mode_table) - ((cardinal)map->bios_ptr)); > > > > Can I just ditch the cast+%x and use %p? I don't have an i386 system > > to test on, and I don't want to break anything if I submit a patch... > > What is actually being printed isn't a pointer, but the difference > between two pointers (I assume from your comments; the code included > isn't enough to show where they come from). That means the correct > type of what's being printed is size_t, which our printf seems to > support with a "z" modifier. Removing the explicit casts or (if > necessary), replacing them with something that is big enough will also > be needed. The difference of two pointers is actually a ptrdiff_t rather than a size_t. size_t is what sizeof() returns. -- John Baldwin From stephen at math.missouri.edu Fri Sep 19 13:52:56 2008 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Fri Sep 19 13:53:01 2008 Subject: Calling malloc from a signal handler Message-ID: <48D3AE8D.50304@math.missouri.edu> I notice that if you use "malloc" from within a signal handler on FreeBSD-6.x, that you can potentially trigger a "recursive call" error. But this seems to have changed in FreeBSD-7.x. Is it now permissible to call "malloc" from within a signal handler in FreeBSD-7.x? If so, should the man page of "sigaction(2)" be upgraded to say this? Thanks, Stephen From jasone at FreeBSD.org Fri Sep 19 14:11:07 2008 From: jasone at FreeBSD.org (Jason Evans) Date: Fri Sep 19 14:11:11 2008 Subject: Calling malloc from a signal handler In-Reply-To: <48D3AE8D.50304@math.missouri.edu> References: <48D3AE8D.50304@math.missouri.edu> Message-ID: <48D3B2F9.7020900@FreeBSD.org> Stephen Montgomery-Smith wrote: > I notice that if you use "malloc" from within a signal handler on > FreeBSD-6.x, that you can potentially trigger a "recursive call" error. > > But this seems to have changed in FreeBSD-7.x. The malloc implementation is completely new in FreeBSD 7, so not all of the internal error checking code is the same. > Is it now permissible to call "malloc" from within a signal handler in > FreeBSD-7.x? Calling malloc from within a signal handler can cause application deadlock, so although you won't see an error message printed, you are unlikely to be happy with the results. Jason From joerg at britannica.bec.de Fri Sep 19 14:20:27 2008 From: joerg at britannica.bec.de (Joerg Sonnenberger) Date: Fri Sep 19 14:20:30 2008 Subject: Calling malloc from a signal handler In-Reply-To: <48D3AE8D.50304@math.missouri.edu> References: <48D3AE8D.50304@math.missouri.edu> Message-ID: <20080919140239.GA28134@britannica.bec.de> On Fri, Sep 19, 2008 at 08:52:13AM -0500, Stephen Montgomery-Smith wrote: > Is it now permissible to call "malloc" from within a signal handler in > FreeBSD-7.x? No. Joerg From benjie at addgene.org Fri Sep 19 15:33:28 2008 From: benjie at addgene.org (Benjie Chen) Date: Fri Sep 19 15:47:55 2008 Subject: Interrupts issues Message-ID: Hi FreeBSD hackers: I have two Dell workstations that I recently added FreeBSD 6.2 on. One is a Precision T3400, one is an Inspiron 530. Nothing fancy. Installed FBsd. Everything else is fine except both machines have interrupt storm issues: one core (both dual core) is 100% servicing interrupts. On the Precision, it's irq20 atapci, on Inspiron it's irq19 uhci. The other core is fine and both machines run well otherwise. I saw several recent posts on the net about some of these issues and did not find a resolution. It seems unlikely that it's just a ata or usb issue since both machines happen to have the same problem. Any thoughts? Thanks, Benjie From deischen at freebsd.org Fri Sep 19 16:40:30 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Fri Sep 19 16:40:39 2008 Subject: Calling malloc from a signal handler In-Reply-To: <48D3AE8D.50304@math.missouri.edu> References: <48D3AE8D.50304@math.missouri.edu> Message-ID: On Fri, 19 Sep 2008, Stephen Montgomery-Smith wrote: > I notice that if you use "malloc" from within a signal handler on > FreeBSD-6.x, that you can potentially trigger a "recursive call" error. > > But this seems to have changed in FreeBSD-7.x. > > Is it now permissible to call "malloc" from within a signal handler in > FreeBSD-7.x? > > If so, should the man page of "sigaction(2)" be upgraded to say this? You shouldn't call malloc() or any other function that isn't async-signal-safe from a signal handler. I don't think we should say if it works or not, since it is not portable and could change at any given time in future versions of FreeBSD. -- DE From unixmania at gmail.com Sat Sep 20 02:23:49 2008 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Sat Sep 20 02:23:53 2008 Subject: Interrupts issues In-Reply-To: References: Message-ID: On Fri, Sep 19, 2008 at 12:04 PM, Benjie Chen wrote: > Hi FreeBSD hackers: > > I have two Dell workstations that I recently added FreeBSD 6.2 on. One > is a Precision T3400, one is an Inspiron 530. Nothing fancy. Installed > FBsd. Everything else is fine except both machines have interrupt > storm issues: one core (both dual core) is 100% servicing interrupts. > On the Precision, it's irq20 atapci, on Inspiron it's irq19 uhci. The > other core is fine and both machines run well otherwise. > > I saw several recent posts on the net about some of these issues and > did not find a resolution. It seems unlikely that it's just a ata or > usb issue since both machines happen to have the same problem. > > Any thoughts? Please provide the output of "dmesg" after a boot in verbose mode. This may help the maintainers to understand your problem and give you additional instructions. Do you have any special reason to use FreeBSD 6.2? It is a rather old version, so I'd suggest you to try 7.1 instead. There are prerelease images available. Look at http://www.freebsd.org/where.html -- cd /usr/ports/sysutils/life make clean From volker at vwsoft.com Sat Sep 20 16:29:02 2008 From: volker at vwsoft.com (Volker) Date: Sat Sep 20 16:29:07 2008 Subject: Interrupts issues In-Reply-To: References: Message-ID: <48D51FAF.70603@vwsoft.com> On 12/23/-58 20:59, Carlos A. M. dos Santos wrote: > On Fri, Sep 19, 2008 at 12:04 PM, Benjie Chen wrote: >> Hi FreeBSD hackers: >> >> I have two Dell workstations that I recently added FreeBSD 6.2 on. One >> is a Precision T3400, one is an Inspiron 530. Nothing fancy. Installed >> FBsd. Everything else is fine except both machines have interrupt >> storm issues: one core (both dual core) is 100% servicing interrupts. >> On the Precision, it's irq20 atapci, on Inspiron it's irq19 uhci. The >> other core is fine and both machines run well otherwise. >> >> I saw several recent posts on the net about some of these issues and >> did not find a resolution. It seems unlikely that it's just a ata or >> usb issue since both machines happen to have the same problem. >> >> Any thoughts? > > Please provide the output of "dmesg" after a boot in verbose mode. > This may help the maintainers to understand your problem and give you > additional instructions. > > Do you have any special reason to use FreeBSD 6.2? It is a rather old > version, ... 6.2 has already been EOL'd in May. From remko at FreeBSD.org Sun Sep 21 07:57:46 2008 From: remko at FreeBSD.org (Remko Lodder) Date: Sun Sep 21 07:57:50 2008 Subject: Interrupts issues In-Reply-To: <48D51FAF.70603@vwsoft.com> References: <48D51FAF.70603@vwsoft.com> Message-ID: <48D5F518.4040904@FreeBSD.org> Volker wrote: > On 12/23/-58 20:59, Carlos A. M. dos Santos wrote: >> On Fri, Sep 19, 2008 at 12:04 PM, Benjie Chen wrote: >>> Hi FreeBSD hackers: >>> >>> I have two Dell workstations that I recently added FreeBSD 6.2 on. One >>> is a Precision T3400, one is an Inspiron 530. Nothing fancy. Installed >>> FBsd. Everything else is fine except both machines have interrupt >>> storm issues: one core (both dual core) is 100% servicing interrupts. >>> On the Precision, it's irq20 atapci, on Inspiron it's irq19 uhci. The >>> other core is fine and both machines run well otherwise. >>> >>> I saw several recent posts on the net about some of these issues and >>> did not find a resolution. It seems unlikely that it's just a ata or >>> usb issue since both machines happen to have the same problem. >>> >>> Any thoughts? >> Please provide the output of "dmesg" after a boot in verbose mode. >> This may help the maintainers to understand your problem and give you >> additional instructions. >> >> Do you have any special reason to use FreeBSD 6.2? It is a rather old >> version, ... > > 6.2 has already been EOL'd in May. > _______________________________________________ I need to join the club, my machine starts doing interrupt storms after an uptime of ${random} on the IRQ19 (atapci0) thingy. Next time I'll boot the machine I'll try to make it a verbose boot. It's a production machine which cannot restart on demand ofcourse :) Note: First the problems occured much more, this was because the usb interfaces on the machine co-existed with the atapci0 interface, after disabling usb on the system, it took a lot longer to trigger the interrupt storm (50 days if I recall correctly). Cheers remko Regular dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #7: Thu Sep 18 09:53:16 CEST 2008 root@xxxxx.elvandar.org:/usr/obj/usr/src/sys/xxxxx Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2799.99-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 2103840768 (2006 MB) avail memory = 2028867584 (1934 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7df00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xfc000000-0xfdffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.2 (no driver attached) pcib2: at device 7.0 on pci0 pci2: on pcib2 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff irq 19 at device 0.0 on pci2 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:b1:a3:2f re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] pci0: at device 19.0 (no driver attached) pci0: at device 19.1 (no driver attached) pci0: at device 19.2 (no driver attached) pci0: at device 19.3 (no driver attached) pci0: at device 19.4 (no driver attached) pci0: at device 19.5 (no driver attached) pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 acpi_button0: on acpi0 sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 3 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: CLK_VAL field overlaps THT_EN bit device_attach: acpi_throttle0 attach returned 6 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xcd800-0xce7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 6 ZFS storage pool version 6 ad4: 381554MB at ata2-master SATA300 ad6: 381554MB at ata3-master SATA300 SMP: AP CPU #1 Launched! Trying to mount root from zfs:tank/root -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From piso at FreeBSD.org Sun Sep 21 12:15:57 2008 From: piso at FreeBSD.org (Paolo Pisati) Date: Sun Sep 21 12:16:04 2008 Subject: smbus & i2c: why i2c is not enabled on ich? Message-ID: <20080921115545.GA61452@tin.it> Any reason why i2c mode in not enable in ichsmb? ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x82d81043 chip=0x266a8086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB (ICH6) SMBus Controller' class = serial bus subclass = SMBus piso@nano:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 01 piso@nano:~/eeebsd >sudo ./scan_smbus res: 0 slave = 0x44 data = res: 0 slave = 0x50 data = res: 0 slave = 0x69 data = res: 0 slave = 0xC4 data = res: 0 slave = 0xD0 data = res: 0 slave = 0xE9 data = piso@nano:~/eeebsd >sudo pciconf -wb pci0:0:31:3: 0x40 5 piso@nano:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 05 piso@nano:~/eeebsd >sudo ./scan_smbus res: 0 slave = 0x44 data = FF FF FF FF res: 0 slave = 0x50 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 res: 0 slave = 0x69 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 res: 0 slave = 0xC4 data = FF FF FF FF res: 0 slave = 0xD0 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 res: 0 slave = 0xE9 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 FYI this is on an asus eeepc. -- bye, P. From nox at jelal.kn-bremen.de Sun Sep 21 13:55:08 2008 From: nox at jelal.kn-bremen.de (Juergen Lock) Date: Sun Sep 21 13:59:43 2008 Subject: kgdb's add-kld broken on amd64 In-Reply-To: <200809171628.52406.jhb@freebsd.org> References: <200809171131.30819.jhb@freebsd.org> Message-ID: <200809211326.m8LDQq16065877@saturn.kn-bremen.de> In article <200809171628.52406.jhb@freebsd.org> you write: >On Wednesday 17 September 2008 03:51:02 pm Navdeep Parhar wrote: >> Hello John, >> >> The patch did NOT fix the problem. Read on for more.... >> >> On Wed, Sep 17, 2008 at 8:31 AM, John Baldwin wrote: >> > On Tuesday 16 September 2008 04:07:46 pm Navdeep Parhar wrote: >> >> Hello everyone, >> >> >> >> The add-kld command in kgdb does not work as expected on amd64 >> >> (I'm using a recent HEAD, problem may affect others too). It uses >> >> the same address for all sections: >> >> >> >> (kgdb) add-kld if_cxgb.ko >> >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> >> .text_addr = 0xffffffff81022000 >> >> .rodata_addr = 0xffffffff81022000 >> >> .rodata.str1.8_addr = 0xffffffff81022000 >> >> .rodata.str1.1_addr = 0xffffffff81022000 >> >> set_modmetadata_set_addr = 0xffffffff81022000 >> >> set_sysctl_set_addr = 0xffffffff81022000 >> >> set_sysinit_set_addr = 0xffffffff81022000 >> >> set_sysuninit_set_addr = 0xffffffff81022000 >> >> .data_addr = 0xffffffff81022000 >> >> .bss_addr = 0xffffffff81022000 >> >> (y or n) >> >> >> >> This is not correct. The .text section's address is OK but the >> >> others are not. >> >> >> >> The problem seems to be that all amd64 kernel objects have VMA set >> >> to 0 for all sections. add_section() in gnu/usr.bin/gdb/kgdb/kld.c >> >> uses this VMA to adjust the address of the section: >> >> >> >> address = asi->base_addr + bfd_get_section_vma(bfd, sect); >> >> >> >> objdump -h shows that the userland objects on amd64 and all >> >> objects (kernel + userland) on i386 set VMA. It is only the >> >> kernel objects on amd64 that have VMA = 0. (sample output from >> >> amd64 and i386 machines appended at the end) >> >> >> >> For the time being I've patched kgdb to consider the file offset >> >> and not the VMA while calculating the section address. It seems >> >> to work but is probably not the right way to fix the problem. >> >> >> >> Any thoughts? >> > >> > Hmm, I wonder if this is because on amd64 modules are .o's rather >than .so's. >> > It is. File offset isn't quite right. Instead, the way >> > sys/kern/link_elf_obj.c works is that it just loads the PROGBITS (text, >code, >> > etc.) and NOBITS (bss) sections in the order they are in the file and >> > concatenates them. So, the relocation logic in kgdb will need to be >updated >> > to recognize a .o vs .so and apply that algorithm for .o files. >> > >> > Actually, what I've done is to replace the home-rolled section relocation >> > stuff with the gdb primitives that the solib code in gdb uses. It works >here >> > on i386, and hopefully this will fix this as this is how the sharedlibrary >> > kld stuff is doing the relocations: >> >> I had to modify the patch a bit as add-kld -> build_section_table() -> >xfree() >> was a bad free and led to bus errors or segv: >> >> - struct section_table *sections, *sections_end, *s; >> + struct section_table *sections = NULL, *sections_end = NULL, *s; >> >> After fixing that, add-kld still wouldn't pick up the correct >> addresses: >> >> (kgdb) add-kld if_cxgb.ko >> add symbol table from file "/boot/kernel/if_cxgb.ko" at >> .text_addr = 0xffffffff81022000 >> .rodata_addr = 0xffffffff81022000 >> .rodata.str1.8_addr = 0xffffffff81022000 >> .rodata.str1.1_addr = 0xffffffff81022000 >> set_modmetadata_set_addr = 0xffffffff81022000 >> set_sysctl_set_addr = 0xffffffff81022000 >> set_sysinit_set_addr = 0xffffffff81022000 >> set_sysuninit_set_addr = 0xffffffff81022000 >> .data_addr = 0xffffffff81022000 >> .bss_addr = 0xffffffff81022000 >> >> With the patch the section relocation is still taking place based >> on the VMA (which is 0 for amd64 modules as I pointed out >> earlier). So the behaviour is no different than before. If I >> read the code right, each section's addr is calculated as: >> >> load_kld -> build_section_table -> add_to_section_table >> >> This sets it to bfd_section_vma(abfd, asect), which is no good >> for amd64 kernel modules. > >Well, this means gdb can't handle loading .o's, though I guess that is to be >expected. :( Even if I fix add-kld there's probably no way I can easily fix >the sharedlibrary stuff w/o ripping gdb itself up a bunch. I haven't looked at what the gdb patch exactly does, but I was able to load klds the old way on amd64 using a patched asf(8) as posted here: http://lists.freebsd.org/pipermail/freebsd-amd64/2008-May/011062.html Better than nothing I guess... :) Juergen From ticso at cicely7.cicely.de Sun Sep 21 20:51:49 2008 From: ticso at cicely7.cicely.de (Bernd Walter) Date: Sun Sep 21 20:51:52 2008 Subject: smbus & i2c: why i2c is not enabled on ich? In-Reply-To: <20080921115545.GA61452@tin.it> References: <20080921115545.GA61452@tin.it> Message-ID: <20080921205137.GM93308@cicely7.cicely.de> On Sun, Sep 21, 2008 at 01:55:45PM +0200, Paolo Pisati wrote: > > Any reason why i2c mode in not enable in ichsmb? Because the controller is a SMB controller and not a I2C one. SMB is more specific than I2C in that it defines complete I2C sequences. With SMB you don't have the individual control over all I2C phases. You can do SMB with an I2C controller, but you can't do raw I2C with an SMB controller. Use SMB to address your devices - SMB is good enough to handle most I2C cases. > ichsmb0@pci0:0:31:3: class=0x0c0500 card=0x82d81043 chip=0x266a8086 rev=0x04 hdr=0x00 > vendor = 'Intel Corporation' > device = '82801FB (ICH6) SMBus Controller' > class = serial bus > subclass = SMBus > > piso@nano:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 > 01 > piso@nano:~/eeebsd >sudo ./scan_smbus > res: 0 slave = 0x44 data = > res: 0 slave = 0x50 data = > res: 0 slave = 0x69 data = > res: 0 slave = 0xC4 data = > res: 0 slave = 0xD0 data = > res: 0 slave = 0xE9 data = > piso@nano:~/eeebsd >sudo pciconf -wb pci0:0:31:3: 0x40 5 > piso@nano:~/eeebsd >sudo pciconf -rb pci0:0:31:3: 0x40 > 05 > piso@nano:~/eeebsd >sudo ./scan_smbus > res: 0 slave = 0x44 data = FF FF FF FF > res: 0 slave = 0x50 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 > res: 0 slave = 0x69 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 > res: 0 slave = 0xC4 data = FF FF FF FF > res: 0 slave = 0xD0 data = 0A 60 40 00 05 30 45 00 82 08 00 00 0C 04 > res: 0 slave = 0xE9 data = FF F7 00 00 01 0F 07 E0 18 46 1B 24 D8 63 00 > > FYI this is on an asus eeepc. > -- > bye, > P. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From christophe.cap at gdnmail.net Mon Sep 22 12:40:49 2008 From: christophe.cap at gdnmail.net (Christophe Cap) Date: Mon Sep 22 12:40:52 2008 Subject: VirtualBox looks for FreeBSD developer Message-ID: <20080922050941.88CAFE41@resin17.mta.everyone.net> Hey, I stumbled upon this cry for help from Sun : [1]http://groups.google.com/group/mailing.freebsd.ports/browse_thread/ thread/5d525a3d040e0a0e?pli=1 Is anybody looking into this ? ciao! Christophe --- Truly great madness cannot be achieved without significant intelligence. --- _________________________________________________________________ GameDev.net Email Service - "Plenty of 1's and 0's" References 1. http://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/5d525a3d040e0a0e?pli=1 From max at love2party.net Mon Sep 22 20:33:28 2008 From: max at love2party.net (Max Laier) Date: Mon Sep 22 20:33:37 2008 Subject: cosum: Checkout verification PoC Message-ID: <200809222233.26053.max@love2party.net> Hi, the attached script will generate md5 and sha256 checksums of a checkout and try to find the corresponding svn-revision. This can help to verify that your checkout from cvsupX.yy.freebsd.org is authentic. Not that there is reason to believe that we have compromised cvsup-servers. This is just something I've been toying with and wanted to let you know to see if people find the idea interesting. I'd also be interested in reviews of the concept (note that I know that https would be a good idea, I just cba to setup a certificate). The coverage currently is head and stable/{6,7} svn revision 179451:183186 (i.e. since the first svn commit up to "2008-09-19 16:51:41 +0200". I don't yet have a cronjob in place to generate new checksums, so this will become less useful quick. If people do find it interesting, however, I could certainly roll something. As you can see, the script is ready to checksum cvs and svn checkouts. If you obtain your checkout from some local git/hg/svk/... mirror you must modify the find excludes accordingly. Let me know what you think. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News -------------- next part -------------- #!/bin/sh BASEURL="http://laiers.net/cosum/data/md5" tempfoo=`basename $0` TMPFILE=`mktemp -t ${tempfoo}` || exit 1 MD5SUM=`find -s . -type f -not -path "*/.svn/*" -not -path "*/CVS/*" \ -exec cat {} + | md5` SHA256SUM=`find -s . -type f -not -path "*/.svn/*" -not -path "*/CVS/*" \ -exec cat {} + | sha256` MD5DIR=`echo ${MD5SUM} | cut -c 1-2` if ! fetch -o ${TMPFILE} ${BASEURL}/${MD5DIR}/${MD5SUM} ; then echo "No corresponding md5sum found, try again in a bit" >&2 exit 1 fi ORIG_MD5SUM=`cat ${TMPFILE} | grep ^md5 | cut -d":" -f 2` ORIG_SHA256SUM=`cat ${TMPFILE} | grep ^sha256 | cut -d":" -f 2` if [ "${MD5SUM}" != "${ORIG_MD5SUM}" ]; then echo "md5 mismatch - something went terribly wrong!" >&2 exit 1 fi if [ "${SHA256SUM}" != "${ORIG_SHA256SUM}" ]; then echo "sha256 mismatch, but same md5 - please report this!" >&2 cat ${TMPFILE} exit 1 fi echo "Your checkout seems to be:" cat ${TMPFILE} From fabien.thomas at netasq.com Tue Sep 23 12:37:01 2008 From: fabien.thomas at netasq.com (Fabien Thomas) Date: Tue Sep 23 12:44:52 2008 Subject: Announcement: PmcTools callchain capture for RELENG_7 In-Reply-To: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> References: <84dead720807122205i33bf6eb0p998d473df9e52304@mail.gmail.com> Message-ID: <02117AD8-A70C-4B2A-9EA1-56A4847D845F@netasq.com> Hello, A new patch is available that was done just after dtrace backport. You can find it like the previous one on the pmc wiki. It also include some new bugfix from head. Fabien Le 13 juil. 08 ? 07:05, Joseph Koshy a ?crit : > Hello List(s), > > I am very pleased to announce a patch, by Fabien Thomas, that brings > PmcTools' callchain capture features to 7-STABLE. Thank you, Fabien! > > The patch is linked to from the PmcTools wiki page: > http://wiki.freebsd.org/PmcTools. > > The current file name is: "patch-callchain-FreeBSD-7- > STABLE-2008-07-12.gz". > As the file name indicates, it should apply against a 7-STABLE tree of > 2008-07-12 > vintage. > > To apply the patch: > % cd /home/src-7x # or whereever your RELENG_7 tree resides > % patch < PATCH-FILE > > Then you should follow the full procedure to update userland > and kernel from source as spelled out in src/UPDATING. > > Please note that HWPMC(4) log files that contain callchain > information are > not binary compatible with prior versions of pmc(3) and pmcstat(8). > > Please do test on your systems and let Fabien and me know > how you fared. > > Koshy > From rea-fbsd at codelabs.ru Tue Sep 23 13:50:45 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Sep 23 13:50:48 2008 Subject: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages Message-ID: Good day. A while ago I had created the new utility that serves as VuXML filter for the installed packages: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853 My primary intention was to speed up the process of auditing the vulnerable ports: I needed to run portaudit checks with Nagios and to avoid large timeouts. The new utility is called pkg_audit and it serves as a simple text filter: on input it takes the full VuXML feed and on output it puts VuXML entries that matches ports that are installed in the system with port version specification substituted with the actual port versions. No harm is done to the actual poartudit -- if pkg_audit is missing, old code path is activated. If someone is interested and will be able to test -- I am all ears. Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080923/e9a4aa93/attachment.pgp From freebsd-hackers at wheelhouse.org Tue Sep 23 16:06:51 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Tue Sep 23 16:06:54 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 Message-ID: Got the following panic overnight: panic: lockmgr: thread 0xffffff0053cda680, not exclusive lock holder 0xffffff002d7da680 unlocking cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a _lockmgr() at _lockmgr+0x872 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 null_unlock() at null_unlock+0xff VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 nullfs_mount() at nullfs_mount+0x244 vfs_donmount() at vfs_donmount+0xe4d nmount() at nmount+0xa5 syscall() at syscall+0x254 Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = 0x7fffffffdfb8, rbp = 0x7fffffffdfc0 --- I've done some searches and "not exclusive lock holder" has been seen before, but I didn't find any previous reports related to nullfs with a stack trace at all like this on FreeBSD 7. This machine is diskless and thus cannot store a kernel dump. Ideas/ suggestions for fixes, causes or debugging steps? The kernel is amd64, with config shown below. Thanks, Jeff include GENERIC device carp device pf device pflog device pfsync options SW_WATCHDOG options DEVICE_POLLING options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_PRIQ options ALTQ_NOPCC options KDB options KDB_UNATTENDED options KDB_TRACE options DDB options BREAK_TO_DEBUGGER From alec-keyword-freebsd.org.a6e2e4 at SetFilePointer.com Wed Sep 24 02:22:39 2008 From: alec-keyword-freebsd.org.a6e2e4 at SetFilePointer.com (Alec Kloss) Date: Wed Sep 24 02:22:41 2008 Subject: Patch for working AMD Geode CS5530 audio driver on HEAD In-Reply-To: <20080809193233.GC19885@rink.nu> References: <20080803161057.GB35301@rink.nu> <20080809193233.GC19885@rink.nu> Message-ID: <20080924015556.GN23927@hamlet.SetFilePointer.com> On 2008-08-09 21:32, Rink Springer wrote: > Hi Ivan, > > On Sat, Aug 09, 2008 at 07:36:07PM +0200, Ivan Voras wrote: > > This patch looks like it needs something. Can you post or link to the > > entire driver please? > > Sure - this was already outlined in the original thread, but have a look > at http://63.249.85.132/gx_audio/index.html - the driver there works. > You need minor tweaks to the Makefile, these can be found in > http://setfilepointer.com/pub/geode/ns_geode.diff. > > Regards, I just got around to playing with this again, to no avail: **** geode Probe devid 20821022 classid 00000010! **** geode Probe devid 20931022 classid 00000004! pcm0: port 0xfe00-0xfe7f irq 11 at device 15.3 on pci0 **** geode Attach! ---> Geode mem regs at fe01 **** AUDIO PCI HDR *** -->Vendor ID =1022 -->Dev ID =2093 -->PCI cmd =5 -->PCI status =2a0 -->Dev revision =1 -->PCI class =ffffffff -->PCI latency =0 -->PCI header type =0 -->BIST =0 --> Register Base address =fe01 pcm0: calling bus_alloc_resource pcm0: failed to enable memory mapping! pcm0: unable to map BAR reg device_attach: pcm0 attach returned 6 Anyone got any ideas? Remote access is available upon request. -- Alec Kloss alec@SetFilePointer.com IM: angryspamhater@yahoo.com PGP key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA241980E "No Bunny!" -- Simon, http://wiki.adultswim.com/xwiki/bin/Frisky+Dingo/Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080924/4bf7987b/attachment.pgp From freebsd-hackers at wheelhouse.org Wed Sep 24 04:53:03 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 04:53:06 2008 Subject: Major SMP problems with lstat/namei Message-ID: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> We have encountered some serious SMP performance/scalability problems that we've tracked back to lstat/namei calls. I've written a quick benchmark with a pair of tests to simplify/measure the problem. Both tests use a tree of directories: the top level directory contains five subdirectories a, b, c, d, and e. Each subdirectory contains five subdirectories a, b, c, d, and e, and so on.. 1 directory at level one, 5 at level two, 25 at level three, 125 at level four, 625 at level five, and 3125 at level six. In the "realpath" test, a random path is constructed at the bottom of the tree (e.g. /tmp/lstat/a/b/c/d/e) and realpath() is called on that, provoking lstat() calls on the whole tree. This is to simulate a mix of high-contention and low-contention lstat() calls. In the "lstat" test, lstat is called directly on a path at the bottom of the tree. Since there are 3125 files, this simulates relatively low-contention lstat() calls. In both cases, the test repeats as many times as possible for 60 seconds. Each test is run simultaneously by multiple processes, with progressively doubling concurrency from 1 to 512. What I found was that everything is fine at concurrency 2, probably indicating that the benchmark pegged on some other resource limit. At concurrency 4, realpath drops to 31.8% of concurrency 1. At concurrency 8, performance is down to 18.3%. In the interim, CPU load goes to 80-90% system CPU. I've confirmed via ktrace and the rusage that the CPU usage is all system time, and that lstat() is the *only* system call in the test (realpath() is called with an absolute path). I then reran the 32-process test on 1-7 cores, and found that performance peaks at 2 cores and drops sharply from there. eight cores runs *fifteen* times slower than two cores. The test full results are at the bottom of this message. This is on 6.3-RELEASE-p4 with vfs.lookup_shared=1. I believe this is the same issue that was previously discussed as "2 x quad-core system is slower that 2 x dual core on FreeBSD" archived here: http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038441.html In that post, Kris Kennaway wrote: > It is hard to say for certain without a direct profile comparison of the > workload, but it is probably due to lockmgr contention. lockmgr is used > for various locking operations to do with VFS data structures. It is > known to have poor performance and scale very badly." At this point, what I've got is one of those synthetic benchmarks, but it matches our production problems exactly, except that the production processes need a whole lot more RAM and eventually when this manifests, they backlog and the server death spirals through swap, which is a most unfortunate difference. I've chased my way up the kernel source to kern_lstat(), where a shared lock is obtained, and then onto namei, where vfs.lookup_shared comes into play. But unfortunately, I don't understand lockmgr, I don't know how the macros and flags I see here relate to it, I can't figure out what happened to the changes that Attilio Rao was working on, and there didn't seem to be much other hope at the time. This is becoming a huge problem for us. Is there anything that at all can be done, or any news? In the case linked above, improvement was made by changing a PHP setting that isn't applicable in our case. Thanks, Jeff Concurrency 1 realpath Total = 1409069 (100%) Total/Sec = 23484 Total/Sec/Worker = 23484 lstat Total = 6828763 (100%) Total/Sec = 113812 Total/Sec/Worker = 113812 Concurrency 2 realpath Total = 1450489 (100%) Total/Sec = 24174 Total/Sec/Worker = 12087 lstat Total = 6891417 (100.9%) Total/Sec = 114856 Total/Sec/Worker = 57428 Concurrency 4 realpath Total = 448693 (31.8%) Total/Sec = 7478 Total/Sec/Worker = 1869 lstat Total = 3047933 (44.6%) Total/Sec = 50798 Total/Sec/Worker = 12699 Concurrency 8 realpath Total = 258281 (18.3%) Total/Sec = 4304 Total/Sec/Worker = 538 lstat Total = 1688728 (24.7%) Total/Sec = 28145 Total/Sec/Worker = 3518 Concurrency 16 realpath Total = 179150 (12.7%) Total/Sec = 2985 Total/Sec/Worker = 186 lstat Total = 966558 (14.1%) Total/Sec = 16109 Total/Sec/Worker = 1006 Concurrency 32 realpath Total = 116982 (8.3%) Total/Sec = 1949 Total/Sec/Worker = 60 lstat Total = 644703 (9.4%) Total/Sec = 10745 Total/Sec/Worker = 335 Concurrency 64 realpath Total = 112050 (7.9%) Total/Sec = 1867 Total/Sec/Worker = 29 lstat Total = 572798 (8.3%) Total/Sec = 9546 Total/Sec/Worker = 149 Concurrency 128 realpath Total = 111544 (7.9%) Total/Sec = 1859 Total/Sec/Worker = 14 lstat Total = 570800 (8.3%) Total/Sec = 9513 Total/Sec/Worker = 74 Concurrency 256 realpath Total = 96461 (6.8%) Total/Sec = 1607 Total/Sec/Worker = 6 lstat Total = 580679 (8.5%) Total/Sec = 9677 Total/Sec/Worker = 37 Concurrency 512 realpath Total = 91224 (6.4%) Total/Sec = 1520 Total/Sec/Worker = 2 lstat Total = 498342 (7.2%) Total/Sec = 8305 Total/Sec/Worker = 16 realpath Concurrency 32 - 1 Core Total = 1289527 Total/Sec = 21492 Total/Sec/Worker = 671 realpath Concurrency 32 - 2 Core Total = 1753625 Total/Sec = 29227 Total/Sec/Worker = 913 realpath Concurrency 32 - 3 Core Total = 1197896 Total/Sec = 19964 Total/Sec/Worker = 623 realpath Concurrency 32 - 4 Core Total = 631293 Total/Sec = 10521 Total/Sec/Worker = 328 realpath Concurrency 32 - 5 Core Total = 227814 Total/Sec = 3796 Total/Sec/Worker = 118 realpath Concurrency 32 - 6 Core Total = 153550 Total/Sec = 2559 Total/Sec/Worker = 79 realpath Concurrency 32 - 7 Core Total = 136013 Total/Sec = 2266 Total/Sec/Worker = 70 From ivoras at freebsd.org Wed Sep 24 10:12:26 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Sep 24 10:12:29 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: Jeff Wheelhouse wrote: > This is on 6.3-RELEASE-p4 with vfs.lookup_shared=1. > > I believe this is the same issue that was previously discussed as "2 x > quad-core system is slower that 2 x dual core on FreeBSD" archived here: > > http://lists.freebsd.org/pipermail/freebsd-stable/2007-November/038441.html > This is becoming a huge problem for us. Is there anything that at all > can be done, or any news? In the case linked above, improvement was > made by changing a PHP setting that isn't applicable in our case. There is nothing that can be done within the 6.x branch. 7.x contains many improvements but I think only 8.x will directly change the lockmgr and the namei cache. The best things you can try right now is to use 7-STABLE (or soon to be released 7.1; you might need tuning with 7.0-RELEASE) or try 8-CURRENT (it's quite stable). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080924/c5b2e7f5/signature.pgp From ivoras at freebsd.org Wed Sep 24 10:23:41 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Sep 24 10:23:43 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: Ivan Voras wrote: > There is nothing that can be done within the 6.x branch. 7.x contains > many improvements but I think only 8.x will directly change the lockmgr > and the namei cache. The best things you can try right now is to use > 7-STABLE (or soon to be released 7.1; you might need tuning with > 7.0-RELEASE) or try 8-CURRENT (it's quite stable). I remembered two more things: * The problematic load can also be generated with benchmarks/blogbench * I don't have the numbers here but I think I remember that ZFS had noticably larger score than UFS in this workload. Of course, ZFS has other problems. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080924/319dbc8f/signature.pgp From danger at rulez.sk Wed Sep 24 07:46:47 2008 From: danger at rulez.sk (Daniel Gerzo) Date: Wed Sep 24 11:30:12 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: <5654e5239c4c2cda3aaa56bb7e1acd30@services.rulez.sk> Hello Jeff, On Wed, 24 Sep 2008 00:52:59 -0400, Jeff Wheelhouse wrote: > > We have encountered some serious SMP performance/scalability problems > that we've tracked back to lstat/namei calls. I've written a quick this all seems like a reason of very poor performance of PHP when used with open_basedir and safe_mode enabled. It would be nice to see if there's something what could be done to make it better. -- S pozdravom / Best regards Daniel Ger?o From koitsu at FreeBSD.org Wed Sep 24 11:40:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Sep 24 11:40:42 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <5654e5239c4c2cda3aaa56bb7e1acd30@services.rulez.sk> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <5654e5239c4c2cda3aaa56bb7e1acd30@services.rulez.sk> Message-ID: <20080924114038.GA81573@icarus.home.lan> On Wed, Sep 24, 2008 at 09:26:55AM +0200, Daniel Gerzo wrote: > Hello Jeff, > > On Wed, 24 Sep 2008 00:52:59 -0400, Jeff Wheelhouse > wrote: > > > > We have encountered some serious SMP performance/scalability problems > > that we've tracked back to lstat/namei calls. I've written a quick > > this all seems like a reason of very poor performance of PHP when used with > open_basedir and safe_mode enabled. It would be nice to see if there's > something what could be done to make it better. Both of which are features which will, thankfully, be removed in PHP 6. Whoever uses these features in PHP deserves the pain -- they're worthless and provide no security what-so-ever. Consider using suPHP or an MPM like mpm-itk. Also, PHP and performance shouldn't be put in the same sentence. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd-hackers at wheelhouse.org Wed Sep 24 16:17:59 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 16:18:02 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: References: Message-ID: We got the same panic again, this time after switching to the ULE scheduler: panic: lockmgr: thread 0xffffff0050858350, not exclusive lock holder 0xffffff00074959f0 unlocking cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a _lockmgr() at _lockmgr+0x872 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 null_unlock() at null_unlock+0xff VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 nullfs_mount() at nullfs_mount+0x244 vfs_donmount() at vfs_donmount+0xe4d nmount() at nmount+0xa5 syscall() at syscall+0x254 Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = 0x7fffffffdfc8, rbp = 0x7fffffffdfd0 --- Thanks, Jeff On Sep 23, 2008, at 11:51 AM, Jeff Wheelhouse wrote: > > Got the following panic overnight: > > panic: lockmgr: thread 0xffffff0053cda680, not exclusive lock holder > 0xffffff002d7da680 unlocking > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x17a > _lockmgr() at _lockmgr+0x872 > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > null_unlock() at null_unlock+0xff > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > nullfs_mount() at nullfs_mount+0x244 > vfs_donmount() at vfs_donmount+0xe4d > nmount() at nmount+0xa5 > syscall() at syscall+0x254 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = > 0x7fffffffdfb8, rbp = 0x7fffffffdfc0 --- > > I've done some searches and "not exclusive lock holder" has been > seen before, but I didn't find any previous reports related to > nullfs with a stack trace at all like this on FreeBSD 7. > > This machine is diskless and thus cannot store a kernel dump. Ideas/ > suggestions for fixes, causes or debugging steps? > > The kernel is amd64, with config shown below. > > Thanks, > Jeff > > include GENERIC > > device carp > device pf > device pflog > device pfsync > > options SW_WATCHDOG > options DEVICE_POLLING > > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > options ALTQ_NOPCC > > options KDB > options KDB_UNATTENDED > options KDB_TRACE > options DDB > options BREAK_TO_DEBUGGER > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org > " From jdw at wheelhouse.org Wed Sep 24 16:41:51 2008 From: jdw at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 16:51:23 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: On Sep 24, 2008, at 6:12 AM, Ivan Voras wrote: > There is nothing that can be done within the 6.x branch. 7.x contains > many improvements but I think only 8.x will directly change the > lockmgr > and the namei cache. The best things you can try right now is to use > 7-STABLE (or soon to be released 7.1; you might need tuning with > 7.0-RELEASE) or try 8-CURRENT (it's quite stable). Really? Nothing? We get lockmgr-related panics on FreeBSD 7.0, as detailed elsewhere on this list. Stability issues aside, what else would we need to tune on 7.0, besides enabling the ULE scheduler, and how much benefit would we really get? These servers are in production, so 8-CURRENT is not an option. I've already had my knuckles rapped by a customer for trying 7.1-PRERELEASE on one of their machines. Thanks, Jeff From jhb at freebsd.org Wed Sep 24 16:54:57 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 24 16:55:05 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: <200809241212.09920.jhb@freebsd.org> On Wednesday 24 September 2008 12:52:59 am Jeff Wheelhouse wrote: > > We have encountered some serious SMP performance/scalability problems > that we've tracked back to lstat/namei calls. I've written a quick > benchmark with a pair of tests to simplify/measure the problem. Both > tests use a tree of directories: the top level directory contains five > subdirectories a, b, c, d, and e. Each subdirectory contains five > subdirectories a, b, c, d, and e, and so on.. 1 directory at level > one, 5 at level two, 25 at level three, 125 at level four, 625 at > level five, and 3125 at level six. > > In the "realpath" test, a random path is constructed at the bottom of > the tree (e.g. /tmp/lstat/a/b/c/d/e) and realpath() is called on that, > provoking lstat() calls on the whole tree. This is to simulate a mix > of high-contention and low-contention lstat() calls. > > In the "lstat" test, lstat is called directly on a path at the bottom > of the tree. Since there are 3125 files, this simulates relatively > low-contention lstat() calls. > > In both cases, the test repeats as many times as possible for 60 > seconds. Each test is run simultaneously by multiple processes, with > progressively doubling concurrency from 1 to 512. > > What I found was that everything is fine at concurrency 2, probably > indicating that the benchmark pegged on some other resource limit. At > concurrency 4, realpath drops to 31.8% of concurrency 1. At > concurrency 8, performance is down to 18.3%. In the interim, CPU load > goes to 80-90% system CPU. I've confirmed via ktrace and the rusage > that the CPU usage is all system time, and that lstat() is the *only* > system call in the test (realpath() is called with an absolute path). > > I then reran the 32-process test on 1-7 cores, and found that > performance peaks at 2 cores and drops sharply from there. eight > cores runs *fifteen* times slower than two cores. > > The test full results are at the bottom of this message. > > This is on 6.3-RELEASE-p4 with vfs.lookup_shared=1. Shared lookups only work on the NFS client in 6.x. I'm about to turn them on for UFS in HEAD (8.x) and will backport the needed fixes to 7.x after 7.1 (too risky to merge to 7.x this close to a release). So lookup_shared=1 isn't going to really help on 6.x unless you are doing it all over NFS. You also want to backport my fix to cache_enter() before using lookup_shared at all: jhb 2008-08-23 15:13:39 UTC FreeBSD src repository Modified files: sys/kern vfs_cache.c Log: SVN rev 182061 on 2008-08-23 15:13:39Z by jhb Fix a race condition with concurrent LOOKUP namecache operations for a vnode not in the namecache when shared lookups are enabled (vfs.lookup_shared=1, it is currently off by default) and the filesystem supports shared lookups (e.g. NFS client). Specifically, if multiple concurrent LOOKUPs both miss in the name cache in parallel, each of the lookups may each end up adding an entry to the namecache resulting in duplicate entries in the namecache for the same pathname. A subsequent removal of the mapping of that pathname to that vnode (via remove or rename) would only evict one of the entries from the name cache. As a result, subseqent lookups for that pathname would still return the old vnode. This race was observed with shared lookups over NFS where a file was updated by writing a new file out to a temporary file name and then renaming that temporary file to the "real" file to effect atomic updates of a file. Other processes on the same client that were periodically reading the file would occasionally receive an ESTALE error from open(2) because the VOP_GETATTR() in nfs_open() would receive that error when given the stale vnode. The fix here is to check for duplicates in cache_enter() and just return if an entry for this same directory and leaf file name for this vnode is already in the cache. The check for duplicates is done by walking the per-vnode list of name cache entries. It is expected that this list should be very small in the common case (usually 0 or 1 entries during a cache_enter() since most files only have 1 "leaf" name). Reviewed by: ups, scottl MFC after: 2 months Revision Changes Path 1.124 +33 -9 src/sys/kern/vfs_cache.c If you want to try the UFS stuff on 7, you would need to probably backport at least the following, maybe more: jeff 2008-04-11 09:44:25 UTC FreeBSD src repository Modified files: sys/ufs/ufs ufs_lookup.c Log: - cache dp->i_offset in the local 'i_offset' variable for use in loop indexes so directory lookup becomes shared lock safe. In the modifying cases an exclusive lock is held here so the commit routine may rely on the state of i_offset. - Similarly handle i_diroff by fetching at the start and setting only once the operation is complete. Without the exclusive lock these are only considered hints. - Assert that an exclusive lock is held when we're preparing for a commit routine. - Honor the lock type request from lookup instead of always using exclusive locking. Tested by: pho, kris Revision Changes Path 1.87 +48 -29 src/sys/ufs/ufs/ufs_lookup.c jeff 2008-04-22 12:34:16 UTC FreeBSD src repository Modified files: sys/ufs/ufs inode.h ufs_lookup.c Log: - Use a local variable for i_ino in ufs_lookup. It is only used to communicate between two parts of this one function. This was causing problems with shared lookups as each would trash the ino value in the inode. - Remove the unused i_ino field from the inode structure. Revision Changes Path 1.53 +0 -1 src/sys/ufs/ufs/inode.h 1.88 +10 -13 src/sys/ufs/ufs/ufs_lookup.c jhb 2008-07-30 21:07:56 UTC FreeBSD src repository Modified files: sys/ufs/ufs ufs_lookup.c Log: SVN rev 181018 on 2008-07-30 21:07:56Z by jhb Whitespace tweak. Revision Changes Path 1.90 +0 -1 src/sys/ufs/ufs/ufs_lookup.c jhb 2008-09-16 16:18:36 UTC FreeBSD src repository Modified files: sys/ufs/ufs ufs_lookup.c Log: SVN rev 183079 on 2008-09-16 16:18:36Z by jhb - Only set i_offset in the parent directory's i-node during a lookup for non-LOOKUP operations. - Relax a VOP assertion for a DELETE lookup. rename() uses WANTPARENT instead of LOCKPARENT when looking up the source pathname. ufs_rename() uses a relookup() to lock the parent directory when it decides to finally remove the source path. Thus, it is ok for a DELETE with WANTPARENT set instead of LOCKPARENT to use a shared vnode lock rather than an exclusive vnode lock. Reported by: kris (2) Reviewed by: jeff Revision Changes Path 1.91 +9 -3 src/sys/ufs/ufs/ufs_lookup.c jhb 2008-09-16 19:06:44 UTC FreeBSD src repository Modified files: sys/ufs/ufs inode.h ufs_lookup.c Log: SVN rev 183093 on 2008-09-16 19:06:44Z by jhb Retire the 'i_reclen' field from the in-memory i-node. Previously, during a DELETE lookup operation, lookup would cache the length of the directory entry to be deleted in 'i_reclen'. Later, the actual VOP to remove the directory entry (ufs_remove, ufs_rename, etc.) would call ufs_dirremove() which extended the length of the previous directory entry to "remove" the deleted entry. However, we always read the entire block containing the directory entry when doing the removal, so we always have the directory entry to be deleted in-memory when doing the update to the directory block. Also, we already have to figure out where the directory entry that is being removed is in the block so that we can pass the component name to the dirhash code to update the dirhash. So, instead of passing 'i_reclen' from ufs_lookup() to the ufs_dirremove() routine, just read the 'd_reclen' field directly out of the entry being removed when updating the length of the previous entry in the block. This avoids a cosmetic issue of writing to 'i_reclen' while holding a shared vnode lock. It also slightly reduces the amount of side-band data passed from ufs_lookup() to operations updating a directory via the directory's i-node. Reviewed by: jeff Revision Changes Path 1.54 +0 -1 src/sys/ufs/ufs/inode.h 1.92 +9 -6 src/sys/ufs/ufs/ufs_lookup.c jeff 2008-04-11 09:48:12 UTC FreeBSD src repository Modified files: sys/ufs/ufs dirhash.h ufs_dirhash.c Log: - Use a lockmgr lock rather than a mtx to protect dirhash. This lock may be held for the duration of the various dirhash operations which avoids many complex unlock/lock/revalidate sequences. - Permit shared locks on lookup. To protect the ip->i_dirhash pointer we use the vnode interlock in the shared case. Callers holding the exclusive vnode lock can run without fear of concurrent modification to i_dirhash. - Hold an exclusive dirhash lock when creating the dirhash structure for the first time or when re-creating a dirhash structure which has been recycled. Tested by: kris, pho Revision Changes Path 1.6 +2 -1 src/sys/ufs/ufs/dirhash.h 1.24 +289 -227 src/sys/ufs/ufs/ufs_dirhash.c jhb 2008-09-16 16:23:56 UTC FreeBSD src repository Modified files: sys/ufs/ufs dirhash.h ufs_dirhash.c Log: SVN rev 183080 on 2008-09-16 16:23:56Z by jhb Fix a race with shared lookups on UFS. If the the dirhash code reached the cap on memory usage, then shared LOOKUP operations could start free'ing dirhash structures. Without these fixes, concurrent free's on the same directory could result in one of the threads blocked on a lock in a dirhash structure free'd by the other thread. - Replace the lockmgr lock in the dirhash structure with an sx lock. - Use a reference count managed with ufsdirhash_hold()/drop() to determine when to free the dirhash structures. The directory i-node holds a reference while the dirhash is attached to an i-node. Code that wishes to lock the dirhash while holding a shared vnode lock must first acquire a private reference to the dirhash while holding the vnode interlock before acquiring the dirhash sx lock. After acquiring the sx lock, it drops the private reference after checking to see if the dirhash is still used by the directory i-node. Revision Changes Path 1.7 +5 -1 src/sys/ufs/ufs/dirhash.h 1.25 +82 -33 src/sys/ufs/ufs/ufs_dirhash.c jhb 2008-09-22 20:53:22 UTC FreeBSD src repository Modified files: sys/ufs/ufs ufs_dirhash.c Log: SVN rev 183280 on 2008-09-22 20:53:22Z by jhb Close a race between concurrent calls to ufsdirhash_recycle() and ufsdirhash_free() introduced in my last commit by removing the dirhash about to be free'd in ufsdirhash_free() from the global dirhash list before dropping the sx lock. Tested by: kris Revision Changes Path 1.26 +10 -5 src/sys/ufs/ufs/ufs_dirhash.c There are additional fixes needed to fix races with umount -f, so if you backport all this stuff, don't use umount -f or you risk panics. :) Also, you will need to set the flag in the mount flags to enable shared lookups in the mount VOP in ffs_vfsops.c: --- //depot/projects/smpng/sys/ufs/ffs/ffs_vfsops.c 2008/08/25 16:33:41 +++ //depot/user/jhb/lock/ufs/ffs/ffs_vfsops.c 2008/08/29 15:04:03 @@ -852,7 +852,7 @@ * Initialize filesystem stat information in mount struct. */ MNT_ILOCK(mp); - mp->mnt_kern_flag |= MNTK_MPSAFE; + mp->mnt_kern_flag |= MNTK_MPSAFE | MNTK_LOOKUP_SHARED; MNT_IUNLOCK(mp); #ifdef UFS_EXTATTR #ifdef UFS_EXTATTR_AUTOSTART For 6.x you could in theory backport all of this as well, but there may be other fixes needed as well for 6.x. I'm only planning on merging this stuff back to 7.x myself. -- John Baldwin From jhb at freebsd.org Wed Sep 24 16:55:02 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 24 16:55:06 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: References: Message-ID: <200809241234.55075.jhb@freebsd.org> On Wednesday 24 September 2008 12:17:56 pm Jeff Wheelhouse wrote: > > We got the same panic again, this time after switching to the ULE > scheduler: > > panic: lockmgr: thread 0xffffff0050858350, not exclusive lock holder > 0xffffff00074959f0 unlocking > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x17a > _lockmgr() at _lockmgr+0x872 > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > null_unlock() at null_unlock+0xff > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > nullfs_mount() at nullfs_mount+0x244 > vfs_donmount() at vfs_donmount+0xe4d > nmount() at nmount+0xa5 > syscall() at syscall+0x254 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = > 0x7fffffffdfc8, rbp = 0x7fffffffdfd0 --- Can you use gdb or the like to get the souce file/line for the nullfs_mount+0x244 frame? i.e. 'gdb /boot/kernel/kernel' (gdb) l *nullfs_mount+0x244 -- John Baldwin From freebsd-hackers at wheelhouse.org Wed Sep 24 17:35:47 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 17:35:55 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <200809241234.55075.jhb@freebsd.org> References: <200809241234.55075.jhb@freebsd.org> Message-ID: On Sep 24, 2008, at 12:34 PM, John Baldwin wrote: > On Wednesday 24 September 2008 12:17:56 pm Jeff Wheelhouse wrote: >> nullfs_mount() at nullfs_mount+0x244 >> > Can you use gdb or the like to get the souce file/line for the > nullfs_mount+0x244 frame? > > i.e. 'gdb /boot/kernel/kernel' > > (gdb) l *nullfs_mount+0x244 The running kernel did not have -g so I added it to the same config and rebuilt. I will slip in a reboot ASAP and post more info after the next panic. Thanks for taking a look! Thanks, Jeff From freebsd-hackers at wheelhouse.org Wed Sep 24 17:47:35 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 17:47:38 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <200809241212.09920.jhb@freebsd.org> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <200809241212.09920.jhb@freebsd.org> Message-ID: On Sep 24, 2008, at 12:12 PM, John Baldwin wrote: > Shared lookups only work on the NFS client in 6.x. I'm about to > turn them on > for UFS in HEAD (8.x) and will backport the needed fixes to 7.x > after 7.1 > (too risky to merge to 7.x this close to a release). Testers available, when you get to that. :-) > So lookup_shared=1 > isn't going to really help on 6.x unless you are doing it all over > NFS. You > also want to backport my fix to cache_enter() before using > lookup_shared at > all: Since it sounds like 6.x is a dead end, we'll focus on 7.x, provided we can get it to be stable for us. Having never used svn, I do need to figure out how to pull the specific patches you referenced, but I'm sure that's not an unclimbable mountain. :-) I appreciate your insight on this, it's very helpful. Thanks, Jeff From jhb at freebsd.org Wed Sep 24 18:11:25 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 24 18:11:30 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <200809241212.09920.jhb@freebsd.org> Message-ID: <200809241410.23238.jhb@freebsd.org> On Wednesday 24 September 2008 01:47:32 pm Jeff Wheelhouse wrote: > > On Sep 24, 2008, at 12:12 PM, John Baldwin wrote: > > Shared lookups only work on the NFS client in 6.x. I'm about to > > turn them on > > for UFS in HEAD (8.x) and will backport the needed fixes to 7.x > > after 7.1 > > (too risky to merge to 7.x this close to a release). > > Testers available, when you get to that. :-) > > > So lookup_shared=1 > > isn't going to really help on 6.x unless you are doing it all over > > NFS. You > > also want to backport my fix to cache_enter() before using > > lookup_shared at > > all: > > Since it sounds like 6.x is a dead end, we'll focus on 7.x, provided > we can get it to be stable for us. Yes. > Having never used svn, I do need to figure out how to pull the > specific patches you referenced, but I'm sure that's not an > unclimbable mountain. :-) You can still use cvs to pull the revisions. All those e-mail msg's have the CVS revisions in them, too. -- John Baldwin From jhb at freebsd.org Wed Sep 24 18:11:31 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 24 18:11:34 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: References: <200809241234.55075.jhb@freebsd.org> Message-ID: <200809241410.59492.jhb@freebsd.org> On Wednesday 24 September 2008 01:35:44 pm Jeff Wheelhouse wrote: > On Sep 24, 2008, at 12:34 PM, John Baldwin wrote: > > On Wednesday 24 September 2008 12:17:56 pm Jeff Wheelhouse wrote: > >> nullfs_mount() at nullfs_mount+0x244 > >> > > Can you use gdb or the like to get the souce file/line for the > > nullfs_mount+0x244 frame? > > > > i.e. 'gdb /boot/kernel/kernel' > > > > (gdb) l *nullfs_mount+0x244 > > The running kernel did not have -g so I added it to the same config > and rebuilt. I will slip in a reboot ASAP and post more info after > the next panic. > > Thanks for taking a look! If possible, get a crashdump. -- John Baldwin From freebsd-hackers at wheelhouse.org Wed Sep 24 18:16:03 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 18:16:05 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <200809241410.59492.jhb@freebsd.org> References: <200809241234.55075.jhb@freebsd.org> <200809241410.59492.jhb@freebsd.org> Message-ID: <121FE098-4426-4C8E-B003-37BB12B0684F@wheelhouse.org> On Sep 24, 2008, at 2:10 PM, John Baldwin wrote: > If possible, get a crashdump. gmirror. :( Thanks, Jeff From freebsd-hackers at wheelhouse.org Wed Sep 24 18:21:42 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Wed Sep 24 18:21:44 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <200809241410.23238.jhb@freebsd.org> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <200809241212.09920.jhb@freebsd.org> <200809241410.23238.jhb@freebsd.org> Message-ID: On Sep 24, 2008, at 2:10 PM, John Baldwin wrote: > You can still use cvs to pull the revisions. All those e-mail msg's > have the > CVS revisions in them, too. If I'm ever to do anything that will benefit someone besides myself, it's worth my making the effort to learn SVN. We have coasted on the back of FreeBSD without giving back for long enough. Thanks, Jeff From jhb at freebsd.org Wed Sep 24 18:50:08 2008 From: jhb at freebsd.org (John Baldwin) Date: Wed Sep 24 18:50:34 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <121FE098-4426-4C8E-B003-37BB12B0684F@wheelhouse.org> References: <200809241410.59492.jhb@freebsd.org> <121FE098-4426-4C8E-B003-37BB12B0684F@wheelhouse.org> Message-ID: <200809241434.53043.jhb@freebsd.org> On Wednesday 24 September 2008 02:15:59 pm Jeff Wheelhouse wrote: > > On Sep 24, 2008, at 2:10 PM, John Baldwin wrote: > > If possible, get a crashdump. > > gmirror. :( Gah. Make pjd@ fix crashdumps on that. :P -- John Baldwin From julian at elischer.org Wed Sep 24 20:25:54 2008 From: julian at elischer.org (Julian Elischer) Date: Wed Sep 24 20:25:56 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: <48DAA252.2050406@elischer.org> Jeff Wheelhouse wrote: > > On Sep 24, 2008, at 6:12 AM, Ivan Voras wrote: >> There is nothing that can be done within the 6.x branch. 7.x contains >> many improvements but I think only 8.x will directly change the lockmgr >> and the namei cache. The best things you can try right now is to use >> 7-STABLE (or soon to be released 7.1; you might need tuning with >> 7.0-RELEASE) or try 8-CURRENT (it's quite stable). > > Really? Nothing? > > We get lockmgr-related panics on FreeBSD 7.0, as detailed elsewhere on > this list. > > Stability issues aside, what else would we need to tune on 7.0, besides > enabling the ULE scheduler, and how much benefit would we really get? > > These servers are in production, so 8-CURRENT is not an option. I've > already had my knuckles rapped by a customer for trying 7.1-PRERELEASE > on one of their machines. You are supposed to edit the uname info back to 7.0 before installing experimental 7.1 systems! Didn't you get the memo? > > Thanks, > Jeff > > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From freebsd-hackers at wheelhouse.org Thu Sep 25 05:34:10 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Thu Sep 25 05:34:18 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <200809241234.55075.jhb@freebsd.org> References: <200809241234.55075.jhb@freebsd.org> Message-ID: <57DCDBC7-8542-4082-8893-5B96DA92DA9A@wheelhouse.org> On Sep 24, 2008, at 12:34 PM, John Baldwin wrote: > On Wednesday 24 September 2008 12:17:56 pm Jeff Wheelhouse wrote: >> panic: lockmgr: thread 0xffffff0050858350, not exclusive lock holder >> 0xffffff00074959f0 unlocking >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> panic() at panic+0x17a >> _lockmgr() at _lockmgr+0x872 >> VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 >> null_unlock() at null_unlock+0xff >> VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 >> nullfs_mount() at nullfs_mount+0x244 >> vfs_donmount() at vfs_donmount+0xe4d >> nmount() at nmount+0xa5 >> syscall() at syscall+0x254 >> Xfast_syscall() at Xfast_syscall+0xab >> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = >> 0x7fffffffdfc8, rbp = 0x7fffffffdfd0 --- > > Can you use gdb or the like to get the souce file/line for the > nullfs_mount+0x244 frame? Got it again, this time with the full debug kernel, and I'm getting the same weird results from gdb, so I'll go ahead and post it: panic: lockmgr: thread 0xffffff0003e499f0, not exclusive lock holder 0xffffff000a5e16a0 unlocking cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x17a _lockmgr() at _lockmgr+0x872 VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 null_unlock() at null_unlock+0xff VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 nullfs_mount() at nullfs_mount+0x244 vfs_donmount() at vfs_donmount+0xe4d nmount() at nmount+0xa5 syscall() at syscall+0x254 Xfast_syscall() at Xfast_syscall+0xab --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = 0x7fffffffe1c8, rbp = 0x7fffffffe1d0 --- $ gdb /boot/kernel/nullfs.ko 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"... (gdb) l *nullfs_mount+0x244 0x9c4 is in nullfs_mount (namei.h:163). 158 struct thread *td) 159 { 160 ndp->ni_cnd.cn_nameiop = op; 161 ndp->ni_cnd.cn_flags = flags; 162 ndp->ni_segflg = segflg; 163 ndp->ni_dirp = namep; 164 ndp->ni_cnd.cn_thread = td; 165 } 166 167 #define NDF_NO_DVP_RELE 0x00000001 (gdb) (That's NDINIT(), but line 163 doesn't look like it belongs in the middle of a call stack. There's a VOP_UNLOCK a few lines above NDINIT() in mount_nullfs(), and another one some ways farther on in the function.) The good news is we took this particular machine out of production and came up with a synthetic test based on our in-house code that can probably reliably reproduce this within a few minutes. As you might expect, the test involves hammering the same nullfs mount point with mounts and umounts from multiple processes without any external synchronization. Thanks, Jeff From jhb at freebsd.org Thu Sep 25 13:30:02 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 25 13:30:24 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <57DCDBC7-8542-4082-8893-5B96DA92DA9A@wheelhouse.org> References: <200809241234.55075.jhb@freebsd.org> <57DCDBC7-8542-4082-8893-5B96DA92DA9A@wheelhouse.org> Message-ID: <200809250845.06042.jhb@freebsd.org> On Thursday 25 September 2008 01:34:06 am Jeff Wheelhouse wrote: > > On Sep 24, 2008, at 12:34 PM, John Baldwin wrote: > > > On Wednesday 24 September 2008 12:17:56 pm Jeff Wheelhouse wrote: > >> panic: lockmgr: thread 0xffffff0050858350, not exclusive lock holder > >> 0xffffff00074959f0 unlocking > >> cpuid = 0 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > >> panic() at panic+0x17a > >> _lockmgr() at _lockmgr+0x872 > >> VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > >> null_unlock() at null_unlock+0xff > >> VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > >> nullfs_mount() at nullfs_mount+0x244 > >> vfs_donmount() at vfs_donmount+0xe4d > >> nmount() at nmount+0xa5 > >> syscall() at syscall+0x254 > >> Xfast_syscall() at Xfast_syscall+0xab > >> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = > >> 0x7fffffffdfc8, rbp = 0x7fffffffdfd0 --- > > > > Can you use gdb or the like to get the souce file/line for the > > nullfs_mount+0x244 frame? > > Got it again, this time with the full debug kernel, and I'm getting > the same weird results from gdb, so I'll go ahead and post it: > > panic: lockmgr: thread 0xffffff0003e499f0, not exclusive lock holder > 0xffffff000a5e16a0 unlocking > cpuid = 0 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x17a > _lockmgr() at _lockmgr+0x872 > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > null_unlock() at null_unlock+0xff > VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x46 > nullfs_mount() at nullfs_mount+0x244 > vfs_donmount() at vfs_donmount+0xe4d > nmount() at nmount+0xa5 > syscall() at syscall+0x254 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x206845ac, rsp = > 0x7fffffffe1c8, rbp = 0x7fffffffe1d0 --- > > $ gdb /boot/kernel/nullfs.ko > 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"... > (gdb) l *nullfs_mount+0x244 > 0x9c4 is in nullfs_mount (namei.h:163). > 158 struct thread *td) > 159 { > 160 ndp->ni_cnd.cn_nameiop = op; > 161 ndp->ni_cnd.cn_flags = flags; > 162 ndp->ni_segflg = segflg; > 163 ndp->ni_dirp = namep; > 164 ndp->ni_cnd.cn_thread = td; > 165 } > 166 > 167 #define NDF_NO_DVP_RELE 0x00000001 > (gdb) > > (That's NDINIT(), but line 163 doesn't look like it belongs in the > middle of a call stack. There's a VOP_UNLOCK a few lines above > NDINIT() in mount_nullfs(), and another one some ways farther on in > the function.) It's probably the one just before the NDINIT (note that the return address in the call stack is pointing to the next instruction to be executed after the call to VOP_UNLOCK(), so sometimes it can end up referring to the next line in the source code from the actual function call): if ((mp->mnt_vnodecovered->v_op == &null_vnodeops) && VOP_ISLOCKED(mp->mnt_vnodecovered)) { VOP_UNLOCK(mp->mnt_vnodecovered, 0); isvnunlocked = 1; } /* * Find lower node */ NDINIT(ndp, LOOKUP, FOLLOW|LOCKLEAF, UIO_SYSSPACE, target, td); error = namei(ndp); Can you 'p *mp'? I'm curious if mp->mnt_vnodecovered is NULL (in which case, why didn't the two tests in the if() fail?) > The good news is we took this particular machine out of production and > came up with a synthetic test based on our in-house code that can > probably reliably reproduce this within a few minutes. As you might > expect, the test involves hammering the same nullfs mount point with > mounts and umounts from multiple processes without any external > synchronization. Ok. Reproducibility is good. :) -- John Baldwin From des at des.no Thu Sep 25 14:51:41 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Sep 25 14:51:48 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> (Jeff Wheelhouse's message of "Wed, 24 Sep 2008 00:52:59 -0400") References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> Message-ID: <86ljxgs2h0.fsf@ds4.des.no> Jeff Wheelhouse writes: > I've written a quick benchmark with a pair of tests to > simplify/measure the problem. [...] Care to share? DES -- Dag-Erling Sm?rgrav - des@des.no From nparhar at gmail.com Thu Sep 25 18:02:10 2008 From: nparhar at gmail.com (Navdeep Parhar) Date: Thu Sep 25 18:02:17 2008 Subject: kgdb's add-kld broken on amd64 In-Reply-To: <200809171628.52406.jhb@freebsd.org> References: <200809171131.30819.jhb@freebsd.org> <200809171628.52406.jhb@freebsd.org> Message-ID: > Well, this means gdb can't handle loading .o's, though I guess that is to be > expected. :( Even if I fix add-kld there's probably no way I can easily fix > the sharedlibrary stuff w/o ripping gdb itself up a bunch. > > -- > John Baldwin > I thought I'd leave this patch here on the list in case anyone finds it helpful. This patch works both when "add-kld ..." is explicitly called, and when kgdb autodetects KLDs and reads in their symbols automatically. The changes to kld.c are from what John B. posted in this thread earlier. The additional changes to exec.c mimic what the kernel does in link_elf_obj.c for amd64 modules. I used "info files" to verify that the segment reloc info was correct. Regards, Navdeep diff -r 3292f0cda869 contrib/gdb/gdb/exec.c --- a/contrib/gdb/gdb/exec.c Wed Sep 24 17:32:58 2008 -0700 +++ b/contrib/gdb/gdb/exec.c Wed Sep 24 19:54:31 2008 -0700 @@ -348,6 +348,18 @@ (*table_pp)->bfd = abfd; (*table_pp)->the_bfd_section = asect; (*table_pp)->addr = bfd_section_vma (abfd, asect); + if ((*table_pp)->addr == 0 && asect->index > 0) { + /* + * KLDs on amd64 go down this code path. Adjust the addr as is done in + * kern/link_elf_obj.c. We need the previous section's endaddr in order + * to do that. + */ + struct section_table *p = (*table_pp) - 1; + + (*table_pp)->addr = align_power(p->endaddr, + bfd_section_alignment(abfd, asect)); + } + (*table_pp)->endaddr = (*table_pp)->addr + bfd_section_size (abfd, asect); (*table_pp)++; } diff -r 3292f0cda869 gnu/usr.bin/gdb/kgdb/kld.c --- a/gnu/usr.bin/gdb/kgdb/kld.c Wed Sep 24 17:32:58 2008 -0700 +++ b/gnu/usr.bin/gdb/kgdb/kld.c Wed Sep 24 19:54:31 2008 -0700 @@ -37,6 +37,7 @@ #include #include #include +#include #include #include #include @@ -196,39 +197,14 @@ return (0); } -struct add_section_info { - struct section_addr_info *section_addrs; - int sect_index; - CORE_ADDR base_addr; -}; - -static void -add_section (bfd *bfd, asection *sect, void *arg) -{ - struct add_section_info *asi = arg; - CORE_ADDR address; - char *name; - - /* Ignore non-resident sections. */ - if ((bfd_get_section_flags(bfd, sect) & (SEC_ALLOC | SEC_LOAD)) == 0) - return; - - name = xstrdup(bfd_get_section_name(bfd, sect)); - make_cleanup(xfree, name); - address = asi->base_addr + bfd_get_section_vma(bfd, sect); - asi->section_addrs->other[asi->sect_index].name = name; - asi->section_addrs->other[asi->sect_index].addr = address; - asi->section_addrs->other[asi->sect_index].sectindex = sect->index; - printf_unfiltered("\t%s_addr = %s\n", name, local_hex_string(address)); - asi->sect_index++; -} - static void load_kld (char *path, CORE_ADDR base_addr, int from_tty) { - struct add_section_info asi; struct cleanup *cleanup; + struct section_addr_info *sap; + struct section_table *sections = NULL, *sections_end = NULL, *s; bfd *bfd; + int i; /* Open the kld. */ bfd = bfd_openr(path, gnutarget); @@ -244,19 +220,30 @@ if (bfd_get_section_by_name (bfd, ".text") == NULL) error("\"%s\": can't find text section", path); + /* Build a section table from the bfd and relocate the sections. */ + if (build_section_table(bfd, §ions, §ions_end)) + error("\"%s\": can't find file sections", path); + cleanup = make_cleanup(xfree, sections); + for (s = sections; s < sections_end; s++) { + s->addr += base_addr; + s->endaddr += base_addr; + } + + /* Build a section addr info to pass to symbol_file_add(). */ + sap = build_section_addr_info_from_section_table (sections, + sections_end); + cleanup = make_cleanup((make_cleanup_ftype *)free_section_addr_info, + sap); + printf_unfiltered("add symbol table from file \"%s\" at\n", path); - - /* Build a section table for symbol_file_add() from the bfd sections. */ - asi.section_addrs = alloc_section_addr_info(bfd_count_sections(bfd)); - cleanup = make_cleanup(xfree, asi.section_addrs); - asi.sect_index = 0; - asi.base_addr = base_addr; - bfd_map_over_sections(bfd, add_section, &asi); + for (i = 0; i < sap->num_sections; i++) + printf_unfiltered("\t%s_addr = %s\n", sap->other[i].name, + local_hex_string(sap->other[i].addr)); if (from_tty && (!query("%s", ""))) error("Not confirmed."); - symbol_file_add(path, from_tty, asi.section_addrs, 0, OBJF_USERLOADED); + symbol_file_add(path, from_tty, sap, 0, OBJF_USERLOADED); do_cleanups(cleanup); } From freebsd-hackers at wheelhouse.org Thu Sep 25 18:02:30 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Thu Sep 25 18:02:36 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <86ljxgs2h0.fsf@ds4.des.no> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <86ljxgs2h0.fsf@ds4.des.no> Message-ID: <05B718C6-BBC9-4B78-B580-4E250199DDCF@wheelhouse.org> On Sep 25, 2008, at 10:51 AM, Dag-Erling Sm?rgrav wrote: > Jeff Wheelhouse writes: >> I've written a quick benchmark with a pair of tests to >> simplify/measure the problem. [...] > > Care to share? No problem: http://software.wheelhouse.org/rptest.tar.bz2 Thanks, Jeff From freebsd-hackers at wheelhouse.org Thu Sep 25 19:29:23 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Thu Sep 25 19:29:30 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <200809250845.06042.jhb@freebsd.org> References: <200809241234.55075.jhb@freebsd.org> <57DCDBC7-8542-4082-8893-5B96DA92DA9A@wheelhouse.org> <200809250845.06042.jhb@freebsd.org> Message-ID: <61B6EB36-0E0C-4FFA-A84B-B434050B6244@wheelhouse.org> On Sep 25, 2008, at 8:45 AM, John Baldwin wrote: > It's probably the one just before the NDINIT (note that the return > address in > the call stack is pointing to the next instruction to be executed > after the > call to VOP_UNLOCK(), so sometimes it can end up referring to the > next line > in the source code from the actual function call): Seems like we're six or seven lines of source down, not on the next line, which was the source of my confusion. But if you're not confused, I won't be. :) > Can you 'p *mp'? I'm curious if mp->mnt_vnodecovered is NULL (in > which case, > why didn't the two tests in the if() fail?) Apparently I can't; we're stuck with DDB since we can't get a crash dump and the serial console goes to a hardware terminal server. I'm afraid I'm not quite clever enough to find the right data structure without symbols. I could try to throw a printf in there, or add a panic if mp- >mt_vnodecovered is NULL, if you think that would help. The printf will probably significantly alter timings, so I might need some guidance as far as what to print, and under what conditions. Thanks, Jeff From jespasac at minibofh.org Thu Sep 25 21:44:53 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Thu Sep 25 21:45:00 2008 Subject: Regenerate ports tree from installed ports? Message-ID: <48DC01DA.9040108@minibofh.org> Hi all, I suppose it's a dumb (and crazy) question, but as post subject says: ?Is it possible to regenerate the /usr/ports tree _from_ the installed ports? Let's me to explain. I've a lot of production servers with 6.2 and 6.3 version, and I wanna update them to new 7.x branch. I'll use the 'traditional' method (cvsup, make buildworld, make kernel...etc) instead the new binary method (freebsd-update) because of I've a customized kernel in these boxes. Until that point, it's all right. But everybody knows that you have to recompile all your installed ports after the kernel and userland upgrade, to re-link the new libraries and disappeared ones. But in my case, these boxes are used as shared web-hostings, and a lot of particularities are present. Change the php version, for example, can means that tens of webs not work fine. If I would have a perfect ports tree it would be easy: simple recompile all the ports with portupgrade; but the nasty reality is that I'm not sure that the present ports tree is the identical mirror of installed ports. Even there are more possibilities that ports tree is more updated than the majority of installed ports. So, the only way I can see is the next: * update buildworld and kernel * remove /usr/ports * regenerate the /usr/ports from _installed_ ports * recompile all ports in new kernel/userland ?Is it possible? Please, be polite if I'm saying a stupid things :P -- Thanks, Jordi Espasa Clofent From delphij at delphij.net Thu Sep 25 21:59:52 2008 From: delphij at delphij.net (Xin LI) Date: Thu Sep 25 22:00:00 2008 Subject: Regenerate ports tree from installed ports? In-Reply-To: <48DC01DA.9040108@minibofh.org> References: <48DC01DA.9040108@minibofh.org> Message-ID: <48DC09CC.9010606@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jordi Espasa Clofent wrote: > Hi all, > > I suppose it's a dumb (and crazy) question, but as post subject says: > ?Is it possible to regenerate the /usr/ports tree _from_ the installed > ports? As long as your ports tree is not very old, you will be able to use it in newer system but this is not always guaranteed. It is, however, possible to checkout ports tree from the date you specified with either cvsup or cvs. My personal suggestion is that when upgrading, try to build a new environment from scratch (say, everything is brand new) with ports named by 'pkg_info -qoa' on old system, and have the new environment reveal potential issues before making major updates to running system. Another possible approach is to update from time to time but this could cause you a lot of downtime. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkjcCcsACgkQi+vbBBjt66D+5gCgraZv+FSEuxKFFiPNTan16Oyf HvEAoIt0OWlpSqgYwxo7Og/+7e9WBG2g =DJkP -----END PGP SIGNATURE----- From jhb at freebsd.org Thu Sep 25 22:16:42 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Sep 25 22:16:49 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <61B6EB36-0E0C-4FFA-A84B-B434050B6244@wheelhouse.org> References: <200809250845.06042.jhb@freebsd.org> <61B6EB36-0E0C-4FFA-A84B-B434050B6244@wheelhouse.org> Message-ID: <200809251553.48978.jhb@freebsd.org> On Thursday 25 September 2008 03:29:20 pm Jeff Wheelhouse wrote: > > On Sep 25, 2008, at 8:45 AM, John Baldwin wrote: > > It's probably the one just before the NDINIT (note that the return > > address in > > the call stack is pointing to the next instruction to be executed > > after the > > call to VOP_UNLOCK(), so sometimes it can end up referring to the > > next line > > in the source code from the actual function call): > > Seems like we're six or seven lines of source down, not on the next > line, which was the source of my confusion. But if you're not > confused, I won't be. :) > > > Can you 'p *mp'? I'm curious if mp->mnt_vnodecovered is NULL (in > > which case, > > why didn't the two tests in the if() fail?) > > Apparently I can't; we're stuck with DDB since we can't get a crash > dump and the serial console goes to a hardware terminal server. I'm > afraid I'm not quite clever enough to find the right data structure > without symbols. > > I could try to throw a printf in there, or add a panic if mp- > >mt_vnodecovered is NULL, if you think that would help. The printf > will probably significantly alter timings, so I might need some > guidance as far as what to print, and under what conditions. You can use KTR instead of printf perhaps and then use 'show ktr' from DDB. This won't have the same impact on timing as printf(). I would include PIDs in any KTR traces you do so it's easier to parse the interleaved entries from multiple CPUs. Also, if you have a good test case, it might be worth grabbing a box w/o gmirror that can generate a crashdump and reproduce it there. -- John Baldwin From freebsd-hackers at wheelhouse.org Thu Sep 25 23:00:08 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Thu Sep 25 23:00:15 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <200809241212.09920.jhb@freebsd.org> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <200809241212.09920.jhb@freebsd.org> Message-ID: On Sep 24, 2008, at 12:12 PM, John Baldwin wrote: > Shared lookups only work on the NFS client in 6.x. I'm about to > turn them on > for UFS in HEAD (8.x) and will backport the needed fixes to 7.x > after 7.1 > (too risky to merge to 7.x this close to a release). OK, given all the patches you referenced, I did make a decent effort at backporting to 7.0. Here are the results: > Revision Changes Path > 1.87 +48 -29 src/sys/ufs/ufs/ufs_lookup.c Applied, changing a couple of VOP_ISLOCKED() and vn_lock() calls to add "td" as the last parameter. > Revision Changes Path > 1.53 +0 -1 src/sys/ufs/ufs/inode.h > 1.88 +10 -13 src/sys/ufs/ufs/ufs_lookup.c Applied successfully. > SVN rev 181018 on 2008-07-30 21:07:56Z by jhb NOT applied, because it was a whitespace tweak on ufs_lookup 1.89 which was not on your list. > SVN rev 183079 on 2008-09-16 16:18:36Z by jhb Applied cleanly. > Modified files: > sys/ufs/ufs inode.h ufs_lookup.c > Log: > SVN rev 183093 on 2008-09-16 19:06:44Z by jhb Applied cleanly. > 1.6 +2 -1 src/sys/ufs/ufs/dirhash.h > 1.24 +289 -227 src/sys/ufs/ufs/ufs_dirhash.c This patch applies but generates an awful lot of errors (enclosed at end). I think it may be dependent on the 8.0 lockmgr. Since most of the remaining patches are against the same files, I bailed out here. > SVN rev 183080 on 2008-09-16 16:23:56Z by jhb Skipped. > SVN rev 183280 on 2008-09-22 20:53:22Z by jhb Skipped. > There are additional fixes needed to fix races with umount -f, > so if you backport all this stuff, don't use umount -f or you > risk panics. :) Noted. > - mp->mnt_kern_flag |= MNTK_MPSAFE; > + mp->mnt_kern_flag |= MNTK_MPSAFE | MNTK_LOOKUP_SHARED; Applied. If I can make the backport work (a big if, given the dirhash changes) on 7.0, I am happy to maintain and test the diffs locally until after the 7.1 release and send them over to you at that time, if it will save you some effort. Thanks, Jeff Dirhash compile errors: /usr/src/sys/ufs/ufs/ufs_dirhash.c:132:37: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_release': /usr/src/sys/ufs/ufs/ufs_dirhash.c:132: error: 'lockmgr' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:132: error: (Each undeclared identifier is reported only once /usr/src/sys/ufs/ufs/ufs_dirhash.c:132: error: for each function it appears in.) /usr/src/sys/ufs/ufs/ufs_dirhash.c:161:45: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_create': /usr/src/sys/ufs/ufs/ufs_dirhash.c:161: error: 'lockmgr' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:178:17: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c:193:60: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c:198:42: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c:222:39: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_acquire': /usr/src/sys/ufs/ufs/ufs_dirhash.c:222: error: 'lockmgr' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:248:17: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_free': /usr/src/sys/ufs/ufs/ufs_dirhash.c:247: error: 'lockmgr' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:385:39: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_build': /usr/src/sys/ufs/ufs/ufs_dirhash.c:385: error: 'lockmgr' undeclared (first use in this function) cc1: warnings being treated as errors /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_free_locked': /usr/src/sys/ufs/ufs/ufs_dirhash.c:403: warning: implicit declaration of function 'lockmgr_assert' /usr/src/sys/ufs/ufs/ufs_dirhash.c:403: warning: nested extern declaration of 'lockmgr_assert' /usr/src/sys/ufs/ufs/ufs_dirhash.c:403: error: 'KA_LOCKED' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:417:37: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c:417: error: 'lockmgr' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:418:35: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c:438:37: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_lookup': /usr/src/sys/ufs/ufs/ufs_dirhash.c:473: error: 'KA_LOCKED' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_findfree': /usr/src/sys/ufs/ufs/ufs_dirhash.c:621: error: 'KA_LOCKED' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_enduseful': /usr/src/sys/ufs/ufs/ufs_dirhash.c:692: error: 'KA_LOCKED' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_findslot': /usr/src/sys/ufs/ufs/ufs_dirhash.c:1001: error: 'KA_LOCKED' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_delslot': /usr/src/sys/ufs/ufs/ufs_dirhash.c:1025: error: 'KA_LOCKED' undeclared (first use in this function) /usr/src/sys/ufs/ufs/ufs_dirhash.c:1101:59: error: macro "lockmgr" requires 4 arguments, but only 3 given /usr/src/sys/ufs/ufs/ufs_dirhash.c: In function 'ufsdirhash_recycle': /usr/src/sys/ufs/ufs/ufs_dirhash.c:1101: error: 'lockmgr' undeclared (first use in this function) From freebsd-hackers at wheelhouse.org Thu Sep 25 23:06:01 2008 From: freebsd-hackers at wheelhouse.org (Jeff Wheelhouse) Date: Thu Sep 25 23:06:16 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: <200809251553.48978.jhb@freebsd.org> References: <200809250845.06042.jhb@freebsd.org> <61B6EB36-0E0C-4FFA-A84B-B434050B6244@wheelhouse.org> <200809251553.48978.jhb@freebsd.org> Message-ID: On Sep 25, 2008, at 3:53 PM, John Baldwin wrote: > You can use KTR instead of printf perhaps and then use 'show ktr' > from DDB. > This won't have the same impact on timing as printf(). I would > include PIDs > in any KTR traces you do so it's easier to parse the interleaved > entries from > multiple CPUs. OK, while I am educating myself about how KTR works, what would you like to see? Just mp->mnt_vnodecovered? > Also, if you have a good test case, it might be worth > grabbing a box w/o gmirror that can generate a crashdump and > reproduce it > there. Not an option for us right now; spare 8-core boxes are hard to come by. We're looking for a USB hard drive or something we can dump to. Thanks, Jeff From daniel at dgnetwork.com.br Thu Sep 25 23:46:39 2008 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Thu Sep 25 23:47:11 2008 Subject: FreeBSD and ISCSI, Strange Problem Message-ID: <48DC1C97.6010701@dgnetwork.com.br> I'm with a very strange problem in the FreeBSD 7.0R I use the iscsi_initiator to mount two devices of a Dell MD3000i, the file system is UFS. The problem occurs when I make a copy of a great directory for inside of the /data/email directory, passed some minutes of beginning of copy, the SSH connection stops to answer, when trying to open a new connection " Password: " it isn't requested, in the console, when typing the user "root" e to press enter, " Password: " also it isn't requested. The only way to come back is restarting the FreeBSD. When press CTRL+T during the freeze it is shown: # ssh root@10.0.20.10 load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k In another freeze it showed state [ufs] During freeze, send and receive pings work fine, but no service runing work. I already verified for some related LOG, however not see nothing related. MOUNT: /dev/da0s1g on /home (ufs, local, soft-updates) /dev/da0s1f on /tmp (ufs, local, soft-updates) /dev/da0s1d on /usr (ufs, local, soft-updates) /dev/da0s1e on /var (ufs, NFS exported, local, soft-updates) /dev/da2s1d on /data/db (ufs, NFS exported, local, soft-updates) /dev/da3s1d on /data/email (ufs, NFS exported, local, soft-updates) DMESG: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Mon Sep 15 20:00:35 BRT 2008 root@srvdata1:/usr/src/sys/i386/compile/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2329.84-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd> AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 3484745728 (3323 MB) avail memory = 3405615104 (3247 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Sep 15 2008 20:00:23) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 720072006000720 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci4: on pcib1 pcib2: at device 0.0 on pci4 pci5: on pcib2 pcib3: at device 0.0 on pci5 pci6: on pcib3 pcib4: at device 0.0 on pci6 pci7: on pcib4 bce0: mem 0xf4000000-0xf5ffffff irq 16 at device 0.0 on pci7 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:1e:c9:b4:e5:2b bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x04000305); Flags( MFW MSI ) pcib5: at device 1.0 on pci5 pci8: on pcib5 pcib6: at device 0.3 on pci4 pci9: on pcib6 pcib7: at device 3.0 on pci0 pci1: on pcib7 mpt0: port 0xec00-0xecff mem 0xfc8fc000-0xfc8fffff,0xfc8e0000-0xfc8effff irq 16 at device 0.0 on pci1 mpt0: [ITHREAD] mpt0: MPI Version=1.5.14.0 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x12 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x16 mpt0: mpt_cam_event: 0x21 mpt0: mpt_cam_event: 0x21 pcib8: at device 4.0 on pci0 pci10: on pcib8 em0: port 0xdce0-0xdcff mem 0xfc5e0000-0xfc5fffff,0xfc5c0000-0xfc5dffff irq 16 at device 0.0 on pci10 em0: Using MSI interrupt em0: Ethernet address: 00:15:17:8b:23:12 em0: [FILTER] pcib9: at device 5.0 on pci0 pci11: on pcib9 pcib10: at device 6.0 on pci0 pci12: on pcib10 em1: port 0xcce0-0xccff mem 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16 at device 0.0 on pci12 em1: Using MSI interrupt em1: Ethernet address: 00:15:17:8b:4f:92 em1: [FILTER] pcib11: at device 7.0 on pci0 pci13: on pcib11 pci0: at device 8.0 (no driver attached) pcib12: at device 28.0 on pci0 pci2: on pcib12 pcib13: at device 0.0 on pci2 pci3: on pcib13 bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:1e:c9:b4:e5:29 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x04000305); Flags( MFW MSI ) uhci0: port 0xace0-0xacff irq 21 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xacc0-0xacdf irq 20 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xaca0-0xacbf irq 21 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xac80-0xac9f irq 20 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xfca00000-0xfca003ff irq 21 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered uhub5: on uhub4 uhub5: multiple transaction translators uhub5: 4 ports with 4 removable, self powered ukbd0: on uhub5 kbd2 at ukbd0 uhid0: on uhub5 umass0: on uhub4 pcib14: at device 30.0 on pci0 pci14: on pcib14 vgapci0: port 0xbc00-0xbcff mem 0xd8000000-0xdfffffff,0xfc2d0000-0xfc2dffff irq 19 at device 13.0 on pci14 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc8fff,0xcf000-0xcffff,0xec000-0xeffff pnpid ORM0000 on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec hptrr: no controller detected. acd0: CDRW at ata0-master UDMA33 ses0 at mpt0 bus 0 target 8 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 300.000MB/s transfers ses0: SCSI-3 SES Device da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing Enabled da0: 237464MB (486326272 512 byte sectors: 255H 63S/T 30272C) da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: 959MB (1964032 512 byte sectors: 64H 32S/T 959C) SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! GEOM_LABEL: Label for provider da1s4 is msdosfs/Hypervisor0. GEOM_LABEL: Label for provider da1s5 is msdosfs/Hypervisor1. GEOM_LABEL: Label for provider da1s6 is msdosfs/Hypervisor2. GEOM_LABEL: Label for provider da1s8 is msdosfs/Hypervisor3. Trying to mount root from ufs:/dev/da0s1a bce0: link state changed to UP em0: link state changed to UP lagg0: link state changed to UP em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP ic_init: cam subsystem initialized 0] i_create_session: sessionID=0 0] i_create_session: error=0 0] i_setopt: maxRecvDataSegmentLength=65535 0] i_setopt: maXmitDataSegmentLength=8192 0] i_setopt: maxBurstLength=131072 0] i_setopt: maxRecvDataSegmentLength=65535 0] i_setopt: maXmitDataSegmentLength=65024 0] i_setopt: maxBurstLength=131072 0] i_setopt: opt.headerDigest='None' 0] ism_fullfeature: flag=1 0] _scan_target: target=0 da2 at iscsi0 bus 0 target 0 lun 0 da2: Fixed Direct Access SCSI-5 device da3 at iscsi0 bus 0 target 0 lun 1 da3: Fixed Direct Access SCSI-5 device Somebody can help me ? Thanks. Daniel From fbsd-hackers at mawer.org Thu Sep 25 23:56:25 2008 From: fbsd-hackers at mawer.org (Antony Mawer) Date: Thu Sep 25 23:56:32 2008 Subject: panic: lockmgr on FreeBSD 7.0-RELEASE-p4 amd64 In-Reply-To: References: <200809250845.06042.jhb@freebsd.org> <61B6EB36-0E0C-4FFA-A84B-B434050B6244@wheelhouse.org> <200809251553.48978.jhb@freebsd.org> Message-ID: <48DC1D93.1000108@mawer.org> Jeff Wheelhouse wrote: >> Also, if you have a good test case, it might be worth >> grabbing a box w/o gmirror that can generate a crashdump and reproduce it >> there. > > Not an option for us right now; spare 8-core boxes are hard to come by. > We're looking for a USB hard drive or something we can dump to. Can you set your dump device to the underlying GEOM component's swap partition rather than to the gmirror device...? -- Antony From danny at cs.huji.ac.il Fri Sep 26 06:39:30 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 06:39:36 2008 Subject: FreeBSD and ISCSI, Strange Problem In-Reply-To: <48DC1C97.6010701@dgnetwork.com.br> References: <48DC1C97.6010701@dgnetwork.com.br> Message-ID: > I'm with a very strange problem in the FreeBSD 7.0R > I use the iscsi_initiator to mount two devices of a Dell MD3000i, the > file system is UFS. > The problem occurs when I make a copy of a great directory for inside of > the /data/email directory, passed some minutes of beginning of copy, the > SSH connection stops to answer, when trying to open a new connection " > Password: " it isn't requested, in the console, when typing the user > "root" e to press enter, " Password: " also it isn't requested. The only > way to come back is restarting the FreeBSD. > > When press CTRL+T during the freeze it is shown: > # ssh root@10.0.20.10 > load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k > > In another freeze it showed state [ufs] > During freeze, send and receive pings work fine, but no service runing work. > > I already verified for some related LOG, however not see nothing related. hi Daniel, the problem is probably that iscsi is deadlocked, so fetch ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gz cd /usr/src tar xpzf /path-to-tar-file/iscsi-2.1.tar.gz (cd sys/modules/iscsi/initiator; make; make install) (cd sbin/iscontrol;make; make install) probably the safest is now to reboot. Let me know what happens. obrigado (thanks?), danny From danny at cs.huji.ac.il Fri Sep 26 07:04:17 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 07:04:24 2008 Subject: bad NFS/UDP performance Message-ID: Hi, There seems to be some serious degradation in performance. Under 7.0 I get about 90 MB/s (on write), while, on the same machine under 7.1 it drops to 20! Any ideas? thanks, danny From koitsu at FreeBSD.org Fri Sep 26 08:18:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 26 08:18:16 2008 Subject: bad NFS/UDP performance In-Reply-To: References: Message-ID: <20080926081806.GA19055@icarus.home.lan> On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? 1) Network card driver changes, 2) This could be relevant, but rwatson@ will need to help determine that. http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From des at des.no Fri Sep 26 09:20:16 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri Sep 26 09:20:23 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <05B718C6-BBC9-4B78-B580-4E250199DDCF@wheelhouse.org> (Jeff Wheelhouse's message of "Thu, 25 Sep 2008 14:02:26 -0400") References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <86ljxgs2h0.fsf@ds4.des.no> <05B718C6-BBC9-4B78-B580-4E250199DDCF@wheelhouse.org> Message-ID: <868wtf8drl.fsf@ds4.des.no> Jeff Wheelhouse writes: > http://software.wheelhouse.org/rptest.tar.bz2 Thanks. I get similar results on head; vfs.lookup_shared actually seems to *reduce* performance by about 10% - 20%. I ran the test on both UFS and ZFS; there is no significant difference. DES -- Dag-Erling Sm?rgrav - des@des.no From danny at cs.huji.ac.il Fri Sep 26 09:27:10 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 09:27:38 2008 Subject: bad NFS/UDP performance In-Reply-To: <20080926081806.GA19055@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> Message-ID: > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > Hi, > > There seems to be some serious degradation in performance. > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > under 7.1 it drops to 20! > > Any ideas? > > 1) Network card driver changes, could be, but at least iperf/tcp is ok - can't get udp numbers, do you know of any tool to measure udp performance? BTW, I also checked on different hardware, and the badness is there. > > 2) This could be relevant, but rwatson@ will need to help determine > that. > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html gut feeling is that it's somewhere else: Writing 16 MB file BS Count /---- 7.0 ------/ /---- 7.1 -----/ 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s Average: 75.86 33.00 the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in the measurements, but the relation are similar, good on 7.0, bad on 7.1 Cheers, danny From koitsu at FreeBSD.org Fri Sep 26 09:52:32 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 26 09:52:45 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> Message-ID: <20080926095230.GA20789@icarus.home.lan> On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > Hi, > > > There seems to be some serious degradation in performance. > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > under 7.1 it drops to 20! > > > Any ideas? > > > > 1) Network card driver changes, > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > know of any tool to measure udp performance? > BTW, I also checked on different hardware, and the badness is there. According to INDEX, benchmarks/iperf does UDP bandwidth testing. benchmarks/nttcp should as well. What network card is in use? If Intel, what driver version (should be in dmesg). > > 2) This could be relevant, but rwatson@ will need to help determine > > that. > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html > > gut feeling is that it's somewhere else: > > Writing 16 MB file > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > Average: 75.86 33.00 > > the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in > the > measurements, but the relation are similar, good on 7.0, bad on 7.1 Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From jespasac at minibofh.org Fri Sep 26 10:22:59 2008 From: jespasac at minibofh.org (Jordi Espasa Clofent) Date: Fri Sep 26 10:23:07 2008 Subject: Rare problems in upgrade process (corrupted FS?) Message-ID: <48DCB7FF.1000604@minibofh.org> Hi all, I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've found a rare problems. 1) I do the sync process with csup(1); next I go into /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized kernels) and this file doesn't exists. Mmmm.... I decide to repeat the process againt other cvsup mirror but I get the same results: GENERIC file isn't there. 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, copy and paste. Yes, I know: a very nasty process. The big problem appears when I try to do 'make cleandir' and others. I get the next outputs: # pwd /usr/src # make cleandir make: don't know how to make cleandir. Stop # make buildworld make: don't know how to make buildworld. Stop # ls -l /usr/bin/make -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make # file /usr/bin/make /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 (FreeBSD), for FreeBSD 6.3, statically linked, stripped ??????? * I reboot the machine (because of I suspect a very weird FS problem), boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) found and repair several errors. Epecially, one error claims my attention: SUPERBLOCK. * After the theorical FS reparation I'm again in the point 1. ?Any clues? -- Thanks, Jordi Espasa Clofent From koitsu at FreeBSD.org Fri Sep 26 10:47:34 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 26 10:47:47 2008 Subject: Rare problems in upgrade process (corrupted FS?) In-Reply-To: <48DCB7FF.1000604@minibofh.org> References: <48DCB7FF.1000604@minibofh.org> Message-ID: <20080926104732.GA22641@icarus.home.lan> On Fri, Sep 26, 2008 at 12:22:55PM +0200, Jordi Espasa Clofent wrote: > Hi all, > > I'm traying to update a FreeBSD server box from 6.3p11 to 7.0 and I've > found a rare problems. > > 1) I do the sync process with csup(1); next I go into > /usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized > kernels) and this file doesn't exists. Mmmm.... I decide to repeat the > process againt other cvsup mirror but I get the same results: GENERIC > file isn't there. > > 2) I go to FreeBSD CVSWeb , locate the GENERIC file under the 7_0 tag, > copy and paste. Yes, I know: a very nasty process. The big problem > appears when I try to do 'make cleandir' and others. I get the next > outputs: > > # pwd > /usr/src > # make cleandir > make: don't know how to make cleandir. Stop > # make buildworld > make: don't know how to make buildworld. Stop > # ls -l /usr/bin/make > -r-xr-xr-x 1 root wheel 351024 Aug 18 13:19 /usr/bin/make > # file /usr/bin/make > /usr/bin/make: ELF 64-bit LSB executable, AMD x86-64, version 1 > (FreeBSD), for FreeBSD 6.3, statically linked, stripped Looks to me like you have no /usr/src/Makefile. > * After the theorical FS reparation I'm again in the point 1. None of the information you provided in your above output, however, shows anything about the filesystem (other than /usr/bin/make). But this sounds honestly like some sort of corrupted supdb, or a cvsup mirror that's broken. I would do the following: rm -fr /usr/src/* rm -fr /var/db/sup/src-all csup -h -L 2 -g /usr/share/examples/stable-supfile I can assure you /sys/amd64/conf/GENERIC exists, and is on the cvsup mirrors. > * I reboot the machine (because of I suspect a very weird FS problem), > boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) > found and repair several errors. Epecially, one error claims my > attention: SUPERBLOCK. Superblock problems wouldn't explain this; there are hundreds of superblocks available (you wouldn't be able to use your machine if they were all horked). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From peterjeremy at optushome.com.au Fri Sep 26 11:13:18 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Fri Sep 26 11:13:32 2008 Subject: Rare problems in upgrade process (corrupted FS?) In-Reply-To: <48DCB7FF.1000604@minibofh.org> References: <48DCB7FF.1000604@minibofh.org> Message-ID: <20080926111313.GA7231@server.vk2pj.dyndns.org> On 2008-Sep-26 12:22:55 +0200, Jordi Espasa Clofent wrote: >1) I do the sync process with csup(1); next I go into >/usr/src/sys/amd64/conf to edit the GENERIC file (I use a custimized >kernels) and this file doesn't exists. You might like to check your CVSup site against http://www.mavetju.org/unix/freebsd-mirrors/ to confirm it is updating correctly. GENERIC should exist. >* I reboot the machine (because of I suspect a very weird FS problem), >boot in single user mode and do a 'fsck -fy'. Effectively, the fsck(8) >found and repair several errors. Epecially, one error claims my >attention: SUPERBLOCK. It might have been useful if you had kept a record of the exact messages. If you repeat the fsck, does it now report any problems? If you are using an up-to-date CVSup mirror, my next suggestion would be hardware problems. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080926/6284fbd7/attachment.pgp From kometen at gmail.com Fri Sep 26 07:59:07 2008 From: kometen at gmail.com (Claus Guttesen) Date: Fri Sep 26 11:21:50 2008 Subject: bad NFS/UDP performance In-Reply-To: References: Message-ID: > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? Can you compare performanc with tcp? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From gavin at FreeBSD.org Fri Sep 26 12:33:07 2008 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Fri Sep 26 12:33:14 2008 Subject: bad NFS/UDP performance In-Reply-To: References: Message-ID: <1222430498.2993.1.camel@buffy.york.ac.uk> On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote: > Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? The scheduler has been changed to ULE, and NFS has historically been very sensitive to changes like that. You could try switching back to the 4BSD scheduler and seeing if that makes a difference. If it does, toggling PREEMPTION would also be interesting to see the results of. Gavin From daniel at dgnetwork.com.br Fri Sep 26 13:12:36 2008 From: daniel at dgnetwork.com.br (=?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?=) Date: Fri Sep 26 13:13:41 2008 Subject: FreeBSD and ISCSI, Strange Problem In-Reply-To: References: <48DC1C97.6010701@dgnetwork.com.br> Message-ID: <48DCD95D.9020400@dgnetwork.com.br> Danny Braniss escreveu: >> I'm with a very strange problem in the FreeBSD 7.0R >> I use the iscsi_initiator to mount two devices of a Dell MD3000i, the >> file system is UFS. >> The problem occurs when I make a copy of a great directory for inside of >> the /data/email directory, passed some minutes of beginning of copy, the >> SSH connection stops to answer, when trying to open a new connection " >> Password: " it isn't requested, in the console, when typing the user >> "root" e to press enter, " Password: " also it isn't requested. The only >> way to come back is restarting the FreeBSD. >> >> When press CTRL+T during the freeze it is shown: >> # ssh root@10.0.20.10 >> load: 0.76 cmd: ssh 86930 [sbwait] 0.00u 0.01s 0% 2076k >> >> In another freeze it showed state [ufs] >> During freeze, send and receive pings work fine, but no service runing work. >> >> I already verified for some related LOG, however not see nothing related. >> > > hi Daniel, > the problem is probably that iscsi is deadlocked, so fetch > ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gz > cd /usr/src > tar xpzf /path-to-tar-file/iscsi-2.1.tar.gz > (cd sys/modules/iscsi/initiator; make; make install) > (cd sbin/iscontrol;make; make install) > probably the safest is now to reboot. > > Let me know what happens. > > obrigado (thanks?), > danny > > > > > Danny, You typed the ftp wrong. Obrigado, thanks !! =) Daniel From danny at cs.huji.ac.il Fri Sep 26 13:35:19 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 13:35:25 2008 Subject: bad NFS/UDP performance In-Reply-To: <20080926095230.GA20789@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > > Hi, > > > > There seems to be some serious degradation in performance. > > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > > under 7.1 it drops to 20! > > > > Any ideas? > > > > > > 1) Network card driver changes, > > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > > know of any tool to measure udp performance? > > BTW, I also checked on different hardware, and the badness is there. > > According to INDEX, benchmarks/iperf does UDP bandwidth testing. I know, but I get about 1mgb, which seems somewhat low :-( > > benchmarks/nttcp should as well. > > What network card is in use? If Intel, what driver version (should be > in dmesg). bge: and bce: and intels, but haven't tested there yet. > > > > 2) This could be relevant, but rwatson@ will need to help determine > > > that. > > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html > > > > gut feeling is that it's somewhere else: > > > > Writing 16 MB file > > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.86 33.00 > > > > the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in > > the > > measurements, but the relation are similar, good on 7.0, bad on 7.1 > > Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? > no, but diffing the sysctl show: -vfs.nfs.realign_test: 22141777 +vfs.nfs.realign_test: 498351 -vfs.nfsrv.realign_test: 5005908 +vfs.nfsrv.realign_test: 0 +vfs.nfsrv.commit_miss: 0 +vfs.nfsrv.commit_blks: 0 changing them did nothing - or at least with respect to nfs throughput :-) danny From danny at cs.huji.ac.il Fri Sep 26 13:41:24 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 13:41:31 2008 Subject: bad NFS/UDP performance In-Reply-To: <1222430498.2993.1.camel@buffy.york.ac.uk> References: <1222430498.2993.1.camel@buffy.york.ac.uk> Message-ID: > On Fri, 2008-09-26 at 10:04 +0300, Danny Braniss wrote: > > Hi, > > There seems to be some serious degradation in performance. > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > under 7.1 it drops to 20! > > Any ideas? > > The scheduler has been changed to ULE, and NFS has historically been > very sensitive to changes like that. You could try switching back to > the 4BSD scheduler and seeing if that makes a difference. If it does, > toggling PREEMPTION would also be interesting to see the results of. > > Gavin I'm testing 7.0-stable vs 7.1-prerelease, and both have ULE. BTW, the nfs client hosts I'm testing are idle. danny From jhb at freebsd.org Fri Sep 26 14:05:07 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Sep 26 14:05:14 2008 Subject: Major SMP problems with lstat/namei In-Reply-To: <868wtf8drl.fsf@ds4.des.no> References: <8185F68B-C443-4891-BEC2-5E3D453DDC93@wheelhouse.org> <05B718C6-BBC9-4B78-B580-4E250199DDCF@wheelhouse.org> <868wtf8drl.fsf@ds4.des.no> Message-ID: <200809260949.21592.jhb@freebsd.org> On Friday 26 September 2008 05:20:14 am Dag-Erling Sm?rgrav wrote: > Jeff Wheelhouse writes: > > http://software.wheelhouse.org/rptest.tar.bz2 > > Thanks. I get similar results on head; vfs.lookup_shared actually seems > to *reduce* performance by about 10% - 20%. I ran the test on both UFS > and ZFS; there is no significant difference. You might try http://www.FreeBSD.org/~jhb/patches/namei_rwlock.patch However, it might also be useful in general to enable lock profiling and see which locks (if any) are contested. -- John Baldwin From jhb at freebsd.org Fri Sep 26 14:05:29 2008 From: jhb at freebsd.org (John Baldwin) Date: Fri Sep 26 14:05:58 2008 Subject: bad NFS/UDP performance In-Reply-To: References: Message-ID: <200809260952.26896.jhb@freebsd.org> On Friday 26 September 2008 03:04:16 am Danny Braniss wrote: > Hi, > There seems to be some serious degradation in performance. > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > under 7.1 it drops to 20! > Any ideas? > > thanks, > danny Perhaps use nfsstat to see if 7.1 is performing more on-the-wire requests? Also, if you can, do a binary search to narrow down when the regression occurred in RELENG_7. -- John Baldwin From koitsu at FreeBSD.org Fri Sep 26 14:31:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Sep 26 14:32:08 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: <20080926143153.GA26978@icarus.home.lan> On Fri, Sep 26, 2008 at 04:35:17PM +0300, Danny Braniss wrote: > > On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > > > Hi, > > > > > There seems to be some serious degradation in performance. > > > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > > > under 7.1 it drops to 20! > > > > > Any ideas? > > > > > > > > 1) Network card driver changes, > > > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > > > know of any tool to measure udp performance? > > > BTW, I also checked on different hardware, and the badness is there. > > > > According to INDEX, benchmarks/iperf does UDP bandwidth testing. > > I know, but I get about 1mgb, which seems somewhat low :-( > > > > > benchmarks/nttcp should as well. > > > > What network card is in use? If Intel, what driver version (should be > > in dmesg). > > bge: > and > bce: > and intels, but haven't tested there yet. Both bge(4) and bce(4) claim to support checksum offloading. You might try disabling it (ifconfig ... -txcsum -rxcsum) to see if things improve. If not, more troubleshooting is needed. You might also try turning off TSO if it's supported (check your ifconfig output for TSO in the options=<> section. Then use ifconfig ... -tso) > > Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? > > > no, but diffing the sysctl show: > > -vfs.nfs.realign_test: 22141777 > +vfs.nfs.realign_test: 498351 > > -vfs.nfsrv.realign_test: 5005908 > +vfs.nfsrv.realign_test: 0 > > +vfs.nfsrv.commit_miss: 0 > +vfs.nfsrv.commit_blks: 0 > > changing them did nothing - or at least with respect to nfs throughput :-) I'm not sure what any of these do, as NFS is a bit out of my league. :-) I'll be following this thread though! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From danny at cs.huji.ac.il Fri Sep 26 14:38:00 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 14:38:07 2008 Subject: FreeBSD and ISCSI, Strange Problem In-Reply-To: Your message of Fri, 26 Sep 2008 09:45:17 -0300 . Message-ID: > the problem is probably that iscsi is deadlocked, so fetch > ftp://ftp/users/danny/freebsd/iscsi-2.1.tar.gzs;/ftp/;/&.cs.huji.ac.il; > > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.1.tar.gz > Danny, > > You typed the ftp wrong. > > hi Daniel, oh well, it was before coffee :-) > Obrigado, thanks !! =) > > Daniel > > From danny at cs.huji.ac.il Fri Sep 26 14:45:58 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Sep 26 14:46:17 2008 Subject: bad NFS/UDP performance In-Reply-To: <20080926095230.GA20789@icarus.home.lan> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > On Fri, Sep 26, 2008 at 12:27:08PM +0300, Danny Braniss wrote: > > > On Fri, Sep 26, 2008 at 10:04:16AM +0300, Danny Braniss wrote: > > > > Hi, > > > > There seems to be some serious degradation in performance. > > > > Under 7.0 I get about 90 MB/s (on write), while, on the same machine > > > > under 7.1 it drops to 20! > > > > Any ideas? > > > > > > 1) Network card driver changes, > > could be, but at least iperf/tcp is ok - can't get udp numbers, do you > > know of any tool to measure udp performance? > > BTW, I also checked on different hardware, and the badness is there. > > According to INDEX, benchmarks/iperf does UDP bandwidth testing. > > benchmarks/nttcp should as well. > > What network card is in use? If Intel, what driver version (should be > in dmesg). > > > > 2) This could be relevant, but rwatson@ will need to help determine > > > that. > > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045109.html > > > > gut feeling is that it's somewhere else: > > > > Writing 16 MB file > > BS Count /---- 7.0 ------/ /---- 7.1 -----/ > > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.86 33.00 > > > > the nfs filer is a NetWork Appliance, and is in use, so i get fluctuations in > > the > > measurements, but the relation are similar, good on 7.0, bad on 7.1 > > Do you have any NFS-related tunings in /etc/rc.conf or /etc/sysctl.conf? > after more testing, it seems it's related to changes made between Aug 4 and Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try and close the gap. danny From dillon at apollo.backplane.com Fri Sep 26 18:30:32 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Fri Sep 26 18:30:46 2008 Subject: bad NFS/UDP performance References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> <20080926143153.GA26978@icarus.home.lan> Message-ID: <200809261818.m8QII6jF004333@apollo.backplane.com> :> -vfs.nfs.realign_test: 22141777 :> +vfs.nfs.realign_test: 498351 :> :> -vfs.nfsrv.realign_test: 5005908 :> +vfs.nfsrv.realign_test: 0 :> :> +vfs.nfsrv.commit_miss: 0 :> +vfs.nfsrv.commit_blks: 0 :> :> changing them did nothing - or at least with respect to nfs throughput :-) : :I'm not sure what any of these do, as NFS is a bit out of my league. ::-) I'll be following this thread though! : :-- :| Jeremy Chadwick jdc at parodius.com | A non-zero nfs_realign_count is bad, it means NFS had to copy the mbuf chain to fix the alignment. nfs_realign_test is just the number of times it checked. So nfs_realign_test is irrelevant. it's nfs_realign_count that matters. Several things can cause NFS payloads to be improperly aligned. Anything from older network drivers which can't start DMA on a 2-byte boundary, resulting in the 14-byte encapsulation header causing improper alignment of the IP header & payload, to rpc embedded in NFS TCP streams winding up being misaligned. Modern network hardware either support 2-byte-aligned DMA, allowing the encapsulation to be 2-byte aligned so the payload winds up being 4-byte aligned, or support DMA chaining allowing the payload to be placed in its own mbuf, or pad, etc. -- One thing I would check is to be sure a couple of nfsiod's are running on the client when doing your tests. If none are running the RPCs wind up being more synchronous and less pipelined. Another thing I would check is IP fragment reassembly statistics (for UDP) - there should be none for TCP connections no matter what the NFS I/O size selected. (It does seem more likely to be scheduler-related, though). -Matt From mwm-keyword-freebsdhackers2.e313df at mired.org Fri Sep 26 18:34:48 2008 From: mwm-keyword-freebsdhackers2.e313df at mired.org (Mike Meyer) Date: Fri Sep 26 18:34:54 2008 Subject: Regenerate ports tree from installed ports? In-Reply-To: <48DC01DA.9040108@minibofh.org> References: <48DC01DA.9040108@minibofh.org> Message-ID: <20080926140610.0f6ea7f6@bhuda.mired.org> On Thu, 25 Sep 2008 23:25:46 +0200 Jordi Espasa Clofent wrote: > Hi all, > > I suppose it's a dumb (and crazy) question, but as post subject says: > ?Is it possible to regenerate the /usr/ports tree _from_ the installed > ports? Possibly. If the installed ports were built from a consistent tree, you can always just use CVS to check out a copy of the ports tree for the date of the last port you installed. However, as was pointed out here, that doesn't mean you can actually build ports from them on an upgraded operating system. > Until that point, it's all right. But everybody knows that you have to > recompile all your installed ports after the kernel and userland > upgrade, to re-link the new libraries and disappeared ones. Um, no, everyone doesn't know you need to do that. In fact, I've almost *never* been able to do that, because I've almost always had proprietary, binary-only software of some sort or another running on my boxes for which the vendor hadn't provided an appropriate update. That's what the compat libraries are for - you can install those, and just keep on running your old binaries. It's been a while, but I'm pretty sure I managed one update by doing the OS update - including compat - and then replacing the ports piecemeal while the old ones ran on the compat libraries. Of course, running on the compat libraries isn't the ideal solution, so you want to rebuild the ports if you can. Of course, the same thing applies to running old versions of the ports - you really want to get new bug fixes, security patches, and such like that may have come out since you installed the original software. > But in my > case, these boxes are used as shared web-hostings, and a lot of > particularities are present. Change the php version, for example, can > means that tens of webs not work fine. The solution in this case is to buy one new box, build the new version on it, including all ports, clone your customers environments to it, and start it as "foobar-new". Tell your customers it's there, let them test things, help them fix what's needed, and after everyone is happy, swap the names. Repeat this process using the just-retired box to build the new one on. If these are inhouse services - so you can have some real down time - then I typically build a new system on a second disk with the same data directories, and test there. When it's all working, put everything on one disk, and then mirror the two disks, so it's there next time I need to do the dual boot upgrade thing. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From michael.schuh at gmail.com Fri Sep 26 18:43:32 2008 From: michael.schuh at gmail.com (Michael Schuh) Date: Fri Sep 26 18:47:20 2008 Subject: experimantal question about md's Message-ID: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> Hallo @list, first please answer me directly, i be not on the list. Let us say i have a Machine with 8 CPUs and a lot of RAM. An i need a very high perfomance Storage for holding data. My idea was to setup a raid1(0) with virtual disk images. Created with mdconfig. My idea was to create minimum 2 md-diskimages, these are located fisrt one on the harddisk as type vnode second one as exact copy totally in the memory as type malloc For now the man-page mentoid me to not to do so, while large disks in RAM cause panics, and i know panics come surely Is the above scenario possible without panics? thanks a lot. greetings from sunny Germany michael -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbr?cken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === From dwmalone at maths.tcd.ie Fri Sep 26 19:08:52 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Fri Sep 26 19:09:00 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: <20080926190848.GA65901@walton.maths.tcd.ie> On Fri, Sep 26, 2008 at 04:35:17PM +0300, Danny Braniss wrote: > I know, but I get about 1mgb, which seems somewhat low :-( Since UDP has no way to know how fast to send, you need to tell iperf how fast to send the packets. I think 1Mbps is the default speed. David. From xorquewasp at googlemail.com Fri Sep 26 22:27:17 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Sep 26 22:27:23 2008 Subject: popen() in multithreaded program - hangs? Message-ID: <20080926222711.GA74003@logik.internal.network> I'm trying to write a client for the jack audio connection kit (http://jackaudio.org), have hit an apparent bug and am not sure who's at fault. This is the client: -- #include #include jack_port_t *input_port; jack_port_t *output_port; jack_client_t *client; int main (void) { jack_status_t status; client = jack_client_open ("cdemo", JackNoStartServer, &status, "default"); if (!client) errx (112, "client_open: could not"); jack_client_close (client); return 0; } -- The jack_client_open() call never returns and the process can only be killed with SIGKILL. Tracing execution in gdb shows that the hang occurs in the popen() call in jack_get_tmpdir(), defined at client.c:114: http://trac.jackaudio.org/browser/trunk/jack/libjack/client.c Is there a known issue with calling popen() in a multithreaded program? At the point of that call, on my system, there are three running threads. Any help/advice on how to resolve this problem would be appreciated. xw From oberman at es.net Fri Sep 26 22:28:45 2008 From: oberman at es.net (Kevin Oberman) Date: Fri Sep 26 22:43:18 2008 Subject: bad NFS/UDP performance In-Reply-To: Your message of "Fri, 26 Sep 2008 20:08:48 BST." <20080926190848.GA65901@walton.maths.tcd.ie> Message-ID: <20080926221700.1C4AE4500E@ptavv.es.net> David, You beat me to it. Danny, read the iperf man page: -b, --bandwidth n[KM] set target bandwidth to n bits/sec (default 1 Mbit/sec). This setting requires UDP (-u). The page needs updating, though. It should read "-b, --bandwidth n[KMG]. It also does NOT require -u. If you use -b, UDP is assumed. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 224 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080926/f2199d43/attachment.pgp From julian at elischer.org Fri Sep 26 23:43:38 2008 From: julian at elischer.org (Julian Elischer) Date: Fri Sep 26 23:43:46 2008 Subject: popen() in multithreaded program - hangs? In-Reply-To: <20080926222711.GA74003@logik.internal.network> References: <20080926222711.GA74003@logik.internal.network> Message-ID: <48DD73A9.5000505@elischer.org> xorquewasp@googlemail.com wrote: > I'm trying to write a client for the jack audio connection kit > (http://jackaudio.org), have hit an apparent bug and am not sure what revision of FreeBSD? > who's at fault. > > This is the client: > > -- > > #include > #include > > jack_port_t *input_port; > jack_port_t *output_port; > jack_client_t *client; > > int > main (void) > { > jack_status_t status; > > client = jack_client_open ("cdemo", JackNoStartServer, &status, "default"); > if (!client) errx (112, "client_open: could not"); > > jack_client_close (client); > return 0; > } > > -- > > The jack_client_open() call never returns and the process can only be killed > with SIGKILL. Tracing execution in gdb shows that the hang occurs in the > popen() call in jack_get_tmpdir(), defined at client.c:114: > > http://trac.jackaudio.org/browser/trunk/jack/libjack/client.c > > Is there a known issue with calling popen() in a multithreaded program? At > the point of that call, on my system, there are three running threads. > > Any help/advice on how to resolve this problem would be appreciated. > > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From ravi.murty at intel.com Fri Sep 26 23:45:03 2008 From: ravi.murty at intel.com (Murty, Ravi) Date: Fri Sep 26 23:45:11 2008 Subject: priority fields in a thread Message-ID: Hello, I was wondering what all these different priority related fields in a thread structure meant. This is the 8.0 kernel tree. Thanks Ravi Td_base_pri Td_user_pri Td_base_user_pri Td_priority From xorquewasp at googlemail.com Fri Sep 26 23:47:32 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Fri Sep 26 23:47:39 2008 Subject: popen() in multithreaded program - hangs? In-Reply-To: <48DD73A9.5000505@elischer.org> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> Message-ID: <20080926234727.GA60860@logik.internal.network> On 20080926 16:43:37, Julian Elischer wrote: > xorquewasp@googlemail.com wrote: >> I'm trying to write a client for the jack audio connection kit >> (http://jackaudio.org), have hit an apparent bug and am not sure > > what revision of FreeBSD? Ahem, should've mentioned that. FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC -- xw From deischen at freebsd.org Sat Sep 27 01:43:51 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Sat Sep 27 01:43:58 2008 Subject: popen() in multithreaded program - hangs? In-Reply-To: <20080926234727.GA60860@logik.internal.network> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> Message-ID: On Sat, 27 Sep 2008, xorquewasp@googlemail.com wrote: > On 20080926 16:43:37, Julian Elischer wrote: >> xorquewasp@googlemail.com wrote: >>> I'm trying to write a client for the jack audio connection kit >>> (http://jackaudio.org), have hit an apparent bug and am not sure >> >> what revision of FreeBSD? > > Ahem, should've mentioned that. > > FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 > root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC http://www.freebsd.org/releases/6.3R/errata.html http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc -- DE From xorquewasp at googlemail.com Sat Sep 27 02:17:16 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Sep 27 02:17:23 2008 Subject: popen() in multithreaded program - hangs? In-Reply-To: References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> Message-ID: <20080927021709.GB60860@logik.internal.network> On 20080926 21:43:48, Daniel Eischen wrote: > On Sat, 27 Sep 2008, xorquewasp@googlemail.com wrote: > >> On 20080926 16:43:37, Julian Elischer wrote: >>> xorquewasp@googlemail.com wrote: >>>> I'm trying to write a client for the jack audio connection kit >>>> (http://jackaudio.org), have hit an apparent bug and am not sure >>> >>> what revision of FreeBSD? >> >> Ahem, should've mentioned that. >> >> FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 >> root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > > http://www.freebsd.org/releases/6.3R/errata.html > http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc I wonder if I'm missing something: $ sudo freebsd-update fetch Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 6.3-RELEASE-p4. I appear to have that update but the problem persists. -- xw From deischen at freebsd.org Sat Sep 27 05:06:24 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Sat Sep 27 05:06:30 2008 Subject: popen() in multithreaded program - hangs? In-Reply-To: <20080927021709.GB60860@logik.internal.network> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> Message-ID: On Sat, 27 Sep 2008, xorquewasp@googlemail.com wrote: > On 20080926 21:43:48, Daniel Eischen wrote: >> On Sat, 27 Sep 2008, xorquewasp@googlemail.com wrote: >> >>> On 20080926 16:43:37, Julian Elischer wrote: >>>> xorquewasp@googlemail.com wrote: >>>>> I'm trying to write a client for the jack audio connection kit >>>>> (http://jackaudio.org), have hit an apparent bug and am not sure >>>> >>>> what revision of FreeBSD? >>> >>> Ahem, should've mentioned that. >>> >>> FreeBSD 6.3-RELEASE-p1 #0: Wed Feb 13 02:40:56 UTC 2008 >>> root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >> >> http://www.freebsd.org/releases/6.3R/errata.html >> http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc > > I wonder if I'm missing something: > > $ sudo freebsd-update fetch > Looking up update.FreeBSD.org mirrors... 1 mirrors found. > Fetching metadata signature for 6.3-RELEASE from update1.FreeBSD.org... done. > Fetching metadata index... done. > Inspecting system... done. > Preparing to download files... done. > > No updates needed to update system to 6.3-RELEASE-p4. > > I appear to have that update but the problem persists. It's not security related, so I don't know whether it would be in a binary update. You should follow the procedure listed in the links above. -- DE From xorquewasp at googlemail.com Sat Sep 27 06:52:32 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Sep 27 06:52:39 2008 Subject: freebsd-update missed? (was: popen() in multithreaded program - hangs?) In-Reply-To: References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> Message-ID: <20080927065227.GB4416@logik.internal.network> On 20080927 01:06:22, Daniel Eischen wrote: > > It's not security related, so I don't know whether it would be in a > binary update. You should follow the procedure listed in the links > above. I'm not sure either. In every description I see of freebsd-update, there's a claim that it installs "binary security and errata updates". I only use freebsd-update to update my machines and I was under the impression that I've been getting errata updates too. Could this have been missed on the system used to build updates? I'd be surprised, but you know, these things happen. I've CCd in cperciva@ to see what he thinks... -- xw From julian at elischer.org Sat Sep 27 07:07:59 2008 From: julian at elischer.org (Julian Elischer) Date: Sat Sep 27 07:08:06 2008 Subject: freebsd-update missed? In-Reply-To: <20080927065227.GB4416@logik.internal.network> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> Message-ID: <48DDDBCD.40708@elischer.org> xorquewasp@googlemail.com wrote: > On 20080927 01:06:22, Daniel Eischen wrote: >> It's not security related, so I don't know whether it would be in a >> binary update. You should follow the procedure listed in the links >> above. > > I'm not sure either. In every description I see of freebsd-update, > there's a claim that it installs "binary security and errata updates". > > I only use freebsd-update to update my machines and I was under the > impression that I've been getting errata updates too. > > Could this have been missed on the system used to build updates? > I'd be surprised, but you know, these things happen. > > I've CCd in cperciva@ to see what he thinks... > > -- > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" I'm sure it's there.. it may be a different problem of course. From danny at cs.huji.ac.il Sat Sep 27 07:20:40 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Sep 27 07:20:54 2008 Subject: bad NFS/UDP performance In-Reply-To: <200809261818.m8QII6jF004333@apollo.backplane.com> References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> <20080926143153.GA26978@icarus.home.lan> <200809261818.m8QII6jF004333@apollo.backplane.com> Message-ID: > > :> -vfs.nfs.realign_test: 22141777 > :> +vfs.nfs.realign_test: 498351 > :> > :> -vfs.nfsrv.realign_test: 5005908 > :> +vfs.nfsrv.realign_test: 0 > :> > :> +vfs.nfsrv.commit_miss: 0 > :> +vfs.nfsrv.commit_blks: 0 > :> > :> changing them did nothing - or at least with respect to nfs throughput :-) > : > :I'm not sure what any of these do, as NFS is a bit out of my league. > ::-) I'll be following this thread though! > : > :-- > :| Jeremy Chadwick jdc at parodius.com | > > A non-zero nfs_realign_count is bad, it means NFS had to copy the > mbuf chain to fix the alignment. nfs_realign_test is just the > number of times it checked. So nfs_realign_test is irrelevant. > it's nfs_realign_count that matters. > it's zero, so I guess I'm ok there. funny though, on my 'good' machine, vfs.nfsrv.realign_test: 5862999 and on the slow one, it's 0 - but then again the good one has been up for several days. > Several things can cause NFS payloads to be improperly aligned. > Anything from older network drivers which can't start DMA on a > 2-byte boundary, resulting in the 14-byte encapsulation header > causing improper alignment of the IP header & payload, to rpc > embedded in NFS TCP streams winding up being misaligned. > > Modern network hardware either support 2-byte-aligned DMA, allowing > the encapsulation to be 2-byte aligned so the payload winds up being > 4-byte aligned, or support DMA chaining allowing the payload to be > placed in its own mbuf, or pad, etc. > > -- > > One thing I would check is to be sure a couple of nfsiod's are running > on the client when doing your tests. If none are running the RPCs wind > up being more synchronous and less pipelined. Another thing I would > check is IP fragment reassembly statistics (for UDP) - there should be > none for TCP connections no matter what the NFS I/O size selected. > ahh, nfsiod, it seems that it's now dynamicaly started! at least none show when host is idle, after i run my tests there are 20! with ppid 0 need to refresh my NFS knowledge. how can I see the IP fragment reassembly statistics? > (It does seem more likely to be scheduler-related, though). > tend to agree, I tried bith ULE/BSD, but the badness is there. > -Matt > thanks, danny From dillon at apollo.backplane.com Sat Sep 27 07:23:50 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Sat Sep 27 07:24:02 2008 Subject: bad NFS/UDP performance References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> <20080926143153.GA26978@icarus.home.lan> <200809261818.m8QII6jF004333@apollo.backplane.com> Message-ID: <200809270723.m8R7NeEv009152@apollo.backplane.com> :how can I see the IP fragment reassembly statistics? : :thanks, : danny netstat -s Also look for unexpected dropped packets, dropped fragments, and errors during the test and such, they are counted in the statistics as well. -Matt Matthew Dillon From danny at cs.huji.ac.il Sat Sep 27 08:12:41 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Sep 27 08:12:53 2008 Subject: bad NFS/UDP performance In-Reply-To: <20080926221700.1C4AE4500E@ptavv.es.net> References: <20080926221700.1C4AE4500E@ptavv.es.net> Message-ID: > --==_Exmh_1222467420_5817P > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > David, > > You beat me to it. > > Danny, read the iperf man page: > -b, --bandwidth n[KM] > set target bandwidth to n bits/sec (default 1 Mbit/sec). This > setting requires UDP (-u). > > The page needs updating, though. It should read "-b, --bandwidth > n[KMG]. It also does NOT require -u. If you use -b, UDP is assumed. I did RTFM(*), but when i tried it just wouldn't work, I tried today and it's actually working - so don't RTFM before coffee! btw, even though iperf sucks, netperf udp tends to bring the server down to it's knees. danny PS: * - i don't seem to have the iperf man, all I have is iperf -h From xorquewasp at googlemail.com Sat Sep 27 09:17:37 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Sep 27 09:17:44 2008 Subject: freebsd-update missed? In-Reply-To: <48DDDBCD.40708@elischer.org> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> <48DDDBCD.40708@elischer.org> Message-ID: <20080927091733.GA98052@logik.internal.network> On 20080927 00:07:57, Julian Elischer wrote: > I'm sure it's there.. > it may be a different problem of course. > I don't know... Checking with ident gives: $FreeBSD: src/lib/libpthread/thread/thr_kern.c,v 1.116.2.1 2006/03/16 23:29:07 deischen Exp $ The patch claims "1.116.2.1.6.1" Are these the same revisions? I mean, if I can determine that I definitely have the patch, then I have another problem to worry about! From bipolor at gmail.com Sat Sep 27 10:15:16 2008 From: bipolor at gmail.com (Mike Price) Date: Sat Sep 27 10:15:23 2008 Subject: SSH Tunneling All TCP Traffic Message-ID: I need to tunnel all of my TCP SSH-2 traffic from my local box to my remote box that I will have an account on. I heard this can be done in one command? ssh -f me@lab.com -L 8888:lab.com:53 -N SOCKS: 8888 SSH2: 53 What am I doing wrong? From rwatson at FreeBSD.org Sat Sep 27 10:16:00 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Sat Sep 27 10:16:06 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: On Fri, 26 Sep 2008, Danny Braniss wrote: > after more testing, it seems it's related to changes made between Aug 4 and > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try > and close the gap. I think this is the best way forward -- skimming August changes, there are a number of candidate commits, including retuning of UDP hashes by mav, my rwlock changes, changes to mbuf chain handling, etc. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From mohacsi at niif.hu Sat Sep 27 10:34:59 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Sat Sep 27 10:35:06 2008 Subject: SSH Tunneling All TCP Traffic In-Reply-To: References: Message-ID: On Sat, 27 Sep 2008, Mike Price wrote: > I need to tunnel all of my TCP SSH-2 traffic from my > local box to my remote box that I will have an account on. I heard this can > be done in one command? > > ssh -f me@lab.com -L 8888:lab.com:53 -N > > SOCKS: 8888 > SSH2: 53 If you want you use SOCKS use -D option instead of individual TCP connection forwading. However you need SOCKS capable client. Regards, Janos Mohacsi > > What am I doing wrong? > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From koitsu at FreeBSD.org Sat Sep 27 10:59:31 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sat Sep 27 10:59:38 2008 Subject: freebsd-update missed? In-Reply-To: <20080927091733.GA98052@logik.internal.network> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> <48DDDBCD.40708@elischer.org> <20080927091733.GA98052@logik.internal.network> Message-ID: <20080927105928.GA49923@icarus.home.lan> On Sat, Sep 27, 2008 at 10:17:33AM +0100, xorquewasp@googlemail.com wrote: > On 20080927 00:07:57, Julian Elischer wrote: > > I'm sure it's there.. > > it may be a different problem of course. > > > > I don't know... Checking with ident gives: > > $FreeBSD: src/lib/libpthread/thread/thr_kern.c,v 1.116.2.1 2006/03/16 23:29:07 deischen Exp $ > > The patch claims "1.116.2.1.6.1" > > Are these the same revisions? > > I mean, if I can determine that I definitely have the patch, then I have another > problem to worry about! The advisory explicitly goes over what files were changed, and what revisions include the fix. The below versions include the fix. If you have older versions, then the answer is no, you do not have the fix. http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc src/UPDATING 1.416.2.37.2.6 src/sys/conf/newvers.sh 1.69.2.15.2.5 src/lib/libpthread/sys/lock.c 1.9.2.1.8.1 src/lib/libpthread/thread/thr_kern.c 1.116.2.1.6.1 These are for CVS tag RELENG_6_3. I do not use freebsd-update. That said: The man page for it states that it's a binary updater for pieces in the base system, so you looking at your *source* files would indicate absolutely nothing, other than when you last ran csup to update your /usr/src tree. I do not know of a way to verify if your libpthread library actually contains the fix. We will have to wait for Colin's answer. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From simon at FreeBSD.org Sat Sep 27 11:15:16 2008 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Sat Sep 27 11:15:35 2008 Subject: freebsd-update missed? In-Reply-To: <20080927105928.GA49923@icarus.home.lan> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> <48DDDBCD.40708@elischer.org> <20080927091733.GA98052@logik.internal.network> <20080927105928.GA49923@icarus.home.lan> Message-ID: <20080927111514.GA1107@arthur.nitro.dk> On 2008.09.27 03:59:28 -0700, Jeremy Chadwick wrote: > The advisory explicitly goes over what files were changed, and what > revisions include the fix. The below versions include the fix. If you > have older versions, then the answer is no, you do not have the fix. > > http://security.freebsd.org/advisories/FreeBSD-EN-08:01.libpthread.asc > > src/UPDATING 1.416.2.37.2.6 > src/sys/conf/newvers.sh 1.69.2.15.2.5 > src/lib/libpthread/sys/lock.c 1.9.2.1.8.1 > src/lib/libpthread/thread/thr_kern.c 1.116.2.1.6.1 > > These are for CVS tag RELENG_6_3. > > I do not use freebsd-update. That said: > > The man page for it states that it's a binary updater for pieces in the > base system, so you looking at your *source* files would indicate > absolutely nothing, other than when you last ran csup to update your > /usr/src tree. > > I do not know of a way to verify if your libpthread library actually > contains the fix. We will have to wait for Colin's answer. Errata's are distributed with freebsd-update just like advisories. Since freebsd-update 2 (the one in the base system) /usr/src is also updated if it exists. That said, note that freebsd-update does not get's patches from CVS so $FreeBSD$ unfortunatly isn't updated. I just checked, for 6.3 the patch 'EN-08:01.libpthread' is on the freebsd-update build server. -- Simon L. Nielsen Hat: FreeBSD Deputy Security Officer (IE, one of the people making freebsd-update builds) From xorquewasp at googlemail.com Sat Sep 27 11:17:58 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Sep 27 11:18:09 2008 Subject: freebsd-update missed? In-Reply-To: <20080927105928.GA49923@icarus.home.lan> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> <48DDDBCD.40708@elischer.org> <20080927091733.GA98052@logik.internal.network> <20080927105928.GA49923@icarus.home.lan> Message-ID: <20080927111753.GA32980@logik.internal.network> On 20080927 03:59:28, Jeremy Chadwick wrote: > On Sat, Sep 27, 2008 at 10:17:33AM +0100, xorquewasp@googlemail.com wrote: > > The man page for it states that it's a binary updater for pieces in the > base system, so you looking at your *source* files would indicate > absolutely nothing, other than when you last ran csup to update your > /usr/src tree. > > I do not know of a way to verify if your libpthread library actually > contains the fix. We will have to wait for Colin's answer. For the record, I was using ident (1), which I thought was supposed to give me exactly that: $ ident /usr/lib/libpthread.so /usr/lib/libpthread.so: $FreeBSD: src/lib/libpthread/thread/thr_kern.c,v 1.116.2.1 2006/03/16 23:29:07 deischen Exp $ Perhaps patches don't change this value (seems wrong)? -- xw From xorquewasp at googlemail.com Sat Sep 27 11:23:00 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Sep 27 11:23:07 2008 Subject: freebsd-update missed? In-Reply-To: <20080927111514.GA1107@arthur.nitro.dk> References: <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> <48DDDBCD.40708@elischer.org> <20080927091733.GA98052@logik.internal.network> <20080927105928.GA49923@icarus.home.lan> <20080927111514.GA1107@arthur.nitro.dk> Message-ID: <20080927112255.GB32980@logik.internal.network> On 20080927 13:15:15, Simon L. Nielsen wrote: > Errata's are distributed with freebsd-update just like advisories. > > Since freebsd-update 2 (the one in the base system) /usr/src is also > updated if it exists. That said, note that freebsd-update does not > get's patches from CVS so $FreeBSD$ unfortunatly isn't updated. > > I just checked, for 6.3 the patch 'EN-08:01.libpthread' is on the > freebsd-update build server. So for now, at least, I have to assume that I do have the patched library and the problem is either still occuring for some unknown reason or this is a new issue with the same or at least similar symptoms. I unfortunately don't have access to anything running > 6.3, so I'll need to set up another box with 7.0 to see if the same thing still occurs. From danny at cs.huji.ac.il Sat Sep 27 11:32:57 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Sat Sep 27 11:33:05 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > On Fri, 26 Sep 2008, Danny Braniss wrote: > > > after more testing, it seems it's related to changes made between Aug 4 and > > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try > > and close the gap. > > I think this is the best way forward -- skimming August changes, there are a > number of candidate commits, including retuning of UDP hashes by mav, my > rwlock changes, changes to mbuf chain handling, etc. it more difficult than I expected. for one, the kernel date was missleading, the actual source update is the key, so the window of changes is now 28/July to 19/August. I have the diffs, but nothing yet seems relevant. on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' give the same throughput, which seem to point to UDP changes ... danny From cperciva at freebsd.org Sat Sep 27 11:38:55 2008 From: cperciva at freebsd.org (Colin Percival) Date: Sat Sep 27 11:39:02 2008 Subject: freebsd-update missed? In-Reply-To: <20080927065227.GB4416@logik.internal.network> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> Message-ID: <48DE1B4D.80608@freebsd.org> xorquewasp@googlemail.com wrote: > I've CCd in cperciva@ to see what he thinks... I missed the beginning of this thread, but looking back in the archives... 1. I'm very confident that FreeBSD Update is distributing the updated libpthread.so. 2. If you run ident on the libpthread.so.2 which FreeBSD Update distributes, or look at the src/lib/libpthread/thread/thr_kern.c which FreeBSD Update distributes, you'll see the old 1.116.2.1 RCS number. This is because FreeBSD Update mimics "start with the released source code and then apply the patches which are signed by the FreeBSD Security Officer" without a detour through CVS -- that detour through CVS would be impossible, in fact, since we build the binary updates before doing CVS (oops, SVN) commits. 3. If you want to check that you have the latest libpthread.so for FreeBSD 6.3, `sha256 /lib/libpthread.so.2` on an i386 system should print SHA256 (/lib/libpthread.so.2) = ff3fc6111331d5b64f939117daef176cc5c511362786ed6325a2333848e80573 4. If your system claims to be running 6.3-RELEASE-p1 but says that there are no updates needed to update to 6.3-RELEASE-p4, it probably means that you installed the updated kernel which came with 6.3-RELEASE-p4 but you haven't rebooted yet. Colin Percival From xorquewasp at googlemail.com Sat Sep 27 12:01:43 2008 From: xorquewasp at googlemail.com (xorquewasp@googlemail.com) Date: Sat Sep 27 12:01:49 2008 Subject: freebsd-update missed? In-Reply-To: <48DE1B4D.80608@freebsd.org> References: <20080926222711.GA74003@logik.internal.network> <48DD73A9.5000505@elischer.org> <20080926234727.GA60860@logik.internal.network> <20080927021709.GB60860@logik.internal.network> <20080927065227.GB4416@logik.internal.network> <48DE1B4D.80608@freebsd.org> Message-ID: <20080927120137.GA1128@logik.internal.network> On 20080927 04:38:53, Colin Percival wrote: > I missed the beginning of this thread, but looking back in the archives... > > 1. I'm very confident that FreeBSD Update is distributing the updated > libpthread.so. Right. > 2. If you run ident on the libpthread.so.2 which FreeBSD Update distributes, > or look at the src/lib/libpthread/thread/thr_kern.c which FreeBSD Update > distributes, you'll see the old 1.116.2.1 RCS number. This is because > FreeBSD Update mimics "start with the released source code and then apply > the patches which are signed by the FreeBSD Security Officer" without a > detour through CVS -- that detour through CVS would be impossible, in fact, > since we build the binary updates before doing CVS (oops, SVN) commits. Ok! > 3. If you want to check that you have the latest libpthread.so for FreeBSD > 6.3, `sha256 /lib/libpthread.so.2` on an i386 system should print > SHA256 (/lib/libpthread.so.2) = > ff3fc6111331d5b64f939117daef176cc5c511362786ed6325a2333848e80573 Yes, seems I have the patched version. > 4. If your system claims to be running 6.3-RELEASE-p1 but says that there > are no updates needed to update to 6.3-RELEASE-p4, it probably means that > you installed the updated kernel which came with 6.3-RELEASE-p4 but you > haven't rebooted yet. That seems pretty likely. I tend to reboot on power outages when the UPS doesn't hold out... Thanks for this info. -- xw From rik at inse.ru Sat Sep 27 16:40:22 2008 From: rik at inse.ru (Roman Kurakin) Date: Sat Sep 27 16:40:35 2008 Subject: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages In-Reply-To: References: Message-ID: <48DE5CC0.9000708@localhost.inse.ru> Have you also posted this to ports@? rik Eygene Ryabinkin wrote: > Good day. > > A while ago I had created the new utility that serves as VuXML > filter for the installed packages: > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853 > > My primary intention was to speed up the process of auditing the > vulnerable ports: I needed to run portaudit checks with Nagios and to > avoid large timeouts. > > The new utility is called pkg_audit and it serves as a simple text > filter: on input it takes the full VuXML feed and on output it puts > VuXML entries that matches ports that are installed in the system with > port version specification substituted with the actual port versions. > > No harm is done to the actual poartudit -- if pkg_audit is missing, old > code path is activated. > > If someone is interested and will be able to test -- I am all ears. > > Thanks! > From dart at es.net Sat Sep 27 18:52:29 2008 From: dart at es.net (Eli Dart) Date: Sat Sep 27 19:03:49 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: <48DE7E76.8050209@es.net> Danny Braniss wrote: > I know, but I get about 1mgb, which seems somewhat low :-( If you don't tell iperf how much bandwidth to use for a UDP test, it defaults to 1Mbps. See -b option. http://dast.nlanr.net/projects/Iperf/iperfdocs_1.7.0.php#bandwidth --eli -- Eli Dart ESnet Network Engineering Group Lawrence Berkeley National Laboratory PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3 From aryeh.friedman at gmail.com Sat Sep 27 23:52:38 2008 From: aryeh.friedman at gmail.com (Aryeh M. Friedman) Date: Sat Sep 27 23:52:45 2008 Subject: Increasing partition size by removing partitions Message-ID: <48DEC02C.90302@gmail.com> I have a disk that is laid out with partion 0 being NTFS and 1 being FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one but all the docs I have seen only talk about how to do this if the new part of the partition is at the end of the partition you wish to grow. How do I go about this? From koitsu at FreeBSD.org Sun Sep 28 00:18:57 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 00:19:04 2008 Subject: Increasing partition size by removing partitions In-Reply-To: <48DEC02C.90302@gmail.com> References: <48DEC02C.90302@gmail.com> Message-ID: <20080928001855.GA66050@icarus.home.lan> On Sat, Sep 27, 2008 at 07:22:20PM -0400, Aryeh M. Friedman wrote: > I have a disk that is laid out with partion 0 being NTFS and 1 being > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one > but all the docs I have seen only talk about how to do this if the new > part of the partition is at the end of the partition you wish to grow. > How do I go about this? There isn't a way to do this, as far as I know. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bipolor at gmail.com Sun Sep 28 01:45:11 2008 From: bipolor at gmail.com (Mike Price) Date: Sun Sep 28 01:45:18 2008 Subject: Problem Protecting Directories Securly Message-ID: My buddy helped me install Apache Webserver but there is somthing wrong when I try to password protect my directories? I already created '.htaccess' & 'htpasswd' and but I still cannot password protect the directory... I know there is a command to do this 'htpasswd -c .htpasswd' fred but it dosn't work. Please help me... From mkhitrov at gmail.com Sun Sep 28 01:59:14 2008 From: mkhitrov at gmail.com (Maxim Khitrov) Date: Sun Sep 28 01:59:20 2008 Subject: Increasing partition size by removing partitions In-Reply-To: <48DEC02C.90302@gmail.com> References: <48DEC02C.90302@gmail.com> Message-ID: <26ddd1750809271838m414b4214vb726f5e74fd6f8c2@mail.gmail.com> On Sat, Sep 27, 2008 at 7:22 PM, Aryeh M. Friedman wrote: > I have a disk that is laid out with partion 0 being NTFS and 1 being > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one but > all the docs I have seen only talk about how to do this if the new part of > the partition is at the end of the partition you wish to grow. How do I go > about this? Assuming that there is no (free) software that will do it for you, and you are unable for some reason to move the data to another place and repartition the drive, you have to manually move your FreeBSD partition back and then extend it. I've never done this before, but if I had to try it the first time I would do the following: 1. Try very hard to find some other hard drive where I can just dump the data and avoid this whole thing to begin with. :) 2. Boot from a FreeBSD livecd, attach a usb drive for storing some temporary files and mount it under /mnt. 3. Create a back-up of your master boot record (dd if=/dev/ad0 of=/mnt/mbr-backup bs=512 count=1). Assuming here that your drive is ad0. 4. Use fdisk to get the start and size values of your two partitions (in sectors). 5. Erase the ntfs partition (dd if=/dev/zero of=/dev/ad0s1 bs=2m). 6. Copy your FreeBSD partition to the former start location of ntfs (dd if=/dev/ad0 of=/dev/ad0 bs=512 iseek= oseek= count=). Using bs=512 is slow, but it makes it easier for you to just take the numbers that fdisk gives you and plug them in. 7. Once this is done you will need to edit your mbr sector to overwrite the first partition entry with the second, but certain fields will need to be updated... I recommend you use a hex editor and work on the file that you saved in step 3. You can try the same thing with a partition editor, but you may not get the desired results. For the manual (and more fun) method, the partition table begins at offset 0x01BE, and each entry is 16 bytes long. That means that you need to copy 16 bytes starting at address 0x01CE to address 0x01BE. However, before you do this, you need to set the correct values for cylinder-head-sector of first and last sectors in the FreeBSD partition, as well as the logical address of the first sector. First, take 3 bytes starting at address 0x01BF and copy them to 0x01CF. This takes care of CHS start, which is unchanged. Next, take 4 bytes at address 0x01C6 and copy them to 0x01D6. This is the logical sector start. The tricky bit is the CHS last sector value. If your two partitions were of identical size, then you can copy 3 bytes from 0x01C3 to 0x01D3. Otherwise, you'll need to calculate the new values by hand. If your NTFS partition was marked as active before, then set byte 0x01CE to be 0x80. One this is done, copy that second record over the first and zero-out the 16 bytes at 0x01CE. Use dd again to copy the updated mbr sector to your drive. At this point your master boot record will have the correct entry for your FreeBSD partition, which was moved over the NTFS one. See if you can mount /dev/ad0s1a while still in the livecd environment (actually, you will need to reboot first). If ad0s1a is under /dev and you can mount it, then your mbr is fine. Use growfs from here and then boot from the hard drive. As you can see, it's not a trivial thing to do, but it's possible if you are careful. Once again, I've never done this and am basing the whole thing on some of my previous experience in messing with the master boot record. There may be some other things that I missed. I also don't know if there is existing software that might make this whole process much easier, the directions here are a worst-case scenario for moving your partition by hand. - Max From perryh at pluto.rain.com Sun Sep 28 06:32:45 2008 From: perryh at pluto.rain.com (perryh@pluto.rain.com) Date: Sun Sep 28 06:32:51 2008 Subject: Increasing partition size by removing partitions In-Reply-To: <48DEC02C.90302@gmail.com> References: <48DEC02C.90302@gmail.com> Message-ID: <48df1df9.VJWOzhYoAET2LZg4%perryh@pluto.rain.com> > I have a disk that is laid out with partion 0 being NTFS and 1 > being FreeBSD. I want to remove the NTFS partition and grow the > FreeBSD one but all the docs I have seen only talk about how to > do this if the new part of the partition is at the end of the > partition you wish to grow. How do I go about this? Partition Commander is aware of *BSD partitions and should be able to do this. (Granted it is payware.) Delete the NTFS partition, move the FreeBSD partition (slice in FreeBSD parlance) to the beginning of the drive, boot into FreeBSD to make sure everything is working, then go ahead with the grow operation as usual. As always, it's highly recommended to make a full backup first. Having done that, it may be easier to reslice the disk as FreeBSD only and then restore the backup. From rea-fbsd at codelabs.ru Sun Sep 28 09:28:38 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Sep 28 09:28:47 2008 Subject: Problem Protecting Directories Securly In-Reply-To: References: Message-ID: Mike, good day. Sat, Sep 27, 2008 at 06:45:11PM -0700, Mike Price wrote: > My buddy helped me install Apache Webserver but there is somthing wrong when > I try to password protect my directories? I already created '.htaccess' & > 'htpasswd' and but I still cannot password protect the directory... I know > there is a command to do this 'htpasswd -c .htpasswd' fred but it dosn't > work. It is certainly not the question for freebsd-hackers, but it should rather go to some Apache-related list, perhaps Apache-hosted lists themselves. See http://httpd.apache.org/userslist.html And try not to miss the link named "Asking Questions the Smart Way" on the above mentioned page -- it is a good reading. To the point: you can be interested in two links, depending on your Apache version: http://httpd.apache.org/docs/1.3/howto/auth.html http://httpd.apache.org/docs/2.2/howto/auth.html -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080928/0cea09fb/attachment.pgp From rea-fbsd at codelabs.ru Sun Sep 28 09:49:21 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Sep 28 09:49:29 2008 Subject: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages In-Reply-To: <48DE5CC0.9000708@localhost.inse.ru> References: <48DE5CC0.9000708@localhost.inse.ru> Message-ID: Roman, good day. Sat, Sep 27, 2008 at 08:18:08PM +0400, Roman Kurakin wrote: > Have you also posted this to ports@? No, forgot to do it. CC'ing ports@ Thanks! The original posting to hackers@ goes below. It will be double-posted to the bug-followup@ -- sorry for this. > Eygene Ryabinkin wrote: > > Good day. > > > > A while ago I had created the new utility that serves as VuXML > > filter for the installed packages: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853 > > > > My primary intention was to speed up the process of auditing the > > vulnerable ports: I needed to run portaudit checks with Nagios and to > > avoid large timeouts. > > > > The new utility is called pkg_audit and it serves as a simple text > > filter: on input it takes the full VuXML feed and on output it puts > > VuXML entries that matches ports that are installed in the system with > > port version specification substituted with the actual port versions. > > > > No harm is done to the actual poartudit -- if pkg_audit is missing, old > > code path is activated. > > > > If someone is interested and will be able to test -- I am all ears. Additional clarifications inspired by the off-line talk with rik@: I could take another route and add this functionality to the pkg_info. I took another approach for the following reasons. 1. pkg_info's option list is already quite big -- around 32 options and switches. 2. It is easier to test for the presence of the new tool (pkg_audit) and use it, instead of checking the support for the new option in pkg_info. 3. I see no options in pkg_info that can be naturally extended to absorbe the new functionality. The closest is '-E', but pkg_audit needs to read VuXML entries, choose ones that are present in the system and output the found VuXML entries with version templates substituted with the real entries, so pkg_audit is filter-like utility. In my opinion, such extension of pkg_info's "-E" will be very unnatural. 4. I feel that it is Unix-way to do the things: create small utilities that do their (small) job in a proper fashion. Moreover, since the majority of a code sits in the pkg_install's library, there is a very slight code duplication, if any. Thanks for you time. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080928/ae620de5/attachment.pgp From bipolor at gmail.com Sun Sep 28 10:25:56 2008 From: bipolor at gmail.com (Mike Price) Date: Sun Sep 28 10:26:03 2008 Subject: FreeBSD SSH XP Tunneling Message-ID: I am looking for a FreeBSD SSH command-line command that will forward all TCP/UDP traffic through port: 53. Then I need a plink or Cygwin MS-DOS command to tunnel all my XP traffic. please help... From disintx at autistici.org Sun Sep 28 11:30:27 2008 From: disintx at autistici.org (disintx) Date: Sun Sep 28 11:30:33 2008 Subject: FreeBSD SSH XP Tunneling In-Reply-To: References: Message-ID: <48DF644B.5010807@autistici.org> Mike Price wrote: > I am looking for a FreeBSD SSH command-line command that will forward all > TCP/UDP traffic through port: 53. > Then I need a plink or Cygwin MS-DOS command to tunnel all my XP traffic. > > please help... freebsd: ssh -D 53 user@host Cygwin...I would imagine it would be the exact same assuming you have ssh on the base install. From ken at hercules.mthelicon.com Sun Sep 28 10:44:00 2008 From: ken at hercules.mthelicon.com (Pegasus McCleaft) Date: Sun Sep 28 11:39:40 2008 Subject: atacontrol broken in 7.1-PR Message-ID: <20080928103937.U51561@hercules.mthelicon.com> Hello everyone. I was wondering if anyone else is experiencing this problem. I have recently reloaded my machine (due to a meltdown of my primary boot drive) and noticed that under 7.0-rel the atacontrol command seems to work great, however, under 7.1 I get and error atacontrol: ioctl(IOCATADEVICES): Device not configured Has anyone else seen this error. I wouldent be conserned if it wasent for the fact that it worked under 7.0-rel but now dosent. The machine is using both the: atapci0: atapci1: Thanks in advance, Peg From 000.fbsd at quip.cz Sun Sep 28 11:33:52 2008 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Sun Sep 28 11:45:18 2008 Subject: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages In-Reply-To: References: <48DE5CC0.9000708@localhost.inse.ru> Message-ID: <48DF6735.4030906@quip.cz> Eygene Ryabinkin wrote: > Roman, good day. > > Sat, Sep 27, 2008 at 08:18:08PM +0400, Roman Kurakin wrote: > >>Have you also posted this to ports@? > > > No, forgot to do it. CC'ing ports@ > > Thanks! > > The original posting to hackers@ goes below. It will be double-posted > to the bug-followup@ -- sorry for this. > > >>Eygene Ryabinkin wrote: >> >>>Good day. >>> >>>A while ago I had created the new utility that serves as VuXML >>>filter for the installed packages: >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/126853 >>> >>>My primary intention was to speed up the process of auditing the >>>vulnerable ports: I needed to run portaudit checks with Nagios and to >>>avoid large timeouts. >>> >>>The new utility is called pkg_audit and it serves as a simple text >>>filter: on input it takes the full VuXML feed and on output it puts >>>VuXML entries that matches ports that are installed in the system with >>>port version specification substituted with the actual port versions. >>> >>>No harm is done to the actual poartudit -- if pkg_audit is missing, old >>>code path is activated. >>> >>>If someone is interested and will be able to test -- I am all ears. > > > Additional clarifications inspired by the off-line talk with rik@: > I could take another route and add this functionality to the pkg_info. > I took another approach for the following reasons. > > 1. pkg_info's option list is already quite big -- around 32 options > and switches. > > 2. It is easier to test for the presence of the new tool (pkg_audit) > and use it, instead of checking the support for the new option in > pkg_info. > > 3. I see no options in pkg_info that can be naturally extended to > absorbe the new functionality. The closest is '-E', but pkg_audit > needs to read VuXML entries, choose ones that are present in the system > and output the found VuXML entries with version templates substituted > with the real entries, so pkg_audit is filter-like utility. In my > opinion, such extension of pkg_info's "-E" will be very unnatural. > > 4. I feel that it is Unix-way to do the things: create small utilities > that do their (small) job in a proper fashion. Moreover, since the > majority of a code sits in the pkg_install's library, there is a very > slight code duplication, if any. Is there any possibility to cooperate portaudit / pkg_audit with pkg_version to show vulnerable package with information if newer (not vulnerable) package (or port) version is available for upgrade to? If I read nightly security e-mail with for example 4 vulnerable packages, then I need to log in to server and manualy try, if newer (fixed) packages are available. It seems not so hard to check output of `pkg_version -vIL =` and compare both versions (installed and available) with portaudit in some shellscript, I didn't start to write it yet ;). Miroslav Lachman From rea-fbsd at codelabs.ru Sun Sep 28 12:14:28 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Sep 28 12:14:40 2008 Subject: ports/126853: ports-mgmt/portaudit: speed up audit of installed packages In-Reply-To: <48DF6735.4030906@quip.cz> References: <48DE5CC0.9000708@localhost.inse.ru> <48DF6735.4030906@quip.cz> Message-ID: <4bESZpNwE3z/DdlE2fwK/BXzQSo@2MQ0uKCiT7mdMUuLeUzs8Nv3ToQ> Miroslav, good day. Sun, Sep 28, 2008 at 01:15:01PM +0200, Miroslav Lachman wrote: > Is there any possibility to cooperate portaudit / pkg_audit with > pkg_version to show vulnerable package with information if newer (not > vulnerable) package (or port) version is available for upgrade to? > > If I read nightly security e-mail with for example 4 vulnerable > packages, then I need to log in to server and manualy try, if newer > (fixed) packages are available. It seems not so hard to check output of > `pkg_version -vIL =` and compare both versions (installed and available) > with portaudit in some shellscript, I didn't start to write it yet ;). I think it won't be very hard: I'll try to see how to extend portaudit with such functionality -- it would be very handy, in my opinion. Hadn't you have a chance to test my patch? Thanks! -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080928/0f23306a/attachment.pgp From fb-hackers at psconsult.nl Sun Sep 28 13:09:13 2008 From: fb-hackers at psconsult.nl (Paul Schenkeveld) Date: Sun Sep 28 13:09:20 2008 Subject: Increasing partition size by removing partitions In-Reply-To: <48DEC02C.90302@gmail.com> References: <48DEC02C.90302@gmail.com> Message-ID: <20080928124940.GA89922@psconsult.nl> On Sat, Sep 27, 2008 at 07:22:20PM -0400, Aryeh M. Friedman wrote: > I have a disk that is laid out with partion 0 being NTFS and 1 being > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one but > all the docs I have seen only talk about how to do this if the new part of > the partition is at the end of the partition you wish to grow. How do I > go about this? For clarity, let's use the FreeBSD terminology and call these slices, one NTFS slice and one FreeBSD slice. Partitions are what go in the FreeBSD slice (your root, swap, var and usr aprtitions). Do you really need one big FreeBSD slice? You could remove the NTFS slice and create another FreeBSD slice in that place. To make things workable, be sure to have a standard FreeBSD boot manager in the MBR block by doing something like: # fdisk -B -b /boot/boot0 ad0 Then you can create a disklabel in the new slice holding one or more FreeBSD partitions. Next newfs them and add them to /etc/fstab and mount them. All these steps could be done from the Configure submenu of sysinstall if you're not familiar with the fdisk, bsdlabel and newfs commands. The very brave among us could copy the existing FreeBSD partitions from slice 2 to slice 1, enlarging them if needed and using fdisk and bsdlabel to combine the two slices into one, all depending on the size of the slices. The big issue here is to be aware not to overwrite anything before copying it into its final place. Regards, Paul Schenkeveld From koitsu at FreeBSD.org Sun Sep 28 20:42:43 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 20:42:50 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928103937.U51561@hercules.mthelicon.com> References: <20080928103937.U51561@hercules.mthelicon.com> Message-ID: <20080928204241.GA88408@icarus.home.lan> On Sun, Sep 28, 2008 at 10:43:58AM +0000, Pegasus McCleaft wrote: > I was wondering if anyone else is experiencing this problem. I have > recently reloaded my machine (due to a meltdown of my primary boot > drive) and noticed that under 7.0-rel the atacontrol command seems to > work great, however, under 7.1 I get and error > > atacontrol: ioctl(IOCATADEVICES): Device not configured What arguments did you give atacontrol? > Has anyone else seen this error. I wouldent be conserned if it wasent > for the fact that it worked under 7.0-rel but now dosent. The machine is > using both the: > > atapci0: > atapci1: atapci is just the PCI portion, and doesn't show any sign of the ATA driver being attached. Do you have ataX (e.g. ata0) devices showing up in dmesg? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ken at mthelicon.com Sun Sep 28 22:10:27 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Sun Sep 28 22:10:33 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928204241.GA88408@icarus.home.lan> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928204241.GA88408@icarus.home.lan> Message-ID: <200809282232.49053.ken@mthelicon.com> On Sunday 28 September 2008 21:42:41 Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 10:43:58AM +0000, Pegasus McCleaft wrote: > > I was wondering if anyone else is experiencing this problem. I have > > recently reloaded my machine (due to a meltdown of my primary boot > > drive) and noticed that under 7.0-rel the atacontrol command seems to > > work great, however, under 7.1 I get and error > > > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > What arguments did you give atacontrol? Sorry, forgot to add that in. I was typing from a terminal window while xorg was rebuilding. Perhapse some more usefull information to follow :> feathers# atacontrol list atacontrol: ioctl(IOCATADEVICES): Device not configured > > > Has anyone else seen this error. I wouldent be conserned if it wasent > > for the fact that it worked under 7.0-rel but now dosent. The machine is > > using both the: > > > > atapci0: > > atapci1: > > atapci is just the PCI portion, and doesn't show any sign of the ATA > driver being attached. Do you have ataX (e.g. ata0) devices showing > up in dmesg? Yea.. The machine is otherwise running fine, and also loaded the driver for the ata raid controller (I made the machine boot off a raid-1 pack and made slices on the pack for /, /usr, /var . The rest zfs for /usr/home) Thinking about it, I also added atapicd in the kernel config so I could use things like K3B and xcdroast.. I dont know if maybe that shim might be causing issues. I'll try making another kernel without it and giving that a try. feathers# dmesg | grep ata atapci0: port 0x9000-0x907f mem 0xe7004000-0xe700407f,0xe7000000-0xe7003fff irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: mem 0xec100000-0xec101fff irq 19 at device 0.0 on pci5 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI Version 01.00 controller with 2 ports detected ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] atapci2: port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 16 at device 0.1 on pci5 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] atapci3: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xec406000-0xec4067ff irq 19 at device 31.2 on pci0 atapci3: [ITHREAD] atapci3: AHCI Version 01.20 controller with 6 ports detected ata7: on atapci3 ata7: [ITHREAD] ata8: on atapci3 ata8: [ITHREAD] ata9: on atapci3 ata9: [ITHREAD] ata10: on atapci3 ata10: [ITHREAD] ata11: on atapci3 ata11: [ITHREAD] ata12: on atapci3 ata12: [ITHREAD] acd0: DVDR at ata3-master SATA150 ad8: 476940MB at ata4-master SATA300 ad10: 476940MB at ata5-master SATA300 ad14: 476938MB at ata7-master SATA300 ad16: 476940MB at ata8-master SATA300 ad18: 476940MB at ata9-master SATA300 ad20: 476940MB at ata10-master SATA300 ad22: 476940MB at ata11-master SATA300 ad24: 476940MB at ata12-master SATA300 ar0: disk0 READY (master) using ad8 at ata4-master ar0: disk1 READY (mirror) using ad10 at ata5-master cd0 at ata1 bus 0 target 0 lun 0 From bruce at cran.org.uk Sun Sep 28 22:25:10 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Sun Sep 28 22:25:17 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928103937.U51561@hercules.mthelicon.com> References: <20080928103937.U51561@hercules.mthelicon.com> Message-ID: <20080928232438.5d0c4a55@tau.draftnet> On Sun, 28 Sep 2008 10:43:58 +0000 (UTC) Pegasus McCleaft wrote: > Hello everyone. > > I was wondering if anyone else is experiencing this problem. > I have recently reloaded my machine (due to a meltdown of my primary > boot drive) and noticed that under 7.0-rel the atacontrol command > seems to work great, however, under 7.1 I get and error > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > Has anyone else seen this error. I wouldent be conserned if > it wasent for the fact that it worked under 7.0-rel but now dosent. > The machine is using both the: > > atapci0: > atapci1: I'm also seeing this problem on my amd64 7.1-PRERELEASE system: > atacontrol list ATA channel 0: Master: acd0 ATA/ATAPI revision 5 Slave: no device present atacontrol: ioctl(IOCATADEVICES): Device not configured I've attached the dmesg, and truss output from "atacontrol list". -- Bruce Cran -------------- next part -------------- __sysctl(0x7fffffffe8b0,0x2,0x7fffffffe8cc,0x7fffffffe8c0,0x0,0x0) = 0 (0x0) mmap(0x0,576,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365149184 (0x800529000) munmap(0x800529000,576) = 0 (0x0) __sysctl(0x7fffffffe920,0x2,0x800630fc8,0x7fffffffe918,0x0,0x0) = 0 (0x0) mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34365149184 (0x800529000) issetugid(0x80052a015,0x800524869,0x800634910,0x8006348e0,0x57ac,0x7fffffffe918) = 0 (0x0) open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or directory' open("/var/run/ld-elf.so.hints",O_RDONLY,057) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\M^\\0\0"...,128) = 128 (0x80) lseek(3,0x80,SEEK_SET) = 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,156) = 156 (0x9c) close(3) = 0 (0x0) access("/lib/libc.so.7",0) = 0 (0x0) open("/lib/libc.so.7",O_RDONLY,030607240) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=17511,size=1174560,blksize=4096 }) = 0 (0x0) read(3,"\^?ELF\^B\^A\^A\t\0\0\0\0\0\0\0"...,4096) = 4096 (0x1000) mmap(0x0,2240512,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,3,0x0) = 34366246912 (0x800635000) mprotect(0x800724000,4096,PROT_READ|PROT_WRITE|PROT_EXEC) = 0 (0x0) mprotect(0x800724000,4096,PROT_READ|PROT_EXEC) = 0 (0x0) mmap(0x800824000,118784,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xef000) = 34368274432 (0x800824000) mmap(0x800841000,94208,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34368393216 (0x800841000) close(3) = 0 (0x0) sysarch(0x81,0x7fffffffe9a0,0x80052e088,0x0,0xffffffffffd03650,0x7fffffffe6f8) = 0 (0x0) mmap(0x0,384,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365181952 (0x800531000) munmap(0x800531000,384) = 0 (0x0) mmap(0x0,42096,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 34365181952 (0x800531000) munmap(0x800531000,42096) = 0 (0x0) __sysctl(0x7fffffffe950,0x2,0x800841ae0,0x7fffffffe948,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) open("/dev/ata",O_RDWR,037777766320) = 3 (0x3) ioctl(3,IOCATAGMAXCHANNEL,0xffffec20) = 0 (0x0) ioctl(3,IOCATADEVICES,0xffffe590) = 0 (0x0) fstat(1,{ mode=-rw-r--r-- ,inode=307828,size=2281,blksize=4096 }) = 0 (0x0) __sysctl(0x7fffffffdba0,0x2,0x800845b48,0x7fffffffdbb8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd6f0,0x2,0x8008547d8,0x7fffffffd6e8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd730,0x2,0x7fffffffd74c,0x7fffffffd740,0x0,0x0) = 0 (0x0) readlink("/etc/malloc.conf",0x7fffffffd790,1024) ERR#2 'No such file or directory' issetugid(0x80071c2aa,0x7fffffffd790,0xffffffffffffffff,0x0,0xffffffff80ac1c40,0x7fffffffd768) = 0 (0x0) break(0x600000) = 0 (0x0) break(0x700000) = 0 (0x0) ioctl(3,IOCATADEVICES,0xffffe590) ERR#6 'Device not configured' atacontrol: write(2,"atacontrol: ",12) = 12 (0xc) ioctl(IOCATADEVICES)write(2,"ioctl(IOCATADEVICES)",20) = 20 (0x14) : write(2,": ",2) = 2 (0x2) Device not configured write(2,"Device not configured\n",22) = 22 (0x16) ATA channel 0: Master: acd0 ATA/ATAPI revision 5 Slave: no device present write(1,"ATA channel 0:\n Master: acd0"...,122) = 122 (0x7a) process exit, rval = 1 -------------- next part -------------- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Fri Sep 12 22:23:24 BST 2008 brucec@tau.draftnet:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-52 (1600.06-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 usable memory = 2065436672 (1969 MB) avail memory = 1992933376 (1900 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported acpi0: reservation of 0, 1000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xd4000000-0xd7ffffff,0xd0100000-0xd010ffff irq 17 at device 5.0 on pci1 pcib2: at device 5.0 on pci0 pci2: on pcib2 pcib3: at device 6.0 on pci0 pci5: on pcib3 pci5: at device 0.0 (no driver attached) atapci0: port 0x8438-0x843f,0x8454-0x8457,0x8430-0x8437,0x8450-0x8453,0x8400-0x840f mem 0xd0004000-0xd00043ff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xd0005000-0xd0005fff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xd0006000-0xd0006fff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xd0007000-0xd0007fff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xd0008000-0xd0008fff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xd0009000-0xd0009fff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xd0004400-0xd00044ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8420-0x842f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pci8: on pcib4 bfe0: mem 0xd0300000-0xd0301fff irq 21 at device 0.0 on pci8 miibus0: on bfe0 bmtphy0: PHY 1 on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:19:b9:54:f0:4a bfe0: [ITHREAD] pci8: at device 1.0 (no driver attached) pci8: at device 1.1 (no driver attached) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_lid0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 orm0: at iomem 0xc0000-0xccfff,0xcd000-0xcdfff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA33 ad4: 114473MB at ata2-master SATA150 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s2a fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 pid 859 (gnome-keyring-daemo), uid 1001: exited on signal 11 (core dumped) umass0: on uhub5 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 239372MB (490234752 512 byte sectors: 255H 63S/T 30515C) From koitsu at FreeBSD.org Sun Sep 28 22:37:11 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 22:37:18 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <200809282232.49053.ken@mthelicon.com> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928204241.GA88408@icarus.home.lan> <200809282232.49053.ken@mthelicon.com> Message-ID: <20080928223709.GA90348@icarus.home.lan> On Sun, Sep 28, 2008 at 10:32:48PM +0100, Pegasus Mc Cleaft wrote: > On Sunday 28 September 2008 21:42:41 Jeremy Chadwick wrote: > > On Sun, Sep 28, 2008 at 10:43:58AM +0000, Pegasus McCleaft wrote: > > > I was wondering if anyone else is experiencing this problem. I have > > > recently reloaded my machine (due to a meltdown of my primary boot > > > drive) and noticed that under 7.0-rel the atacontrol command seems to > > > work great, however, under 7.1 I get and error > > > > > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > > What arguments did you give atacontrol? > > Sorry, forgot to add that in. I was typing from a terminal window while xorg > was rebuilding. Perhapse some more usefull information to follow :> > > feathers# atacontrol list > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > > > > Has anyone else seen this error. I wouldent be conserned if it wasent > > > for the fact that it worked under 7.0-rel but now dosent. The machine is > > > using both the: > > > > > > atapci0: > > > atapci1: > > > > atapci is just the PCI portion, and doesn't show any sign of the ATA > > driver being attached. Do you have ataX (e.g. ata0) devices showing > > up in dmesg? > > Yea.. The machine is otherwise running fine, and also loaded the driver for > the ata raid controller (I made the machine boot off a raid-1 pack and made > slices on the pack for /, /usr, /var . The rest zfs for /usr/home) I don't know what filesystems you have assigned to what drives, but please be aware there are known major problems with Silicon Image controllers on FreeBSD, Linux, and Windows. The most common problem is silent data corruption. I can refer you to previous discussions of this problem if you'd like. If at all possible, disable this controller in the BIOS, and do not use it. JMicron controllers are known to behave OK, but have a history of serious driver problems under Windows. I doubt that'll affect you, but it's something to keep in mind. I see the system has an Intel AHCI-based controller (probably an ICH10 chip, since the ICH10 is the first to support 6 SATA channels). I would recommend using that for as much as you can (I see you have disks ad14 through ad24 off that controller). Just things you should be aware of. > Thinking about it, I also added atapicd in the kernel config so I could use > things like K3B and xcdroast.. I dont know if maybe that shim might be causing > issues. I'll try making another kernel without it and giving that a try. I highly doubt that's the problem. Can you please include your kernel configuration file here? Also, please do not copy/paste the file; I noticed in your dmesg|grep ata output, all of the lines had trailing spaces (I've stripped them off). I've CC'd sos@freebsd.org who maintains ata(4). I see no reason why "atacontrol list" would be returning such an error. > feathers# dmesg | grep ata > atapci0: port 0x9000-0x907f mem > 0xe7004000-0xe700407f,0xe7000000-0xe7003fff irq 16 at device 0.0 on pci3 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > atapci1: mem 0xec100000-0xec101fff irq 19 > at device 0.0 on pci5 > atapci1: [ITHREAD] > atapci1: AHCI called from vendor specific driver > atapci1: AHCI Version 01.00 controller with 2 ports detected > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > atapci2: port > 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 16 > at device 0.1 on pci5 > atapci2: [ITHREAD] > ata6: on atapci2 > ata6: [ITHREAD] > atapci3: port > 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem > 0xec406000-0xec4067ff irq 19 at device 31.2 on pci0 > atapci3: [ITHREAD] > atapci3: AHCI Version 01.20 controller with 6 ports detected > ata7: on atapci3 > ata7: [ITHREAD] > ata8: on atapci3 > ata8: [ITHREAD] > ata9: on atapci3 > ata9: [ITHREAD] > ata10: on atapci3 > ata10: [ITHREAD] > ata11: on atapci3 > ata11: [ITHREAD] > ata12: on atapci3 > ata12: [ITHREAD] > acd0: DVDR at ata3-master SATA150 > ad8: 476940MB at ata4-master SATA300 > ad10: 476940MB at ata5-master SATA300 > ad14: 476938MB at ata7-master SATA300 > ad16: 476940MB at ata8-master SATA300 > ad18: 476940MB at ata9-master SATA300 > ad20: 476940MB at ata10-master SATA300 > ad22: 476940MB at ata11-master SATA300 > ad24: 476940MB at ata12-master SATA300 > ar0: disk0 READY (master) using ad8 at ata4-master > ar0: disk1 READY (mirror) using ad10 at ata5-master > cd0 at ata1 bus 0 target 0 lun 0 -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From ken at mthelicon.com Sun Sep 28 23:23:14 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Sun Sep 28 23:23:22 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928223709.GA90348@icarus.home.lan> References: <20080928103937.U51561@hercules.mthelicon.com> <200809282232.49053.ken@mthelicon.com> <20080928223709.GA90348@icarus.home.lan> Message-ID: <200809290021.42930.ken@mthelicon.com> On Sunday 28 September 2008 23:37:09 Jeremy Chadwick wrote: > > Yea.. The machine is otherwise running fine, and also loaded the driver > > for the ata raid controller (I made the machine boot off a raid-1 pack > > and made slices on the pack for /, /usr, /var . The rest zfs for > > /usr/home) > > I don't know what filesystems you have assigned to what drives, but > please be aware there are known major problems with Silicon Image > controllers on FreeBSD, Linux, and Windows. The most common problem is > silent data corruption. I can refer you to previous discussions of this > problem if you'd like. If at all possible, disable this controller in > the BIOS, and do not use it. I didnt know that, so thanks for telling me. As luck would have it, I just have the DVD-RW drive on the Silicon Image controller. I originally tried to use the SI controller for the primary boot, but the driver support was not there for it with the 7.0 boot disks, so I played with the cables and put the two raid-1 drives on the JMicron controller. It was only after I got a 7.1 kernel installed that it showed back up and I got use of the DVD-Rom drive. > I see the system has an Intel AHCI-based controller (probably an ICH10 > chip, since the ICH10 is the first to support 6 SATA channels). I would > recommend using that for as much as you can (I see you have disks ad14 > through ad24 off that controller). Its actually a ICH9R based motherboard by Gigabyte (GS-X48-DS5). It seems to be a decent board, with the exception of, what I believe to be a hardware fault with the watchdog timer. I think they have put a pull-up resistor on the speaker line on the ICH9 that on release of reset is hardware disabling the watchdog timer function. I have gone round and round with them on this, but I can not adequately explain the problem to there tech-support as there is a language barrier. > > Thinking about it, I also added atapicd in the kernel config so I could > > use things like K3B and xcdroast.. I dont know if maybe that shim might > > be causing issues. I'll try making another kernel without it and giving > > that a try. > > I highly doubt that's the problem. > > Can you please include your kernel configuration file here? > > Also, please do not copy/paste the file; I noticed in your dmesg|grep > ata output, all of the lines had trailing spaces (I've stripped them > off). Sure, I'll attach the config file and also a full dmesg. Forgive the state of the config file.. Its basically a copy of the GENERIC with a bunch of stuff added at the end. > > I've CC'd sos@freebsd.org who maintains ata(4). I see no reason why > "atacontrol list" would be returning such an error. Thank you... I'm not sure why I'm having the problem either. I just thought it was strange that it worked using the GENERIC kernel from 7.0-REL but once I built the latest 7.1-PR it stopped working. My machine (feathers) is actually a sister machine from one I built at work so I could test things out at home and then make changes to the production machine. The other machine does not have the SI controller in it (everything else is the same) and it also will not do the atacontrol list without erroring in the same way. I will hold my hands up and say that it could very well be something I have done in the config file by adding so much 'Stuff' to it.. There could be a conflict there I dont know about.. Thanks again for you time, Peg -------------- next part -------------- # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/FEATHERS,v 1.484.2.7 2008/04/10 22:09:21 rwatson Exp $ cpu HAMMER ident FEATHERS # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options NTFS # NT File System options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI # Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. device amd # AMD 53C974 (Tekram DC-390(T)) device hptiop # Highpoint RocketRaid 3xxx series device isp # Qlogic family #device ispfw # Firmware for QLogic HBAs- normally a module device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # RAID controllers interfaced to the SCSI subsystem device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device ciss # Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options device hptmv # Highpoint RocketRAID 182x device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID device twa # 3ware 9000 series PATA/SATA RAID # RAID controllers device aac # Adaptec FSA RAID device aacp # SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device mfi # LSI MegaRAID SAS device mlx # Mylex DAC960 family #XXX pointer/int warnings #device pst # Promise Supertrak SX6000 device twe # 3ware ATA RAID # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device #device vpo # Requires scbus and da # If you've got a "dumb" serial or parallel PCI card that is # supported by the puc(4) glue driver, uncomment the following # line to enable it (connects to sio, uart and/or ppc drivers): #device puc # PCI Ethernet NICs. options NETGRAPH device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device igb # Intel PRO/1000 PCIE Server Gigabit Family device ixgb # Intel PRO/10GbE Ethernet Card device le # AMD Am7900 LANCE and Am79C9xx PCnet device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device age # Attansic/Atheros L1 Gigabit Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet #device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100 (precedence over 'le') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Wireless NIC cards device wlan # 802.11 support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device wlan_scan_ap # 802.11 AP mode scanning device wlan_scan_sta # 802.11 STA mode scanning device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros pci/cardbus NIC's device ath_hal # Atheros HAL (Hardware Access Layer) device ath_rate_sample # SampleRate tx rate control for ath device awi # BayStack 660 and others device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse device ural # Ralink Technology RT2500USB wireless NICs device urio # Diamond Rio 500 MP3 player device uscanner # Scanners # USB Serial devices device ucom # Generic com ttys device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device ubser # BWCT console serial adapters device uftdi # For FTDI usb serial adapters device uipaq # Some WinCE based devices device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters device uvisor # Visor and Palm devices device uvscom # USB serial support for DDI pocket's PHS # USB Ethernet, requires miibus device aue # ADMtek USB Ethernet device axe # ASIX Electronics USB Ethernet device cdce # Generic USB over Ethernet device cue # CATC USB Ethernet device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) device fwe # Ethernet over FireWire (non-standard!) device fwip # IP over FireWire (RFC 2734,3146) device dcons # Dumb console driver device dcons_crom # Configuration ROM for dcon #device thingies device sound device snd_hda device snd_atiixp device snd_ich #Pega Options #options SW_WATCHDOG options HZ=1000 #device mem device coretemp device atapicam device drm # DRM core module required by DRM drivers #device radeondrm # ATI Radeon device smbus # Bus support, required for smb below. device intpm device alpm device ichsmb device viapm device amdpm device amdsmb device nfpm device nfsmb device smb device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge options IPSEC options IPSEC_FILTERTUNNEL options TCP_SIGNATURE device crypto # core crypto support device cryptodev # /dev/crypto for access to h/w device rndtest # FIPS 140-2 entropy tester device hifn # Hifn 7951, 7781, etc. options HIFN_RNDTEST options GEOM_ELI device ichwd options ACCEPT_FILTER_HTTP # Apache Tuning options ACCEPT_FILTER_DATA # # mchain library. It can be either loaded as KLD or compiled into kernel options LIBMCHAIN # libalias library, performing NAT options LIBALIAS options IPFIREWALL #firewall #options IPFIREWALL_VERBOSE #enable logging to syslogd(8) #options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFIREWALL_FORWARD #packet destination changes options IPFIREWALL_NAT #ipfw kernel nat support options IPDIVERT #divert sockets options IPFILTER #ipfilter support #options IPFILTER_LOG #ipfilter logging options IPFILTER_LOOKUP #ipfilter pools #options IPFILTER_DEFAULT_BLOCK #block all packets by default options IPSTEALTH #support for stealth forwarding #options TCPDEBUG device pf options DUMMYNET -------------- next part -------------- Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #1: Sun Sep 28 18:26:29 BST 2008 ken@feathers.peganest.com:/usr/obj/usr/src/sys/FEATHERS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q9450 @ 2.66GHz (3003.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 8574144512 (8176 MB) avail memory = 8285323264 (7901 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ichwd module loaded ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x8000-0x80ff mem 0xd0000000-0xdfffffff,0xe5000000-0xe500ffff irq 16 at device 0.0 on pci1 pcm0: mem 0xe5010000-0xe5013fff irq 17 at device 0.1 on pci1 pcm0: [ITHREAD] pcib2: irq 16 at device 6.0 on pci0 pci2: on pcib2 uhci0: port 0xe100-0xe11f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe200-0xe21f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe000-0xe01f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xec405000-0xec4053ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered ukbd0: on uhub4 kbd2 at ukbd0 ulpt0: on uhub4 ulpt0: using bi-directional mode uhub5: on uhub4 uhub5: single transaction translator uhub5: 4 ports with 4 removable, self powered ums0: on uhub5 ums0: 3 buttons. pcm1: mem 0xec400000-0xec403fff irq 22 at device 27.0 on pci0 pcm1: [ITHREAD] pcib3: irq 16 at device 28.0 on pci0 pci3: on pcib3 atapci0: port 0x9000-0x907f mem 0xe7004000-0xe700407f,0xe7000000-0xe7003fff irq 16 at device 0.0 on pci3 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 em0: port 0xa000-0xa01f mem 0xe9020000-0xe903ffff,0xe9000000-0xe901ffff irq 18 at device 0.0 on pci4 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1b:21:1c:03:ce pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 atapci1: mem 0xec100000-0xec101fff irq 19 at device 0.0 on pci5 atapci1: [ITHREAD] atapci1: AHCI called from vendor specific driver atapci1: AHCI Version 01.00 controller with 2 ports detected ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] atapci2: port 0xb000-0xb007,0xb100-0xb103,0xb200-0xb207,0xb300-0xb303,0xb400-0xb40f irq 16 at device 0.1 on pci5 atapci2: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] pcib6: irq 16 at device 28.4 on pci0 pci6: on pcib6 re0: port 0xc000-0xc0ff mem 0xec010000-0xec010fff,0xec000000-0xec00ffff irq 16 at device 0.0 on pci6 re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:7d:07:24:1a re0: [FILTER] pcib7: irq 17 at device 28.5 on pci0 pci7: on pcib7 re1: port 0xd000-0xd0ff mem 0xec210000-0xec210fff,0xec200000-0xec20ffff irq 17 at device 0.0 on pci7 re1: Chip rev. 0x3c000000 re1: MAC rev. 0x00200000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:1d:7d:07:24:18 re1: [FILTER] uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub6: on usb4 uhub6: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub7: on usb5 uhub7: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub8: on usb6 uhub8: 2 ports with 2 removable, self powered ehci1: mem 0xec404000-0xec4043ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub9: on usb7 uhub9: 6 ports with 6 removable, self powered pcib8: at device 30.0 on pci0 pci8: on pcib8 hifn0 mem 0xec30f000-0xec30ffff,0xec30c000-0xec30dfff,0xec300000-0xec307fff irq 20 at device 0.0 on pci8 hifn0: [ITHREAD] hifn0: Hifn 7955, rev 0, 32KB dram, pll=0x801 fwohci0: mem 0xec30e000-0xec30e7ff,0xec308000-0xec30bfff irq 18 at device 6.0 on pci8 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:0e:96:1f:00:00:1d:7d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xcf294000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:0e:96:00:1d:7d fwe0: Ethernet address: 02:0e:96:00:1d:7d fwip0: on firewire0 fwip0: Firewire address: 00:0e:96:1f:00:00:1d:7d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci3: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xec406000-0xec4067ff irq 19 at device 31.2 on pci0 atapci3: [ITHREAD] atapci3: AHCI Version 01.20 controller with 6 ports detected ata7: on atapci3 ata7: [ITHREAD] ata8: on atapci3 ata8: [ITHREAD] ata9: on atapci3 ata9: [ITHREAD] ata10: on atapci3 ata10: [ITHREAD] ata11: on atapci3 ata11: [ITHREAD] ata12: on atapci3 ata12: [ITHREAD] ichsmb0: port 0x500-0x51f mem 0xec407000-0xec4070ff irq 18 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082006000820 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082006000820 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082006000820 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082006000820 device_attach: est3 attach returned 6 p4tcc3: on cpu3 cryptosoft0: on motherboard ichwd0: on isa0 ichwd0: ICH WDT present but disabled in BIOS or hardware device_attach: ichwd0 attach returned 6 orm0: at iomem 0xd0000-0xd1fff,0xd2000-0xd4fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ucom0: on uhub7 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. IP Filter: v4.1.28 initialized. Default = pass all, Logging = disabled firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to accept, logging disabled acd0: DVDR at ata3-master SATA150 ad8: 476940MB at ata4-master SATA300 ad10: 476940MB at ata5-master SATA300 ad14: 476938MB at ata7-master SATA300 ad16: 476940MB at ata8-master SATA300 ad18: 476940MB at ata9-master SATA300 ad20: 476940MB at ata10-master SATA300 ad22: 476940MB at ata11-master SATA300 ad24: 476940MB at ata12-master SATA300 pcm0: pcm0: pcm1: pcm1: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 ar0: 476928MB status: READY ar0: disk0 READY (master) using ad8 at ata4-master ar0: disk1 READY (mirror) using ad10 at ata5-master SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! From koitsu at FreeBSD.org Sun Sep 28 23:52:39 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Sep 28 23:52:46 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <200809290021.42930.ken@mthelicon.com> References: <20080928103937.U51561@hercules.mthelicon.com> <200809282232.49053.ken@mthelicon.com> <20080928223709.GA90348@icarus.home.lan> <200809290021.42930.ken@mthelicon.com> Message-ID: <20080928235233.GA91555@icarus.home.lan> On Mon, Sep 29, 2008 at 12:21:42AM +0100, Pegasus Mc Cleaft wrote: > On Sunday 28 September 2008 23:37:09 Jeremy Chadwick wrote: > > > > > Yea.. The machine is otherwise running fine, and also loaded the driver > > > for the ata raid controller (I made the machine boot off a raid-1 pack > > > and made slices on the pack for /, /usr, /var . The rest zfs for > > > /usr/home) > > > > I don't know what filesystems you have assigned to what drives, but > > please be aware there are known major problems with Silicon Image > > controllers on FreeBSD, Linux, and Windows. The most common problem is > > silent data corruption. I can refer you to previous discussions of this > > problem if you'd like. If at all possible, disable this controller in > > the BIOS, and do not use it. > > I didnt know that, so thanks for telling me. As luck would have it, I just > have the DVD-RW drive on the Silicon Image controller. I originally tried to > use the SI controller for the primary boot, but the driver support was not > there for it with the 7.0 boot disks, so I played with the cables and put the > two raid-1 drives on the JMicron controller. It was only after I got a 7.1 > kernel installed that it showed back up and I got use of the DVD-Rom drive. This often happens when a change is made between two versions of FreeBSD but there's no available ISO which contains the drivers/changes which provide the hardware support you need. You might be interested in the snapshots/ directory on the FTP mirrors: ftp://ftp4.freebsd.org/pub/FreeBSD/snapshots/200809/ The allbsd.org site is also quite useful when you need something that's been added in the past few days/weeks, and not within the past month: http://pub.allbsd.org/FreeBSD-snapshots/ > > I see the system has an Intel AHCI-based controller (probably an ICH10 > > chip, since the ICH10 is the first to support 6 SATA channels). I would > > recommend using that for as much as you can (I see you have disks ad14 > > through ad24 off that controller). > > Its actually a ICH9R based motherboard by Gigabyte (GS-X48-DS5). Ahh, right. The ICH9R, ICH9DH, and ICH9DO contain 6 ports, while the ICH9 only provides 4 ports (confirmed in the data sheet). The ICH10 is the first to include 6 ports on the non-RAID version of the chip, that's why I made that assumption. > It seems to be a decent board, with the exception of, what I believe > to be a hardware fault with the watchdog timer. I think they have put > a pull-up resistor on the speaker line on the ICH9 that on release of > reset is hardware disabling the watchdog timer function. I have gone > round and round with them on this, but I can not adequately explain > the problem to there tech-support as there is a language barrier. One has to remember that Gigabyte is predominantly a "consumer" product vendor. Chances of getting through to an engineer are slim; Tier 1 support "shields" customers from engineers -- understandable (you don't want some irate customer wasting engineering's time on something that's simple), but it's also a problem because most T1 folks often lack the ability to make the judgement call as to when they should forward the request. Instead, the (false) conclusion they reach is "This is just some one-off, what a waste of time, /dev/null it". Supermicro is the one company I've had luck with, where their Tier 1 guys understand that certain topics should be forwarded directly to engineers, while other topics remain in T1s hands. > > > Thinking about it, I also added atapicd in the kernel config so I could > > > use things like K3B and xcdroast.. I dont know if maybe that shim might > > > be causing issues. I'll try making another kernel without it and giving > > > that a try. > > > > I highly doubt that's the problem. > > > > Can you please include your kernel configuration file here? > > > > Also, please do not copy/paste the file; I noticed in your dmesg|grep > > ata output, all of the lines had trailing spaces (I've stripped them > > off). > > Sure, I'll attach the config file and also a full dmesg. Forgive the state of > the config file.. Its basically a copy of the GENERIC with a bunch of stuff > added at the end. > > > > I've CC'd sos@freebsd.org who maintains ata(4). I see no reason why > > "atacontrol list" would be returning such an error. > > Thank you... > > I'm not sure why I'm having the problem either. I just thought it was strange > that it worked using the GENERIC kernel from 7.0-REL but once I built the > latest 7.1-PR it stopped working. My machine (feathers) is actually a sister > machine from one I built at work so I could test things out at home and then > make changes to the production machine. The other machine does not have the SI > controller in it (everything else is the same) and it also will not do the > atacontrol list without erroring in the same way. 7.0-RELEASE to 7.1-PRERELEASE is pretty major in terms of changes; there's been a lot. I'd like to blame ata(4), but I don't know of any changes there (and I follow those closely) which might explain this phenomenon. I'm also CC'ing Andrey Elsukov who has some experience dealing with ata(4) and AHCI. He might know of something that could cause this. I'm especially interested now that Bruce Cran reports the exact same problem on completely different hardware. (I myself can't reproduce it on a Supermicro PDSMi+ board running 7.1-PRERELEASE built September 24th). > I will hold my hands up and say that it could very well be something I have > done in the config file by adding so much 'Stuff' to it.. There could be a > conflict there I dont know about.. Okay, so after reviewing your config file, the two pieces which could explain it (that differ from mine) are: 1) use of ATA_STATIC_ID, 2) use of atapicam I'm providing a link to your mail so that Andrey and others can read your kernel config and dmesg output if need be; I'm removing it as quoted material to keep the size of the mails down. http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/026153.html Also, an unrelated tip regarding SMBus, the only devices you'll need are: device smbus device smb device ichsmb The others are superfluous devices (won't apply to your board), unless you really plan on utilising some I2C hardware you have. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon Sep 29 00:02:29 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 29 00:02:36 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928232438.5d0c4a55@tau.draftnet> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> Message-ID: <20080929000226.GA92057@icarus.home.lan> On Sun, Sep 28, 2008 at 11:24:38PM +0100, Bruce Cran wrote: > On Sun, 28 Sep 2008 10:43:58 +0000 (UTC) > Pegasus McCleaft wrote: > > > Hello everyone. > > > > I was wondering if anyone else is experiencing this problem. > > I have recently reloaded my machine (due to a meltdown of my primary > > boot drive) and noticed that under 7.0-rel the atacontrol command > > seems to work great, however, under 7.1 I get and error > > > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > > Has anyone else seen this error. I wouldent be conserned if > > it wasent for the fact that it worked under 7.0-rel but now dosent. > > The machine is using both the: > > > > atapci0: > > atapci1: > > I'm also seeing this problem on my amd64 7.1-PRERELEASE system: > > > atacontrol list > ATA channel 0: > Master: acd0 ATA/ATAPI revision 5 > Slave: no device present > atacontrol: ioctl(IOCATADEVICES): Device not configured > > I've attached the dmesg, and truss output from "atacontrol list". Your dmesg output implies you're not using atapicam, while Pegasus is. So I believe that rules that out. Are you using ATA_STATIC_ID? If not, then I'm out of "simple" ideas as to what could be causing this. > open("/dev/ata",O_RDWR,037777766320) = 3 (0x3) > ioctl(3,IOCATAGMAXCHANNEL,0xffffec20) = 0 (0x0) > ioctl(3,IOCATADEVICES,0xffffe590) = 0 (0x0) > fstat(1,{ mode=-rw-r--r-- ,inode=307828,size=2281,blksize=4096 }) = 0 (0x0) > __sysctl(0x7fffffffdba0,0x2,0x800845b48,0x7fffffffdbb8,0x0,0x0) = 0 (0x0) > __sysctl(0x7fffffffd6f0,0x2,0x8008547d8,0x7fffffffd6e8,0x0,0x0) = 0 (0x0) > __sysctl(0x7fffffffd730,0x2,0x7fffffffd74c,0x7fffffffd740,0x0,0x0) = 0 (0x0) > readlink("/etc/malloc.conf",0x7fffffffd790,1024) ERR#2 'No such file or directory' > issetugid(0x80071c2aa,0x7fffffffd790,0xffffffffffffffff,0x0,0xffffffff80ac1c40,0x7fffffffd768) = 0 (0x0) > break(0x600000) = 0 (0x0) > break(0x700000) = 0 (0x0) > ioctl(3,IOCATADEVICES,0xffffe590) ERR#6 'Device not configured' I've snipped the truss output to the relevant piece. fd 3 points to /dev/ata, and there are no man pages which document the IOCATADEVICES ioctl. I'll have to look at the source. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon Sep 29 00:36:08 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 29 00:36:15 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080929000226.GA92057@icarus.home.lan> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> <20080929000226.GA92057@icarus.home.lan> Message-ID: <20080929003603.GA92998@icarus.home.lan> On Sun, Sep 28, 2008 at 05:02:26PM -0700, Jeremy Chadwick wrote: > On Sun, Sep 28, 2008 at 11:24:38PM +0100, Bruce Cran wrote: > > On Sun, 28 Sep 2008 10:43:58 +0000 (UTC) > > Pegasus McCleaft wrote: > > > > > Hello everyone. > > > > > > I was wondering if anyone else is experiencing this problem. > > > I have recently reloaded my machine (due to a meltdown of my primary > > > boot drive) and noticed that under 7.0-rel the atacontrol command > > > seems to work great, however, under 7.1 I get and error > > > > > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > > > > Has anyone else seen this error. I wouldent be conserned if > > > it wasent for the fact that it worked under 7.0-rel but now dosent. > > > The machine is using both the: > > > > > > atapci0: > > > atapci1: > > > > I'm also seeing this problem on my amd64 7.1-PRERELEASE system: > > > > > atacontrol list > > ATA channel 0: > > Master: acd0 ATA/ATAPI revision 5 > > Slave: no device present > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > > I've attached the dmesg, and truss output from "atacontrol list". > > Your dmesg output implies you're not using atapicam, while Pegasus is. > So I believe that rules that out. > > Are you using ATA_STATIC_ID? If not, then I'm out of "simple" ideas as > to what could be causing this. > > > open("/dev/ata",O_RDWR,037777766320) = 3 (0x3) > > ioctl(3,IOCATAGMAXCHANNEL,0xffffec20) = 0 (0x0) > > ioctl(3,IOCATADEVICES,0xffffe590) = 0 (0x0) > > fstat(1,{ mode=-rw-r--r-- ,inode=307828,size=2281,blksize=4096 }) = 0 (0x0) > > __sysctl(0x7fffffffdba0,0x2,0x800845b48,0x7fffffffdbb8,0x0,0x0) = 0 (0x0) > > __sysctl(0x7fffffffd6f0,0x2,0x8008547d8,0x7fffffffd6e8,0x0,0x0) = 0 (0x0) > > __sysctl(0x7fffffffd730,0x2,0x7fffffffd74c,0x7fffffffd740,0x0,0x0) = 0 (0x0) > > readlink("/etc/malloc.conf",0x7fffffffd790,1024) ERR#2 'No such file or directory' > > issetugid(0x80071c2aa,0x7fffffffd790,0xffffffffffffffff,0x0,0xffffffff80ac1c40,0x7fffffffd768) = 0 (0x0) > > break(0x600000) = 0 (0x0) > > break(0x700000) = 0 (0x0) > > ioctl(3,IOCATADEVICES,0xffffe590) ERR#6 'Device not configured' > > I've snipped the truss output to the relevant piece. > > fd 3 points to /dev/ata, and there are no man pages which document > the IOCATADEVICES ioctl. I'll have to look at the source. Bruce and Pegasus, Can you please apply the below patch to src/sbin/atacontrol.c and let me know what the output is when doing "atacontrol list"? This won't solve the problem, but it will help in determining which piece of code in src/sys/dev/ata/ata-all.c is returning an error to ioctl() (different pieces of the code return different errors, either ENXIO, ENODEV, or another error depending upon what gets returned from ata_raid_ioctl_func()). Thanks. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | --- atacontrol.c.orig 2008-04-08 03:48:20.000000000 -0700 +++ atacontrol.c 2008-09-28 17:32:39.000000000 -0700 @@ -261,12 +261,14 @@ static void info_print(int fd, int channel, int prchan) { + int ret; struct ata_ioc_devices devices; devices.channel = channel; - if (ioctl(fd, IOCATADEVICES, &devices) < 0) - err(1, "ioctl(IOCATADEVICES)"); + if ((ret = ioctl(fd, IOCATADEVICES, &devices)) < 0) { + err(1, "ioctl(IOCATADEVICES) returned %d", ret); + } if (prchan) printf("ATA channel %d:\n", channel); From bruce at cran.org.uk Mon Sep 29 02:08:16 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Mon Sep 29 02:08:23 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080929003603.GA92998@icarus.home.lan> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> <20080929000226.GA92057@icarus.home.lan> <20080929003603.GA92998@icarus.home.lan> Message-ID: <20080929030748.08b19c52@tau.draftnet> On Sun, 28 Sep 2008 17:36:03 -0700 Jeremy Chadwick wrote: > Bruce and Pegasus, > > Can you please apply the below patch to src/sbin/atacontrol.c and let > me know what the output is when doing "atacontrol list"? > > This won't solve the problem, but it will help in determining which > piece of code in src/sys/dev/ata/ata-all.c is returning an error to > ioctl() (different pieces of the code return different errors, either > ENXIO, ENODEV, or another error depending upon what gets returned > from ata_raid_ioctl_func()). ATA channel 0: Master: acd0 ATA/ATAPI revision 5 Slave: no device present atacontrol: ioctl(IOCATADEVICES) returned -1: Device not configured This laptop's running GENERIC, so ATA_STATIC_ID is in my kernel config. -- Bruce Cran From fbsd06 at mlists.homeunix.com Mon Sep 29 02:13:07 2008 From: fbsd06 at mlists.homeunix.com (RW) Date: Mon Sep 29 02:13:13 2008 Subject: experimantal question about md's In-Reply-To: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> References: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> Message-ID: <20080929025636.781ed1ff@gumby.homeunix.com.> On Fri, 26 Sep 2008 20:15:43 +0200 "Michael Schuh" wrote: > Let us say i have a Machine with 8 CPUs and a lot of RAM. > An i need a very high perfomance Storage for holding data. > > My idea was to setup a raid1(0) with virtual disk images. > Created with mdconfig. > > My idea was to create minimum 2 md-diskimages, > these are located > fisrt one on the harddisk as type vnode > second one as exact copy totally in the memory as type malloc > > For now the man-page mentoid me to not to do so, while large disks in > RAM cause panics, and i know panics come surely > > Is the above scenario possible without panics? You could use swap-backed devices. They are very similar, in both cases you are writing into ram backed by swap. I doubt it will work, I think raid works at the speed of the slower device. You need to be careful how you benchmark it. Your raid array will have the unfair advantage of starting with preloaded data. From koitsu at FreeBSD.org Mon Sep 29 03:07:47 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 29 03:07:54 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080929030748.08b19c52@tau.draftnet> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> <20080929000226.GA92057@icarus.home.lan> <20080929003603.GA92998@icarus.home.lan> <20080929030748.08b19c52@tau.draftnet> Message-ID: <20080929030744.GA95060@icarus.home.lan> On Mon, Sep 29, 2008 at 03:07:48AM +0100, Bruce Cran wrote: > On Sun, 28 Sep 2008 17:36:03 -0700 > Jeremy Chadwick wrote: > > Bruce and Pegasus, > > > > Can you please apply the below patch to src/sbin/atacontrol.c and let > > me know what the output is when doing "atacontrol list"? > > > > This won't solve the problem, but it will help in determining which > > piece of code in src/sys/dev/ata/ata-all.c is returning an error to > > ioctl() (different pieces of the code return different errors, either > > ENXIO, ENODEV, or another error depending upon what gets returned > > from ata_raid_ioctl_func()). I misread part of the code. ata_raid_ioctl() only gets called if the ata_raid_ioctl_func pointer is non-NULL (it defaults to NULL unless your system is found to need/require ataraid support; need/require does not mean "compiled in", I assume it means "we found devices/metadata that ataraid can handle"). In your case, there are no arX devices, and the only ATA device you have is an ATAPI CD/DVD drive. > ATA channel 0: > Master: acd0 ATA/ATAPI revision 5 > Slave: no device present > atacontrol: ioctl(IOCATADEVICES) returned -1: Device not configured Right, silly me. Here I was hoping I could get the return code of ata_ioctl(), but that's not the case. There's no way for me to get that information; ioctl() returns -1 on failure, and 0 on success. truss isn't going to be enough for this, because I need to see into the kernel ioctl() layer to find out what's going on in the ATA code. Simply put, I don't know how to efficiently debug this problem under FreeBSD. dtrace is available on 7.1-PRERELEASE, but I'm unfamiliar with it. > This laptop's running GENERIC, so ATA_STATIC_ID is in my kernel config. Thanks. I realised on all of my systems I also use ATA_STATIC_ID (I must've missed it when I was skimming the config), so neither atapicam nor ATA_STATIC_ID are responsible for this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Mon Sep 29 03:13:26 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 29 03:13:32 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080929030744.GA95060@icarus.home.lan> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> <20080929000226.GA92057@icarus.home.lan> <20080929003603.GA92998@icarus.home.lan> <20080929030748.08b19c52@tau.draftnet> <20080929030744.GA95060@icarus.home.lan> Message-ID: <20080929031324.GA96457@icarus.home.lan> On Sun, Sep 28, 2008 at 08:07:44PM -0700, Jeremy Chadwick wrote: > On Mon, Sep 29, 2008 at 03:07:48AM +0100, Bruce Cran wrote: > > On Sun, 28 Sep 2008 17:36:03 -0700 > > Jeremy Chadwick wrote: > > > Bruce and Pegasus, > > > > > > Can you please apply the below patch to src/sbin/atacontrol.c and let > > > me know what the output is when doing "atacontrol list"? > > > > > > This won't solve the problem, but it will help in determining which > > > piece of code in src/sys/dev/ata/ata-all.c is returning an error to > > > ioctl() (different pieces of the code return different errors, either > > > ENXIO, ENODEV, or another error depending upon what gets returned > > > from ata_raid_ioctl_func()). > > I misread part of the code. ata_raid_ioctl() only gets called if the > ata_raid_ioctl_func pointer is non-NULL (it defaults to NULL unless your > system is found to need/require ataraid support; need/require does not > mean "compiled in", I assume it means "we found devices/metadata that > ataraid can handle"). > > In your case, there are no arX devices, and the only ATA device you have > is an ATAPI CD/DVD drive. > > > ATA channel 0: > > Master: acd0 ATA/ATAPI revision 5 > > Slave: no device present > > atacontrol: ioctl(IOCATADEVICES) returned -1: Device not configured > > Right, silly me. Here I was hoping I could get the return code of > ata_ioctl(), but that's not the case. There's no way for me to get that > information; ioctl() returns -1 on failure, and 0 on success. > > truss isn't going to be enough for this, because I need to see into the > kernel ioctl() layer to find out what's going on in the ATA code. > > Simply put, I don't know how to efficiently debug this problem under > FreeBSD. dtrace is available on 7.1-PRERELEASE, but I'm unfamiliar with > it. Lucky! While working on some other ATA-related code on a test/dev box I just built about 30 minutes ago, I decided to do "atacontrol list" to see what would happen: testbox# atacontrol list ATA channel 0: Master: ad0 Serial ATA v1.0 Slave: no device present ATA channel 1: Master: acd0 ATA/ATAPI revision 0 Slave: no device present atacontrol: ioctl(IOCATADEVICES): Device not configured testbox# This box I have physical + serial access to, so I should be able to try and track this down, now that I have something to work with. :-) I'll let you guys know what I find. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From bu7cher at yandex.ru Mon Sep 29 04:25:39 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Mon Sep 29 04:25:46 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928232438.5d0c4a55@tau.draftnet> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> Message-ID: <48E05471.8090705@yandex.ru> Bruce Cran wrote: > I'm also seeing this problem on my amd64 7.1-PRERELEASE system: > >> atacontrol list > ATA channel 0: > Master: acd0 ATA/ATAPI revision 5 > Slave: no device present > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > I've attached the dmesg, and truss output from "atacontrol list". This is known problem and it fixed in CURRENT. You need to apply this patch: http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c.diff?r1=1.47;r2=1.48 I cc'ed person, who commited this fix. Hi, Poul-Henning, I think it should be MFCed before release. -- WBR, Andrey V. Elsukov From koitsu at FreeBSD.org Mon Sep 29 05:07:07 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 29 05:07:14 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <48E05471.8090705@yandex.ru> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> <48E05471.8090705@yandex.ru> Message-ID: <20080929050705.GA98771@icarus.home.lan> On Mon, Sep 29, 2008 at 08:07:13AM +0400, Andrey V. Elsukov wrote: > Bruce Cran wrote: >> I'm also seeing this problem on my amd64 7.1-PRERELEASE system: >> >>> atacontrol list >> ATA channel 0: >> Master: acd0 ATA/ATAPI revision 5 >> Slave: no device present >> atacontrol: ioctl(IOCATADEVICES): Device not configured >> >> >> I've attached the dmesg, and truss output from "atacontrol list". > > This is known problem and it fixed in CURRENT. > You need to apply this patch: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c.diff?r1=1.47;r2=1.48 > > I cc'ed person, who commited this fix. > Hi, Poul-Henning, I think it should be MFCed before release. I agree, it should be MFC'd. Cute bug too; never would've guessed it. Saves me from the effort of trying to get kgdb over serial working and all that jazz. :-) Thanks, Andrey! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From zbeeble at gmail.com Mon Sep 29 05:19:24 2008 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Mon Sep 29 05:19:31 2008 Subject: experimantal question about md's In-Reply-To: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> References: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> Message-ID: <5f67a8c40809282219w6ae93986od211c6e8c47066fe@mail.gmail.com> On Fri, Sep 26, 2008 at 2:15 PM, Michael Schuh wrote: > Hallo @list, > > Let us say i have a Machine with 8 CPUs and a lot of RAM. > An i need a very high perfomance Storage for holding data. > > My idea was to setup a raid1(0) with virtual disk images. > Created with mdconfig. > > My idea was to create minimum 2 md-diskimages, > these are located > fisrt one on the harddisk as type vnode > second one as exact copy totally in the memory as type malloc > > For now the man-page mentoid me to not to do so, while large disks in RAM > cause panics, and i know panics come surely > > Is the above scenario possible without panics? My first concern is not the panics (you can somewhat solve this by using swap-backed MD), but the fact that you can't really gain an advantage this way. If you have enough RAM, the regular process of filesystem buffering will do the work for you. If you don't have enough RAM, the RAM starvation of buffers and processes will be your problem and not the speed of your filesystem. Regardless, if you were to construct a raid with an MD and a real disk (no need to make it a vnode MD --- but that has the same drawbacks) the RAID filesystem would be constrained by the speed of writes to the slower filesystem. You may get a few percent out of teaching the gmirror node to prefer reading from the memory disk, but would this be an advantage over the natural buffering that already takes place? Probably not. From bipolor at gmail.com Mon Sep 29 05:19:35 2008 From: bipolor at gmail.com (Mike Price) Date: Mon Sep 29 05:19:41 2008 Subject: What file on FreeBSD acts like autoexec.bat? Message-ID: What file on FreeBSD acts like autoexec.bat? Also please leave the full path% From max at love2party.net Mon Sep 29 05:29:19 2008 From: max at love2party.net (Max Laier) Date: Mon Sep 29 05:29:27 2008 Subject: What file on FreeBSD acts like autoexec.bat? In-Reply-To: References: Message-ID: <200809290729.15531.max@love2party.net> On Monday 29 September 2008 07:19:34 Mike Price wrote: > What file on FreeBSD acts like autoexec.bat? > Also please leave the full path% You might find the following article enlightening: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/rc-scripting/ -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From tim at clewlow.org Mon Sep 29 05:50:21 2008 From: tim at clewlow.org (Tim Clewlow) Date: Mon Sep 29 05:50:28 2008 Subject: What file on FreeBSD acts like autoexec.bat? In-Reply-To: References: Message-ID: <4f8f44b57d2cf76e60663bd79ae3b65f.squirrel@192.168.1.100> > What file on FreeBSD acts like autoexec.bat? > Also please leave the full path% > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > >From my point of view, I would say that this file acts like an 'autoexec.bat' file, in a highly abstract manner: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ But I imaging the rc mechanism is more what you are looking for: http://www.freebsd.org/cgi/man.cgi?query=rc&sektion=8 Cheers, Tim. -- The code that never executes at all is the fastest. From ken at mthelicon.com Mon Sep 29 06:35:18 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Sep 29 06:35:25 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <48E05471.8090705@yandex.ru> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928232438.5d0c4a55@tau.draftnet> <48E05471.8090705@yandex.ru> Message-ID: <200809290733.44487.ken@mthelicon.com> On Monday 29 September 2008 05:07:13 Andrey V. Elsukov wrote: > Bruce Cran wrote: > > I'm also seeing this problem on my amd64 7.1-PRERELEASE system: > >> atacontrol list > > > > ATA channel 0: > > Master: acd0 ATA/ATAPI revision 5 > > Slave: no device present > > atacontrol: ioctl(IOCATADEVICES): Device not configured > > > > > > I've attached the dmesg, and truss output from "atacontrol list". > > This is known problem and it fixed in CURRENT. > You need to apply this patch: > http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c.diff >?r1=1.47;r2=1.48 > > I cc'ed person, who commited this fix. > Hi, Poul-Henning, I think it should be MFCed before release. Thanks everyone, I just got up this morning and used the above patch and now everything is working great! Thanks to everyone for your help Peg From olli at lurza.secnetix.de Mon Sep 29 07:39:38 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 29 07:39:50 2008 Subject: What file on FreeBSD acts like autoexec.bat? In-Reply-To: Message-ID: <200809290739.m8T7dZDp064978@lurza.secnetix.de> Mike Price wrote: > What file on FreeBSD acts like autoexec.bat? > Also please leave the full path% The file that probably comes closest is /etc/rc.local (you have to create it, it doesn't exist by default). Actually FreeBSD's rc system allows much more flexible scripting ... If you're interested, start by reading the rc(8) manual page. But if you only need some simple commands executed upon every boot, just put them in /etc/rc.local and you're done. Note, however, that you have to use sh(1) shell command syntax, not COMMAND.COM syntax. ;-) By the way, the file that corresponds to config.sys on a FreeBSD system is /etc/rc.conf (see the rc.conf(5) manual page for details). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "A language that doesn't have everything is actually easier to program in than some that do." -- Dennis M. Ritchie From danny at cs.huji.ac.il Mon Sep 29 07:56:34 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Sep 29 07:56:41 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > On Fri, 26 Sep 2008, Danny Braniss wrote: > > > > > after more testing, it seems it's related to changes made between Aug 4 and > > > Aug 29 ie, a kernel built on Aug 4 works fine, Aug 29 is slow. I'l now try > > > and close the gap. > > > > I think this is the best way forward -- skimming August changes, there are a > > number of candidate commits, including retuning of UDP hashes by mav, my > > rwlock changes, changes to mbuf chain handling, etc. > > it more difficult than I expected. > for one, the kernel date was missleading, the actual source update is the key, so > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > yet seems relevant. > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > give the same throughput, which seem to point to UDP changes ... > > danny Grr, there goes binary search theory out of the window, So far I have managed to pinpoint the day that the changes affect the throughput: 18/08/08 00:00:00 19/08/08 00:00:00 (I assume cvs's date is GMT). now would be a good time for some help, specially how to undo changes, my knowledge of csup/cvs are close to zero. danny From danny at cs.huji.ac.il Mon Sep 29 09:39:59 2008 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Sep 29 09:40:12 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > > it more difficult than I expected. > > for one, the kernel date was missleading, the actual source update is the key, so > > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > > yet seems relevant. > > > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > > give the same throughput, which seem to point to UDP changes ... > > Can you post the network-numbers? [again :-] > > Writing 16 MB file > > BS Count /---- 7.0 ------/ /---- 7.1 -----/ should now read: /---- Aug 18 ------/ /--- Aug 19 ----/ > > 1*512 32768 0.16s 98.11MB/s 0.43s 37.18MB/s > > 2*512 16384 0.17s 92.04MB/s 0.46s 34.79MB/s > > 4*512 8192 0.16s 101.88MB/s 0.43s 37.26MB/s > > 8*512 4096 0.16s 99.86MB/s 0.44s 36.41MB/s > > 16*512 2048 0.16s 100.11MB/s 0.50s 32.03MB/s > > 32*512 1024 0.26s 61.71MB/s 0.46s 34.79MB/s > > 64*512 512 0.22s 71.45MB/s 0.45s 35.41MB/s > > 128*512 256 0.21s 77.84MB/s 0.51s 31.34MB/s > > 256*512 128 0.19s 82.47MB/s 0.43s 37.22MB/s > > 512*512 64 0.18s 87.77MB/s 0.49s 32.69MB/s > > 1024*512 32 0.18s 89.24MB/s 0.47s 34.02MB/s > > 2048*512 16 0.17s 91.81MB/s 0.30s 53.41MB/s > > 4096*512 8 0.16s 100.56MB/s 0.42s 38.07MB/s > > 8192*512 4 0.82s 19.56MB/s 0.80s 19.95MB/s > > 16384*512 2 0.82s 19.63MB/s 0.95s 16.80MB/s > > 32768*512 1 0.81s 19.69MB/s 0.96s 16.64MB/s > > > > Average: 75.86 33.00 From phk at phk.freebsd.dk Mon Sep 29 10:41:22 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon Sep 29 10:41:28 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: Your message of "Mon, 29 Sep 2008 08:07:13 +0400." <48E05471.8090705@yandex.ru> Message-ID: <73955.1222683574@critter.freebsd.dk> In message <48E05471.8090705@yandex.ru>, "Andrey V. Elsukov" writes: >This is known problem and it fixed in CURRENT. >You need to apply this patch: >http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/atacontrol/atacontrol.c.diff?r1=1.47;r2=1.48 > >I cc'ed person, who commited this fix. >Hi, Poul-Henning, I think it should be MFCed before release. I agree, but I'm ENOTIME. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From paul at fletchermoorland.co.uk Mon Sep 29 11:00:41 2008 From: paul at fletchermoorland.co.uk (Paul Wootton) Date: Mon Sep 29 11:01:13 2008 Subject: Spam ? - Re: Increasing partition size by removing partitions In-Reply-To: <26ddd1750809271838m414b4214vb726f5e74fd6f8c2@mail.gmail.com> References: <48DEC02C.90302@gmail.com> <26ddd1750809271838m414b4214vb726f5e74fd6f8c2@mail.gmail.com> Message-ID: <200809291144.22135.paul@fletchermoorland.co.uk> I dont know if it going to be of any use, but in the past, I have used a free but very low level partition editing tool called Ranish http://www.ranish.com/part/ It does allow for moving of any partitions (or slices in BSD terms) Watch out though, as there is no real checks done against commands you issue (It WILL do exactly what you ask - be it right or wrong) I have used it (v2.44 - the lastest beta version) in the past for moving, growing and shrinking of NTFS and FAT32 partitions with a FreeBSD slice on the drive, just never tried changing a BSD slice it self If I remember right, if you try to run the editor under windows 2000 or XP, it will try to create a bootable floppy disk which might be more useful to FreeBSD users Like I said, it might not be any use in this instance, but probably still worth a look, just incase Paul On Sunday 28 September 2008 02:38:14 Maxim Khitrov wrote: > On Sat, Sep 27, 2008 at 7:22 PM, Aryeh M. Friedman > > wrote: > > I have a disk that is laid out with partion 0 being NTFS and 1 being > > FreeBSD. I want to remove the NTFS partition and grow the FreeBSD one > > but all the docs I have seen only talk about how to do this if the new > > part of the partition is at the end of the partition you wish to grow. > > How do I go about this? > > Assuming that there is no (free) software that will do it for you, and > you are unable for some reason to move the data to another place and > repartition the drive, you have to manually move your FreeBSD > partition back and then extend it. I've never done this before, but if > I had to try it the first time I would do the following: > > 1. Try very hard to find some other hard drive where I can just dump > the data and avoid this whole thing to begin with. :) > 2. Boot from a FreeBSD livecd, attach a usb drive for storing some > temporary files and mount it under /mnt. > 3. Create a back-up of your master boot record (dd if=/dev/ad0 > of=/mnt/mbr-backup bs=512 count=1). Assuming here that your drive is > ad0. > 4. Use fdisk to get the start and size values of your two partitions > (in sectors). > 5. Erase the ntfs partition (dd if=/dev/zero of=/dev/ad0s1 bs=2m). > 6. Copy your FreeBSD partition to the former start location of ntfs > (dd if=/dev/ad0 of=/dev/ad0 bs=512 iseek= > oseek= count=). Using > bs=512 is slow, but it makes it easier for you to just take the > numbers that fdisk gives you and plug them in. > 7. Once this is done you will need to edit your mbr sector to > overwrite the first partition entry with the second, but certain > fields will need to be updated... > > I recommend you use a hex editor and work on the file that you saved > in step 3. You can try the same thing with a partition editor, but you > may not get the desired results. > > For the manual (and more fun) method, the partition table begins at > offset 0x01BE, and each entry is 16 bytes long. That means that you > need to copy 16 bytes starting at address 0x01CE to address 0x01BE. > However, before you do this, you need to set the correct values for > cylinder-head-sector of first and last sectors in the FreeBSD > partition, as well as the logical address of the first sector. > > First, take 3 bytes starting at address 0x01BF and copy them to > 0x01CF. This takes care of CHS start, which is unchanged. Next, take 4 > bytes at address 0x01C6 and copy them to 0x01D6. This is the logical > sector start. The tricky bit is the CHS last sector value. If your two > partitions were of identical size, then you can copy 3 bytes from > 0x01C3 to 0x01D3. Otherwise, you'll need to calculate the new values > by hand. If your NTFS partition was marked as active before, then set > byte 0x01CE to be 0x80. > > One this is done, copy that second record over the first and zero-out > the 16 bytes at 0x01CE. Use dd again to copy the updated mbr sector to > your drive. At this point your master boot record will have the > correct entry for your FreeBSD partition, which was moved over the > NTFS one. See if you can mount /dev/ad0s1a while still in the livecd > environment (actually, you will need to reboot first). If ad0s1a is > under /dev and you can mount it, then your mbr is fine. Use growfs > from here and then boot from the hard drive. > > As you can see, it's not a trivial thing to do, but it's possible if > you are careful. Once again, I've never done this and am basing the > whole thing on some of my previous experience in messing with the > master boot record. There may be some other things that I missed. I > also don't know if there is existing software that might make this > whole process much easier, the directions here are a worst-case > scenario for moving your partition by hand. > > - Max > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From michael.schuh at gmail.com Mon Sep 29 08:36:48 2008 From: michael.schuh at gmail.com (Michael Schuh) Date: Mon Sep 29 11:32:58 2008 Subject: experimantal question about md's In-Reply-To: <5f67a8c40809282219w6ae93986od211c6e8c47066fe@mail.gmail.com> References: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> <5f67a8c40809282219w6ae93986od211c6e8c47066fe@mail.gmail.com> Message-ID: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> Hi, thank you for your answer. Clearly the Writeprocess of writeing data to an mirror is totally ended, as all mirrordevices are written. But for the read the kernel uses the faster device......and there it could be an advantage.....i m thinking. And yes i think it could be an advantage, if the RAMed mirror is very fast, we have only to wait for the first initialization, all the ongoing reads go to the ramdisk, all writes goes to both devices. so we have a webserver (par example) at this mirror it has very good speed for the file-access (ok i know in allmost cases is not the disk the bottleneck, and if we could doing caching...) at the above examle it is not really important if the write process needs a second or two longer, but by millions of requests it could be interseting to read the data very fast...... in my idea it was only focused on reads not on writes, the drawbacks of Raid are well known if i have enough ram in the box, it is possible to say: Hi kernel use plase 8 Gigs of ram for buffering the directory abc on the disk directaccesABC ??? i think not. in the case of my idea it is clearly..... but on the other side we need to have to say: Hi kernel, do never ever buffering on this rambased Diskdevice.... or we shoot us in our knees....as i think.... thank you michael 2008/9/29 Zaphod Beeblebrox > > > On Fri, Sep 26, 2008 at 2:15 PM, Michael Schuh wrote: > >> Hallo @list, >> >> Let us say i have a Machine with 8 CPUs and a lot of RAM. >> An i need a very high perfomance Storage for holding data. >> >> My idea was to setup a raid1(0) with virtual disk images. >> Created with mdconfig. >> >> My idea was to create minimum 2 md-diskimages, >> these are located >> fisrt one on the harddisk as type vnode >> second one as exact copy totally in the memory as type malloc >> >> For now the man-page mentoid me to not to do so, while large disks in RAM >> cause panics, and i know panics come surely >> >> Is the above scenario possible without panics? >> > > My first concern is not the panics (you can somewhat solve this by using > swap-backed MD), but the fact that you can't really gain an advantage this > way. > > If you have enough RAM, the regular process of filesystem buffering will do > the work for you. If you don't have enough RAM, the RAM starvation of > buffers and processes will be your problem and not the speed of your > filesystem. > > Regardless, if you were to construct a raid with an MD and a real disk (no > need to make it a vnode MD --- but that has the same drawbacks) the RAID > filesystem would be constrained by the speed of writes to the slower > filesystem. You may get a few percent out of teaching the gmirror node to > prefer reading from the memory disk, but would this be an advantage over the > natural buffering that already takes place? Probably not. > > -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbr?cken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === From kometen at gmail.com Mon Sep 29 08:40:07 2008 From: kometen at gmail.com (Claus Guttesen) Date: Mon Sep 29 11:33:06 2008 Subject: bad NFS/UDP performance In-Reply-To: References: <20080926081806.GA19055@icarus.home.lan> <20080926095230.GA20789@icarus.home.lan> Message-ID: > it more difficult than I expected. > for one, the kernel date was missleading, the actual source update is the key, so > the window of changes is now 28/July to 19/August. I have the diffs, but nothing > yet seems relevant. > > on the other hand, I tried NFS/TCP, and there things seem ok, ie the 'good' and the 'bad' > give the same throughput, which seem to point to UDP changes ... Can you post the network-numbers? -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From olli at lurza.secnetix.de Mon Sep 29 11:59:17 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 29 11:59:34 2008 Subject: bad NFS/UDP performance In-Reply-To: Message-ID: <200809291158.m8TBwped076763@lurza.secnetix.de> Danny Braniss wrote: > Grr, there goes binary search theory out of the window, > So far I have managed to pinpoint the day that the changes affect the > throughput: > 18/08/08 00:00:00 19/08/08 00:00:00 > (I assume cvs's date is GMT). > now would be a good time for some help, specially how to undo changes, my > knowledge of csup/cvs are close to zero. So you've nailed to down to this 24-hour window: http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7 I'm afraid that r181822 by rwatson is the most likely candidate that might be causing the regression. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C is quirky, flawed, and an enormous success." -- Dennis M. Ritchie. From rwatson at FreeBSD.org Mon Sep 29 12:22:34 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Sep 29 12:22:41 2008 Subject: bad NFS/UDP performance In-Reply-To: <200809291158.m8TBwped076763@lurza.secnetix.de> References: <200809291158.m8TBwped076763@lurza.secnetix.de> Message-ID: On Mon, 29 Sep 2008, Oliver Fromme wrote: > Danny Braniss wrote: > > Grr, there goes binary search theory out of the window, > > So far I have managed to pinpoint the day that the changes affect the > > throughput: > > 18/08/08 00:00:00 19/08/08 00:00:00 > > (I assume cvs's date is GMT). > > now would be a good time for some help, specially how to undo changes, my > > knowledge of csup/cvs are close to zero. > > So you've nailed to down to this 24-hour window: > > http://www.secnetix.de/olli/FreeBSD/svnews/?day=2008-08-18&p=/stable/7 > > I'm afraid that r181822 by rwatson is the most likely candidate that might > be causing the regression. If we can confirm that it was that specific change, then I can create a patch to restore exclusive locking for UDP and we can see if it was the general move to rwlocking, or specifically the read-locking of certain data structures. Perhaps what we've done is moved contention from a mutex to a sleep lock, reducing the efficiency of handling contention? Adding Kris to the CC line because he often has useful insights on this sort of thing. Robert N M Watson Computer Laboratory University of Cambridge From olli at lurza.secnetix.de Mon Sep 29 13:00:19 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Sep 29 13:00:26 2008 Subject: experimantal question about md's In-Reply-To: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> Message-ID: <200809291300.m8TD0G86079925@lurza.secnetix.de> Michael Schuh wrote: > Clearly the Writeprocess of writeing data to an mirror is totally ended, as > all mirrordevices are written. > But for the read the kernel uses the faster device......and there it could > be an advantage.....i m thinking. > And yes i think it could be an advantage, if the RAMed mirror is very fast, > we have only to wait > for the first initialization, all the ongoing reads go to the ramdisk, all > writes goes to both devices. I think it would be completely sufficient to use a normal device and let the kernel cache the data. This is much better because the kernel dynamically adapts the cache size to the workload and memory requirements. If you use an unusual asymmetric mirror setupt with a physical disk and a memory disk (swap-backed), the machine will have to start paging as soon as the requirements of your processes grow beyond what's available. This will be very slow, of course. For example (a little bit simplified): Say there's a spike in web accesses so you get many processes that want to allocate memory. If you run out of free memory, the kernel will drop some pages that contain cached data and re-use them. If the cached data is used later, the kernel will re-read it from the disk. On the other hand, if you use a memory disk, you effectively reduce the amount of memory available by the size of that disk. If a process wants to allocate memory now, the kernel can't simply drop any pages used by the memory disk -- it has to write them to the swap area first. It is obvious that the performance is worse. And of course, the kernel will still try to cache the file system data (the VFS code doesn't care that the file system is on a gmirror with one half on a memory disk). So the cache and the memory disk fight for RAM at the same time. Basically you would be wasting RAM and losing performance. > if i have enough ram in the box, it is possible to say: Hi kernel use plase > 8 Gigs of ram for buffering > the directory abc on the disk directaccesABC ??? i think not. The kernel will basically use all available RAM for caching and buffering. This works especially well for static web content. There are a few sysctl variables to influence the behaviour, but it's usually better not to touch them. I get the impression that you're trying to solve a problem that doesn't exist. If you think you _do_ have a problem, please provide some evidence, such as output from iostat, gstat, vmstat and so on. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke From fbsd06 at mlists.homeunix.com Mon Sep 29 13:14:20 2008 From: fbsd06 at mlists.homeunix.com (RW) Date: Mon Sep 29 13:14:27 2008 Subject: experimantal question about md's In-Reply-To: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> References: <1dbad3150809261115h379a611aweb20e47124e254d4@mail.gmail.com> <5f67a8c40809282219w6ae93986od211c6e8c47066fe@mail.gmail.com> <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> Message-ID: <20080929141415.387f931f@gumby.homeunix.com.> On Mon, 29 Sep 2008 10:36:46 +0200 "Michael Schuh" wrote: > so we have a webserver (par example) at this mirror it has very good > speed for the file-access > (ok i know in allmost cases is not the disk the bottleneck, and if we > could doing caching...) > at the above examle it is not really important if the write process > needs a second or two longer, > but by millions of requests it could be interseting to read the data > very fast...... That's exactly the case in which caching will work best. FreeBSD's integrated cache/VM system would keep such pages in memory even at the expense of writing other user data to swap. When I suggested a swap-backed device I was forgetting that malloc backed devices use memory that won't be paged, so there may be an advantage, but I think it would be the opposite to what you want. What it would do is keep rarely used file data in memory even if there's a better use for the memory elsewhere, so you would be trading performance for better worst-case latency. From michael.schuh at gmail.com Mon Sep 29 13:13:03 2008 From: michael.schuh at gmail.com (Michael Schuh) Date: Mon Sep 29 13:50:11 2008 Subject: experimantal question about md's In-Reply-To: <200809291300.m8TD0G86079925@lurza.secnetix.de> References: <1dbad3150809290136r2af024bdha9672aa0418e6cda@mail.gmail.com> <200809291300.m8TD0G86079925@lurza.secnetix.de> Message-ID: <1dbad3150809290613j3ebd7226t15918234332fa598@mail.gmail.com> Hello @all, hello Oliver, thnak you for your reply. No i do not try to solve a real problem. It was hypothetically, an idea, not more not less. I have this written in my first posting. And for me, it is a logical dependency that the ram get paged to the swap if there is not enough RAM for all processes and in-memory data. I think my question is answered good enough. Thanks for all. greetings Michael 2008/9/29 Oliver Fromme > Michael Schuh wrote: > > Clearly the Writeprocess of writeing data to an mirror is totally ended, > as > > all mirrordevices are written. > > But for the read the kernel uses the faster device......and there it > could > > be an advantage.....i m thinking. > > And yes i think it could be an advantage, if the RAMed mirror is very > fast, > > we have only to wait > > for the first initialization, all the ongoing reads go to the ramdisk, > all > > writes goes to both devices. > > I think it would be completely sufficient to use a normal > device and let the kernel cache the data. This is much > better because the kernel dynamically adapts the cache > size to the workload and memory requirements. > > If you use an unusual asymmetric mirror setupt with a > physical disk and a memory disk (swap-backed), the machine > will have to start paging as soon as the requirements of > your processes grow beyond what's available. This will > be very slow, of course. > > For example (a little bit simplified): Say there's a spike > in web accesses so you get many processes that want to > allocate memory. If you run out of free memory, the kernel > will drop some pages that contain cached data and re-use > them. If the cached data is used later, the kernel will > re-read it from the disk. On the other hand, if you use > a memory disk, you effectively reduce the amount of memory > available by the size of that disk. If a process wants > to allocate memory now, the kernel can't simply drop any > pages used by the memory disk -- it has to write them to > the swap area first. It is obvious that the performance > is worse. > > And of course, the kernel will still try to cache the file > system data (the VFS code doesn't care that the file system > is on a gmirror with one half on a memory disk). So the > cache and the memory disk fight for RAM at the same time. > Basically you would be wasting RAM and losing performance. > > > if i have enough ram in the box, it is possible to say: Hi kernel use > plase > > 8 Gigs of ram for buffering > > the directory abc on the disk directaccesABC ??? i think not. > > The kernel will basically use all available RAM for > caching and buffering. This works especially well for > static web content. There are a few sysctl variables > to influence the behaviour, but it's usually better not > to touch them. > > I get the impression that you're trying to solve a problem > that doesn't exist. If you think you _do_ have a problem, > please provide some evidence, such as output from iostat, > gstat, vmstat and so on. > > Best regards > Oliver > > -- > Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. > Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: > secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- > chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > > FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > > "C++ is to C as Lung Cancer is to Lung." > -- Thomas Funke > -- === m i c h a e l - s c h u h . n e t === Michael Schuh Postfach 10 21 52 66021 Saarbr?cken phone: 0681/8319664 mobil: 0177/9738644 @: m i c h a e l . s c h u h @ g m a i l . c o m === Ust-ID: DE251072318 === From des at des.no Mon Sep 29 14:19:45 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 29 14:19:52 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <20080928223709.GA90348@icarus.home.lan> (Jeremy Chadwick's message of "Sun, 28 Sep 2008 15:37:09 -0700") References: <20080928103937.U51561@hercules.mthelicon.com> <20080928204241.GA88408@icarus.home.lan> <200809282232.49053.ken@mthelicon.com> <20080928223709.GA90348@icarus.home.lan> Message-ID: <861vz3nif4.fsf@ds4.des.no> Jeremy Chadwick writes: > I see the system has an Intel AHCI-based controller (probably an ICH10 > chip, since the ICH10 is the first to support 6 SATA channels). No. I have an ICH8 with six channels, of which five are in use. DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Mon Sep 29 14:23:44 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 29 14:23:50 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <73955.1222683574@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 29 Sep 2008 10:19:34 +0000") References: <73955.1222683574@critter.freebsd.dk> Message-ID: <86wsgvm3o1.fsf@ds4.des.no> "Poul-Henning Kamp" writes: > "Andrey V. Elsukov" writes: > > Hi, Poul-Henning, I think it should be MFCed before release. > I agree, but I'm ENOTIME. I'll take care of it. DES -- Dag-Erling Sm?rgrav - des@des.no From koitsu at FreeBSD.org Mon Sep 29 14:50:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Mon Sep 29 14:50:36 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <861vz3nif4.fsf@ds4.des.no> References: <20080928103937.U51561@hercules.mthelicon.com> <20080928204241.GA88408@icarus.home.lan> <200809282232.49053.ken@mthelicon.com> <20080928223709.GA90348@icarus.home.lan> <861vz3nif4.fsf@ds4.des.no> Message-ID: <20080929145027.GA10502@icarus.home.lan> On Mon, Sep 29, 2008 at 04:19:43PM +0200, Dag-Erling Sm?rgrav wrote: > Jeremy Chadwick writes: > > I see the system has an Intel AHCI-based controller (probably an ICH10 > > chip, since the ICH10 is the first to support 6 SATA channels). > > No. I have an ICH8 with six channels, of which five are in use. Thanks for the clarification. The breakdown is as follows: ICH7 = 4 ports ICH7R = 6 ports ICH7DH = 6 ports ICH7M = unknown ICH7MDH = unknown ICH7U = unknown ICH8 = 4 ports ICH8R = 6 ports ICH8DH = 6 ports ICH8DO = 6 ports ICH8M = 3 ports ICH8ME = 3 ports ICH9 = 4 ports ICH9R = 4 ports ICH9DH = 4 ports ICH9DO = 4 ports ICH9M = unknown ICH9ME = unknown ICH10 = 6 ports ICH10R = 6 ports -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From des at des.no Mon Sep 29 15:00:47 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Sep 29 15:00:54 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <86wsgvm3o1.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Mon, 29 Sep 2008 16:23:42 +0200") References: <73955.1222683574@critter.freebsd.dk> <86wsgvm3o1.fsf@ds4.des.no> Message-ID: <86hc7zm1y9.fsf@ds4.des.no> Dag-Erling Sm?rgrav writes: > I'll take care of it. kib beat me to it... DES -- Dag-Erling Sm?rgrav - des@des.no From ken at mthelicon.com Mon Sep 29 15:06:47 2008 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Sep 29 15:06:53 2008 Subject: atacontrol broken in 7.1-PR In-Reply-To: <86hc7zm1y9.fsf@ds4.des.no> References: <73955.1222683574@critter.freebsd.dk> <86wsgvm3o1.fsf@ds4.des.no> <86hc7zm1y9.fsf@ds4.des.no> Message-ID: <002301c92244$fd5caec0$f8160c40$@com> Again I would like to extend my thanks to everyone who helped with this problem, and a special thank you Jeremy and Bruce for trying to sus out where the fault might be. Your input and support is deeply appreciated. Peg > -----Original Message----- > From: Dag-Erling Sm?rgrav [mailto:des@des.no] > Sent: 29 September 2008 16:01 > To: Poul-Henning Kamp > Cc: Bruce Cran; freebsd-hackers@freebsd.org; Andrey V. Elsukov; Pegasus > McCleaft > Subject: Re: atacontrol broken in 7.1-PR > > Dag-Erling Sm?rgrav writes: > > I'll take care of it. > > kib beat me to it... > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > > No virus found in this incoming message. > Checked by AVG - http://www.avg.com > Version: 8.0.169 / Virus Database: 270.7.4/1695 - Release Date: > 29/09/2008 07:40 From jhb at freebsd.org Mon Sep 29 17:26:20 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Sep 29 17:26:27 2008 Subject: priority fields in a thread In-Reply-To: References: Message-ID: <200809291202.57731.jhb@freebsd.org> On Friday 26 September 2008 07:15:48 pm Murty, Ravi wrote: > Hello, > > I was wondering what all these different priority related fields in a > thread structure meant. This is the 8.0 kernel tree. > > Td_base_pri What the thread's priority should be while it is in the kernel. Doing a *sleep(..., PFOO) sets this to PFOO. On return to userland it gets set back to td_user_pri. The purpose of this field is to hold the "real" priority of a thread and is used when undoing the effects of priority propagation. > Td_user_pri This is the user priority of the thread. This is always >= PZERO for normal processes (real-time processes are different, though). When exiting the kernel, any priority "boost" from *sleep() is given up by dropping the priority back to this value. > Td_base_user_pri This is like td_base_pri in that it is a saved copy of the "real" userland priority of a thread. The umtx locks now support a userland version of priority propagation and this field is used to restore the user priority of a thread when it drops the locks other user threads need. > Td_priority This is the actual priority of the thread right now. When the thread is in userland, this should equal td_user_pri. When the thread is in the kernel, this should equal td_base_pri except for when the thread has been lent another thread's priority because it holds a lock that other thread needs. -- John Baldwin From daniel at roe.ch Mon Sep 29 23:18:23 2008 From: daniel at roe.ch (Daniel Roethlisberger) Date: Mon Sep 29 23:18:30 2008 Subject: ATA Security patch to atacontrol Message-ID: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> I've added experimental support for the ATA Security command set to atacontrol. Please test and review. If you have some spare disk(s) with ATA Security support and a BIOS which does not freeze the security configuration, I'd like to hear about any results of playing with this patch. See the changes to the manual page for details on the commands. Note that you may render disks unusable using the ATA Security commands. Use with great care. http://daniel.roe.ch/code/ata/atasecurity-20080930-complete.diff -- Daniel Roethlisberger http://daniel.roe.ch/ From koitsu at FreeBSD.org Tue Sep 30 02:39:48 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 30 02:39:56 2008 Subject: ATA Security patch to atacontrol In-Reply-To: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> References: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> Message-ID: <20080930023946.GA23425@icarus.home.lan> On Tue, Sep 30, 2008 at 01:06:55AM +0200, Daniel Roethlisberger wrote: > I've added experimental support for the ATA Security command set to > atacontrol. Please test and review. If you have some spare disk(s) > with ATA Security support and a BIOS which does not freeze the security > configuration, I'd like to hear about any results of playing with this > patch. See the changes to the manual page for details on the commands. > > Note that you may render disks unusable using the ATA Security commands. > Use with great care. > > http://daniel.roe.ch/code/ata/atasecurity-20080930-complete.diff Daniel, Can you provide me datasheet and technical reference material to what "ATA Security" is? Which ATA specification is this documented in? I'd like to read it. Thanks! -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From healey.rich at gmail.com Tue Sep 30 00:33:03 2008 From: healey.rich at gmail.com (Rich Healey) Date: Tue Sep 30 03:14:20 2008 Subject: SSH Brute Force attempts Message-ID: <48E16E93.3090601@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Recently I'm getting a lot of brute force attempts on my server, in the past I've used various tips and tricks with linux boxes but many of them were fairly linux specific. What do you BSD guys use for this purpose? If this belongs on -security let me know and I'll ask over there. Cheers Rich - -- Rich Healey - iTReign \ .''`. / healey.rich@gmail.com Developer / Systems Admin \ : :' : / healey.rich@itreign.com AIM: richohealey33 \ `. `' / richo@psych0tik.net MSN: bitchohealey@hotmail.com \ `- / richohealey@hellboundhackers.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjhbpMACgkQLeTfO4yBSAf36QCdE2cI75OAmyODre33sPPMrA8j 3VYAn3aHl1w5qyynd4rfYuxxqI6b2tAF =plT2 -----END PGP SIGNATURE----- From koitsu at FreeBSD.org Tue Sep 30 03:30:37 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 30 03:30:44 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <20080930033033.GA35849@icarus.home.lan> On Tue, Sep 30, 2008 at 10:10:59AM +1000, Rich Healey wrote: > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? This probably should've gone to -security, correct. There are 3 ports which people often use for solving this: ports/security/blocksshd ports/security/sshblock ports/security/sshguard-(pf|ipfw|ipfilter) The latter depends on which firewalling stack you use, and I believe one of the other two only work with ipfw (I forget which). I have great reservations using any of these, because they dynamically add firewalling rules/tables to your machines based on data in log files. For me, it smells of an accident waiting to happen. I'm an advocate of simply blocking large netblocks where most of these attacks come from (Latin America, eastern Europe, Asia, and Russia). This requires that you appropriately tune things over time, and *be intelligent* about what you're doing. :-) What we use in our pf.conf on our production systems: table persist file "/conf/ME/pf.conf.ssh-allow" table persist file "/conf/ME/pf.conf.ssh-deny" block in on $ext_if proto tcp from to any port ssh pass in on $ext_if proto tcp from to any port ssh flags S/SA keep state pf.conf.ssh-deny contains a list of IPs or CIDRs which are to be blocked. I can provide this file if desired. pf.conf.ssh-allow contains a list of IPs or CIDRs which "override" blocks in the previous "block" rule. The reason we have this is due to one Russian user who wasn't able to SSH into our boxes due to the previous block rule. You naturally have to keep pf.conf.ssh-* in sync if you have multiple machines. You can use pfsync(4) to accomplish this task (I think), or you can do it the obvious way (make a central distribution box that scp/rsync's the files out and runs "/etc/rc.d/pf reload"). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From wmoran at collaborativefusion.com Tue Sep 30 03:46:31 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Tue Sep 30 03:46:53 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <20080929233623.46b73fc0.wmoran@collaborativefusion.com> Rich Healey wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? > > If this belongs on -security let me know and I'll ask over there. http://potentialtech.com/cms/node/16 -- Bill Moran From ges+lists at wingfoot.org Tue Sep 30 03:57:54 2008 From: ges+lists at wingfoot.org (Glenn Sieb) Date: Tue Sep 30 03:58:01 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <48E19FC6.7050105@wingfoot.org> Rich Healey said the following on 9/29/08 8:10 PM: > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? > > If this belongs on -security let me know and I'll ask over there. Hi Rich! I use DenyHosts (/usr/ports/security/denyhosts) and it works great.. :) Best, --Glenn -- ...destination is merely a byproduct of the journey --Eric Hansen From rhavenn at rhavenn.net Tue Sep 30 04:00:04 2008 From: rhavenn at rhavenn.net (Henrik Hudson) Date: Tue Sep 30 04:21:54 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <200809291939.41533.rhavenn@rhavenn.net> On Monday 29 September 2008, Rich Healey sent a missive stating: > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? > > If this belongs on -security let me know and I'll ask over there. > > Cheers > > > Rich Yeap, -security However, also try this in pf.conf (specific rules related to this; you'll need more for a real pf.conf): table { } persist block in quick from pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state (max-src-conn 5, max-src-conn-rate 4/300, overload flush global) This will add "badguys" to the table if they connect more then 4 times in 300 seconds. Then use the expiretables port from a cronjob to remove IPs if you feel like it. Henrik -- Henrik Hudson rhavenn@rhavenn.net ------------------------------ "There are 10 kinds of people in the world: Those who understand binary and those who don't..." From m.seaman at infracaninophile.co.uk Tue Sep 30 05:44:52 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Sep 30 05:45:14 2008 Subject: SSH Brute Force attempts In-Reply-To: <20080930033033.GA35849@icarus.home.lan> References: <48E16E93.3090601@gmail.com> <20080930033033.GA35849@icarus.home.lan> Message-ID: <48E1BCC4.60207@infracaninophile.co.uk> Jeremy Chadwick wrote: > You naturally have to keep pf.conf.ssh-* in sync if you have multiple > machines. You can use pfsync(4) to accomplish this task (I think), or > you can do it the obvious way (make a central distribution box that > scp/rsync's the files out and runs "/etc/rc.d/pf reload"). pfsync sychronises the dynamic state sessions between machines -- ie. basically what you see by doing 'pfctl -ss' It doesn't as far as I know synchronise table contents even if the table changes are themselves dynamically generated in response to traffic. rsync is your friend here. As for blocking based on geographical source of IPs -- I see where you're coming from, but you've missed out one of the largest territories that is the source of this sort of thing, namely the USA. The best strategy IMHO is to foil the automated password guessers but not using passwords. SSH key based auth works nicely, is easy to setup and use and is unfeasible to break by trial and error across a remote network connection. Using firewall blocking on top of this is still useful (to reduce the noise in the log files and stop system resources being sucked up by SSH's crypto requirements) but it shouldn't be a necessity. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080930/68d06f3c/signature.pgp From bu7cher at yandex.ru Tue Sep 30 05:53:16 2008 From: bu7cher at yandex.ru (Andrey V. Elsukov) Date: Tue Sep 30 05:53:23 2008 Subject: ATA Security patch to atacontrol In-Reply-To: <20080930023946.GA23425@icarus.home.lan> References: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> <20080930023946.GA23425@icarus.home.lan> Message-ID: <48E1BEC0.6060407@yandex.ru> Jeremy Chadwick wrote: > Can you provide me datasheet and technical reference material to what > "ATA Security" is? Which ATA specification is this documented in? I'd > like to read it. I think you can found it in ATA-ATAPI-7 vol.1: "4.7 Security Mode feature set". http://en.wikipedia.org/wiki/Advanced_Technology_Attachment#HDD_Passwords_and_Security http://en.wikipedia.org/wiki/Advanced_Technology_Attachment#ATA_standards_versions.2C_transfer_rates.2C_and_features -- WBR, Andrey V. Elsukov From rb at gid.co.uk Tue Sep 30 07:50:36 2008 From: rb at gid.co.uk (Bob Bishop) Date: Tue Sep 30 07:50:42 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <79B5654C-62A9-4D8B-9556-2C38D6D51452@gid.co.uk> Hi, On 30 Sep 2008, at 01:10, Rich Healey wrote: > Recently I'm getting a lot of brute force attempts on my server, in > the > past I've used various tips and tricks with linux boxes but many of > them > were fairly linux specific. > > What do you BSD guys use for this purpose? [various solutions proposed] I too would worry about having something automatically updating filter rulesets. An alternative is to blackhole route the offending source, eg: route -nq add -host a.b.c.d 127.0.0.1 -blackhole WHatever solution you adopt, the ability to whitelist is a very good idea (especially if you are as inaccurate a typist as I am). And I'd second what others have said about avoiding passwords altogether if it's possible in your situation. -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 mobile +44 (0)783 626 4518 From asmodai at in-nomine.org Tue Sep 30 07:56:36 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue Sep 30 07:56:48 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <20080930075632.GT30869@nexus.in-nomine.org> -On [20080930 05:14], Rich Healey (healey.rich@gmail.com) wrote: >What do you BSD guys use for this purpose? I actually use blockhosts, which is a Python solution you tie into hosts.allow. http://www.aczoom.com/cms/blockhosts -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Happiness is the absence of the striving for happiness... From roberto at keltia.freenix.fr Tue Sep 30 08:16:40 2008 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Tue Sep 30 08:16:51 2008 Subject: SSH Brute Force attempts In-Reply-To: <200809291939.41533.rhavenn@rhavenn.net> References: <48E16E93.3090601@gmail.com> <200809291939.41533.rhavenn@rhavenn.net> Message-ID: <20080930081637.GA34744@keltia.freenix.fr> According to Henrik Hudson: > Yeap, -security > > However, also try this in pf.conf (specific rules related to this; you'll need > more for a real pf.conf): > > table { } persist > block in quick from > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state > (max-src-conn 5, max-src-conn-rate 4/300, overload flush global) That one is very effective. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Darwin sidhe.keltia.net Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; i386 From olli at lurza.secnetix.de Tue Sep 30 08:22:24 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Sep 30 08:22:32 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> Message-ID: <200809300822.m8U8MMXV026149@lurza.secnetix.de> Rich Healey wrote: > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? There's nothing that replaces using either *good* passwords or *no* passwords at all (i.e. ssh keys instead). I completely agree with Jeremy Chadwick that using programs that change your packet filter rules automatically can be dangerous. I recommend against this. Especially it does not protect you if you have weak passwords. In fact it might open a hole that someone can successfully run a DoS attack against your machine by spoofing one of your own IP addresses, or the IP address of your upstream router, or DNS server, or whatever. If you're merely annoyed about the large amount of logging entries caused by the break-in attempts, a good solution is to move the sshd service from the standard port 22 to a different, non-standard port (e.g. 222 or whatever, but it should be a "reserved" port, i.e. less than 1024 which is the default high limit for the reserved port range). Most attackers are just "script kiddies" that use automated software that tries only port 22. You can put an entry in ~/.ssh/config on your client machines so you don't even have to remember to specify the port number when ssh'ing to your server. Alternatively you can configure sshd to listen on port 22 *and* an alternate port, and block port 22 for everything except a few known-good addresses or networks. That way you don't have to do anything special when connecting from any of your usual clients, but you can still connect from anywhere else if necessary by using the non-standard port. Of course, the non-standard port trick is *not* a security measure. It only makes your machine "a little bit more invisible" to script kiddies and prevents them from filling your log files. It might also give you a very small advance in case of zero-day attacks. It does *not* help against weak passwords or lazyness to patch known holes, or other kinds of operator failure. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "What is this talk of 'release'? We do not make software 'releases'. Our software 'escapes', leaving a bloody trail of designers and quality assurance people in its wake." From bipolor at gmail.com Tue Sep 30 09:25:55 2008 From: bipolor at gmail.com (Mike Price) Date: Tue Sep 30 09:26:01 2008 Subject: How do I unchown a directory after I: chown -R /etc ??? Message-ID: How do I unchown a directory after I: chown -R /etc From asmodai at in-nomine.org Tue Sep 30 09:36:34 2008 From: asmodai at in-nomine.org (Jeroen Ruigrok van der Werven) Date: Tue Sep 30 09:36:41 2008 Subject: How do I unchown a directory after I: chown -R /etc ??? In-Reply-To: References: Message-ID: <20080930093632.GU30869@nexus.in-nomine.org> -On [20080930 11:26], Mike Price (bipolor@gmail.com) wrote: >How do I unchown a directory after I: chown -R /etc There is no unchown. You either rechown with the correct users or you use mtree with one of the dist files in /etc/mtree to recreate the directory structure with the correct rights/users. -- Jeroen Ruigrok van der Werven / asmodai ????? ?????? ??? ?? ?????? http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B What's in a name? That which we call a rose by any other name would smell as sweet... From daniel at roe.ch Tue Sep 30 09:41:41 2008 From: daniel at roe.ch (Daniel Roethlisberger) Date: Tue Sep 30 09:41:49 2008 Subject: ATA Security patch to atacontrol In-Reply-To: <48E1BEC0.6060407@yandex.ru> References: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> <20080930023946.GA23425@icarus.home.lan> <48E1BEC0.6060407@yandex.ru> Message-ID: <20080930094315.GA1653@hobbes.ustdmz.roe.ch> Andrey V. Elsukov 2008-09-30: > Jeremy Chadwick wrote: > >Can you provide me datasheet and technical reference material to what > >"ATA Security" is? Which ATA specification is this documented in? I'd > >like to read it. > > I think you can found it in ATA-ATAPI-7 vol.1: "4.7 Security Mode feature > set". Exactly. Even though the actual T13 standard must be purchased, you can find the documents and drafts of it online at various places by googling for appropriate keywords. For example: http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-7/ The ATA command set, including the ATA Security commands, is in vol. 1. In 2005, there was a much-cited article in the German c't magazine about the security implications of ATA Security, which might be worth a read too. It is available online in English: http://www.heise.de/ct/english/05/08/172/ -- Daniel Roethlisberger http://daniel.roe.ch/ From koitsu at FreeBSD.org Tue Sep 30 09:45:23 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 30 09:45:29 2008 Subject: SSH Brute Force attempts In-Reply-To: <20080930075632.GT30869@nexus.in-nomine.org> References: <48E16E93.3090601@gmail.com> <20080930075632.GT30869@nexus.in-nomine.org> Message-ID: <20080930094520.GA42893@icarus.home.lan> On Tue, Sep 30, 2008 at 09:56:32AM +0200, Jeroen Ruigrok van der Werven wrote: > -On [20080930 05:14], Rich Healey (healey.rich@gmail.com) wrote: > >What do you BSD guys use for this purpose? > > I actually use blockhosts, which is a Python solution you tie into > hosts.allow. > > http://www.aczoom.com/cms/blockhosts In no way shape or form does this solve the problem of the attackers being able to establish a TCP connection to you -- they are still tying up sockets, mbufs, and extra network I/O (coming from you when you respond and close the socket). TCP wrappers are absolutely 100% worthless in this day and age. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Tue Sep 30 09:47:10 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Sep 30 09:47:17 2008 Subject: How do I unchown a directory after I: chown -R /etc ??? In-Reply-To: References: Message-ID: <20080930094707.GB42893@icarus.home.lan> On Tue, Sep 30, 2008 at 02:25:54AM -0700, Mike Price wrote: > How do I unchown a directory after I: chown -R /etc You can't. Restore /etc from backups. And ***please*** stop posting this stuff to -hackers. It is not the appropriate list for it. Start using -questions. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From des at des.no Tue Sep 30 10:00:07 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 30 10:00:14 2008 Subject: SSH Brute Force attempts In-Reply-To: <200809300822.m8U8MMXV026149@lurza.secnetix.de> (Oliver Fromme's message of "Tue, 30 Sep 2008 10:22:22 +0200 (CEST)") References: <200809300822.m8U8MMXV026149@lurza.secnetix.de> Message-ID: <86abdqkl7g.fsf@ds4.des.no> Oliver Fromme writes: > If you're merely annoyed about the large amount of logging entries > caused by the break-in attempts, a good solution is to move the sshd > service from the standard port 22 to a different, non-standard port The best choice is 443, as many corporate firewalls, especially "guest" wifi networks, block all but a few ports (usually 22, 80 and 443, and sometimes 25). There are other, more complicated tricks you can play; for instance, you could set up a web server on the box, and configure it to tunnel SSH using the HTTP Upgrade header; this would require modifications to both ssh (to send the initial HTTP request) and sshd (to take over the connection from the web server). DES -- Dag-Erling Sm?rgrav - des@des.no From des at des.no Tue Sep 30 10:27:14 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Sep 30 10:27:21 2008 Subject: How do I unchown a directory after I: chown -R /etc ??? In-Reply-To: <20080930094707.GB42893@icarus.home.lan> (Jeremy Chadwick's message of "Tue, 30 Sep 2008 02:47:07 -0700") References: <20080930094707.GB42893@icarus.home.lan> Message-ID: <861vz2kjy7.fsf@ds4.des.no> Jeremy Chadwick writes: > Mike Price writes: > > How do I unchown a directory after I: chown -R /etc > You can't. Restore /etc from backups. Better solution: use mtree to generate a spec file from a clean tree and apply it. You can get a clean copy of etc in /var/tmp/temproot by running mergemaster and answering no to every question. DES -- Dag-Erling Sm?rgrav - des@des.no From lars.engels at 0x20.net Tue Sep 30 05:44:05 2008 From: lars.engels at 0x20.net (Lars Engels) Date: Tue Sep 30 11:36:05 2008 Subject: SSH Brute Force attempts In-Reply-To: <48E16E93.3090601@gmail.com> References: <48E16E93.3090601@gmail.com> Message-ID: <20080930074403.z41gl0wk1bko8c48@0x20.net> Quoting Rich Healey : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Recently I'm getting a lot of brute force attempts on my server, in the > past I've used various tips and tricks with linux boxes but many of them > were fairly linux specific. > > What do you BSD guys use for this purpose? > > If this belongs on -security let me know and I'll ask over there. Just do not use password authentication but public key authentication and a reasonable passphrase on it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: Digitale PGP-Unterschrift Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080930/67b38c33/attachment.pgp From bruce at cran.org.uk Tue Sep 30 13:24:27 2008 From: bruce at cran.org.uk (Bruce Cran) Date: Tue Sep 30 13:24:35 2008 Subject: ATA Security patch to atacontrol In-Reply-To: <20080930094315.GA1653@hobbes.ustdmz.roe.ch> References: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> <20080930023946.GA23425@icarus.home.lan> <48E1BEC0.6060407@yandex.ru> <20080930094315.GA1653@hobbes.ustdmz.roe.ch> Message-ID: <48E22862.3040004@cran.org.uk> Daniel Roethlisberger wrote: > Andrey V. Elsukov 2008-09-30: > >> Jeremy Chadwick wrote: >> >>> Can you provide me datasheet and technical reference material to what >>> "ATA Security" is? Which ATA specification is this documented in? I'd >>> like to read it. >>> >> I think you can found it in ATA-ATAPI-7 vol.1: "4.7 Security Mode feature >> set". >> > > Exactly. Even though the actual T13 standard must be purchased, you can > find the documents and drafts of it online at various places by googling > for appropriate keywords. For example: > > http://hddguru.com/content/en/documentation/2006.01.27-ATA-ATAPI-7/ > > The ATA command set, including the ATA Security commands, is in vol. 1. > > In 2005, there was a much-cited article in the German c't magazine about > the security implications of ATA Security, which might be worth a read > too. It is available online in English: > > http://www.heise.de/ct/english/05/08/172 http://www.t13.org has all the latest drafts at http://www.t13.org/Documents/MinutesDefault.aspx?DocumentType=4&DocumentStage=2 -- Bruce Cran From olli at lurza.secnetix.de Tue Sep 30 14:01:29 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Sep 30 14:01:35 2008 Subject: SSH Brute Force attempts In-Reply-To: <20080930081637.GA34744@keltia.freenix.fr> Message-ID: <200809301401.m8UE1QDm039930@lurza.secnetix.de> Ollivier Robert <> wrote: > According to Henrik Hudson: > > Yeap, -security > > > > However, also try this in pf.conf (specific rules related to this; you'll need > > more for a real pf.conf): > > > > table { } persist > > block in quick from > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state > > (max-src-conn 5, max-src-conn-rate 4/300, overload flush global) > > That one is very effective. It's especially effective to enable to DoS you. An attacker simply has to spoof the source address on SYN packets, which is trivial. :-( It is marginally better to use one of those tools that parse the logs for failed ssh logins, and use that information to block addresses. In order to abuse that, and attacker would have to spoof a full TCP connection setup plus initial SSH conversation, which is far from trivial. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Perl will consistently give you what you want, unless what you want is consistency." -- Larry Wall From m.seaman at infracaninophile.co.uk Tue Sep 30 15:07:32 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Tue Sep 30 15:07:39 2008 Subject: SSH Brute Force attempts In-Reply-To: <200809301401.m8UE1QDm039930@lurza.secnetix.de> References: <200809301401.m8UE1QDm039930@lurza.secnetix.de> Message-ID: <48E240AB.9040802@infracaninophile.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Oliver Fromme wrote: | Ollivier Robert <> wrote: | > According to Henrik Hudson: | > > Yeap, -security | > > | > > However, also try this in pf.conf (specific rules related to this; you'll need | > > more for a real pf.conf): | > > | > > table { } persist | > > block in quick from | > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state | > > (max-src-conn 5, max-src-conn-rate 4/300, overload flush global) | > | > That one is very effective. | | It's especially effective to enable to DoS you. | An attacker simply has to spoof the source address | on SYN packets, which is trivial. :-( Adding a whitelist of ssh addresses that should never be blocked is equally trivial.... But, like the perl folk say: TIMTOWTDI. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. Flat 3 ~ 7 Priory Courtyard PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate ~ Kent, CT11 9PW, UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREDAAYFAkjiQKsACgkQ3jDkPpsZ+VbzsgCfY64vNfuMhRrGRYgK4rDawWq4 xDwAnRMXY54hiooKCFBp7U/SxILUsxsa =yQm5 -----END PGP SIGNATURE----- From danger at FreeBSD.org Tue Sep 30 15:25:37 2008 From: danger at FreeBSD.org (Daniel Gerzo) Date: Tue Sep 30 15:28:26 2008 Subject: SSH Brute Force attempts In-Reply-To: <20080930033033.GA35849@icarus.home.lan> References: <48E16E93.3090601@gmail.com> <20080930033033.GA35849@icarus.home.lan> Message-ID: <33bf69ba4e07a4aea346fc25f7939bc7@services.rulez.sk> Hello guys, On Mon, 29 Sep 2008 20:30:33 -0700, Jeremy Chadwick wrote: > On Tue, Sep 30, 2008 at 10:10:59AM +1000, Rich Healey wrote: >> Recently I'm getting a lot of brute force attempts on my server, in the >> past I've used various tips and tricks with linux boxes but many of them >> were fairly linux specific. >> >> What do you BSD guys use for this purpose? > > This probably should've gone to -security, correct. > > There are 3 ports which people often use for solving this: > > ports/security/blocksshd > ports/security/sshblock > ports/security/sshguard-(pf|ipfw|ipfilter) There's also a tool written by me which can be found in security/bruteforceblocker - you may read a bit about it on http://danger.rulez.sk/index.php/bruteforceblocker/. The official release currently works only with pf, but I know there's a person working towards porting it to ipf/ipfw. He recently ported it to iptables and added CIDR support for whitelists, but I haven't had a time to review his changes, however once I get to it I will release a new version. -- Best regards Daniel Ger?o From pierre.riteau at gmail.com Tue Sep 30 15:28:57 2008 From: pierre.riteau at gmail.com (Pierre Riteau) Date: Tue Sep 30 15:29:26 2008 Subject: SSH Brute Force attempts In-Reply-To: <200809301401.m8UE1QDm039930@lurza.secnetix.de> References: <20080930081637.GA34744@keltia.freenix.fr> <200809301401.m8UE1QDm039930@lurza.secnetix.de> Message-ID: <20080930151550.GA20490@omicron.my.domain> On Tue, Sep 30, 2008 at 04:01:26PM +0200, Oliver Fromme wrote: > Ollivier Robert <> wrote: > > According to Henrik Hudson: > > > Yeap, -security > > > > > > However, also try this in pf.conf (specific rules related to this; you'll need > > > more for a real pf.conf): > > > > > > table { } persist > > > block in quick from > > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state > > > (max-src-conn 5, max-src-conn-rate 4/300, overload flush global) > > > > That one is very effective. > > It's especially effective to enable to DoS you. > An attacker simply has to spoof the source address > on SYN packets, which is trivial. :-( This is not true. pf.conf(5) says: For stateful TCP connections, limits on established connections (connec- tions which have completed the TCP 3-way handshake) can also be enforced per source IP. max-src-conn Limits the maximum number of simultaneous TCP connections which have completed the 3-way handshake that a single host can make. max-src-conn-rate / Limit the rate of new connections over a time interval. The con- nection rate is an approximation calculated as a moving average. Because the 3-way handshake ensures that the source address is not being spoofed, more aggressive action can be taken based on these limits. From olli at lurza.secnetix.de Tue Sep 30 15:37:42 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Sep 30 15:37:49 2008 Subject: SSH Brute Force attempts In-Reply-To: <20080930151550.GA20490@omicron.my.domain> Message-ID: <200809301537.m8UFbcrt044684@lurza.secnetix.de> Pierre Riteau wrote: > Oliver Fromme wrote: > > Ollivier Robert wrote: > > > According to Henrik Hudson: > > > > Yeap, -security > > > > > > > > However, also try this in pf.conf (specific rules related to this; you'll need > > > > more for a real pf.conf): > > > > > > > > table { } persist > > > > block in quick from > > > > pass in on $ext_if proto tcp from any to ($ext_if) port ssh keep state > > > > (max-src-conn 5, max-src-conn-rate 4/300, overload flush global) > > > > > > That one is very effective. > > > > It's especially effective to enable to DoS you. > > An attacker simply has to spoof the source address > > on SYN packets, which is trivial. :-( > > This is not true. pf.conf(5) says: > > For stateful TCP connections, limits on established connections (connec- > tions which have completed the TCP 3-way handshake) can also be enforced > per source IP. Thanks for the correction. I prefer IPFW most of the time, therefore I wasn't aware of this detail. > Because the 3-way handshake ensures that the source address is not being > spoofed, more aggressive action can be taken based on these limits. s/not being spoofed/more difficult to spoofe/ ;-) Still, detecting the break-in attempts on application layer (e.g. auth log file) is better than on TCP layer. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "It combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript." -- Jamie Zawinski, when asked: "What's wrong with perl?" From wmoran at collaborativefusion.com Tue Sep 30 15:50:16 2008 From: wmoran at collaborativefusion.com (Bill Moran) Date: Tue Sep 30 15:50:23 2008 Subject: SSH Brute Force attempts In-Reply-To: <200809301537.m8UFbcrt044684@lurza.secnetix.de> References: <20080930151550.GA20490@omicron.my.domain> <200809301537.m8UFbcrt044684@lurza.secnetix.de> Message-ID: <20080930115014.45a0cd88.wmoran@collaborativefusion.com> In response to Oliver Fromme : > Pierre Riteau wrote: > > > Because the 3-way handshake ensures that the source address is not being > > spoofed, more aggressive action can be taken based on these limits. > > s/not being spoofed/more difficult to spoofe/ ;-) On a modern OS (like FreeBSD) where ISNs are random, the possibility of blindly spoofing an IP during a 3-way handshake is so low as to be effectively impossible. Yes, it _can_ be done, but the effort required makes it not an effective method of attack. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023 From olli at lurza.secnetix.de Tue Sep 30 16:08:29 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Tue Sep 30 16:08:36 2008 Subject: SSH Brute Force attempts In-Reply-To: <20080930115014.45a0cd88.wmoran@collaborativefusion.com> Message-ID: <200809301605.m8UG5xpr046010@lurza.secnetix.de> Bill Moran wrote: > In response to Oliver Fromme : > > Pierre Riteau wrote: > > > > > Because the 3-way handshake ensures that the source address is not being > > > spoofed, more aggressive action can be taken based on these limits. > > > > s/not being spoofed/more difficult to spoofe/ ;-) > > On a modern OS (like FreeBSD) where ISNs are random, the possibility of > blindly spoofing an IP during a 3-way handshake is so low as to be > effectively impossible. It depends a lot on the environment, for example whether the attacker has access (or can somehow get access) to the server's uplink and trace packets. This can happen if the server is located with many other servers on the same network, which is often the case for co-location or so-called root servers. Of course, if the network is regarded "secure", then you are right. Spoofing a TCP handshake would be very difficult in that case. (I try to avoid the word "impossible". Nothing is impossible, especially in the security business.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd Python is executable pseudocode. Perl is executable line noise. From igor at hybrid-lab.co.uk Tue Sep 30 16:15:50 2008 From: igor at hybrid-lab.co.uk (Igor Mozolevsky) Date: Tue Sep 30 16:15:56 2008 Subject: SSH Brute Force attempts In-Reply-To: <200809301605.m8UG5xpr046010@lurza.secnetix.de> References: <20080930115014.45a0cd88.wmoran@collaborativefusion.com> <200809301605.m8UG5xpr046010@lurza.secnetix.de> Message-ID: 2008/9/30 Oliver Fromme : > > Bill Moran wrote: > > In response to Oliver Fromme : > > > Pierre Riteau wrote: > > > > > > > Because the 3-way handshake ensures that the source address is not being > > > > spoofed, more aggressive action can be taken based on these limits. > > > > > > s/not being spoofed/more difficult to spoofe/ ;-) > > > > On a modern OS (like FreeBSD) where ISNs are random, the possibility of > > blindly spoofing an IP during a 3-way handshake is so low as to be > > effectively impossible. > > It depends a lot on the environment, for example whether > the attacker has access (or can somehow get access) to > the server's uplink and trace packets. This can happen > if the server is located with many other servers on the > same network, which is often the case for co-location > or so-called root servers. Yes, but in that situation you probably have the capacity to inject enough traffic into the pipe to cause a total blackout... > Of course, if the network is regarded "secure", then > you are right. Spoofing a TCP handshake would be very > difficult in that case. (I try to avoid the word > "impossible". Nothing is impossible, especially in > the security business.) Security is always about the balance between the effort+risk to you vs the effort+benefit to the attacker... -- Igor From gelraen.ua at gmail.com Tue Sep 30 22:37:33 2008 From: gelraen.ua at gmail.com (gelraen) Date: Tue Sep 30 22:37:40 2008 Subject: [powerd] Adding different adaptive-mode settings for each power source Message-ID: Hi, I've needed to set different idle levels for adaptive mode while on battery or on AC power. Cause powerd can only set mode (min, max, adp) for each power source, I've added this ability and it seems to be a good idea to share this improvement with others. Best regards, gelraen. P.S.: Sorry for my bad English :) --- usr.sbin/powerd/powerd.c.orig 2008-09-30 18:19:04.000000000 +0300 +++ usr.sbin/powerd/powerd.c 2008-10-01 00:49:52.000000000 +0300 @@ -66,6 +66,8 @@ SRC_UNKNOWN, } power_src_t; +#define SRCS_COUNT 3 /* Number of different power sources */ + const char *modes[] = { "AC", "battery", @@ -95,8 +97,8 @@ static int acline_mib[3]; /* Configuration */ -static int cpu_running_mark; -static int cpu_idle_mark; +static int cpu_running_mark[SRCS_COUNT]; +static int cpu_idle_mark[SRCS_COUNT]; static int poll_ival; static int vflag; @@ -357,7 +359,7 @@ { fprintf(stderr, -"usage: powerd [-v] [-a mode] [-b mode] [-i %%] [-n mode] [-p ival] [-r %%] [-P pidfile]\n"); +"usage: powerd [-v] [-a mode] [-b mode] [-A %%:%%] [-B %%:%%] [-i %%] [-n mode] [-N %%:%%] [-p ival] [-r %%] [-P pidfile]\n"); exit(1); } @@ -377,8 +379,11 @@ /* Default mode for all AC states is adaptive. */ mode_ac = mode_battery = mode_none = MODE_ADAPTIVE; - cpu_running_mark = DEFAULT_ACTIVE_PERCENT; - cpu_idle_mark = DEFAULT_IDLE_PERCENT; + for(i=0;i 100) { + warnx("%d is not a valid percent", + cpu_running_mark[SRC_AC]); + usage(); + } + cpu_idle_mark[SRC_AC] = atoi(optarg+i+1); + if (cpu_idle_mark[SRC_AC] < 0 || cpu_idle_mark[SRC_AC] > 100) { + warnx("%d is not a valid percent", + cpu_idle_mark[SRC_AC]); + usage(); + } + break; + case 'B': + i=0; + while (optarg[i]!='\0' && optarg[i]!=':') i++; + if (optarg[i]!=':') + { + warnx("%s is not a valid setting",optarg); + usage(); + } + optarg[i]='\0'; + cpu_running_mark[SRC_BATTERY] = atoi(optarg); + optarg[i]=':'; + if (cpu_running_mark[SRC_BATTERY] < 0 || cpu_running_mark[SRC_BATTERY] > 100) { + warnx("%d is not a valid percent", + cpu_running_mark[SRC_BATTERY]); + usage(); + } + cpu_idle_mark[SRC_BATTERY] = atoi(optarg+i+1); + if (cpu_idle_mark[SRC_BATTERY] < 0 || cpu_idle_mark[SRC_BATTERY] > 100) { + warnx("%d is not a valid percent", + cpu_idle_mark[SRC_BATTERY]); + usage(); + } + break; + case 'N': + i=0; + while (optarg[i]!='\0' && optarg[i]!=':') i++; + if (optarg[i]!=':') + { + warnx("%s is not a valid setting",optarg); + usage(); + } + optarg[i]='\0'; + cpu_running_mark[SRC_UNKNOWN] = atoi(optarg); + optarg[i]=':'; + if (cpu_running_mark[SRC_UNKNOWN] < 0 || cpu_running_mark[SRC_UNKNOWN] > 100) { + warnx("%d is not a valid percent", + cpu_running_mark[SRC_UNKNOWN]); + usage(); + } + cpu_idle_mark[SRC_UNKNOWN] = atoi(optarg+i+1); + if (cpu_idle_mark[SRC_UNKNOWN] < 0 || cpu_idle_mark[SRC_UNKNOWN] > 100) { + warnx("%d is not a valid percent", + cpu_idle_mark[SRC_UNKNOWN]); + usage(); + } + break; case 'i': - cpu_idle_mark = atoi(optarg); - if (cpu_idle_mark < 0 || cpu_idle_mark > 100) { + cpu_idle_mark[0] = atoi(optarg); + if (cpu_idle_mark[0] < 0 || cpu_idle_mark[0] > 100) { warnx("%d is not a valid percent", - cpu_idle_mark); + cpu_idle_mark[0]); usage(); } + else + { + for(i=1;i 100) { + cpu_running_mark[0] = atoi(optarg); + if (cpu_running_mark[0] < 0 || cpu_running_mark[0] > 100) { warnx("%d is not a valid percent", - cpu_running_mark); + cpu_running_mark[0]); usage(); } + else + { + for(i=0;i (total * cpu_idle_mark) / 100 && + } else if (idle > (total * cpu_idle_mark[acline_status]) / 100 && curfreq > freqs[numfreqs - 1]) { i++; if (vflag) { printf("idle time > %d%%, decreasing clock" " speed from %d MHz to %d MHz\n", - cpu_idle_mark, curfreq, freqs[i]); + cpu_idle_mark[acline_status], curfreq, freqs[i]); } if (set_freq(freqs[i]) != 0) warn("error setting CPU frequency %d", --- usr.sbin/powerd/powerd.8.orig 2008-09-30 21:33:01.000000000 +0300 +++ usr.sbin/powerd/powerd.8 2008-10-01 00:52:15.000000000 +0300 @@ -34,8 +34,11 @@ .Nm .Op Fl a Ar mode .Op Fl b Ar mode +.Op Fl A Ar percent:percent +.Op Fl B Ar percent:percent .Op Fl i Ar percent .Op Fl n Ar mode +.Op Fl N Ar percent:percent .Op Fl p Ar ival .Op Fl P Ar pidfile .Op Fl r Ar percent @@ -93,6 +96,13 @@ adaptive mode should consider the CPU running and increase performance. The default is 65% or lower. +.It Fl A Ar percent:percent +Specifies parameters for adaptive mode while on AC power. +Default values in this notation will look as 65:90. Empty values treated as 0 +.It Fl B Ar percent:percent +Specifies parameters for adaptive mode while on battery. +.It Fl N Ar percent:percent +Specifies parameters for adaptive mode when AC line state is unknown. .It Fl v Verbose mode. Messages about power changes will be printed to stdout and From daniel at roe.ch Tue Sep 30 22:45:17 2008 From: daniel at roe.ch (Daniel Roethlisberger) Date: Tue Sep 30 22:45:25 2008 Subject: ATA Security patch to atacontrol In-Reply-To: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> References: <20080929230655.GA16790@hobbes.ustdmz.roe.ch> Message-ID: <20080930224655.GG11823@hobbes.ustdmz.roe.ch> Daniel Roethlisberger 2008-09-30: > I've added experimental support for the ATA Security command set to > atacontrol. Please test and review. If you have some spare disk(s) > with ATA Security support and a BIOS which does not freeze the security > configuration, I'd like to hear about any results of playing with this > patch. See the changes to the manual page for details on the commands. > > Note that you may render disks unusable using the ATA Security commands. > Use with great care. I've slightly improved the patch. Changes: - More sane timeouts on ATA commands - Print a security usage if parameters are illegal - Extended the manual page with some examples and notes about which commands are lethal to mounted filesystems - Teach the kernel about the ATA Security command codes (for console printf messages) Even with the kernel changes, a kernel rebuild is not required in order to test the code. http://daniel.roe.ch/code/ata/atasecurity-20081001-complete.diff Please send me feedback. -- Daniel Roethlisberger http://daniel.roe.ch/