From Andre.Albsmeier at siemens.com Thu Oct 1 15:12:34 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Thu Oct 1 15:12:41 2009 Subject: Bug in 7.2-STABLE's /bin/sh? Message-ID: <20091001144946.GA75477@curry.mchp.siemens.de> Hello all, is it correct to print OK here? ------------------ snip ------------------ #!/bin/sh if false || ! echo bla | grep -q bla; then echo OK fi ------------------ snap ------------------- 7.2-STABLE (can't check others at the moment) does which I think is wrong... Thanks, -Andre From avg at icyb.net.ua Thu Oct 1 15:44:13 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Oct 1 15:44:20 2009 Subject: Bug in 7.2-STABLE's /bin/sh? In-Reply-To: <20091001144946.GA75477@curry.mchp.siemens.de> References: <20091001144946.GA75477@curry.mchp.siemens.de> Message-ID: <4AC4CE48.3080803@icyb.net.ua> on 01/10/2009 17:49 Andre Albsmeier said the following: > Hello all, > > is it correct to print OK here? > > ------------------ snip ------------------ > > #!/bin/sh > > if false || ! echo bla | grep -q bla; then > echo OK > fi > > ------------------ snap ------------------- > > 7.2-STABLE (can't check others at the moment) > does which I think is wrong... This looks like a bug and it seems to be fixed in head. Forgotten MFC? -- Andriy Gapon From Andre.Albsmeier at siemens.com Thu Oct 1 18:31:04 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Thu Oct 1 18:31:11 2009 Subject: Bug in 7.2-STABLE's /bin/sh? In-Reply-To: <4AC4CE48.3080803@icyb.net.ua> References: <20091001144946.GA75477@curry.mchp.siemens.de> <4AC4CE48.3080803@icyb.net.ua> Message-ID: <20091001183101.GB76820@curry.mchp.siemens.de> On Thu, 01-Oct-2009 at 18:44:08 +0300, Andriy Gapon wrote: > on 01/10/2009 17:49 Andre Albsmeier said the following: > > Hello all, > > > > is it correct to print OK here? > > > > ------------------ snip ------------------ > > > > #!/bin/sh > > > > if false || ! echo bla | grep -q bla; then > > echo OK > > fi > > > > ------------------ snap ------------------- > > > > 7.2-STABLE (can't check others at the moment) > > does which I think is wrong... > > This looks like a bug and it seems to be fixed in head. > Forgotten MFC? Have you got a PR# handy? -Andre From Andre.Albsmeier at siemens.com Thu Oct 1 19:31:49 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Thu Oct 1 19:31:56 2009 Subject: Bug in 7.2-STABLE's /bin/sh? In-Reply-To: <20091001183101.GB76820@curry.mchp.siemens.de> References: <20091001144946.GA75477@curry.mchp.siemens.de> <4AC4CE48.3080803@icyb.net.ua> <20091001183101.GB76820@curry.mchp.siemens.de> Message-ID: <20091001191219.GA77569@curry.mchp.siemens.de> On Thu, 01-Oct-2009 at 20:31:01 +0200, Andre Albsmeier wrote: > On Thu, 01-Oct-2009 at 18:44:08 +0300, Andriy Gapon wrote: > > on 01/10/2009 17:49 Andre Albsmeier said the following: > > > Hello all, > > > > > > is it correct to print OK here? > > > > > > ------------------ snip ------------------ > > > > > > #!/bin/sh > > > > > > if false || ! echo bla | grep -q bla; then > > > echo OK > > > fi > > > > > > ------------------ snap ------------------- > > > > > > 7.2-STABLE (can't check others at the moment) > > > does which I think is wrong... > > > > This looks like a bug and it seems to be fixed in head. > > Forgotten MFC? > > Have you got a PR# handy? Found it myself: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/parser.c.diff?r1=1.60;r2=1.61 seems to be it. Could someone please MFC that to 7.2? Thanks, -Andre From yuval_levy at yahoo.com Thu Oct 1 20:40:05 2009 From: yuval_levy at yahoo.com (yuval levy) Date: Thu Oct 1 20:40:21 2009 Subject: Intel S3420GPLC Message-ID: <966178.16483.qm@web50508.mail.re2.yahoo.com> Hi all I've searched the archives and the web in vain. Maybe somebody here can tell me how well FreeBSD stable supports Intel's entry level server board S3420GPLC? specifically, will it work with the on board RAID? thanks Yuv From crapsh at monkeybrains.net Thu Oct 1 21:07:06 2009 From: crapsh at monkeybrains.net (Rudy (bulk)) Date: Thu Oct 1 21:07:13 2009 Subject: em0 watchdog timeouts In-Reply-To: <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> Message-ID: <4AC5198E.7030609@monkeybrains.net> I have rxd and txd set to 1024. How high can I safely go? # add more descriptors to em devices. hw.em.rxd=1024 hw.em.txd=1024 ### other settings... I have tried rx_int_delay=0 and 32 ... doesn't seem to make the watchdogs go away. dev.em.4.rx_int_delay: 32 dev.em.4.tx_int_delay: 66 dev.em.4.rx_abs_int_delay: 66 dev.em.4.tx_abs_int_delay: 66 dev.em.4.rx_processing_limit: 300 I am using a PCI-Express (x8) PCI-e slot according to the motherboard specs: http://supermicro.com/products/motherboard/Xeon3000/3210/X7SBi.cfm Rudy Jack Vogel wrote: > Increase the size of your TX ring, meaning the number of TX descriptors. > > You said this is a quad port card, what size PCI E slot are you in? On > some motherboards slot connectors might suggest its of a certain size > but its not really wired fully. If you are not in a x8 lane slot move it to > one. > > What about system tuning? > > Some ideas, let me know how it goes. > > Jack > > > On Wed, Sep 30, 2009 at 3:28 PM, Rudy wrote: > > >> Rudy wrote: >> >> >>> Rudy wrote: >>> >>> >>>> I am having watchdog timeout issues >>>> >>>> >> Oh, here is some more info from 'pciconf -lcv'. >> >> I offloaded half the traffic from em0 to em5 and there has only been one >> watchdog timeout today (on em5) vs. 10 watchdog timeouts yesterday. We do >> streaming out of our network and the 3 second outage really messes things >> up... >> >> >> em0@pci0:5:0:0: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82571EB Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) >> em1@pci0:5:0:1: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82571EB Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) >> em2@pci0:6:0:0: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82571EB Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) >> em3@pci0:6:0:1: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82571EB Gigabit Ethernet Controller' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x4(x4) >> em4@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82573E Intel Corporation 82573E Gigabit Ethernet >> Controller (Copper)' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >> em5@pci0:15:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 >> rev=0x00 hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82573L Intel PRO/1000 PL Network Adaptor' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) >> vgapci0@pci0:17:3:0: class=0x030000 card=0xd18015d9 chip=0x515e1002 >> rev=0x02 >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > From crapsh at monkeybrains.net Thu Oct 1 21:14:32 2009 From: crapsh at monkeybrains.net (Rudy (bulk)) Date: Thu Oct 1 21:14:39 2009 Subject: em0 watchdog timeouts In-Reply-To: <4AC5198E.7030609@monkeybrains.net> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> Message-ID: <4AC51B4C.7080905@monkeybrains.net> I have a quad card in a PCIe 8x port, and there are 2 ports on the motherboard. I just read the manual and see that the on board ports are PCIe 1x. I have been seeing watchdog events on the onboard ports as well as on the PCIe card. The router is doing roughly 50Mbps on em0, em4 & em5. Does i386 vs amd64 make any difference to the em0 driver? bumping TX Ring to 2048. grep em /boot/loader.conf if_em_load="YES" hw.em.rxd=2048 hw.em.txd=2048 Rudy >> >> You said this is a quad port card, what size PCI E slot are you in? From jfvogel at gmail.com Thu Oct 1 21:50:19 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Oct 1 21:50:28 2009 Subject: em0 watchdog timeouts In-Reply-To: <4AC51B4C.7080905@monkeybrains.net> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> Message-ID: <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> I would say that 1024 should be enough, I thought maybe you were at 256. amd64 kernels just perform better at a lot of things, however I/O is not necessarily one of them, so I wouldn't claim it for sure, still I'd always default to 64 bit these days unless there's some other reason not to. What about system load, perhaps something is bogging the thing down so that it cannot adequately service the network interrupts?? The specs of the motherboard are respectable, how much memory does it have? Another thought, are you using the out-of-band management features (like IPMI)? If you are not then go into the BIOS and disable that stuff. Have you run netstat or some other resource monitor to see if you run out of anything that might coincide with the watchdogs... Jack On Thu, Oct 1, 2009 at 2:12 PM, Rudy (bulk) wrote: > > I have a quad card in a PCIe 8x port, and there are 2 ports on the > motherboard. I just read the manual and see that the on board ports are > PCIe 1x. > > I have been seeing watchdog events on the onboard ports as well as on the > PCIe card. The router is doing roughly 50Mbps on em0, em4 & em5. > > Does i386 vs amd64 make any difference to the em0 driver? > > bumping TX Ring to 2048. grep em /boot/loader.conf > > if_em_load="YES" > hw.em.rxd=2048 > hw.em.txd=2048 > > Rudy > > > > > >>> You said this is a quad port card, what size PCI E slot are you in? >>> >> > From crapsh at monkeybrains.net Fri Oct 2 00:38:37 2009 From: crapsh at monkeybrains.net (Rudy) Date: Fri Oct 2 00:38:44 2009 Subject: em0 watchdog timeouts In-Reply-To: <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> Message-ID: <4AC54B87.2030604@monkeybrains.net> > What about system load, perhaps something is bogging the thing down so that > it cannot adequately service the network interrupts?? > Hardly anything is running on the box... Only things on the box: zebra bgpd (3 peers...) sshd snmpd Here is the top of 'top': load averages: 0.06, 0.08, 0.07 up 7+01:08:16 17:26:39 15 processes: 1 running, 14 sleeping CPU: 0.0% user, 0.0% nice, 4.5% system, 0.0% interrupt, 95.5% idle Mem: 193M Active, 42M Inact, 156M Wired, 196K Cache, 83M Buf, 1610M Free > The specs of the motherboard are respectable, how much memory does it have? > > Another thought, are you using the out-of-band management features (like > IPMI)? > If you are not then go into the BIOS and disable that stuff. > No IPMI card added to that motherboard (you have to add a daughter card). > Have you run netstat or some other resource monitor to see if you run out of > anything that might coincide with the watchdogs... What should I look for? # netstat -s 4105/4610/8715 mbufs in use (current/cache/total) 4103/2303/6406/25600 mbuf clusters in use (current/cache/total/max) 4103/2297 mbuf+clusters out of packet secondary zone in use (current/cache) 0/44/44/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 9232K/5934K/15166K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/6/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines Are there specific router-only tunings that may help? Here are my sysctl settings: kern.ipc.somaxconn=256 kern.random.sys.harvest.interrupt=0 kern.random.sys.harvest.ethernet=0 kern.ipc.nmbcluster=32768 net.inet.icmp.icmplim=1000 net.inet.ip.fastforwarding=1 net.inet.ip.intr_queue_maxlen=92 net.inet.icmp.drop_redirect=1 dev.em.0.rx_processing_limit=200 dev.em.1.rx_processing_limit=200 dev.em.2.rx_processing_limit=200 #dev.em.4.rx_processing_limit=200 # test setting processing limit up to 300 dev.em.4.rx_processing_limit=300 dev.em.5.rx_processing_limit=200 Thanks, Rudy From john.marshall at riverwillow.com.au Fri Oct 2 04:16:41 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Oct 2 04:16:48 2009 Subject: [SOLVED] sshd GSSAPIAuthentication broken after 8.0-BETA1 upgrade In-Reply-To: <20090708085202.GS1025@rwpc12.mby.riverwillow.net.au> References: <20090708085202.GS1025@rwpc12.mby.riverwillow.net.au> Message-ID: <20091002041635.GH37304@rwpc12.mby.riverwillow.net.au> Apologies for including all of OP - but it was 3 months ago and provides necessary context. See solution below OP. On Wed, 08 Jul 2009, 18:52 +1000, John Marshall wrote: > I source upgraded a (test) server here (i386) from 7.2-RELEASE-p2 to > 8.0-BETA1 this morning. I use GSSAPI as the primary authentication > method for sshd on that server. After the upgrade GSSAPI authentication > stopped working and I can't get enough information to figure out why. > Perhaps the newer version of Heimdal behaves differently? Perhaps the > newer version of sshd behaves differently? > > If I run sshd with debug "-ddd" I see the following: > > debug1: attempt 1 failures 0 > debug2: input_userauth_request: try method gssapi-with-mic > debug3: mm_request_send entering: type 37 > debug3: mm_request_receive_expect entering: type 38 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 37 > debug3: mm_request_send entering: type 38 > debug3: mm_request_receive entering > Postponed gssapi-with-mic for john from 192.0.2.123 port 57225 ssh2 > debug3: mm_request_send entering: type 39 > debug3: mm_request_receive_expect entering: type 40 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 39 > debug1: Received some client credentials > debug3: mm_request_send entering: type 40 > debug3: mm_request_receive entering > debug3: mm_request_send entering: type 43 > debug3: mm_request_receive_expect entering: type 44 > debug3: mm_request_receive entering > debug3: monitor_read: checking request 43 > debug3: mm_request_send entering: type 44 > debug3: mm_request_receive entering > GSSAPI MIC check failed > > On the client side (with ssh -vvv) I see: > > debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup gssapi-with-mic > debug3: remaining preferred: publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-with-mic > debug1: Next authentication method: gssapi-with-mic > debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Delegating credentials > debug1: Delegating credentials > debug1: Authentications that can continue: publickey,gssapi-with-mic,keyboard-interactive > debug2: we did not send a packet, disable method > > Does anybody know of changes between existing STABLE releases and 8.0 > which would cause this behaviour - and how to accommodate it? Do any > strange Kerberos things need to be done as part of the upgrade? > > The client still happily authenticates via GSSAPI to sshd on our other > 7.2-RELEASE servers. Subsequent authentication methods succeed on the > 8.0-BETA1 sshd server, it's just GSSAPI that isn't working. With help from Jim Basney on the OpenSSH-dev mailing list, I was able to determine that the gssapi error underlying the sshd debug message "GSSAPI MIC check failed" was GSS_S_BAD_SIG (GSS_S_BAD_MIC). That proved that it was a Kerberos problem but didn't give me any clue as to why a FreeBSD 8.0 server would regard as BAD signatures that were happily validated on FreeBSD 7.2 servers. I am indebted to David P. Discher for discovering this solution. The problem is related to the difference in Heimdal Kerberos versions shipped with FreeBSD 7.2 and 8.0. FreeBSD 7.2 --> Heimdal 0.6.3 FreeBSD 8.0 --> Heimdal 1.1.0 - FreeBSD 7.2 Kerberos includes a broken-by-default gssapi-with-mic. - FreeBSD 8.0 Kerberos includes a correct gssapi-with-mic. FreeBSD 8.0 Kerberos doesn't understand the message produced by the FreeBSD 7.2 Kerberos broken gssapi-with-mic. Fortunately Heimdal 0.6 understands messages produced by both the broken and correct gssapi-with-mic AND provides a switch to enable use of the correct gssapi-with-mic. So, in order to produce messages which can be processed by FreeBSD 8.0 Kerberos, FreeBSD 7.2 machines must add entries like the following to their /etc/krb5.conf [gssapi] correct_des3_mic = host/my.freebsd8.server@MY.REALM correct_des3_mic = host/myother.freebsd8.server@MY.REALM Wildcards can also be used, so as long as none of your machines use a version of Heimdal earlier then 0.6, you can do something like: [gssapi] correct_des3_mic = host/* Note that the Heimdal 0.6.3 verify_krb5_conf utility doesn't know about the [gssapi] section and will flag it as an error. For a full description of the broken/correct gssapi-with-mic issue, see the COMPATIBILITY section of the Heimdal 0.6.3 gssapi(3) man page shipped with (but not installed on) FreeBSD 7.2 /usr/src/crypto/heimdal/lib/gssapi/gssapi.3: $Id: gssapi.3,v 1.5.2.2 2003/04/30 09:56:26 lha Exp $ -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091002/fda64e4d/attachment.pgp From john.marshall at riverwillow.com.au Fri Oct 2 05:31:42 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri Oct 2 05:37:27 2009 Subject: FreeBSD 8.0 Kerberos Login New Behaviour (.k5login) Message-ID: <20091002053134.GJ37304@rwpc12.mby.riverwillow.net.au> Having just spent ages trying to discover why I couldn't log in to one of my recently-upgraded FreeBSD 8.0-RC1 servers... Kerberos login processing has changed! I had a .k5login file on the server with a single entry: john/admin@MY.REALM On FreeBSD 7.2 that meant that I could log in as john on that server with either my john@ (default principal/account mapping) or my john/admin@ (by virtue of .k5login) principal. On FreeBSD 8.0 that means that ONLY john/admin@ can login to that account. The fact that a .k5login file is present restricts access to principals listed in that file. Anyone like to guess where the .k5login man page is? Try krb5_kuserok(3). FreeBSD 7.2 Kerberos Login -------------------------- First krb5_kuserok check if there is a local account name username. If there isn't, krb5_kuserok returns FALSE. Then krb5_kuserok checks if principal is the same as user@realm in any of the default realms. If that is the case, krb5_kuserok returns TRUE. After that it reads the file .k5login (if it exists) in the users home directory and checks if principal is in the file. If it does exists, TRUE is returned. If neither of the above turns out to be true, is returned. FreeBSD 8.0 Kerberos Login -------------------------- The user may have a ~/.k5login file listing principals that are allowed to login as that user. If that file does not exist, all principals with a first component identical to the username, and a realm considered local, are allowed access. Note that if the file exists, no implicit access rights are given to user@. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091002/43d69808/attachment.pgp From stefanf at FreeBSD.org Fri Oct 2 07:47:51 2009 From: stefanf at FreeBSD.org (Stefan Farfeleder) Date: Fri Oct 2 07:47:58 2009 Subject: Bug in 7.2-STABLE's /bin/sh? In-Reply-To: <20091001191219.GA77569@curry.mchp.siemens.de> References: <20091001144946.GA75477@curry.mchp.siemens.de> <4AC4CE48.3080803@icyb.net.ua> <20091001183101.GB76820@curry.mchp.siemens.de> <20091001191219.GA77569@curry.mchp.siemens.de> Message-ID: <20091002072829.GA1610@lizard.fafoe.narf.at> On Thu, Oct 01, 2009 at 09:12:19PM +0200, Andre Albsmeier wrote: > On Thu, 01-Oct-2009 at 20:31:01 +0200, Andre Albsmeier wrote: > > On Thu, 01-Oct-2009 at 18:44:08 +0300, Andriy Gapon wrote: > > > on 01/10/2009 17:49 Andre Albsmeier said the following: > > > > Hello all, > > > > > > > > is it correct to print OK here? > > > > > > > > ------------------ snip ------------------ > > > > > > > > #!/bin/sh > > > > > > > > if false || ! echo bla | grep -q bla; then > > > > echo OK > > > > fi > > > > > > > > ------------------ snap ------------------- > > > > > > > > 7.2-STABLE (can't check others at the moment) > > > > does which I think is wrong... > > > > > > This looks like a bug and it seems to be fixed in head. > > > Forgotten MFC? > > > > Have you got a PR# handy? > > Found it myself: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/parser.c.diff?r1=1.60;r2=1.61 > > seems to be it. Could someone please MFC that to 7.2? Sorry, I'll merge it. From kama at pvp.se Fri Oct 2 11:24:10 2009 From: kama at pvp.se (kama) Date: Fri Oct 2 11:24:21 2009 Subject: FreeBSD 7.2-STABLE boot freeze In-Reply-To: <4AC35CC6.1020103@freebsd.org> References: <20090921140345.H37424@ns1.as.pvp.se> <20090922103150.V37424@ns1.as.pvp.se> <4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se> <4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se> <4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se> <4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se> <20090925110209.E37424@ns1.as.pvp.se> <4ABC894E.7040204@freebsd.org> <20090928092026.B37424@ns1.as.pvp.se> <4AC06ED6.7030402@freebsd.org> <20090928235136.F37424@ns1.as.pvp.se> <20090929085000.B37424@ns1.as.pvp.se> <4AC211AC.1070404@freebsd.org> <20090929204651.G37424@ns1.as.pvp.se> <4AC34952.9010508@freebsd.org> <20090930151542.G37424@ns1.as.pvp.se> <4AC35CC6.1020103@freebsd.org> Message-ID: <20091002132218.P37424@ns1.as.pvp.se> On Wed, 30 Sep 2009, Andriy Gapon wrote: > on 30/09/2009 16:21 kama said the following: > > > > It boot occationally. It does not seem to matter if I include the acpi > > device into the kernel or not. > > > > I get this message in an verbose boot: > > KLD file acpi.ko - could not finalize loading > > Do you get this message in all cases? That is, every time you tried? > Or only with ACPI_DEBUG defined? I cant recall. I have tried so many things lately. But I believe I get it on a verbose boot without ACPI_DEBUG. Im currently rebuilding the system to 8.0. /Bjorn From kama at pvp.se Fri Oct 2 15:08:40 2009 From: kama at pvp.se (kama) Date: Fri Oct 2 15:08:47 2009 Subject: acpi doc misconfusion... Message-ID: <20091002165602.Q37424@ns1.as.pvp.se> Hi, there are a lot of different errors in various document regarding acpi that are wrong. In 'man acpi' it says that 'hint.acpi.0.disabled' should be placed in loader.conf. ------------- LOADER TUNABLES Tunables can be set at the loader(8) prompt before booting the kernel or stored in /boot/loader.conf. Many of these tunables also have a matching sysctl(8) entry for access after boot. ... hint.acpi.0.disabled Set this to 1 to disable all of ACPI. If ACPI has been disabled on your system due to a blacklist entry for your BIOS, you can set this to 0 to re-enable ACPI for testing. ... ------------- In 'man loader' it says: ------------- acpi_load Unset this to disable automatic loading of the ACPI module. See also hint.acpi.0.disabled in device.hints(5). ------------- In 'man device.hints' ------------- The following example disables the ACPI driver: hint.acpi.0.disabled="1" ------------- http://www.freebsd.org/doc/en/articles/laptop/article.html page also states that it should be in device.hints. Well, these are the ones I have found. There are a lot of misconfusion in various forums what to put where and how its done. Maybe its accurate on both places, but then that should be noted somewhere. /Bjorn From amarat at ksu.ru Fri Oct 2 15:34:07 2009 From: amarat at ksu.ru (Marat N.Afanasyev) Date: Fri Oct 2 15:35:01 2009 Subject: acpi doc misconfusion... In-Reply-To: <20091002165602.Q37424@ns1.as.pvp.se> References: <20091002165602.Q37424@ns1.as.pvp.se> Message-ID: <4AC61CB2.3050801@ksu.ru> kama wrote: > Hi, > > there are a lot of different errors in various document regarding acpi > that are wrong. > > In 'man acpi' it says that 'hint.acpi.0.disabled' should be placed in > loader.conf. > > ------------- > LOADER TUNABLES > Tunables can be set at the loader(8) prompt before booting the kernel > or > stored in /boot/loader.conf. Many of these tunables also have a > matching > sysctl(8) entry for access after boot. > ... > hint.acpi.0.disabled > Set this to 1 to disable all of ACPI. If ACPI has been > disabled > on your system due to a blacklist entry for your BIOS, you > can > set this to 0 to re-enable ACPI for testing. > ... > ------------- > > > > In 'man loader' it says: > ------------- > acpi_load > Unset this to disable automatic loading of the ACPI module. > See also hint.acpi.0.disabled in device.hints(5). > ------------- > > In 'man device.hints' > ------------- > The following example disables the ACPI driver: > > hint.acpi.0.disabled="1" > ------------- > > http://www.freebsd.org/doc/en/articles/laptop/article.html page also > states that it should be in device.hints. > > > Well, these are the ones I have found. There are a lot of misconfusion in > various forums what to put where and how its done. Maybe its accurate on > both places, but then that should be noted somewhere. > > /Bjorn > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I was told that there's no difference between loader.conf and device.hints, so you can place this option in either file -- SY, Marat -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3221 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091002/b48e4ac9/smime.bin From oberman at es.net Fri Oct 2 16:05:47 2009 From: oberman at es.net (Kevin Oberman) Date: Fri Oct 2 16:06:00 2009 Subject: acpi doc misconfusion... In-Reply-To: Your message of "Fri, 02 Oct 2009 19:30:58 +0400." <4AC61CB2.3050801@ksu.ru> Message-ID: <20091002160543.49DB61CC0E@ptavv.es.net> > Date: Fri, 02 Oct 2009 19:30:58 +0400 > From: "Marat N.Afanasyev" > Sender: owner-freebsd-stable@freebsd.org > > kama wrote: > > Hi, > > > > there are a lot of different errors in various document regarding acpi > > that are wrong. > > > > In 'man acpi' it says that 'hint.acpi.0.disabled' should be placed in > > loader.conf. > > > > ------------- > > LOADER TUNABLES > > Tunables can be set at the loader(8) prompt before booting the kernel > > or > > stored in /boot/loader.conf. Many of these tunables also have a > > matching > > sysctl(8) entry for access after boot. > > ... > > hint.acpi.0.disabled > > Set this to 1 to disable all of ACPI. If ACPI has been > > disabled > > on your system due to a blacklist entry for your BIOS, you > > can > > set this to 0 to re-enable ACPI for testing. > > ... > > ------------- > > > > > > > > In 'man loader' it says: > > ------------- > > acpi_load > > Unset this to disable automatic loading of the ACPI module. > > See also hint.acpi.0.disabled in device.hints(5). > > ------------- > > > > In 'man device.hints' > > ------------- > > The following example disables the ACPI driver: > > > > hint.acpi.0.disabled="1" > > ------------- > > > > http://www.freebsd.org/doc/en/articles/laptop/article.html page also > > states that it should be in device.hints. > > > > > > Well, these are the ones I have found. There are a lot of misconfusion in > > various forums what to put where and how its done. Maybe its accurate on > > both places, but then that should be noted somewhere. > > > > /Bjorn > > > I was told that there's no difference between loader.conf and > device.hints, so you can place this option in either file This is sort of correct. Hints may be placed in either place with the same results. But there is a difference on how the files, themselves are handled. /boot/loader.conf is never touched by a FreeBSD update, even for major versions. /boot/device.hints is subject to modification between versions. It is not automatically updated, but a new version is included in the /sys/ARCH/conf directory and an update may be required as drivers change. This will delete any custom hints. (E.g. The sio to uart transition on 8.0.) This is why I generally but any hints that really need to survive in /boot/loader.conf. (In my case, I have to disable APIC on my laptop.) -- 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 From matt at chronos.org.uk Fri Oct 2 16:26:38 2009 From: matt at chronos.org.uk (Matt Dawson) Date: Fri Oct 2 16:26:45 2009 Subject: ral(4) on 8-RC1 Message-ID: <200910021726.33663.matt@chronos.org.uk> Odd little issue just cropped up on my lappie running 8.0-RC1 amd64. On 7.2 the ral(4) wireless NIC (2560 1st gen mini-PCI) gave me the Japanese regulatory domain allocations (2.412GHz to 2.477GHz, 14 channels) on 802.11g. I understand a lot has changed with 802.11 on 8, but I can now only ever get 2.412-2.462GHz channels 1 to 11. It's not a huge issue right now as my own AP is within that range, but I may run into problems using open access WiFi on the go sometime in the future, with being in the UK (ETSI) and all that. wlan0 is set up in rc.conf like this: wlans_ral0="wlan0" ifconfig_wlan0="country GB regdomain ETSI protmode off WPA DHCP" Taking the interface down and tweaking ifconfig's regdomain and related options makes no difference. I still only end up with 11 channels no matter what I try. Booting from 6.3 (DSBSD over PXE) lists, yet again, 14 channels when I use ifconfig ral0 list chans. Ifconfig lists the correct country and regdomain, so I'm stumped. I do get the "ral0: need multicast update callback" warning, but I'm led to believe that this is harmless. ral0@pci0:2:4:0: class=0x028000 card=0x614618e8 chip=0x02011814 rev=0x01 hdr=0x00 vendor='Ralink Technology, Corp' device='Ralink Chipset 802.11b/g WLAN card ( PCIVEN_1814&DEV_0201&SUBSYS_68331460&REV_013&)' class=network cap 01[40]=powerspec 2 supports D0 D3 current D0 Any ideas? Anything else I can do to check the card? Anything else I should have included? I also have a 2561 based Gigabyte GN-WI01GS (also ral) and an iwi(4) 2915 dual band card to test with (and no silly BIOS limitations to stop me, thank $DEITY), but I've had zero luck with iwi on amd64, hence the Ralink card. Last time I tried iwi, the default build (7.1 IIRC) didn't build the module or its firmware (I did have the license ack in loader.conf) and I had to faff about connecting the module to the build, which wasn't pleasant and didn't work anyway (no results from scan, no association with my AP despite working perfectly on i386 with the same config). -- Matt Dawson MTD15-RIPE matt@chronos.org.uk From kama at pvp.se Fri Oct 2 17:23:31 2009 From: kama at pvp.se (kama) Date: Fri Oct 2 17:23:39 2009 Subject: acpi doc misconfusion... In-Reply-To: <20091002160543.49DB61CC0E@ptavv.es.net> References: <20091002160543.49DB61CC0E@ptavv.es.net> Message-ID: <20091002192133.R37424@ns1.as.pvp.se> On Fri, 2 Oct 2009, Kevin Oberman wrote: > > Date: Fri, 02 Oct 2009 19:30:58 +0400 > > From: "Marat N.Afanasyev" > > Sender: owner-freebsd-stable@freebsd.org > > > > kama wrote: > > > Hi, > > > > > > there are a lot of different errors in various document regarding acpi > > > that are wrong. > > > > > > In 'man acpi' it says that 'hint.acpi.0.disabled' should be placed in > > > loader.conf. > > > > > > ------------- > > > LOADER TUNABLES > > > Tunables can be set at the loader(8) prompt before booting the kernel > > > or > > > stored in /boot/loader.conf. Many of these tunables also have a > > > matching > > > sysctl(8) entry for access after boot. > > > ... > > > hint.acpi.0.disabled > > > Set this to 1 to disable all of ACPI. If ACPI has been > > > disabled > > > on your system due to a blacklist entry for your BIOS, you > > > can > > > set this to 0 to re-enable ACPI for testing. > > > ... > > > ------------- > > > > > > > > > > > > In 'man loader' it says: > > > ------------- > > > acpi_load > > > Unset this to disable automatic loading of the ACPI module. > > > See also hint.acpi.0.disabled in device.hints(5). > > > ------------- > > > > > > In 'man device.hints' > > > ------------- > > > The following example disables the ACPI driver: > > > > > > hint.acpi.0.disabled="1" > > > ------------- > > > > > > http://www.freebsd.org/doc/en/articles/laptop/article.html page also > > > states that it should be in device.hints. > > > > > > > > > Well, these are the ones I have found. There are a lot of misconfusion in > > > various forums what to put where and how its done. Maybe its accurate on > > > both places, but then that should be noted somewhere. > > > > > > /Bjorn > > > > > I was told that there's no difference between loader.conf and > > device.hints, so you can place this option in either file > > This is sort of correct. Hints may be placed in either place with the > same results. But there is a difference on how the files, themselves are > handled. > > /boot/loader.conf is never touched by a FreeBSD update, even for major > versions. /boot/device.hints is subject to modification between > versions. It is not automatically updated, but a new version is included > in the /sys/ARCH/conf directory and an update may be required as drivers > change. This will delete any custom hints. (E.g. The sio to uart > transition on 8.0.) > > This is why I generally but any hints that really need to survive in > /boot/loader.conf. (In my case, I have to disable APIC on my laptop.) But shouldnt this be mentioned somewhere then? To ease the confusion? /Bjorn From oberman at es.net Fri Oct 2 17:35:52 2009 From: oberman at es.net (Kevin Oberman) Date: Fri Oct 2 17:36:05 2009 Subject: acpi doc misconfusion... In-Reply-To: Your message of "Fri, 02 Oct 2009 19:23:29 +0200." <20091002192133.R37424@ns1.as.pvp.se> Message-ID: <20091002173548.A341E1CC0E@ptavv.es.net> > Date: Fri, 2 Oct 2009 19:23:29 +0200 (CEST) > From: kama > > > On Fri, 2 Oct 2009, Kevin Oberman wrote: > > > > Date: Fri, 02 Oct 2009 19:30:58 +0400 > > > From: "Marat N.Afanasyev" > > > Sender: owner-freebsd-stable@freebsd.org > > > > > > kama wrote: > > > > Hi, > > > > > > > > there are a lot of different errors in various document regarding acpi > > > > that are wrong. > > > > > > > > In 'man acpi' it says that 'hint.acpi.0.disabled' should be placed in > > > > loader.conf. > > > > > > > > ------------- > > > > LOADER TUNABLES > > > > Tunables can be set at the loader(8) prompt before booting the kernel > > > > or > > > > stored in /boot/loader.conf. Many of these tunables also have a > > > > matching > > > > sysctl(8) entry for access after boot. > > > > ... > > > > hint.acpi.0.disabled > > > > Set this to 1 to disable all of ACPI. If ACPI has been > > > > disabled > > > > on your system due to a blacklist entry for your BIOS, you > > > > can > > > > set this to 0 to re-enable ACPI for testing. > > > > ... > > > > ------------- > > > > > > > > > > > > > > > > In 'man loader' it says: > > > > ------------- > > > > acpi_load > > > > Unset this to disable automatic loading of the ACPI module. > > > > See also hint.acpi.0.disabled in device.hints(5). > > > > ------------- > > > > > > > > In 'man device.hints' > > > > ------------- > > > > The following example disables the ACPI driver: > > > > > > > > hint.acpi.0.disabled="1" > > > > ------------- > > > > > > > > http://www.freebsd.org/doc/en/articles/laptop/article.html page also > > > > states that it should be in device.hints. > > > > > > > > > > > > Well, these are the ones I have found. There are a lot of misconfusion in > > > > various forums what to put where and how its done. Maybe its accurate on > > > > both places, but then that should be noted somewhere. > > > > > > > > /Bjorn > > > > > > > I was told that there's no difference between loader.conf and > > > device.hints, so you can place this option in either file > > > > This is sort of correct. Hints may be placed in either place with the > > same results. But there is a difference on how the files, themselves are > > handled. > > > > /boot/loader.conf is never touched by a FreeBSD update, even for major > > versions. /boot/device.hints is subject to modification between > > versions. It is not automatically updated, but a new version is included > > in the /sys/ARCH/conf directory and an update may be required as drivers > > change. This will delete any custom hints. (E.g. The sio to uart > > transition on 8.0.) > > > > This is why I generally but any hints that really need to survive in > > /boot/loader.conf. (In my case, I have to disable APIC on my laptop.) > > But shouldnt this be mentioned somewhere then? To ease the confusion? Sounds like a good idea. Feel free to submit patches/text to the FreeBSD doc folks. -- 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 From crapsh at monkeybrains.net Fri Oct 2 18:36:43 2009 From: crapsh at monkeybrains.net (Rudy) Date: Fri Oct 2 18:36:50 2009 Subject: em0 watchdog timeouts In-Reply-To: <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> Message-ID: <4AC64835.3060107@monkeybrains.net> I noticed something interesting. I set the rc_int_delay to 0: sysctl dev.em.5.rx_int_delay=0 Chcking via sysctl dev.em.5.debug=1 shows ex_int_delay is indeed 0: Oct 1 17:32:41 mango kernel: em5: rx_int_delay = 0, rx_abs_int_delay = 66 After a watchdog event, sysctl dev.em.5.debug=1 shows ex_int_delay is now 32: Oct 2 11:29:49 mango kernel: em5: rx_int_delay = 32, rx_abs_int_delay = 66 However, running sysctl dev.em.5 shows it as 0: dev.em.5.rx_int_delay: 0 dev.em.5.tx_int_delay: 66 Seems like the adapter and the kernel don't agree on the rx_int_delay value. Rudy From jfvogel at gmail.com Fri Oct 2 19:37:26 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Fri Oct 2 19:37:33 2009 Subject: em0 watchdog timeouts In-Reply-To: <4AC64835.3060107@monkeybrains.net> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> Message-ID: <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> Watchdog resets the adapter. Messing with these values is of dubious value anyway. Jack On Fri, Oct 2, 2009 at 11:36 AM, Rudy wrote: > > I noticed something interesting. > > I set the rc_int_delay to 0: > sysctl dev.em.5.rx_int_delay=0 > > Chcking via sysctl dev.em.5.debug=1 shows ex_int_delay is indeed 0: > Oct 1 17:32:41 mango kernel: em5: rx_int_delay = 0, rx_abs_int_delay = 66 > > After a watchdog event, sysctl dev.em.5.debug=1 shows ex_int_delay is > now 32: > Oct 2 11:29:49 mango kernel: em5: rx_int_delay = 32, rx_abs_int_delay = > 66 > > However, running sysctl dev.em.5 shows it as 0: > dev.em.5.rx_int_delay: 0 > dev.em.5.tx_int_delay: 66 > > Seems like the adapter and the kernel don't agree on the rx_int_delay > value. > > Rudy > From crapsh at monkeybrains.net Fri Oct 2 20:36:13 2009 From: crapsh at monkeybrains.net (Rudy) Date: Fri Oct 2 20:36:20 2009 Subject: em0 watchdog timeouts In-Reply-To: <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> Message-ID: <4AC66437.4040704@monkeybrains.net> Ah, I'll stop messing with them. I just set them all to 0 to see if that will help and noticed the card was leaving tx_int_delay=1. # sysctl dev.em.4.debug=1 Oct 2 13:26:07 mango kernel: em4: tx_int_delay = 1, tx_abs_int_delay = 0 Oct 2 13:26:07 mango kernel: em4: rx_int_delay = 0, rx_abs_int_delay = 0 # sysctl dev.em.4 dev.em.4.%desc: Intel(R) PRO/1000 Network Connection 6.9.12 dev.em.4.rx_int_delay: 0 dev.em.4.tx_int_delay: 0 dev.em.4.rx_abs_int_delay: 0 dev.em.4.tx_abs_int_delay: 0 Splitting traffic to different ports has brought down the watchdog events to once a day. ... essentially, I have a quad 30Mbps (not quad 1Gbps) card. heheh. Would turning off net.inet.ip.fastforwarding or any other setting help? Today, I set net.inet.ip.fw.enable=0 and I'll see if that helps. I have a feeling that isn't related to the NIC at all, but I'm not sure what else to try. Rudy Jack Vogel wrote: > Watchdog resets the adapter. Messing with these values is of dubious value > anyway. > > Jack > > > On Fri, Oct 2, 2009 at 11:36 AM, Rudy wrote: > > >> I noticed something interesting. >> >> I set the rc_int_delay to 0: >> sysctl dev.em.5.rx_int_delay=0 >> >> Chcking via sysctl dev.em.5.debug=1 shows ex_int_delay is indeed 0: >> Oct 1 17:32:41 mango kernel: em5: rx_int_delay = 0, rx_abs_int_delay = 66 >> >> After a watchdog event, sysctl dev.em.5.debug=1 shows ex_int_delay is >> now 32: >> Oct 2 11:29:49 mango kernel: em5: rx_int_delay = 32, rx_abs_int_delay = >> 66 >> >> However, running sysctl dev.em.5 shows it as 0: >> dev.em.5.rx_int_delay: 0 >> dev.em.5.tx_int_delay: 66 >> >> Seems like the adapter and the kernel don't agree on the rx_int_delay >> value. >> >> Rudy >> >> > > From kama at pvp.se Fri Oct 2 21:28:38 2009 From: kama at pvp.se (kama) Date: Fri Oct 2 21:28:50 2009 Subject: FreeBSD 7.2-STABLE boot freeze In-Reply-To: <20091002132218.P37424@ns1.as.pvp.se> References: <20090921140345.H37424@ns1.as.pvp.se> <20090922103150.V37424@ns1.as.pvp.se> <4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se> <4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se> <4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se> <4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se> <20090925110209.E37424@ns1.as.pvp.se> <4ABC894E.7040204@freebsd.org> <20090928092026.B37424@ns1.as.pvp.se> <4AC06ED6.7030402@freebsd.org> <20090928235136.F37424@ns1.as.pvp.se> <20090929085000.B37424@ns1.as.pvp.se> <4AC211AC.1070404@freebsd.org> <20090929204651.G37424@ns1.as.pvp.se> <4AC34952.9010508@freebsd.org> <20090930151542.G37424@ns1.as.pvp.se> <4AC35CC6.1020103@freebsd.org> <20091002132218.P37424@ns1.as.pvp.se> Message-ID: <20091002212626.O37424@ns1.as.pvp.se> On Fri, 2 Oct 2009, kama wrote: > > > On Wed, 30 Sep 2009, Andriy Gapon wrote: > > > on 30/09/2009 16:21 kama said the following: > > > > > > It boot occationally. It does not seem to matter if I include the acpi > > > device into the kernel or not. > > > > > > I get this message in an verbose boot: > > > KLD file acpi.ko - could not finalize loading > > > > Do you get this message in all cases? That is, every time you tried? > > Or only with ACPI_DEBUG defined? > > I cant recall. I have tried so many things lately. But I believe I get it > on a verbose boot without ACPI_DEBUG. > > Im currently rebuilding the system to 8.0. Just upgrading to 8.0 did not help regarding the freezes. I ran into the bge freeze bug too when disabling acpi. I then read the acpi-manpage abit more carefully. With ACPI_DEBUG and debug.acpi.disabled="timer" in loader.conf and verbose boot seems to help against the freeze and freezes again if I dont run it in verbose mode. But thats just after 5 starts. Anyhow its better. loader.conf: debug.acpi.disabled="timer" debug.acpi.layer="ACPI_ALL_COMPONENTS" debug.acpi.level="ACPI_LV_VERBOSE,ACPI_LV_VERBOSITY3,ACPI_LV_VERBOSITY1,ACPI_LV_ALL_EXCEPTIONS" I dont know if the output below gives anything. /Bjorn # dmesg | grep -i acpi ACPI set debug layer 'ACPI_ALL_COMPONENTS' level 'ACPI_LV_VERBOSE,ACPI_LV_VERBOSITY3,ACPI_LV_VERBOSITY1,ACPI_LV_ALL_EXCEPTIONS' MADT: Found CPU APIC ID 0 ACPI ID 0: enabled MADT: Found CPU APIC ID 2 ACPI ID 2: enabled MADT: Found CPU APIC ID 4 ACPI ID 4: disabled MADT: Found CPU APIC ID 6 ACPI ID 6: disabled MADT: Found CPU APIC ID 1 ACPI ID 1: enabled MADT: Found CPU APIC ID 3 ACPI ID 3: enabled MADT: Found CPU APIC ID 5 ACPI ID 5: disabled MADT: Found CPU APIC ID 7 ACPI ID 7: disabled ACPI APIC Table: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ACPI: RSDP 0xf4f20 00024 (v2 HP ) ACPI: XSDT 0xbfff83e0 00044 (v1 HP A05 00000002 \M-R\^D 0000162E) ACPI: FACP 0xbfff8460 000F4 (v3 HP A05 00000002 \M-R\^D 0000162E) ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707 ACPI Warning: Invalid length for Pm1bControlBlock: 32, using default 16 20090521 tbfadt-707 ACPI: DSDT 0xbfff8560 0422D (v1 HP DSDT 00000001 MSFT 02000001) ACPI: FACS 0xbfff80c0 00040 ACPI: APIC 0xbfff8100 000B8 (v1 HP 00000083 00000002 00000000) ACPI: SPCR 0xbfff81e0 00050 (v1 HP SPCRRBSU 00000001 \M-R\^D 0000162E) ACPI: SRAT 0xbfff8260 00150 (v1 HP A05 00000001 00000000) acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: SSDT 0xbfffd000 0059D (v1 HP SSDT0 00000001 MSFT 02000001) ACPI: SSDT 0xbfffd700 0059D (v1 HP SSDT1 00000001 MSFT 02000001) ACPI: SSDT 0xbfffde00 0059D (v1 HP SSDT2 00000001 MSFT 02000001) ACPI: SSDT 0xbfffe500 0059D (v1 HP SSDT3 00000001 MSFT 02000001) acpi0: Power Button (fixed) acpi0: wakeup code va 0xc62cd000 pa 0x1000 AcpiOsDerivePciId: \\_SB_.CFG0.NDE0.NDE0 -> bus 0 dev 24 func 0 AcpiOsDerivePciId: \\_SB_.CFG0.MEMC.MEMC -> bus 0 dev 24 func 1 AcpiOsDerivePciId: \\_SB_.CFG0.PCI0.PCI0 -> bus 0 dev 3 func 0 AcpiOsDerivePciId: \\_SB_.CFG0.IBRG.IBRG -> bus 0 dev 4 func 0 AcpiOsDerivePciId: \\_SB_.CFG0.PCI1.PCI1 -> bus 0 dev 7 func 0 AcpiOsDerivePciId: \\_SB_.CFG0.PCI2.PCI2 -> bus 0 dev 8 func 0 AcpiOsDerivePciId: \\_SB_.CFG1.PCI3.PCI3 -> bus 4 dev 9 func 0 AcpiOsDerivePciId: \\_SB_.CFG1.PCI4.PCI4 -> bus 4 dev 10 func 0 AcpiOsDerivePciId: \\_SB_.CFG0.TSMM.TSMM -> bus 0 dev 4 func 3 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 3.0 on pci0 pci1: on pcib1 pcib2: at device 7.0 on pci0 pci2: on pcib2 pcib3: at device 8.0 on pci0 pci3: on pcib3 pcib4: on acpi0 pci4: on pcib4 pcib5: at device 9.0 on pci4 pci5: on pcib5 pcib6: at device 10.0 on pci4 pci6: on pcib6 atkbdc0: port 0x60,0x64 irq 1 on acpi0 psmcpnp0: irq 12 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 fdc0: port 0x3f2-0x3f5 irq 6 drq 2 on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 From sluggo at unknown.nu Fri Oct 2 21:36:31 2009 From: sluggo at unknown.nu (Kim Scarborough) Date: Fri Oct 2 21:36:39 2009 Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-09:05.null In-Reply-To: <200910022012.n92KCtLI004038@freefall.freebsd.org> References: <200910022012.n92KCtLI004038@freefall.freebsd.org> Message-ID: <4AC66F21.7060305@unknown.nu> > To actually enable the feature in FreeBSD 6.x and 7.x, add the > following to either /boot/loader.conf or /etc/sysctl.conf: > > security.bsd.map_at_zero="0" Actually, on my 6.4 box I had to set it in loader.conf. Setting it in sysctl.conf didn't work. -- http://kim.scarborough.chicago.il.us/ http://www.dinosaurgardens.com/ http://www.mercurytheatre.info/ http://www.unknown.nu/ From cowens at greatbaysoftware.com Fri Oct 2 22:16:15 2009 From: cowens at greatbaysoftware.com (Charles Owens) Date: Fri Oct 2 22:16:22 2009 Subject: gjournal "error while writing data (error=6)" Message-ID: <4AC67307.9010604@greatbaysoftware.com> Hello folks, We've had a system crash, apparently related to GEOM_JOURNAL, on an i386 system running 7.0-RELEASE-p11. Here's what we could see on the screen (formatted for readability): GEOM_JOURNAL: [copy] Error while writting data (error=6) \ ad4s1a[WRITE(offset=43561402368, length=16384)] GEOM_JOURNAL: [copy] Error while writting data (error=6) \ ad4s1a[WRITE(offset=48868164096, length=16896)] GEOM_JOURNAL: Error while reading data from ad4s1a (error=6). mode=0134172, inum=5323776, fs = / panic: ffs_valloc: dup alloc cpuid = 3 Uptime: 119d10h5m43s Cannot dump. No dump device defined. GEOM_JOURNAL: Flush of cache of ad4s1a: error=6. GEOM_JOURNAL: [flush] Error while writting data (error=6) \ ad4s1a[WRITE(offset=48868197888, length=98816)] (4 more lines like last one) Rebooting... cpu_reset: Stopping other CPUs The system didn't actually reboot.. just got stuck there. When it was eventually manually rebooted, it booted just fine. Any thoughts as to what could be the real problem? What does "error=6" indicate? I've done some scouring of the net and found something that may not directly relate to this crash... but does relate, at least, to my filesystem configuration. One of the threads: http://markmail.org/message/tamo4r2jho3zdv3z In the described crash, similar error messages were seen, but with "error=1". Ultimately Pawel Dawidek (gjournal author) gave the diagnosis that the crash was related to the first filesystem in the slice being set up with an offset of zero, not the correct offset of 16. Either in this thread or elsewhere I also learned that sysinstall always uses the zero offset... even though it is not best practice. Not a happy discovery. Looking at our system that crashed... sure enough, zero offset (see label below below -- both 'a' and 'd' are journaled). So this then prompts two questions: * Can our crash be explained by the zero offset filesystem configuration? * If not, separate from the crash, how much should we be worried about running a system with gjournal like this. Thanks very much for any and all assistance, Charles # bsdlabel ad4s1 # /dev/ad4s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 77594624 0 4.2BSD 2048 16384 28552 b: 24113088 77594624 swap c: 156296322 0 unused 0 0 # "raw" part, don't edit d: 54588610 101707712 4.2BSD 2048 16384 28552 -- **Charles Owens** *Great Bay Software**|** ** e: *cowens@GreatBaySoftware.com**** From stef-list at memberwebs.com Sat Oct 3 03:18:01 2009 From: stef-list at memberwebs.com (Stef Walter) Date: Sat Oct 3 03:18:09 2009 Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-09:05.null In-Reply-To: <200910022012.n92KCtLI004038@freefall.freebsd.org> References: <200910022012.n92KCtLI004038@freefall.freebsd.org> Message-ID: <4AC6BE97.1030406@memberwebs.com> FreeBSD Errata Notices wrote: > To actually enable the feature in FreeBSD 6.x and 7.x, add the > following to either /boot/loader.conf or /etc/sysctl.conf: > > security.bsd.map_at_zero="0" The sysctl.conf setting must not have quotes. Or you get this: sysctl: invalid integer '"0"' Instead one should use: security.bsd.map_at_zero=0 Cheers, Stef From glen.j.barber at gmail.com Sat Oct 3 18:10:58 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sat Oct 3 18:11:04 2009 Subject: Rearrange entries in GENERIC KERNCONF? Message-ID: <20091003180140.GA3078@orion.hsd1.pa.comcast.net> Hello I was considering submitting a patch to rearrange some USB devices in the GENERIC kernel config. I wanted to get some feedback / comments before I submit a PR. What I was going to propose is moving rum(4), ural(4), uath(4) and zyd(4) into a separate USB section, similar to 'USB Serial devices' and 'USB Ethernet'. A diff of the i386 GENERIC is attached, and comments appreciated. -- Glen Barber -------------- next part -------------- --- GENERIC.orig 2009-10-02 21:35:36.000000000 -0400 +++ GENERIC 2009-10-03 13:40:01.000000000 -0400 @@ -301,10 +301,6 @@ device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse -device rum # Ralink Technology RT2501USB wireless NICs -device ural # Ralink Technology RT2500USB wireless NICs -device uath # Atheros AR5523 wireless NICs -device zyd # ZyDAS zb1211/zb1211b wireless NICs device urio # Diamond Rio 500 MP3 player # USB Serial devices device u3g # USB-based 3G modems (Option, Huawei, Sierra) @@ -324,6 +320,11 @@ device kue # Kawasaki LSI USB Ethernet device rue # RealTek RTL8150 USB Ethernet device udav # Davicom DM9601E USB +# USB Wireless +device rum # Ralink Technology RT2501USB wireless NICs +device ural # Ralink Technology RT2500USB wireless NICs +device uath # Atheros AR5523 wireless NICs +device zyd # ZyDAS zb1211/zb1211b wireless NICs # FireWire support device firewire # FireWire bus code From Andre.Albsmeier at siemens.com Sat Oct 3 18:42:22 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Sat Oct 3 18:42:29 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) Message-ID: <20091003184220.GA2620@curry.mchp.siemens.de> FYI, after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all samba33 programmes did abort() immediately after start. The solution was to use CONFIGURE_ARGS+= --disable-pie -Andre -- BSD, from the people who brought you TCP/IP. From sam at errno.com Sat Oct 3 18:49:05 2009 From: sam at errno.com (Sam Leffler) Date: Sat Oct 3 18:49:13 2009 Subject: ral(4) on 8-RC1 In-Reply-To: <200910021726.33663.matt@chronos.org.uk> References: <200910021726.33663.matt@chronos.org.uk> Message-ID: <4AC797E2.2050709@errno.com> Matt Dawson wrote: > Odd little issue just cropped up on my lappie running 8.0-RC1 amd64. On 7.2 > the ral(4) wireless NIC (2560 1st gen mini-PCI) gave me the Japanese > regulatory domain allocations (2.412GHz to 2.477GHz, 14 channels) on > 802.11g. I understand a lot has changed with 802.11 on 8, but I can now > only ever get 2.412-2.462GHz channels 1 to 11. It's not a huge issue right > now as my own AP is within that range, but I may run into problems using > open access WiFi on the go sometime in the future, with being in the UK > (ETSI) and all that. > > wlan0 is set up in rc.conf like this: > > wlans_ral0="wlan0" > ifconfig_wlan0="country GB regdomain ETSI protmode off WPA DHCP" > > Taking the interface down and tweaking ifconfig's regdomain and related > options makes no difference. I still only end up with 11 channels no matter > what I try. Booting from 6.3 (DSBSD over PXE) lists, yet again, 14 channels > when I use ifconfig ral0 list chans. Ifconfig lists the correct country and > regdomain, so I'm stumped. I do get the "ral0: need multicast update > callback" warning, but I'm led to believe that this is harmless. ral probably does not populate it's initial channel list according to the device capabilities. I'm guessing it falls back on the system code to do that and it fills in only channels 1-11. This means future changes to regulatory cannot setup the channels you want--it's not allowed to add channels that are not listed in the "device capabilities". > > ral0@pci0:2:4:0: class=0x028000 card=0x614618e8 chip=0x02011814 rev=0x01 > hdr=0x00 > vendor='Ralink Technology, Corp' > device='Ralink Chipset 802.11b/g WLAN card ( > PCIVEN_1814&DEV_0201&SUBSYS_68331460&REV_013&)' > class=network > cap 01[40]=powerspec 2 supports D0 D3 current D0 > > Any ideas? Anything else I can do to check the card? Anything else I should > have included? I also have a 2561 based Gigabyte GN-WI01GS (also ral) and > an iwi(4) 2915 dual band card to test with (and no silly BIOS limitations > to stop me, thank $DEITY), but I've had zero luck with iwi on amd64, hence > the Ralink card. Last time I tried iwi, the default build (7.1 IIRC) didn't > build the module or its firmware (I did have the license ack in > loader.conf) and I had to faff about connecting the module to the build, > which wasn't pleasant and didn't work anyway (no results from scan, no > association with my AP despite working perfectly on i386 with the same > config). You can hack ral to setup a proper channel list at attach or you can make a private hack to net80211 to populate the channel list w/ those channels you want. Either is simple. Sam From jhell at DataIX.net Sat Oct 3 20:54:33 2009 From: jhell at DataIX.net (jhell) Date: Sat Oct 3 20:54:40 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <20091003184220.GA2620@curry.mchp.siemens.de> References: <20091003184220.GA2620@curry.mchp.siemens.de> Message-ID: On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: > FYI, > > after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all > samba33 programmes did abort() immediately after start. The > solution was to use > > CONFIGURE_ARGS+= --disable-pie > > -Andre > To add an additional note samba33 even when not running (not enabled by a rcvar) also runs a tdbcleanup routine on shutdown and/or start that also does abort(). -- %{----------------------------------------------------+ | dataix.net!jhell 2048R/89D8547E 2009-09-30 | | BSD since FreeBSD 4.2 Linux since Slackware 2.1 | | 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E | +----------------------------------------------------%} From Andre.Albsmeier at siemens.com Sat Oct 3 21:23:16 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Sat Oct 3 21:23:23 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: References: <20091003184220.GA2620@curry.mchp.siemens.de> Message-ID: <20091003212308.GA3122@curry.mchp.siemens.de> On Sat, 03-Oct-2009 at 16:27:32 -0400, jhell wrote: > On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: > > > FYI, > > > > after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all > > samba33 programmes did abort() immediately after start. The > > solution was to use > > > > CONFIGURE_ARGS+= --disable-pie > > > > -Andre > > > > To add an additional note samba33 even when not running (not enabled by a rcvar) > also runs a tdbcleanup routine on shutdown and/or start that also does > abort(). Yes, every samba programme is linked with -pie per default (so all abort()). -Andre From matt at chronos.org.uk Sat Oct 3 21:40:59 2009 From: matt at chronos.org.uk (Matt Dawson) Date: Sat Oct 3 21:41:06 2009 Subject: ral(4) on 8-RC1 In-Reply-To: <4AC797E2.2050709@errno.com> References: <200910021726.33663.matt@chronos.org.uk> <4AC797E2.2050709@errno.com> Message-ID: <200910032240.45357.matt@chronos.org.uk> On Saturday 03 Oct 2009 19:28:50 you wrote: > ral probably does not populate it's initial channel list according to > the device capabilities. I'm guessing it falls back on the system code > to do that and it fills in only channels 1-11. This means future > changes to regulatory cannot setup the channels you want--it's not > allowed to add channels that are not listed in the "device > capabilities". That makes sense. Given that my 2561 card has "ETSI" stamped on its label, one would think it's the card's job to report to the driver what it supports. If the driver doesn't request this, the safest bet is the lowest common denominator that should be legal everywhere, 11 channels at FCC spec. Got it. Just a quick question, if I may: Are the maxpower specs of regdomain.xml in dBm? ETSI is max 20dBm ERP at 2.4GHz. Euro spec cards are only capable of ~100mW anyway, most more like 60mW and your average foot of RG-174 will knock nearly a dB off at 2.4GHz, so it hardly matters, but I'm curious. The manpage doesn't specify what the fields mean. > You can hack ral to setup a proper channel list at attach or you can > make a private hack to net80211 to populate the channel list w/ those > channels you want. Either is simple. Thank you. I'll probably try the local hack for now, but hacking ral (and probably iwi now I finally have that working, which does exactly the same thing) to do the right thing would be a better long-term solution. To the list: Does anyone have any idea why the iwi firmware modules build by default on i386 and not on amd64? I know from experience that manually building them on 7.1 amd64 didn't work, but it now works well on 8 except for the messages about mcast/promisc update separation. -- Matt Dawson MTD15-RIPE From bzeeb-lists at lists.zabbadoz.net Sat Oct 3 22:39:42 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sat Oct 3 22:39:50 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <20091003212308.GA3122@curry.mchp.siemens.de> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> Message-ID: <20091003215821.V26486@maildrop.int.zabbadoz.net> On Sat, 3 Oct 2009, Andre Albsmeier wrote: Hi, > On Sat, 03-Oct-2009 at 16:27:32 -0400, jhell wrote: >> On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: >> >>> FYI, >>> >>> after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all >>> samba33 programmes did abort() immediately after start. The >>> solution was to use >>> >>> CONFIGURE_ARGS+= --disable-pie >>> >>> -Andre >>> >> >> To add an additional note samba33 even when not running (not enabled by a rcvar) >> also runs a tdbcleanup routine on shutdown and/or start that also does >> abort(). > > Yes, every samba programme is linked with -pie per default (so > all abort()). Thanks for reporting the issue. People are aware of the problem now and we'll try to present a solution within the next days for better position-independent executable (PIE) handling. Meanwhile there are multiple solutions for people affected: (1) recompile the port; but as more than just samba might be affected and we generally do not want to flip the pie switch everywhere that's probably only a temporary, private solution. At the current time ports people should NOT commit any changes to add this option to ports to work around the problem. (2) If you are on 7.x or 6.x, and you are experiencing this problem you flipped the sysctl or tunable yourself. If you are on 8.x or 9.x the feature is enabled by default. As hinted in the errata notice[1] you can use the tunable or sysctl to change the behaviour, (temporary) allowing 0-mappings, if you can accept the possible risk the change tries to mitigate. The tunable/sysctl in question is: security.bsd.map_at_zero and should be set to 1 to permit 0-mappings. This might be the easier option in contrast to (1). If you do this do not forget to change it back again once the issue will be patched. You should also make sure that you are running with a fully patched kernel. As we will try to keep the default in 8.x and 9.x to disallow user mappings at virtual address 0, we are interested in further issues that were not yet metnioned in either this thread or the Errata Notice. /bz [1] http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc -- Bjoern A. Zeeb It will not break if you know what you are doing. From luca at lavabit.com Sun Oct 4 12:27:40 2009 From: luca at lavabit.com (luca) Date: Sun Oct 4 12:29:00 2009 Subject: [setup] no floppies FreeBSD 8 ? Message-ID: <4AC88D03.6000902@lavabit.com> hi, I'm looking for the floppies images to install FreeBSD 8 on a PC which can't boot from CDROM ; but the images are not available (i.e. no floppies directory) Do FreeBSD 8 dropped floppy install ? Regards, Luca From Andre.Albsmeier at siemens.com Sun Oct 4 16:48:00 2009 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Sun Oct 4 16:48:07 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <20091003215821.V26486@maildrop.int.zabbadoz.net> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> Message-ID: <20091004164756.GA6021@curry.mchp.siemens.de> On Sat, 03-Oct-2009 at 22:27:39 +0000, Bjoern A. Zeeb wrote: > On Sat, 3 Oct 2009, Andre Albsmeier wrote: > > Hi, > > > On Sat, 03-Oct-2009 at 16:27:32 -0400, jhell wrote: > >> On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: > >> > >>> FYI, > >>> > >>> after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all > >>> samba33 programmes did abort() immediately after start. The > >>> solution was to use > >>> > >>> CONFIGURE_ARGS+= --disable-pie > >>> > >>> -Andre > >>> > >> > >> To add an additional note samba33 even when not running (not enabled by a rcvar) > >> also runs a tdbcleanup routine on shutdown and/or start that also does > >> abort(). > > > > Yes, every samba programme is linked with -pie per default (so > > all abort()). > > > Thanks for reporting the issue. People are aware of the problem now > and we'll try to present a solution within the next days for better > position-independent executable (PIE) handling. > > Meanwhile there are multiple solutions for people affected: > > (1) recompile the port; but as more than just samba might be affected > and we generally do not want to flip the pie switch everywhere that's > probably only a temporary, private solution. I'll stick to this since I am happy about having the map_at_zero option and want to continue to try it out on 7.2-STABLE. And I see now reason why samba has to be linked with -pie (without -pie it is also 4% smaller). -Andre -- "I think there is a world market for maybe five computers." - Thomas Watson, chairman of IBM, 1943 From dougb at FreeBSD.org Sun Oct 4 19:07:43 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Oct 4 19:07:50 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <20091003215821.V26486@maildrop.int.zabbadoz.net> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> Message-ID: <4AC8F27C.8070208@FreeBSD.org> Bjoern A. Zeeb wrote: > On Sat, 3 Oct 2009, Andre Albsmeier wrote: > > Hi, > >> On Sat, 03-Oct-2009 at 16:27:32 -0400, jhell wrote: >>> On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: >>> >>>> FYI, >>>> >>>> after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all >>>> samba33 programmes did abort() immediately after start. The >>>> solution was to use >>>> >>>> CONFIGURE_ARGS+= --disable-pie >>>> >>>> -Andre >>>> >>> >>> To add an additional note samba33 even when not running (not enabled >>> by a rcvar) >>> also runs a tdbcleanup routine on shutdown and/or start that also does >>> abort(). >> >> Yes, every samba programme is linked with -pie per default (so >> all abort()). > > > Thanks for reporting the issue. People are aware of the problem now > and we'll try to present a solution within the next days for better > position-independent executable (PIE) handling. > > Meanwhile there are multiple solutions for people affected: > > (1) recompile the port; Just to be clear, you have to recompile the port with --disable-pie added to the CONFIGURE_ARGS in the Makefile. It would also be nice if there were a __FreeBSD_version bump for this new feature. Doug -- This .signature sanitized for your protection From gbell72 at rogers.com Sun Oct 4 19:57:53 2009 From: gbell72 at rogers.com (Gardner Bell) Date: Sun Oct 4 19:58:01 2009 Subject: Page Fault: knlist_cleardel Message-ID: <866481.87787.qm@web88005.mail.re2.yahoo.com> I got the following panic after signing out of my X session. Previous to this I was trying to kill off a program that was running through wine. This machine is running 7.2-STABLE and I still have core file if any further debugging info is needed. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x10 fault code = supervisor write, page not present instruction pointer = 0x20:0xc04efdcb stack pointer = 0x28:0xe8cdeb64 frame pointer = 0x28:0xe8cdeb84 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 = 7453 (wine) trap number = 12 panic: page fault cpuid = 1 Uptime: 1d3h58m32s Physical memory: 1005 MB Dumping 192 MB: (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 177 (CTRL-C to abort) 161 (CTRL-C to abort) 145 129 113 97 81 65 (CTRL-C to abort) 49 33 17 1 #1 0xc051afe8 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc051b2c5 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc067bf54 in trap_fatal (frame=0xe8cdeb24, eva=16) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc067c1a4 in trap_pfault (frame=0xe8cdeb24, usermode=0, eva=16) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc067cb06 in trap (frame=0xe8cdeb24) at /usr/src/sys/i386/i386/trap.c:529 #6 0xc06631db in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #7 0xc04efdcb in knlist_cleardel (knl=0xc4f7ba70, td=0x0, islocked=1, killkn=0) at atomic.h:149 #8 0xc055581b in pipeclose (cpipe=0xc4f7ba00) at /usr/src/sys/kern/sys_pipe.c:1510 #9 0xc0555921 in pipe_close (fp=0xc4e1e214, td=0xc52aa900) at /usr/src/sys/kern/sys_pipe.c:1427 #10 0xc04e4bc1 in fdrop (fp=0xc4e1e214, td=0xc52aa900) at file.h:300 #11 0xc04e60c7 in closef (fp=0xc4e1e214, td=0xc52aa900) at /usr/src/sys/kern/kern_descrip.c:2072 #12 0xc04e659c in kern_close (td=0xc52aa900, fd=27) at /usr/src/sys/kern/kern_descrip.c:1125 #13 0xc04e6669 in close (td=0xc52aa900, uap=0xe8cdecfc) at /usr/src/sys/kern/kern_descrip.c:1077 #14 0xc067c4e5 in syscall (frame=0xe8cded38) #15 0xc0663240 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #16 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) l *0xc04efdcb 0xc04efdcb is in knlist_cleardel (atomic.h:149). 144 static __inline int 145 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) 146 { 147 u_char res; 148 149 __asm __volatile( 150 " " MPLOCKED " " 151 " cmpxchgl %2,%1 ; " 152 " sete %0 ; " 153 "1: " (kgdb) From sam at errno.com Sun Oct 4 23:28:33 2009 From: sam at errno.com (Sam Leffler) Date: Sun Oct 4 23:28:40 2009 Subject: ral(4) on 8-RC1 In-Reply-To: <200910032240.45357.matt@chronos.org.uk> References: <200910021726.33663.matt@chronos.org.uk> <4AC797E2.2050709@errno.com> <200910032240.45357.matt@chronos.org.uk> Message-ID: <4AC92F94.4020106@errno.com> Matt Dawson wrote: > On Saturday 03 Oct 2009 19:28:50 you wrote: >> ral probably does not populate it's initial channel list according to >> the device capabilities. I'm guessing it falls back on the system code >> to do that and it fills in only channels 1-11. This means future >> changes to regulatory cannot setup the channels you want--it's not >> allowed to add channels that are not listed in the "device >> capabilities". > > That makes sense. Given that my 2561 card has "ETSI" stamped on its label, > one would think it's the card's job to report to the driver what it > supports. If the driver doesn't request this, the safest bet is the lowest > common denominator that should be legal everywhere, 11 channels at FCC > spec. Got it. > > Just a quick question, if I may: Are the maxpower specs of regdomain.xml in > dBm? ETSI is max 20dBm ERP at 2.4GHz. Euro spec cards are only capable of > ~100mW anyway, most more like 60mW and your average foot of RG-174 will > knock nearly a dB off at 2.4GHz, so it hardly matters, but I'm curious. The > manpage doesn't specify what the fields mean. maxpower are expressed as dBm. > >> You can hack ral to setup a proper channel list at attach or you can >> make a private hack to net80211 to populate the channel list w/ those >> channels you want. Either is simple. > > Thank you. I'll probably try the local hack for now, but hacking ral (and > probably iwi now I finally have that working, which does exactly the same > thing) to do the right thing would be a better long-term solution. > > To the list: Does anyone have any idea why the iwi firmware modules build > by default on i386 and not on amd64? I know from experience that manually > building them on 7.1 amd64 didn't work, but it now works well on 8 except > for the messages about mcast/promisc update separation. I had problems w/ the iwi firmware on 64-bit so set the build to i386 only. The problems I had were relocation errors and noone could help; if those are gone then building the fw image for amd64 should be fine. Whether the driver works is another matter... Sam From rpp at ci.com.au Mon Oct 5 08:28:30 2009 From: rpp at ci.com.au (Richard Perini) Date: Mon Oct 5 08:28:37 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <20091003215821.V26486@maildrop.int.zabbadoz.net> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> Message-ID: <20091005081704.GA77314@mippet.ci.com.au> On Sat, Oct 03, 2009 at 10:27:39PM +0000, Bjoern A. Zeeb wrote: ... > > As we will try to keep the default in 8.x and 9.x to disallow user > mappings at virtual address 0, we are interested in further issues > that were not yet metnioned in either this thread or the Errata Notice. quagga 0.99.15 (built from ports) has the same issue as samba. -- Richard Perini Internet: rpp@ci.com.au Corinthian Engineering Pty Ltd PHONE: +61 2 9552 5500 Sydney, Australia FAX: +61 2 9552 5549 From matt at chronos.org.uk Mon Oct 5 10:39:59 2009 From: matt at chronos.org.uk (Matt Dawson) Date: Mon Oct 5 10:40:06 2009 Subject: ral(4) on 8-RC1 In-Reply-To: <4AC92F94.4020106@errno.com> References: <200910021726.33663.matt@chronos.org.uk> <200910032240.45357.matt@chronos.org.uk> <4AC92F94.4020106@errno.com> Message-ID: <200910051139.43019.matt@chronos.org.uk> On Monday 05 Oct 2009 00:28:20 you wrote: > maxpower are expressed as dBm. Thanks for that and the pointers to get the channels right. A temporary hack in net80211 was trivial and I can take my time with the ral end of things. I believe Kip Macy was the last to look at ral in-depth, around the time support was added for gen 2 chipset, although I can't seem to find the code that was in p4 at that time. It was a while ago... > I had problems w/ the iwi firmware on 64-bit so set the build to i386 > only. The problems I had were relocation errors and noone could help; > if those are gone then building the fw image for amd64 should be fine. > Whether the driver works is another matter... The iwi driver seems to work for normal operation with the caveat that 802.11s is never going to work, but that's noted on the wiki anyway. I haven't been able to get Kismet to work (it used to on i386 on the iwi) although that may be down to PEBKAC in not fully understanding the 802.11 architectural changes in 8. I'll hammer the thing for a few more days, see if I can find any regression tests to apply to this setup and maybe move it to a different machine to ensure it works in multiple environments. This is, however, exactly the same hardware that failed to work with 7.1 amd64, so I'm pretty confident that it should be consistent. I'm torn between decent support for most things on ral and dual band and a more sensitive radio, to the order of around 5dB in the same location, on iwi. I'm tempted to just get an Atheros a/b/g card and be done with it. Oxford Tech have some AR5414/AR5006XS cards for reasonable money. Thanks for your help, Sam. Best regards, -- Matt Dawson MTD15-RIPE From remko at elvandar.org Mon Oct 5 13:00:18 2009 From: remko at elvandar.org (Remko Lodder) Date: Mon Oct 5 13:01:07 2009 Subject: [setup] no floppies FreeBSD 8 ? In-Reply-To: <4AC88D03.6000902@lavabit.com> References: <4AC88D03.6000902@lavabit.com> Message-ID: I am not sure whether we dropped floppy support. But I can imagine that the release candidates do not have floppies. On Oct 4, 2009, at 1:54 PM, luca wrote: > hi, > > I'm looking for the floppies images to install FreeBSD 8 on a PC > which can't boot from CDROM ; but the images are not available (i.e. > no floppies directory) > > Do FreeBSD 8 dropped floppy install ? > > Regards, > Luca > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From db at danielbond.org Mon Oct 5 14:19:10 2009 From: db at danielbond.org (Daniel Bond) Date: Mon Oct 5 14:19:17 2009 Subject: em0 watchdog timeouts In-Reply-To: <4AC66437.4040704@monkeybrains.net> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> Message-ID: <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> Hi, I've been struggling with watchdog timeouts in 7.1/7.2-RELEASE for the past 6months too. It looks related. I've tried to replace the hardware 3 times (2 different IBM x3755 chassis, one IBM x3650 chassis). I tried first with onboard broadcom NICs (bce-based) PCIx-based, until I had issues with "watchdog timeout". I tried replacing it with a 4-port pci-x Intel NIC, which gave me same problems. I was told that the 4-port intel NICs had an onboard bus- controller, that could cause trouble, so I replaced this with a 2-port PCI-e intel, which I was told by a Sepherosa Ziehau was the best performing gig-e NIC (rx/tx). Still getting watchdog timeouts, I tried upgrading all sort of sysctls I found in mailing-list threads (disable msi/msix interrupts, adjust rx/tx processing, etc, etc). I tried upgrading BIOS, firmware on all kinds of stuff (disks, BMC, etc, etc) to newest version. I also tried using a different qlogic isp(4) FC-controller (PCI-e). No matter what I tried, I could not diagnose this problem, or at least fix it. Also it happened rarely enough, to not be easy to debugging. I would get a series of "watchdog timeout -- resetting", until the NIC would go completly offline - at the point I'd reboot it from console. This happened about once every 1-10 days, usually about 11-13:00. This machine has now been replaced with Linux, unfortunately, just to avoid more customer complaints and downtime. The IBM x3755 with FreeBSD7.2 which was replaced with Linux, is still online, and can be put at disposal for any developers who would like to debug this further. Like Stefan Krueger mentioned, this machine is also running as NFS server, with a mix of BSD and Linux clients, and it's getting hit pretty hard by clients. Hope we can iron this bug out, in the future. Best regards, Daniel Bond. On Oct 2, 2009, at 10:36 PM, Rudy wrote: > > Ah, I'll stop messing with them. > > > I just set them all to 0 to see if that will help and noticed the card > was leaving tx_int_delay=1. > > # sysctl dev.em.4.debug=1 > Oct 2 13:26:07 mango kernel: em4: tx_int_delay = 1, > tx_abs_int_delay = 0 > Oct 2 13:26:07 mango kernel: em4: rx_int_delay = 0, > rx_abs_int_delay = 0 > > # sysctl dev.em.4 > dev.em.4.%desc: Intel(R) PRO/1000 Network Connection 6.9.12 > dev.em.4.rx_int_delay: 0 > dev.em.4.tx_int_delay: 0 > dev.em.4.rx_abs_int_delay: 0 > dev.em.4.tx_abs_int_delay: 0 > > Splitting traffic to different ports has brought down the watchdog > events to once a day. ... essentially, I have a quad 30Mbps (not quad > 1Gbps) card. heheh. > Would turning off net.inet.ip.fastforwarding or any other setting > help? > > Today, I set net.inet.ip.fw.enable=0 and I'll see if that helps. I > have > a feeling that isn't related to the NIC at all, but I'm not sure what > else to try. > > Rudy > > > > Jack Vogel wrote: >> Watchdog resets the adapter. Messing with these values is of >> dubious value >> anyway. >> >> Jack >> >> >> On Fri, Oct 2, 2009 at 11:36 AM, Rudy >> wrote: >> >> >>> I noticed something interesting. >>> >>> I set the rc_int_delay to 0: >>> sysctl dev.em.5.rx_int_delay=0 >>> >>> Chcking via sysctl dev.em.5.debug=1 shows ex_int_delay is indeed 0: >>> Oct 1 17:32:41 mango kernel: em5: rx_int_delay = 0, >>> rx_abs_int_delay = 66 >>> >>> After a watchdog event, sysctl dev.em.5.debug=1 shows ex_int_delay >>> is >>> now 32: >>> Oct 2 11:29:49 mango kernel: em5: rx_int_delay = 32, >>> rx_abs_int_delay = >>> 66 >>> >>> However, running sysctl dev.em.5 shows it as 0: >>> dev.em.5.rx_int_delay: 0 >>> dev.em.5.tx_int_delay: 66 >>> >>> Seems like the adapter and the kernel don't agree on the >>> rx_int_delay >>> value. >>> >>> Rudy >>> >>> >> >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091005/d64f966c/PGP.pgp From mike at sentex.net Mon Oct 5 14:48:39 2009 From: mike at sentex.net (Mike Tancsa) Date: Mon Oct 5 14:48:46 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <20091004164756.GA6021@curry.mchp.siemens.de> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> <20091004164756.GA6021@curry.mchp.siemens.de> Message-ID: <200910051448.n95EmVcd025214@lava.sentex.ca> At 12:47 PM 10/4/2009, Andre Albsmeier wrote: >On Sat, 03-Oct-2009 at 22:27:39 +0000, Bjoern A. Zeeb wrote: > > On Sat, 3 Oct 2009, Andre Albsmeier wrote: > > > > Hi, > > > > > On Sat, 03-Oct-2009 at 16:27:32 -0400, jhell wrote: > > >> On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: > > >> > > >>> FYI, > > >>> > > >>> after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all > > >>> samba33 programmes did abort() immediately after start. The > > >>> solution was to use > > >>> > > >>> CONFIGURE_ARGS+= --disable-pie > > >>> > > >>> -Andre > > >>> > > >> > > >> To add an additional note samba33 even when not running (not > enabled by a rcvar) > > >> also runs a tdbcleanup routine on shutdown and/or start that also does > > >> abort(). > > > > > > Yes, every samba programme is linked with -pie per default (so > > > all abort()). > > > > > > Thanks for reporting the issue. People are aware of the problem now > > and we'll try to present a solution within the next days for better > > position-independent executable (PIE) handling. > > > > Meanwhile there are multiple solutions for people affected: > > > > (1) recompile the port; but as more than just samba might be affected > > and we generally do not want to flip the pie switch everywhere that's > > probably only a temporary, private solution. > >I'll stick to this since I am happy about having the map_at_zero >option and want to continue to try it out on 7.2-STABLE. And I >see now reason why samba has to be linked with -pie (without -pie >it is also 4% smaller). Hi, What are the impacts (if any) of compiling all the ports with PIE disabled that are effected by setting security.bsd.map_at_zero=0 ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From rblayzor.bulk at inoc.net Mon Oct 5 16:44:07 2009 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Mon Oct 5 16:44:17 2009 Subject: em0 watchdog timeouts In-Reply-To: <4AC66437.4040704@monkeybrains.net> References: <4AB9638B.8040607@monkeybrains.net> <4AC318E2.70306@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> Message-ID: On Oct 2, 2009, at 4:36 PM, Rudy wrote: > Today, I set net.inet.ip.fw.enable=0 and I'll see if that helps. I > have > a feeling that isn't related to the NIC at all, but I'm not sure what > else to try. Just curious, have you tried (or are you using) device polling? -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From bzeeb-lists at lists.zabbadoz.net Mon Oct 5 16:55:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Oct 5 16:55:14 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <200910051448.n95EmVcd025214@lava.sentex.ca> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> <20091004164756.GA6021@curry.mchp.siemens.de> <200910051448.n95EmVcd025214@lava.sentex.ca> Message-ID: <20091005163052.Q5956@maildrop.int.zabbadoz.net> On Mon, 5 Oct 2009, Mike Tancsa wrote: Hi Mike, >> > Thanks for reporting the issue. People are aware of the problem now >> > and we'll try to present a solution within the next days for better >> > position-independent executable (PIE) handling. >> > >> > Meanwhile there are multiple solutions for people affected: >> > >> > (1) recompile the port; but as more than just samba might be affected >> > and we generally do not want to flip the pie switch everywhere >> that's >> > probably only a temporary, private solution. >> >> I'll stick to this since I am happy about having the map_at_zero >> option and want to continue to try it out on 7.2-STABLE. And I >> see now reason why samba has to be linked with -pie (without -pie >> it is also 4% smaller). > > Hi, > What are the impacts (if any) of compiling all the ports with PIE disabled > that are effected by setting security.bsd.map_at_zero=0 ? Basically in first place compared to yesterday, there is no impact if you do it privately as it will not make much, if any, difference as PIE support in FreeBSD so far has basically been non-existent and was more working out of luck, according to my current understanding. Actually there is a slight difference that I should mention. With PIE valid user code is currently mapped at virtual address 0. That's why it started to fail for people setting map_at_zero to 0. So NULL pointer dereferences in applications like samba will not lead to the obvious error but will point at something, which in that case usually will be garbage and the application will either not work as intended (well that's alsready the case with a NULL derefernce;) or crash in random code (as a later consequence of the NULL deref). In the future though, it seems we will support PIE and in that case you'll get mappings at different place, in the end ideally slightly random so that it'll be hard to exploit the code itself as people no longer can easily pre-guess where things are in virtual memory. Disbaling PIE now means, that this will not happen later but you'll have the fixed (entry point) address, unless you recompile the ports again. I said, no impact if you do it privately above; the problems for the ports crew here are: 1) the entire set of ports affected by PIE is unidentified. 2) they build packages for 6/7 and 8, if not yet 9 as well soon for multiple architectures and cannot just rebuild everything. 3) they can especially not just rebuild the package set for the upcoming 8.0-RELEASE (don't ask, I don't know when it'll happen;). 4) basically they shouldn't need to care about which way the port (read the package as released by its devlepors) choses to be compiled by default. I do not have strong arguments if PIE makes a lot of sense but it seems that for the long term we'll have to support it, as parts of the other world support it as well, and once we support it even old packages will then continue to work even if people disable mapping_at_zero or if the release by default does that. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From jfvogel at gmail.com Mon Oct 5 16:57:50 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Oct 5 16:57:58 2009 Subject: em0 watchdog timeouts In-Reply-To: <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> References: <4AB9638B.8040607@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> Message-ID: <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> This posting just muddies the issue, first you talk about having a problem that involves Broadcom, ok, so post about that on something other than em :) Then you make some references to hardware that you "might have bought" but didn't, I'm not about debugging 'possible worlds problems' though so can't help you there either :) Finally you never say what the actual hardware is, other than a person who I do not know told you it was the best performer... so, what exactly is it? You have a problem once every 10 days, and at a specific time no less, this almost always means something in your environment, a cron job run amok, a piece of hardware that resets, I dunno, but the last thing I would suspect given this description is the driver. You need a good sysadmin for this debugging I would venture, not a driver developer. Jack On Mon, Oct 5, 2009 at 7:19 AM, Daniel Bond wrote: > Hi, > > I've been struggling with watchdog timeouts in 7.1/7.2-RELEASE for the past > 6months too. It looks related. > > I've tried to replace the hardware 3 times (2 different IBM x3755 chassis, > one IBM x3650 chassis). > I tried first with onboard broadcom NICs (bce-based) PCIx-based, until I > had issues with "watchdog timeout". > > I tried replacing it with a 4-port pci-x Intel NIC, which gave me same > problems. I was told that the 4-port intel NICs had an onboard > bus-controller, that > could cause trouble, so I replaced this with a 2-port PCI-e intel, which I > was told by a Sepherosa Ziehau was the best performing gig-e NIC (rx/tx). > > Still getting watchdog timeouts, I tried upgrading all sort of sysctls I > found in mailing-list threads (disable msi/msix interrupts, adjust rx/tx > processing, etc, etc). > I tried upgrading BIOS, firmware on all kinds of stuff (disks, BMC, etc, > etc) to newest version. I also tried using a different qlogic isp(4) > FC-controller (PCI-e). > > No matter what I tried, I could not diagnose this problem, or at least fix > it. Also it happened rarely enough, to not be easy to debugging. I would get > a series of "watchdog timeout -- resetting", until the NIC would go > completly offline - at the point I'd reboot it from console. > > This happened about once every 1-10 days, usually about 11-13:00. This > machine has now been replaced with Linux, unfortunately, just to avoid more > customer complaints and downtime. The IBM x3755 with FreeBSD7.2 which was > replaced with Linux, is still online, and > can be put at disposal for any developers who would like to debug this > further. > > Like Stefan Krueger mentioned, this machine is also running as NFS server, > with a mix of BSD and Linux clients, and it's getting hit pretty hard by > clients. > > > Hope we can iron this bug out, in the future. > > > Best regards, > > > Daniel Bond. > > > > > On Oct 2, 2009, at 10:36 PM, Rudy wrote: > > >> Ah, I'll stop messing with them. >> >> >> I just set them all to 0 to see if that will help and noticed the card >> was leaving tx_int_delay=1. >> >> # sysctl dev.em.4.debug=1 >> Oct 2 13:26:07 mango kernel: em4: tx_int_delay = 1, tx_abs_int_delay = 0 >> Oct 2 13:26:07 mango kernel: em4: rx_int_delay = 0, rx_abs_int_delay = 0 >> >> # sysctl dev.em.4 >> dev.em.4.%desc: Intel(R) PRO/1000 Network Connection 6.9.12 >> dev.em.4.rx_int_delay: 0 >> dev.em.4.tx_int_delay: 0 >> dev.em.4.rx_abs_int_delay: 0 >> dev.em.4.tx_abs_int_delay: 0 >> >> Splitting traffic to different ports has brought down the watchdog >> events to once a day. ... essentially, I have a quad 30Mbps (not quad >> 1Gbps) card. heheh. >> Would turning off net.inet.ip.fastforwarding or any other setting help? >> >> Today, I set net.inet.ip.fw.enable=0 and I'll see if that helps. I have >> a feeling that isn't related to the NIC at all, but I'm not sure what >> else to try. >> >> Rudy >> >> >> >> Jack Vogel wrote: >> >>> Watchdog resets the adapter. Messing with these values is of dubious >>> value >>> anyway. >>> >>> Jack >>> >>> >>> On Fri, Oct 2, 2009 at 11:36 AM, Rudy wrote: >>> >>> >>> I noticed something interesting. >>>> >>>> I set the rc_int_delay to 0: >>>> sysctl dev.em.5.rx_int_delay=0 >>>> >>>> Chcking via sysctl dev.em.5.debug=1 shows ex_int_delay is indeed 0: >>>> Oct 1 17:32:41 mango kernel: em5: rx_int_delay = 0, rx_abs_int_delay = >>>> 66 >>>> >>>> After a watchdog event, sysctl dev.em.5.debug=1 shows ex_int_delay is >>>> now 32: >>>> Oct 2 11:29:49 mango kernel: em5: rx_int_delay = 32, rx_abs_int_delay = >>>> 66 >>>> >>>> However, running sysctl dev.em.5 shows it as 0: >>>> dev.em.5.rx_int_delay: 0 >>>> dev.em.5.tx_int_delay: 66 >>>> >>>> Seems like the adapter and the kernel don't agree on the rx_int_delay >>>> value. >>>> >>>> Rudy >>>> >>>> >>>> >>> >>> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > From jhell at DataIX.net Mon Oct 5 17:06:28 2009 From: jhell at DataIX.net (jhell) Date: Mon Oct 5 17:06:36 2009 Subject: security.bsd.map_at_zero=0 problem with samba33 (including solution) In-Reply-To: <4AC8F27C.8070208@FreeBSD.org> References: <20091003184220.GA2620@curry.mchp.siemens.de> <20091003212308.GA3122@curry.mchp.siemens.de> <20091003215821.V26486@maildrop.int.zabbadoz.net> <4AC8F27C.8070208@FreeBSD.org> Message-ID: On Sun, 4 Oct 2009 12:07 -0700, dougb@ wrote: > Bjoern A. Zeeb wrote: >> On Sat, 3 Oct 2009, Andre Albsmeier wrote: >> >> Hi, >> >>> On Sat, 03-Oct-2009 at 16:27:32 -0400, jhell wrote: >>>> On Sat, 3 Oct 2009 14:42 -0000, Andre.Albsmeier wrote: >>>> >>>>> FYI, >>>>> >>>>> after setting security.bsd.map_at_zero to 0 on 7.2-STABLE all >>>>> samba33 programmes did abort() immediately after start. The >>>>> solution was to use >>>>> >>>>> CONFIGURE_ARGS+= --disable-pie >>>>> >>>>> -Andre >>>>> >>>> >>>> To add an additional note samba33 even when not running (not enabled >>>> by a rcvar) >>>> also runs a tdbcleanup routine on shutdown and/or start that also does >>>> abort(). >>> >>> Yes, every samba programme is linked with -pie per default (so >>> all abort()). >> >> >> Thanks for reporting the issue. People are aware of the problem now >> and we'll try to present a solution within the next days for better >> position-independent executable (PIE) handling. >> >> Meanwhile there are multiple solutions for people affected: >> >> (1) recompile the port; > > Just to be clear, you have to recompile the port with --disable-pie > added to the CONFIGURE_ARGS in the Makefile. > > It would also be nice if there were a __FreeBSD_version bump for this > new feature. > > > Doug > > Just to add on to this for those that may be wondering what they can do to solve this for just the ports infrastructure in the mean time. You may add the following to /etc/make.conf .if ${.CURDIR:M/usr/ports*} CONFIGURE_ARGS+= --disable-pie .endif This is assuming that you have your ports installed in the standard place of /usr/ports. If not you may adjust the match accordingly. This could also be extended to individual ports or substructures of your liking so that you are not adding those configure arguments to every port under the sun. Keep in mind, this should be followed carefully and not expected to be a full workaround as a greater solution still lies in wait. Best regards. -- %{----------------------------------------------------+ | dataix.net!jhell 2048R/89D8547E 2009-09-30 | | BSD since FreeBSD 4.2 Linux since Slackware 2.1 | | 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E | +----------------------------------------------------%} From lehmann at ans-netz.de Mon Oct 5 17:33:35 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Mon Oct 5 17:33:45 2009 Subject: glabel+gmirror (8.0-RC1 problem) In-Reply-To: <20090928184926.GA2016@garage.freebsd.pl> References: <20090927170244.0980d699.lehmann@ans-netz.de> <20090927223725.5893371f.lehmann@ans-netz.de> <20090928084035.GB1659@garage.freebsd.pl> <20090928203756.ef70e0c6.lehmann@ans-netz.de> <20090928184926.GA2016@garage.freebsd.pl> Message-ID: <20091005193340.cd84f0ec.lehmann@ans-netz.de> Pawel Jakub Dawidek wrote: > On Mon, Sep 28, 2009 at 08:37:56PM +0200, Oliver Lehmann wrote: > > Hi Pawel, > > > > Pawel Jakub Dawidek wrote: > > > > > Does anything change between you upgrade from BETA3 and RC1? For example > > > gmirror was compiled into the kernel before and now is loaded as module > > > or something similar? > > > > Nope, it was a clean BETA3 installation with the default GENERIC kernel > > which has afaik geom_label in kernel, but not geom_mirror (nevertheless I > > loaded geom_label.ko at boottime as well as geom_mirror) > > The same with RC1 - clean and fresh installation with the default GENERIC > > kernel and geom_label in kernel (default), but still loaded as module at > > boottime as well as geom_mirror. > > > > > Could you test this patch: > > > > > > http://people.freebsd.org/~pjd/patches/improved_taste.patch > > > > This makes gmirror+glabel work again on RC1 > > Thanks for confirmation. gjorunal is also affected. I tried to use one partition of my gmirror disk as journal device for my 3ware raid-5 device which works until I reboot - the journal is then gone as well. Is this patch likly to fix this as well? Will it be included in a future RC? Until now I've stayed away using glabel+gmirror but I didn't knew that gjournal is affected as well so I'm now left with warning that the journal provider is gone wile booting - and more tragically I'm left without journaling at all (which hurts on a 2.7TB partition when the system was not cleanly shut down) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From freebsd at jdc.parodius.com Mon Oct 5 17:42:23 2009 From: freebsd at jdc.parodius.com (Jeremy Chadwick) Date: Mon Oct 5 17:42:32 2009 Subject: Still possible to panic RELENG_7 with ZFS (kmem exhaustion)? Message-ID: <20091005172904.GA56362@icarus.home.lan> (Note: please keep me CC'd, as I am not subscribed to freebsd-stable) Is it still possible with ZFS to panic a RELENG_7 amd64 box (kernel/world from recent[1] source) with "kmem map too small" or similar conditions? Why I ask: Our production SQL/backup box kernel panic'd a couple days ago. Sadly, the box also acts as a serial console server, so I don't have the exact message spit back from the kernel prior to being dumped to DDB, but the backtrace looks very much like the historic problem of the ZFS ARC exhausting all kernel memory, so I'm betting the message prior to being dumped to DDB was "kmem map too small": db> bt Tracing pid 40738 tid 100168 td 0xffffff001f078720 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x176 kmem_malloc() at kmem_malloc+0x548 uma_large_malloc() at uma_large_malloc+0x3c malloc() at malloc+0xc1 arc_get_data_buf() at arc_get_data_buf+0x1bb arc_buf_alloc() at arc_buf_alloc+0xa1 arc_read_nolock() at arc_read_nolock+0xd1 arc_read() at arc_read+0x71 dbuf_prefetch() at dbuf_prefetch+0x135 dmu_zfetch_dofetch() at dmu_zfetch_dofetch+0xe3 dmu_zfetch() at dmu_zfetch+0xa58 dbuf_read() at dbuf_read+0x433 dmu_buf_hold_array_by_dnode() at dmu_buf_hold_array_by_dnode+0x119 dmu_buf_hold_array() at dmu_buf_hold_array+0x57 dmu_read_uio() at dmu_read_uio+0x3f zfs_freebsd_read() at zfs_freebsd_read+0x55a vn_read() at vn_read+0x1ef dofileread() at dofileread+0x88 kern_readv() at kern_readv+0x43 read() at read+0x4d syscall() at syscall+0x247 Xfast_syscall() at Xfast_syscall+0xab The machine in question has absolutely no loader.conf tuning applied, and kernel/world was built from RELENG_7 dated 2009/06/11. The ZFS pool consisted of a single (entire) disk; nothing special. I do not have sysctl counters from the box before it panic'd, but these are what are active presently: hw.physmem: 4286558208 vm.kmem_size_max: 329853485875 vm.kmem_size_min: 0 vm.kmem_size: 1381478400 With regards to the above counters: ZFS is not in use. I had to switch back to UFS2 (zpool destroy + newfs -O2 -U...) because of stability concerns relating to the question at hand. If someone familiar with the FreeBSD ZFS internals, and/or the VM, please make a statement I think it would beneficial to those who are considering using/migrating to ZFS on FreeBSD. The only "semi-official" statements I've read as of late are here: http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051810.html http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051830.html And what's in src/UPDATING: 20090207: ZFS users on amd64 machines with 4GB or more of RAM should reevaluate their need for setting vm.kmem_size_max and vm.kmem_size manually. In fact, after recent changes to the kernel, the default value of vm.kmem_size is larger than the suggested manual setting in most ZFS/FreeBSD tuning guides. Thanks! [1]: "Recent" means post-February 2009, specifically after Alan Cox's commits listed here: http://svn.freebsd.org/changeset/base/188291 http://svn.freebsd.org/changeset/base/187523 http://svn.freebsd.org/changeset/base/187522 http://svn.freebsd.org/changeset/base/187520 http://svn.freebsd.org/changeset/base/187485 http://svn.freebsd.org/changeset/base/187466 http://svn.freebsd.org/changeset/base/187465 http://svn.freebsd.org/changeset/base/187464 http://svn.freebsd.org/changeset/base/187458 http://svn.freebsd.org/changeset/base/187428 http://svn.freebsd.org/changeset/base/187425 http://svn.freebsd.org/changeset/base/187420 http://svn.freebsd.org/changeset/base/187419 http://svn.freebsd.org/changeset/base/187416 http://svn.freebsd.org/changeset/base/187414 http://svn.freebsd.org/changeset/base/187408 http://svn.freebsd.org/changeset/base/187407 http://svn.freebsd.org/changeset/base/187404 http://svn.freebsd.org/changeset/base/187400 -- | Jeremy Chadwick jdc@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 db at danielbond.org Mon Oct 5 19:32:54 2009 From: db at danielbond.org (Daniel Bond) Date: Mon Oct 5 19:33:14 2009 Subject: em0 watchdog timeouts In-Reply-To: <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> References: <4AB9638B.8040607@monkeybrains.net> <4AC3DB8F.7010602@monkeybrains.net> <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> Message-ID: <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> Hi Jack, I'll comment your mail inline: On Oct 5, 2009, at 6:57 PM, Jack Vogel wrote: > This posting just muddies the issue, first you talk about having a > problem that > involves Broadcom, ok, so post about that on something other than > em :) I only meant to indicate that the problem might exist outside the intel driver. I'm also indicating that it happens with several drivers (bge, bce and em) on several different machines, on both pci-x and pci-e. I'm sorry if this is confusing to you, but I still think it's relevant to mention. > > Then you make some references to hardware that you "might have bought" > but didn't, I'm not about debugging 'possible worlds problems' > though so > can't help you there either :) No. I only made references to hardware I actually used, and had real- world issues with. > > Finally you never say what the actual hardware is, other than a > person who > I do not know told you it was the best performer... so, what exactly > is it? Sepherosa is a guy that writes drivers for BSD based operating systems. Including FreeBSD. He has a lot of knowledge in this area. http://people.freebsd.org/~sephe/ The NIC you are referring to, the one sephe recommended me, is a 82571EB. I didn't mention specific hardware, as I think it's more important to note this is an issue I'm experiencing across different sets of hardware and drivers. > > You have a problem once every 10 days, and at a specific time no > less, > this almost always means something in your environment, a cron job run > amok, a piece of hardware that resets, I dunno, but the last thing I > would > suspect given this description is the driver. This is not what I wrote. I wrote I had a problem every 1-10 days, but it would usually happen once every 3-4 days. At worst, every day in periods. It's not at any specific time. If you read my email correctly, I say it *usually* happens arround 11-13:00, but it has happened at random times too. This is my point exactly. I don't think it's the Intel-driver, I think the problem is elsewhere. I had a suspicion it had to do with the combination of nic + qlogic fc-controller, but I have no evidence of this. > > You need a good sysadmin for this debugging I would venture, not a > driver > developer. What I need is useful advice/help. I never stated I needed a driver developer. I'd like to be able to run my favorite OS on cool hardware, in the future, for a high-performing NFS-server, without problems like I've experienced the past 6months, on a production system. Please note that I'm managing a server-park almost completely based on FreeBSD, and I'm running many NFS servers on other hardware, for other services, without issues. I've seen several other FreeBSD-users having problems with this too, so I think it's of importance for the project. As I mentioned originally, I'm happy to dispose the hardware to any FreeBSD developer that might want to look further into this. Debugging it further is above my skill-set, I don't even know where to begin looking, especially since I can't produce any panics. I'm sorry to say, but your reply was %0 useful, Jack. > > Jack > - Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091005/e5813214/PGP.pgp From jfvogel at gmail.com Mon Oct 5 19:40:00 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Oct 5 19:40:08 2009 Subject: em0 watchdog timeouts In-Reply-To: <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> References: <4AB9638B.8040607@monkeybrains.net> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> Message-ID: <2a41acea0910051239w7abad271n607295418fc2537f@mail.gmail.com> Sorry, its a Monday morning, I was being kinda facetious, guess it didn't work very well :) I apologize. I know it must be annoying for you, its as much so for me when its something I can't just fix because its not reproducible. So, I feel your pain. Will try to restrain my Monday blues in the future. Jack On Mon, Oct 5, 2009 at 11:32 AM, Daniel Bond wrote: > Hi Jack, > > I'll comment your mail inline: > > > On Oct 5, 2009, at 6:57 PM, Jack Vogel wrote: > > This posting just muddies the issue, first you talk about having a problem >> that >> involves Broadcom, ok, so post about that on something other than em :) >> > > I only meant to indicate that the problem might exist outside the intel > driver. > I'm also indicating that it happens with several drivers (bge, bce and em) > on several different machines, on both pci-x and pci-e. > > I'm sorry if this is confusing to you, but I still think it's relevant to > mention. > > >> Then you make some references to hardware that you "might have bought" >> but didn't, I'm not about debugging 'possible worlds problems' though so >> can't help you there either :) >> > > No. I only made references to hardware I actually used, and had real-world > issues with. > > >> Finally you never say what the actual hardware is, other than a person who >> I do not know told you it was the best performer... so, what exactly is >> it? >> > > Sepherosa is a guy that writes drivers for BSD based operating systems. > Including FreeBSD. He has a lot of knowledge in this area. > http://people.freebsd.org/~sephe/ > > The NIC you are referring to, the one sephe recommended me, is a 82571EB. I > didn't mention specific hardware, as I think it's more important > to note this is an issue I'm experiencing across different sets of hardware > and drivers. > > >> You have a problem once every 10 days, and at a specific time no less, >> this almost always means something in your environment, a cron job run >> amok, a piece of hardware that resets, I dunno, but the last thing I would >> suspect given this description is the driver. >> > > This is not what I wrote. I wrote I had a problem every 1-10 days, but it > would usually happen once every 3-4 days. At worst, every day in periods. > > It's not at any specific time. If you read my email correctly, I say it > *usually* happens arround 11-13:00, > but it has happened at random times too. > > This is my point exactly. I don't think it's the Intel-driver, I think the > problem is elsewhere. I had a suspicion it had to do with the combination of > nic + qlogic fc-controller, but I have no evidence of this. > > >> You need a good sysadmin for this debugging I would venture, not a driver >> developer. >> > > What I need is useful advice/help. I never stated I needed a driver > developer. > > I'd like to be able to run my favorite OS on cool hardware, in the future, > for a high-performing NFS-server, without problems like I've experienced the > past 6months, on a production system. > Please note that I'm managing a server-park almost completely based on > FreeBSD, and I'm running many NFS servers on other hardware, for other > services, without issues. > > I've seen several other FreeBSD-users having problems with this too, so I > think it's of importance for the project. As I mentioned originally, I'm > happy to dispose the hardware to any FreeBSD developer > that might want to look further into this. Debugging it further is above my > skill-set, I don't even know where to begin looking, especially since I > can't produce any panics. > > I'm sorry to say, but your reply was %0 useful, Jack. > > >> Jack >> >> > - Daniel > From freebsd at byshenk.net Mon Oct 5 20:30:02 2009 From: freebsd at byshenk.net (Greg Byshenk) Date: Mon Oct 5 20:30:15 2009 Subject: em0 watchdog timeouts In-Reply-To: <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> References: <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> Message-ID: <20091005200900.GE15606@core.byshenk.net> On Mon, Oct 05, 2009 at 08:32:14PM +0200, Daniel Bond wrote: > What I need is useful advice/help. I never stated I needed a driver > developer. > > I'd like to be able to run my favorite OS on cool hardware, in the > future, for a high-performing NFS-server, without problems like I've > experienced the past 6months, on a production system. > Please note that I'm managing a server-park almost completely based on > FreeBSD, and I'm running many NFS servers on other hardware, for other > services, without issues. > > I've seen several other FreeBSD-users having problems with this too, > so I think it's of importance for the project. As I mentioned > originally, I'm happy to dispose the hardware to any FreeBSD developer > that might want to look further into this. Debugging it further is > above my skill-set, I don't even know where to begin looking, > especially since I can't produce any panics. I can give one bit of advice that helped me in a similar situation: check you motherboards. I run about a dozen fileservers on FreeBSD, and have always been very happy with their performance, but some months ago I began to experience problems with one of them. These problems were 'watchdog timeout' errors. Tried all manner of things, different NICs of different types, changing settings, etc., but nothing helped over the long term. At some point, when very heavy i/o was going on to our Beowulf cluster, the 'watchdog timeouts' would begin. What was strange is that other (supposedly identical) machines handled _more_ i/o without a problem. Finally, while doing some comparisons, I realized that the motherboard having the problem was _not_ the same as the others; it was similar, but not identical. I changed the motherboard and all the problems went away, never to reappear. I don't know if it was a specific problem with that particular motherboard, or something about that model, but for whatever reason, it appears that the buses just couldn't handle a RAID card and three active NICs. -- greg byshenk - gbyshenk@byshenk.net - Leiden, NL From crapsh at monkeybrains.net Mon Oct 5 20:53:59 2009 From: crapsh at monkeybrains.net (Rudy) Date: Mon Oct 5 20:54:05 2009 Subject: em0 watchdog timeouts In-Reply-To: <20091005200900.GE15606@core.byshenk.net> References: <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <4AC5198E.7030609@monkeybrains.net> <4AC51B4C.7080905@monkeybrains.net> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> <20091005200900.GE15606@core.byshenk.net> Message-ID: <4ACA5D1E.10006@monkeybrains.net> > Finally, while doing some comparisons, I realized that the motherboard > having the problem was _not_ the same as the others; it was similar, but > not identical. This is a good piece of info. I can try swapping out the MB and see what happens. I do want to add: thank you Jack for all your help and if does turn out to be the MB, then double thanks. Viva Monday! :) What would be nice would be MORE info for a watchdog timeout... maybe a sysctl dev.watchdog.debug=1 or something where when a watchdog event happened --- for whatever driver --- a bunch of stats were dumped relating to the event. Rudy From jfvogel at gmail.com Mon Oct 5 22:16:17 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Oct 5 22:16:24 2009 Subject: em0 watchdog timeouts In-Reply-To: <4ACA5D1E.10006@monkeybrains.net> References: <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> <20091005200900.GE15606@core.byshenk.net> <4ACA5D1E.10006@monkeybrains.net> Message-ID: <2a41acea0910051516n22237511s3c322fe0c1566b1@mail.gmail.com> Hmmm, I did have one of the drivers print more info at watchdog time, but I just looked and that's not em, time to add that I guess. Since you're in the driver there isn't a huge amount of info that you can print, it still may not be enough to help. BTW, I've always been somewhat dissatisfied with the watchdog design and think its kinda flawed, I could try and make you an experimental with debug and some changes that you can try if you'd like. Jack On Mon, Oct 5, 2009 at 1:54 PM, Rudy wrote: > Finally, while doing some comparisons, I realized that the motherboard >> having the problem was _not_ the same as the others; it was similar, but >> not identical. >> > > This is a good piece of info. I can try swapping out the MB and see what > happens. > > I do want to add: thank you Jack for all your help and if does turn out to > be the MB, then double thanks. Viva Monday! :) > > What would be nice would be MORE info for a watchdog timeout... maybe a > sysctl dev.watchdog.debug=1 or something where when a watchdog event > happened --- for whatever driver --- a bunch of stats were dumped relating > to the event. > > Rudy > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From db at danielbond.org Mon Oct 5 22:49:16 2009 From: db at danielbond.org (Daniel Bond) Date: Mon Oct 5 22:49:24 2009 Subject: openssh concerns In-Reply-To: <4ACA6BE8.3000402@FreeBSD.org> References: <20091003121830.GA15170@sorry.mine.nu> <4AC7B690.1060607@gmail.com> <4ACA6BE8.3000402@FreeBSD.org> Message-ID: <460A3E92-37D5-49CA-A079-EC08867B8DD4@danielbond.org> Hi. I explained my opinion quite well (imo) a bit further down in my previous email. I'm not sure what to answer. I don't necessarily think it's relevant for every computer running sshd. I see a tendency to change sshd port to 2022 and other port numbers. I'm not sure everyone doing it is aware that using unprivileged ports also has consequences, compared to (often) a few harmless logentries. I'd much rather use an privileged port, or mac_portacl(4), like mentioned earlier. Best regards, Daniel. I've noticed quite a bit of suggestions to use 2022, 2222 and such On Oct 5, 2009, at 11:58 PM, Doug Barton wrote: > Daniel Bond wrote: >> However, I'm concerned about the suggestion of using an >> unprivileged port > > Please explain your reasoning, and how it's relevant in a world where > the vast majority of Internet users have complete administrative > control over the systems they use. > > > Doug > > -- > > This .signature sanitized for your protection > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091005/2fdda7bc/PGP.pgp From matthew.fleming at isilon.com Mon Oct 5 23:48:56 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Mon Oct 5 23:49:04 2009 Subject: libthr and daemon() Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com> I have some code that tries to use pthread_cond_wait() and it's getting back EPERM. Upon further investigation, here's what I've found: When the app starts, libthr's _libpthread_init calls init_main_thread() to set the thread id in struct pthread's tid. The app opens a log file then calls daemon(). daemon() calls fork() fork() does not appear to be linked to _fork() in libthr; see below. The app creates a thread to handle signals. The app attempts to wait on a condition variable (pthread_cond_wait(); this gives EPERM). Looking into libthr's cond_wait_common(), it does a THR_UMUTEX_LOCK on the cv's c_lock using the struct pthread from _get_curthread(). Here, curthread points to the pthread struct that got the tid from thr_self on startup. Because of fork() this is the same address in the daemonized app as the original. But curthread->tid is the tid of the original app, not the daemonized version, hence my assumption that fork() didn't resolve to libthr's _fork(). When cond_wait_common() calls into the kernel to actually do the cv_wait, do_unlock_umutex/do_unlock_normal() returns EPERM since the tid does not match. AFAICT this has nothing to do with any code in the app itself. The two things I don't know: 1) what utilities can I use to show me which version of fork will be used at runtime? ldd just shows me that the app is linked against libc and libthr. 2) why would fork resolve to the one in libc (presumably, I'm not sure how to prove this) instead of the one in libthr? Thanks, matthew From deischen at freebsd.org Tue Oct 6 00:06:12 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Tue Oct 6 00:06:19 2009 Subject: libthr and daemon() In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com> References: <06D5F9F6F655AD4C92E28B662F7F853E03217DCE@seaxch09.desktop.isilon.com> Message-ID: On Mon, 5 Oct 2009, Matthew Fleming wrote: > I have some code that tries to use pthread_cond_wait() and it's getting > back EPERM. Upon further investigation, here's what I've found: > > When the app starts, libthr's _libpthread_init calls init_main_thread() > to set the thread id in struct pthread's tid. Is the application threaded before calling daemon()? > The app opens a log file then calls daemon(). > daemon() calls fork() > fork() does not appear to be linked to _fork() in libthr; see below. > The app creates a thread to handle signals. > The app attempts to wait on a condition variable (pthread_cond_wait(); > this gives EPERM). Was the condition variable created before daemon() was called? The picture is not clear to me. POSIX states that only async-signal-safe function calls can be made from a child fork()'d from a threaded application. The intent is that the child should soon after call a function in the exec() family. Certainly, any more threaded calls in the child are invalid. -- DE From crapsh at monkeybrains.net Tue Oct 6 03:07:35 2009 From: crapsh at monkeybrains.net (Rudy (bulk)) Date: Tue Oct 6 03:07:41 2009 Subject: em0 watchdog timeouts In-Reply-To: <2a41acea0910051516n22237511s3c322fe0c1566b1@mail.gmail.com> References: <2a41acea0909301556g1df7dbafv813f5924553c8bfb@mail.gmail.com> <2a41acea0910011450v41590f3dn112f367f26faed2d@mail.gmail.com> <4AC64835.3060107@monkeybrains.net> <2a41acea0910021237w415efa2cs4354a0f99aef8f6@mail.gmail.com> <4AC66437.4040704@monkeybrains.net> <6194E9BC-3A3D-4941-A777-88C7411905B0@danielbond.org> <2a41acea0910050957x2d085e90w2ebea7f9eb87c3e4@mail.gmail.com> <57F8F331-E823-4F88-BDD5-A8B95A3B4CB6@danielbond.org> <20091005200900.GE15606@core.byshenk.net> <4ACA5D1E.10006@monkeybrains.net> <2a41acea0910051516n22237511s3c322fe0c1566b1@mail.gmail.com> Message-ID: <4ACAB408.3050202@monkeybrains.net> > BTW, I've always been somewhat dissatisfied with the watchdog design and > think > its kinda flawed, I could try and make you an experimental with debug and > some > changes that you can try if you'd like. > I'm game -- it would be nice if the machine still reset the watchdog in 3 seconds and didn't cause any more damage from the debug code (eg a panic). :) My frequency of watchdog events is about 2 or 3 times per day. I am running: Intel(R) PRO/1000 Network Connection 6.9.12 Rudy From cryx-freebsd at h3q.com Tue Oct 6 12:03:48 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Tue Oct 6 12:05:05 2009 Subject: 8.0-RC1 ZFS-root installscript Message-ID: <4ACB2BE0.8080809@h3q.com> Hi, if anyone has some spare empty disks and always wanted to try out a FreeBSD zfs-root installation, feel free to test http://anonsvn.h3q.com/projects/freebsd-patches/export/45/manageBE/create-zfsboot-gpt_livecd.sh. This script will install FreeBSD onto a GPT based ZFS-root from the Fixit console of a 8.0-RC1 livefs-CD, maybe from the memstick too, haven't tested that. As the livefs on the CD does not include any freebsd packages, you need network connection before running the script. You can use more than one disk to create a zfsroot-mirror. All ZFS tuning recommendations do apply. WARNING: this script will remove any data on the disks you use! Feel free to send bugreports to me. greetings, philipp From gausus at gausus.net Tue Oct 6 13:59:43 2009 From: gausus at gausus.net (Maciej Jan Broniarz) Date: Tue Oct 6 13:59:50 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB2BE0.8080809@h3q.com> References: <4ACB2BE0.8080809@h3q.com> Message-ID: <4ACB4D47.6090107@gausus.net> W dniu 09-10-06 13:37, Philipp Wuensche pisze: > Hi, > As the livefs on the CD does not include any freebsd packages, you need > network connection before running the script. Dumb question, but how can I get gpart on livefs? mjb From cryx-freebsd at h3q.com Tue Oct 6 14:05:46 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Tue Oct 6 14:05:52 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB4D47.6090107@gausus.net> References: <4ACB2BE0.8080809@h3q.com> <4ACB4D47.6090107@gausus.net> Message-ID: <4ACB4EB7.3080305@h3q.com> Maciej Jan Broniarz wrote: > W dniu 09-10-06 13:37, Philipp Wuensche pisze: >> Hi, > >> As the livefs on the CD does not include any freebsd packages, you need >> network connection before running the script. > > Dumb question, but how can I get gpart on livefs? I'm not sure I understand the question. If you boot a 8.0-RC1 livefs CD, you will have usable gpart in the fixit console. greetings, philipp From gausus at gausus.net Tue Oct 6 15:45:32 2009 From: gausus at gausus.net (Maciej Jan Broniarz) Date: Tue Oct 6 15:45:39 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB4EB7.3080305@h3q.com> References: <4ACB2BE0.8080809@h3q.com> <4ACB4D47.6090107@gausus.net> <4ACB4EB7.3080305@h3q.com> Message-ID: <4ACB6616.9000407@gausus.net> W dniu 09-10-06 16:05, Philipp Wuensche pisze: > Maciej Jan Broniarz wrote: >> W dniu 09-10-06 13:37, Philipp Wuensche pisze: >>> Hi, >> >>> As the livefs on the CD does not include any freebsd packages, you need >>> network connection before running the script. >> >> Dumb question, but how can I get gpart on livefs? > > I'm not sure I understand the question. If you boot a 8.0-RC1 livefs CD, > you will have usable gpart in the fixit console. Ok. gpart is not in $PATH. I had to add /dest/sbin to $PATH for the script to work. Still there are some problems. Is there a way to force passive mode in an ftp connection? I keep geting Illegal PORT command during the download phase. Best regards, mjb From cryx-freebsd at h3q.com Tue Oct 6 15:59:37 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Tue Oct 6 15:59:44 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB6616.9000407@gausus.net> References: <4ACB2BE0.8080809@h3q.com> <4ACB4D47.6090107@gausus.net> <4ACB4EB7.3080305@h3q.com> <4ACB6616.9000407@gausus.net> Message-ID: <4ACB6966.5060704@h3q.com> Maciej Jan Broniarz wrote: > W dniu 09-10-06 16:05, Philipp Wuensche pisze: >> Maciej Jan Broniarz wrote: >>> W dniu 09-10-06 13:37, Philipp Wuensche pisze: >>>> Hi, >>> >>>> As the livefs on the CD does not include any freebsd packages, you need >>>> network connection before running the script. >>> >>> Dumb question, but how can I get gpart on livefs? >> >> I'm not sure I understand the question. If you boot a 8.0-RC1 livefs CD, >> you will have usable gpart in the fixit console. > > Ok. gpart is not in $PATH. I had to add /dest/sbin to $PATH for the > script to work. What CD and version are you using? Are you sure you are using the live-filesystem? Don't use the emergency-shell! > Still there are some problems. Is there a way to force > passive mode in an ftp connection? I keep geting Illegal PORT command > during the download phase. passive-mode is the default of the freebsd ftp. greetings, philipp From gausus at gausus.net Tue Oct 6 16:03:43 2009 From: gausus at gausus.net (Maciej Jan Broniarz) Date: Tue Oct 6 16:03:52 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB6966.5060704@h3q.com> References: <4ACB2BE0.8080809@h3q.com> <4ACB4D47.6090107@gausus.net> <4ACB4EB7.3080305@h3q.com> <4ACB6616.9000407@gausus.net> <4ACB6966.5060704@h3q.com> Message-ID: <4ACB6A58.2020705@gausus.net> W dniu 09-10-06 17:59, Philipp Wuensche pisze: > Maciej Jan Broniarz wrote: >> W dniu 09-10-06 16:05, Philipp Wuensche pisze: >>> Maciej Jan Broniarz wrote: >>>> W dniu 09-10-06 13:37, Philipp Wuensche pisze: >>>>> Hi, >>>> >>>>> As the livefs on the CD does not include any freebsd packages, you need >>>>> network connection before running the script. >>>> >>>> Dumb question, but how can I get gpart on livefs? >>> >>> I'm not sure I understand the question. If you boot a 8.0-RC1 livefs CD, >>> you will have usable gpart in the fixit console. >> >> Ok. gpart is not in $PATH. I had to add /dest/sbin to $PATH for the >> script to work. > > What CD and version are you using? Are you sure you are using the > live-filesystem? Don't use the emergency-shell! > I use: 8.0-RC1-amd64-livefs.iso In the main menu i go to: Fixit, and then CD/DVD live fs. >> Still there are some problems. Is there a way to force >> passive mode in an ftp connection? I keep geting Illegal PORT command >> during the download phase. > > passive-mode is the default of the freebsd ftp. Hmmm. Ok. mjb From edhoprima at gmail.com Tue Oct 6 16:57:49 2009 From: edhoprima at gmail.com (Edho P Arief) Date: Tue Oct 6 16:57:58 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB6616.9000407@gausus.net> References: <4ACB2BE0.8080809@h3q.com> <4ACB4D47.6090107@gausus.net> <4ACB4EB7.3080305@h3q.com> <4ACB6616.9000407@gausus.net> Message-ID: On Tue, Oct 6, 2009 at 10:45 PM, Maciej Jan Broniarz wrote: > W dniu 09-10-06 16:05, Philipp Wuensche pisze: >> >> Maciej Jan Broniarz wrote: >>> >>> W dniu 09-10-06 13:37, Philipp Wuensche pisze: >>>> >>>> Hi, >>> >>>> As the livefs on the CD does not include any freebsd packages, you need >>>> network connection before running the script. >>> >>> Dumb question, but how can I get gpart on livefs? >> >> I'm not sure I understand the question. If you boot a 8.0-RC1 livefs CD, >> you will have usable gpart in the fixit console. > > Ok. gpart is not in $PATH. I had to add /dest/sbin to $PATH for the script > to work. Still there are some problems. Is there a way to force passive mode > in an ftp connection? I keep geting Illegal PORT command > during the download phase. > did you change the shell after login to the console? -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From gausus at gausus.net Tue Oct 6 17:16:41 2009 From: gausus at gausus.net (Maciej Jan Broniarz) Date: Tue Oct 6 17:16:49 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: References: <4ACB2BE0.8080809@h3q.com> <4ACB4D47.6090107@gausus.net> <4ACB4EB7.3080305@h3q.com> <4ACB6616.9000407@gausus.net> Message-ID: <4ACB7B72.9050401@gausus.net> W dniu 09-10-06 18:57, Edho P Arief pisze: > On Tue, Oct 6, 2009 at 10:45 PM, Maciej Jan Broniarz wrote: >> W dniu 09-10-06 16:05, Philipp Wuensche pisze: >>> >>> Maciej Jan Broniarz wrote: >>>> >>>> W dniu 09-10-06 13:37, Philipp Wuensche pisze: >>>>> >>>>> Hi, >>>> >>>>> As the livefs on the CD does not include any freebsd packages, you need >>>>> network connection before running the script. >>>> >>>> Dumb question, but how can I get gpart on livefs? >>> >>> I'm not sure I understand the question. If you boot a 8.0-RC1 livefs CD, >>> you will have usable gpart in the fixit console. >> >> Ok. gpart is not in $PATH. I had to add /dest/sbin to $PATH for the script >> to work. Still there are some problems. Is there a way to force passive mode >> in an ftp connection? I keep geting Illegal PORT command >> during the download phase. >> > > did you change the shell after login to the console? > > no i didn't mjb From cryx-freebsd at h3q.com Tue Oct 6 22:16:42 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Tue Oct 6 22:16:50 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACB2BE0.8080809@h3q.com> References: <4ACB2BE0.8080809@h3q.com> Message-ID: <4ACBC1C8.5060400@h3q.com> Philipp Wuensche wrote: > > Feel free to send bugreports to me. Thanks for the bug-reports and feature suggestions! There is a new version available: http://anonsvn.h3q.com/projects/freebsd-patches/export/48/manageBE/create-zfsboot-gpt_livecd.sh New stuff: - support for installing the distribution packages from a local directory, like /dist/8.0-RC1 on the install-DVD - untested support for raidz, I can't test this because virtualbox only provides one BIOS disk to the bootloader and raidz needs at least two disks for booting :-/ - some minor fixes and tunes greetings, philipp From fbsdlist at src.cx Tue Oct 6 22:43:59 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Tue Oct 6 22:44:06 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACBC1C8.5060400@h3q.com> References: <4ACB2BE0.8080809@h3q.com> <4ACBC1C8.5060400@h3q.com> Message-ID: > - untested support for raidz, I can't test this because virtualbox only > provides one BIOS disk to the bootloader and raidz needs at least two > disks for booting :-/ You can try creating raidz from multiple GPT slices on the same disk. --Artem From rmacklem at uoguelph.ca Tue Oct 6 23:44:42 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Oct 6 23:44:49 2009 Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) In-Reply-To: References: <4ABD4BB9.1030804@FreeBSD.org> Message-ID: On Sun, 27 Sep 2009, Robert Watson wrote: > > On Fri, 25 Sep 2009, Jamie Gritton wrote: > >> It seems to be NFS related. I think the null pointer in question is from >> the export's anonymous credential. Try the patch below and see if it helps >> (which I guess means run it overnight and see if it crashes again). I've >> also patched a similar missing cred prison in GSS_SVC, since I'm not versed >> enough in NFS/RPC stuff to know if it might be the problem. > > This is one of the reasons I really dislike "magic" credentials and special > handling of NULL credentials -- they always get into code the author doesn't > expect, and either there are bad pointer dereferences, or incorrect security > decisions. It's almost always the case that a correct credential should have > been cached or generated at some earlier point to represent the security > context... > I don't really understand prisons/jails, but would creating these credentials via: crdup(td->td_ucred); // duplicating the daemon thread's cred - and then replacing the make sense as an alternative to starting with crget()? (ie. All the other stuff except would be "inherited" from the credential for the daemon thread.) rick From pgollucci at p6m7g8.com Wed Oct 7 06:40:07 2009 From: pgollucci at p6m7g8.com (Philip M. Gollucci) Date: Wed Oct 7 06:40:16 2009 Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-09:05.null In-Reply-To: <200910022012.n92KCtLI004038@freefall.freebsd.org> References: <200910022012.n92KCtLI004038@freefall.freebsd.org> Message-ID: <4ACC3315.7040704@p6m7g8.com> > Corrected: 2009-10-02 18:09:56 UTC (RELENG_8, 8.0-RC2) > 2009-10-02 18:09:56 UTC (RELENG_7, 7.2-STABLE) > 2009-10-02 18:09:56 UTC (RELENG_7_2, 7.2-RELEASE-p4) > 2009-10-02 18:09:56 UTC (RELENG_7_1, 7.1-RELEASE-p8) > 2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) > 2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) > 2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) > - ------------------------------------------------------------------------- > RELENG_6 > RELENG_6_4 > RELENG_6_3 > RELENG_7 > RELENG_7_2 > RELENG_7_1 > RELENG_8 > - ------------------------------------------------------------------------- > Branch/path Revision > - ------------------------------------------------------------------------- > stable/6/ r197715 > releng/6.4/ r197715 > releng/6.3/ r197715 > stable/7/ r197715 > releng/7.2/ r197715 > releng/7.1/ r197715 > stable/8/ r197714 > - ------------------------------------------------------------------------- Don't these usually mention HEAD/CURRENT ? and is the 197714 a typo ? -- ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 Consultant - P6M7G8 Inc. http://p6m7g8.net Senior Sys Admin - RideCharge, Inc. http://ridecharge.com ASF Member - Apache Software Foundation http://apache.org FreeBSD Committer - FreeBSD Foundation http://freebsd.org Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From bzeeb-lists at lists.zabbadoz.net Wed Oct 7 07:45:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Oct 7 07:45:14 2009 Subject: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-09:05.null In-Reply-To: <4ACC3315.7040704@p6m7g8.com> References: <200910022012.n92KCtLI004038@freefall.freebsd.org> <4ACC3315.7040704@p6m7g8.com> Message-ID: <20091007073750.K5956@maildrop.int.zabbadoz.net> On Wed, 7 Oct 2009, Philip M. Gollucci wrote: > >> Corrected: 2009-10-02 18:09:56 UTC (RELENG_8, 8.0-RC2) >> 2009-10-02 18:09:56 UTC (RELENG_7, 7.2-STABLE) >> 2009-10-02 18:09:56 UTC (RELENG_7_2, 7.2-RELEASE-p4) >> 2009-10-02 18:09:56 UTC (RELENG_7_1, 7.1-RELEASE-p8) >> 2009-10-02 18:09:56 UTC (RELENG_6, 6.4-STABLE) >> 2009-10-02 18:09:56 UTC (RELENG_6_4, 6.4-RELEASE-p7) >> 2009-10-02 18:09:56 UTC (RELENG_6_3, 6.3-RELEASE-p13) > >> - ------------------------------------------------------------------------- >> RELENG_6 >> RELENG_6_4 >> RELENG_6_3 >> RELENG_7 >> RELENG_7_2 >> RELENG_7_1 >> RELENG_8 >> - ------------------------------------------------------------------------- > >> Branch/path Revision >> - ------------------------------------------------------------------------- >> stable/6/ r197715 >> releng/6.4/ r197715 >> releng/6.3/ r197715 >> stable/7/ r197715 >> releng/7.2/ r197715 >> releng/7.1/ r197715 >> stable/8/ r197714 >> - ------------------------------------------------------------------------- > > Don't these usually mention HEAD/CURRENT ? No. > and is the 197714 a typo ? No. That was a separate MFC from HEAD in constrast to stable/7,8 which were committed along with the 2 security advisories. The correction date in the first line is a bit off though, as the 8.0-RC2 MFC had been a few minutes earlier. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From mailinglist at ucwv.edu Wed Oct 7 17:41:56 2009 From: mailinglist at ucwv.edu (mailinglist) Date: Wed Oct 7 17:42:03 2009 Subject: Installing Cacti from Ports Message-ID: <93C575B79E9B01449EBBB084032BC57011F84E7A52@mail.ucwv.edu> I hada VM running an older installation of FreeBSD 7.2. I recently got back to it and tried to install Cacti from the ports collection. I cvsup'd in an up-to-date ports collection, and did the usual "make, make install" for Cacti. During the "make install" process a dependency failed to build. I believe it was xcb-utils that failed to build because XCB was at version 1.2 and needed to be at 1.4. I couldn't get the issue resolved no matter what I tried. I ended up giving up.....later on I went through the "freebsd-update" process and upgraded to a newer version of 7.2. After that Cacti and all dependencies built and installed successfully. Was XCB upgraded when I did the freebsd-update process? Or what? I'm just trying to find out what happened..... Thanks! From lehmann at ans-netz.de Wed Oct 7 18:10:01 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Wed Oct 7 18:10:08 2009 Subject: samba - SIGABRT Message-ID: <20091007200959.3c93904f.lehmann@ans-netz.de> Hi, I wonder what may have caused this and how should I debug it to find the source? I Installed samba 3.3.7 on a clean 8.0-RC1 and I upgraded then my system to the latest RELENG_8. Since I've not the time searching much longer for the error I'll just go to upgrade to 3.3.8 (recompile it...) tomorrow but I'm curious what it may have caused and how I would have been able to find the cause.... root@nudel samba33> /usr/local/sbin/smbd Abort Exit 134 root@nudel samba33> gdb 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 "i386-marcel-freebsd". (gdb) exec /usr/local/sbin/smbd (gdb) run Starting program: /usr/local/sbin/smbd Program terminated with signal SIGABRT, Aborted. The program no longer exists. You can't do that without a process to debug. (gdb) q root@nudel samba33> ktrace /usr/local/sbin/smbd Abort Exit 134 root@nudel samba33> kdump 2605 ktrace RET ktrace 0 2605 ktrace CALL execve(0xbfbfed83,0xbfbfec50,0xbfbfec58) 2605 ktrace NAMI "/usr/local/sbin/smbd" root@nudel samba33> mount -t procfs /dev/null /proc root@nudel samba33> truss -fad /usr/local/sbin/smbd truss: can not get etype: No such process Exit 2 root@nudel samba33> dmesg | tail -1 fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 root@nudel samba33> ldd /usr/local/sbin/smbd /usr/local/sbin/smbd: libcrypt.so.5 => /lib/libcrypt.so.5 (0x281aa000) libpam.so.5 => /usr/lib/libpam.so.5 (0x281c3000) libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x281cb000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x288d2000) libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x281d6000) libc.so.7 => /lib/libc.so.7 (0x28091000) libm.so.5 => /lib/libm.so.5 (0x281df000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x289d1000) root@nudel samba33> ls -l /lib/libcrypt.so.5 /usr/lib/libpam.so.5 /usr/local/lib/libexecinfo.so.1 /usr/local/lib/libiconv.so.3 /usr/local/lib/libpopt.so.0 /lib/libc.so.7 /lib/libm.so.5 /usr/local/lib/libintl.so.8 -r--r--r-- 1 root wheel 1144500 Oct 5 16:40 /lib/libc.so.7 -r--r--r-- 1 root wheel 32060 Oct 5 16:41 /lib/libcrypt.so.5 -r--r--r-- 1 root wheel 119372 Oct 5 16:41 /lib/libm.so.5 -r--r--r-- 1 root wheel 28424 Oct 5 16:42 /usr/lib/libpam.so.5 -r--r--r-- 1 root wheel 40636 Oct 4 19:59 /usr/local/lib/libexecinfo.so.1 -r--r--r-- 1 root wheel 1050349 Oct 4 19:41 /usr/local/lib/libiconv.so.3 -r--r--r-- 1 root wheel 39876 Oct 4 19:52 /usr/local/lib/libintl.so.8 -rwxr-xr-x 1 root wheel 39623 Oct 4 20:00 /usr/local/lib/libpopt.so.0* root@nudel samba33> ls -l /usr/local/sbin/smbd -rwxr-xr-x 1 root wheel 6698391 Oct 4 20:30 /usr/local/sbin/smbd* root@nudel samba33> file /usr/local/sbin/smbd /usr/local/sbin/smbd: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.0 (800107), not stripped root@nudel samba33> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From mailinglist at ucwv.edu Wed Oct 7 18:23:35 2009 From: mailinglist at ucwv.edu (mailinglist) Date: Wed Oct 7 18:23:41 2009 Subject: Installing Cacti from Ports In-Reply-To: <6201873e0910071103j2eb5ee4bn1fb80c6de3370b92@mail.gmail.com> References: <93C575B79E9B01449EBBB084032BC57011F84E7A52@mail.ucwv.edu>, <6201873e0910071103j2eb5ee4bn1fb80c6de3370b92@mail.gmail.com> Message-ID: <93C575B79E9B01449EBBB084032BC57011F84E7A54@mail.ucwv.edu> As part of the "freebsd-update" process I did run a few portupgrade commands. But I thought portupgrade only did whatever it does to installed ports. Or are you saying it upgraded the xcb port which allowed Cacti to build to completion? Also, off topic I know, but what is the proper way to reply to this? Reply? Reply to all? Or reply just to the mailing list? ________________________________________ From: Adam Vande More [amvandemore@gmail.com] Sent: Wednesday, October 07, 2009 2:03 PM To: mailinglist Cc: freebsd-stable@freebsd.org Subject: Re: Installing Cacti from Ports On Wed, Oct 7, 2009 at 12:31 PM, mailinglist > wrote: I hada VM running an older installation of FreeBSD 7.2. I recently got back to it and tried to install Cacti from the ports collection. I cvsup'd in an up-to-date ports collection, and did the usual "make, make install" for Cacti. During the "make install" process a dependency failed to build. I believe it was xcb-utils that failed to build because XCB was at version 1.2 and needed to be at 1.4. I couldn't get the issue resolved no matter what I tried. I ended up giving up.....later on I went through the "freebsd-update" process and upgraded to a newer version of 7.2. After that Cacti and all dependencies built and installed successfully. Was XCB upgraded when I did the freebsd-update process? Or what? I'm just trying to find out what happened..... Thanks! _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" You might want to try a tool like portmaster or portupgrade to manage these dependency and package backup process. -- Adam Vande More From amvandemore at gmail.com Wed Oct 7 18:29:28 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Wed Oct 7 18:29:35 2009 Subject: Installing Cacti from Ports In-Reply-To: <93C575B79E9B01449EBBB084032BC57011F84E7A52@mail.ucwv.edu> References: <93C575B79E9B01449EBBB084032BC57011F84E7A52@mail.ucwv.edu> Message-ID: <6201873e0910071103j2eb5ee4bn1fb80c6de3370b92@mail.gmail.com> On Wed, Oct 7, 2009 at 12:31 PM, mailinglist wrote: > I hada VM running an older installation of FreeBSD 7.2. I recently got > back to it and tried to install Cacti from the ports collection. I cvsup'd > in an up-to-date ports collection, and did the usual "make, make install" > for Cacti. During the "make install" process a dependency failed to build. > I believe it was xcb-utils that failed to build because XCB was at version > 1.2 and needed to be at 1.4. I couldn't get the issue resolved no matter > what I tried. I ended up giving up.....later on I went through the > "freebsd-update" process and upgraded to a newer version of 7.2. After that > Cacti and all dependencies built and installed successfully. Was XCB > upgraded when I did the freebsd-update process? Or what? I'm just trying > to find out what happened..... Thanks! > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > You might want to try a tool like portmaster or portupgrade to manage these dependency and package backup process. -- Adam Vande More From amvandemore at gmail.com Wed Oct 7 18:47:56 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Wed Oct 7 18:48:04 2009 Subject: Installing Cacti from Ports In-Reply-To: <93C575B79E9B01449EBBB084032BC57011F84E7A54@mail.ucwv.edu> References: <93C575B79E9B01449EBBB084032BC57011F84E7A52@mail.ucwv.edu> <6201873e0910071103j2eb5ee4bn1fb80c6de3370b92@mail.gmail.com> <93C575B79E9B01449EBBB084032BC57011F84E7A54@mail.ucwv.edu> Message-ID: <6201873e0910071147j1cc6e3a7t87b723b1597672f8@mail.gmail.com> On Wed, Oct 7, 2009 at 1:21 PM, mailinglist wrote: > As part of the "freebsd-update" process I did run a few portupgrade > commands. But I thought portupgrade only did whatever it does to installed > ports. Or are you saying it upgraded the xcb port which allowed Cacti to > build to completion? > > Also, off topic I know, but what is the proper way to reply to this? > Reply? Reply to all? Or reply just to the mailing list? > ________________________________________ > > freebsd-update and portupgrade are different. freebsd-update updates core compoments, portupgrade deals with apps installed via the ports tree. xcb is part of ports. I usually do reply to all although a few don't like it but it's generally more convenient. Also please do not top post. http://catb.org/jargon/html/T/top-post.html -- Adam Vande More From jhell at DataIX.net Wed Oct 7 18:53:06 2009 From: jhell at DataIX.net (jhell) Date: Wed Oct 7 18:54:38 2009 Subject: samba - SIGABRT In-Reply-To: <20091007200959.3c93904f.lehmann@ans-netz.de> References: <20091007200959.3c93904f.lehmann@ans-netz.de> Message-ID: On Wed, 7 Oct 2009 20:09 +0200, lehmann@ wrote: > Hi, > > I wonder what may have caused this and how should I debug it to find the > source? I Installed samba 3.3.7 on a clean 8.0-RC1 and I upgraded then my > system to the latest RELENG_8. > Since I've not the time searching much longer for the error I'll just go > to upgrade to 3.3.8 (recompile it...) tomorrow but I'm curious what it > may have caused and how I would have been able to find the cause.... > > > root@nudel samba33> /usr/local/sbin/smbd > Abort > Exit 134 > > > root@nudel samba33> gdb > 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 "i386-marcel-freebsd". > (gdb) exec /usr/local/sbin/smbd > (gdb) run > Starting program: /usr/local/sbin/smbd > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > You can't do that without a process to debug. > (gdb) q > root@nudel samba33> ktrace /usr/local/sbin/smbd > Abort > Exit 134 > root@nudel samba33> kdump > 2605 ktrace RET ktrace 0 > 2605 ktrace CALL execve(0xbfbfed83,0xbfbfec50,0xbfbfec58) > 2605 ktrace NAMI "/usr/local/sbin/smbd" > root@nudel samba33> mount -t procfs /dev/null /proc > root@nudel samba33> truss -fad /usr/local/sbin/smbd > truss: can not get etype: No such process > Exit 2 > root@nudel samba33> dmesg | tail -1 > fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 > root@nudel samba33> ldd /usr/local/sbin/smbd > /usr/local/sbin/smbd: > libcrypt.so.5 => /lib/libcrypt.so.5 (0x281aa000) > libpam.so.5 => /usr/lib/libpam.so.5 (0x281c3000) > libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x281cb000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x288d2000) > libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x281d6000) > libc.so.7 => /lib/libc.so.7 (0x28091000) > libm.so.5 => /lib/libm.so.5 (0x281df000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x289d1000) > root@nudel samba33> ls -l /lib/libcrypt.so.5 /usr/lib/libpam.so.5 /usr/local/lib/libexecinfo.so.1 /usr/local/lib/libiconv.so.3 /usr/local/lib/libpopt.so.0 /lib/libc.so.7 /lib/libm.so.5 /usr/local/lib/libintl.so.8 > -r--r--r-- 1 root wheel 1144500 Oct 5 16:40 /lib/libc.so.7 > -r--r--r-- 1 root wheel 32060 Oct 5 16:41 /lib/libcrypt.so.5 > -r--r--r-- 1 root wheel 119372 Oct 5 16:41 /lib/libm.so.5 > -r--r--r-- 1 root wheel 28424 Oct 5 16:42 /usr/lib/libpam.so.5 > -r--r--r-- 1 root wheel 40636 Oct 4 19:59 /usr/local/lib/libexecinfo.so.1 > -r--r--r-- 1 root wheel 1050349 Oct 4 19:41 /usr/local/lib/libiconv.so.3 > -r--r--r-- 1 root wheel 39876 Oct 4 19:52 /usr/local/lib/libintl.so.8 > -rwxr-xr-x 1 root wheel 39623 Oct 4 20:00 /usr/local/lib/libpopt.so.0* > root@nudel samba33> ls -l /usr/local/sbin/smbd > -rwxr-xr-x 1 root wheel 6698391 Oct 4 20:30 /usr/local/sbin/smbd* > root@nudel samba33> file /usr/local/sbin/smbd > /usr/local/sbin/smbd: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.0 (800107), not stripped > root@nudel samba33> > You need to compile with the following: CONFIGURE_ARGS+= --disable-pie This was caused by your setting of the following: security.bsd.map_at_zero=0 You can reset that value to 1 and you should be alright to operate like normal otherwise you will have to compile samba over again with the above mentioned configure options. Best regards. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From bschmidt at techwires.net Wed Oct 7 19:14:53 2009 From: bschmidt at techwires.net (Bernhard Schmidt) Date: Wed Oct 7 19:15:01 2009 Subject: samba - SIGABRT In-Reply-To: <20091007200959.3c93904f.lehmann@ans-netz.de> References: <20091007200959.3c93904f.lehmann@ans-netz.de> Message-ID: <200910072053.34044.bschmidt@techwires.net> On Wednesday 07 October 2009 20:09:59 Oliver Lehmann wrote: > Hi, > > I wonder what may have caused this and how should I debug it to find the > source? I Installed samba 3.3.7 on a clean 8.0-RC1 and I upgraded then my > system to the latest RELENG_8. > Since I've not the time searching much longer for the error I'll just go > to upgrade to 3.3.8 (recompile it...) tomorrow but I'm curious what it > may have caused and how I would have been able to find the cause.... Is by any chance security.bsd.map_at_zero set to 0? If it is http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052235.html has a solution. > > > root@nudel samba33> /usr/local/sbin/smbd > Abort > Exit 134 > > > root@nudel samba33> gdb > 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 "i386-marcel-freebsd". > (gdb) exec /usr/local/sbin/smbd > (gdb) run > Starting program: /usr/local/sbin/smbd > > Program terminated with signal SIGABRT, Aborted. > The program no longer exists. > You can't do that without a process to debug. > (gdb) q > root@nudel samba33> ktrace /usr/local/sbin/smbd > Abort > Exit 134 > root@nudel samba33> kdump > 2605 ktrace RET ktrace 0 > 2605 ktrace CALL execve(0xbfbfed83,0xbfbfec50,0xbfbfec58) > 2605 ktrace NAMI "/usr/local/sbin/smbd" > root@nudel samba33> mount -t procfs /dev/null /proc > root@nudel samba33> truss -fad /usr/local/sbin/smbd > truss: can not get etype: No such process > Exit 2 > root@nudel samba33> dmesg | tail -1 > fxp0: Microcode loaded, int_delay: 1000 usec bundle_max: 6 > root@nudel samba33> ldd /usr/local/sbin/smbd > /usr/local/sbin/smbd: > libcrypt.so.5 => /lib/libcrypt.so.5 (0x281aa000) > libpam.so.5 => /usr/lib/libpam.so.5 (0x281c3000) > libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x281cb000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x288d2000) > libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x281d6000) > libc.so.7 => /lib/libc.so.7 (0x28091000) > libm.so.5 => /lib/libm.so.5 (0x281df000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x289d1000) > root@nudel samba33> ls -l /lib/libcrypt.so.5 /usr/lib/libpam.so.5 > /usr/local/lib/libexecinfo.so.1 /usr/local/lib/libiconv.so.3 > /usr/local/lib/libpopt.so.0 /lib/libc.so.7 /lib/libm.so.5 > /usr/local/lib/libintl.so.8 -r--r--r-- 1 root wheel 1144500 Oct 5 > 16:40 /lib/libc.so.7 > -r--r--r-- 1 root wheel 32060 Oct 5 16:41 /lib/libcrypt.so.5 > -r--r--r-- 1 root wheel 119372 Oct 5 16:41 /lib/libm.so.5 > -r--r--r-- 1 root wheel 28424 Oct 5 16:42 /usr/lib/libpam.so.5 > -r--r--r-- 1 root wheel 40636 Oct 4 19:59 > /usr/local/lib/libexecinfo.so.1 -r--r--r-- 1 root wheel 1050349 Oct 4 > 19:41 /usr/local/lib/libiconv.so.3 -r--r--r-- 1 root wheel 39876 Oct > 4 19:52 /usr/local/lib/libintl.so.8 -rwxr-xr-x 1 root wheel 39623 Oct > 4 20:00 /usr/local/lib/libpopt.so.0* root@nudel samba33> ls -l > /usr/local/sbin/smbd > -rwxr-xr-x 1 root wheel 6698391 Oct 4 20:30 /usr/local/sbin/smbd* > root@nudel samba33> file /usr/local/sbin/smbd > /usr/local/sbin/smbd: ELF 32-bit LSB shared object, Intel 80386, version 1 > (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 8.0 > (800107), not stripped root@nudel samba33> > -- Bernhard From jamie at FreeBSD.org Wed Oct 7 20:08:47 2009 From: jamie at FreeBSD.org (Jamie Gritton) Date: Wed Oct 7 20:08:59 2009 Subject: 8.0-RC1: kernel page fault in NLM master thread (VIMAGE or ZFS related?) In-Reply-To: References: <4ABD4BB9.1030804@FreeBSD.org> Message-ID: <4ACCF548.2070200@FreeBSD.org> Rick Macklem wrote: > On Sun, 27 Sep 2009, Robert Watson wrote: >> On Fri, 25 Sep 2009, Jamie Gritton wrote: >> >>> It seems to be NFS related. I think the null pointer in question is >>> from the export's anonymous credential. Try the patch below and see >>> if it helps (which I guess means run it overnight and see if it >>> crashes again). I've also patched a similar missing cred prison in >>> GSS_SVC, since I'm not versed enough in NFS/RPC stuff to know if it >>> might be the problem. >> >> This is one of the reasons I really dislike "magic" credentials and >> special handling of NULL credentials -- they always get into code the >> author doesn't expect, and either there are bad pointer dereferences, >> or incorrect security decisions. It's almost always the case that a >> correct credential should have been cached or generated at some >> earlier point to represent the security context... >> > I don't really understand prisons/jails, but would creating these > credentials via: > crdup(td->td_ucred); // duplicating the daemon thread's cred > - and then replacing the > make sense as an alternative to starting with crget()? > (ie. All the other stuff except would be "inherited" from the > credential for the daemon thread.) That sounds right to me for cases when the cred is based on passed UID/GIDs. Perhaps you'd want to use the UID-changing helper functions on kern_prot.c, or perhaps a new helper or helpers just for the circumstance. - Jamie From matthew.fleming at isilon.com Wed Oct 7 20:50:21 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Wed Oct 7 20:50:29 2009 Subject: [SOLVED] Re: libthr and daemon() Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E0321806B@seaxch09.desktop.isilon.com> > 2) why would fork resolve to the one in libc (presumably, I'm not sure how > to prove this) instead of the one in libthr? Well, I'm not sure how the application plus libraries linked, but there was no explicit -lthr or -lpthread in the Makefile. So the resulting binary used the fork() in libc. When I added -lthr the app grew by about 15 bytes, and correctly used the fork() weak-referenced to the explicit _fork() in libthr. Weird. Thanks, matthew From jeff.dowsley at mac.com Wed Oct 7 23:51:41 2009 From: jeff.dowsley at mac.com (Jeff Dowsley) Date: Wed Oct 7 23:51:48 2009 Subject: NDIS broken? Message-ID: Folks Just upgraded from 7.2 to 8.0RC1 Under 7.2, I was using an ndis wrapper to provide a Windows network driver for an old Linksys PCMIA card (non-ath). Worked beautifully as per the Handbook under 7.2. Sadly, under 8.0RC1, the process to generate the wrapper appears to work OK, but when I attempt to set any of the card's parameters, ifconfig returns I/O errors. For example: ifconfig ndis0 up (back to prompt without errors, but then... ifconfig ndis0 inet 192.168.1.105 netmask 255.255.255.0 ifconfig: ioctl (SIOCAIFADDR): Invalid argument or ifconfig ndis0 ssid chcs ifconfig: SIOCS80211: Invalid argument dmesg reports that ndis0 is available as a Wireless-G Notebook Adapter after the ndis drivers are loaded. Any advice? JeffD _____________________________ M 0427565791 jeff.dowsley@mac.com From glen.j.barber at gmail.com Thu Oct 8 00:28:10 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Thu Oct 8 00:28:17 2009 Subject: NDIS broken? In-Reply-To: References: Message-ID: <4ad871310910071728t78a1fa80m2e1953865fd328f7@mail.gmail.com> Hi On Wed, Oct 7, 2009 at 7:51 PM, Jeff Dowsley wrote: > Folks > > Just upgraded from 7.2 to 8.0RC1 > > Under 7.2, I was using an ndis wrapper to provide a Windows network driver > for an old Linksys PCMIA card (non-ath). Worked beautifully as per the > Handbook under 7.2. > > Sadly, under 8.0RC1, the process to generate the wrapper appears to work OK, > but when I attempt to set any of the card's parameters, ifconfig returns I/O > errors. > > For example: > > ifconfig ndis0 up ? ? ? ? ? ? ? (back to prompt without errors, but then... > > ifconfig ndis0 inet 192.168.1.105 netmask 255.255.255.0 > > ifconfig: ioctl (SIOCAIFADDR): Invalid argument > > or > > ifconfig ndis0 ssid chcs > > ifconfig: SIOCS80211: Invalid argument > > Have a look at the 20080420 entry in /usr/src/UPDATING for 8.X. You have to change ndis to wlan with an additional change in rc.conf. HTH. -- Glen Barber From jhell at DataIX.net Thu Oct 8 04:59:44 2009 From: jhell at DataIX.net (jhell) Date: Thu Oct 8 04:59:52 2009 Subject: r197748 - base/stable/7/bin/sh/ 7.2-STABLE i386 Message-ID: ------------------------------------------------------------------------ r197748 | jilles | 2009-10-04 13:16:11 -0400 (Sun, 04 Oct 2009) | 7 lines MFC r197371: Mention that NUL characters are not allowed in sh(1) input. I do not consider this a bug because POSIX permits it and argument strings and environment variables cannot contain '\0' anyway. PR: bin/25542 ------------------------------------------------------------------------ Recently I have been noticing strange happenings of what I believe to be coming from the latest revision of /bin/sh. Prior to this revision it had not happened to the following examples. I am taking this as it could just be a following behavior in sudo due to fixing the first behavior in sh(1) but I am not sure and looking for feedback. How to repeat: ( Let me know if this is only me. ) # sudo rm -rf /usr/ports/*/*/work After issuing the above command the process waits for the list of (work) directories to be collected and ends by bombing out with pam timeout error. This could probably be easier seen with higher IO load but it has struck me kind of odd since I have not seen it at all till now. Also once it gets started you can not ^C the process until it has run the full directory tree. Behavior before, you could issue the command and it would ask you for your password before it would issue any IO to the disk. Is the new behavior called for adjusting your command to sh -c "rm -rf /usr/blah/bloo/bla*" ? Thanks -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From barney at databus.com Thu Oct 8 05:29:50 2009 From: barney at databus.com (Barney Wolff) Date: Thu Oct 8 05:29:57 2009 Subject: r197748 - base/stable/7/bin/sh/ 7.2-STABLE i386 In-Reply-To: References: Message-ID: <20091008052946.GA42664@pit.databus.com> I believe you are wrong about prior behavior. sudo is from a port and is in /usr/local/bin. Any shell is going to expand the list of args *before* giving control to the executable. So the system will churn for a while before sudo gets to ask for the password. On Thu, Oct 08, 2009 at 12:59:36AM -0400, jhell wrote: > > ------------------------------------------------------------------------ > r197748 | jilles | 2009-10-04 13:16:11 -0400 (Sun, 04 Oct 2009) | 7 lines > > MFC r197371: Mention that NUL characters are not allowed in sh(1) input. > > I do not consider this a bug because POSIX permits it and argument strings > and environment variables cannot contain '\0' anyway. > > PR: bin/25542 > > ------------------------------------------------------------------------ > > Recently I have been noticing strange happenings of what I believe to be > coming from the latest revision of /bin/sh. Prior to this revision it had > not happened to the following examples. I am taking this as it could just > be a following behavior in sudo due to fixing the first behavior in sh(1) > but I am not sure and looking for feedback. > > How to repeat: ( Let me know if this is only me. ) > # sudo rm -rf /usr/ports/*/*/work > > After issuing the above command the process waits for the list of (work) > directories to be collected and ends by bombing out with pam timeout > error. This could probably be easier seen with higher IO load but it has > struck me kind of odd since I have not seen it at all till now. Also once > it gets started you can not ^C the process until it has run the full > directory tree. > > Behavior before, you could issue the command and it would ask you for your > password before it would issue any IO to the disk. Is the new behavior > called for adjusting your command to sh -c "rm -rf /usr/blah/bloo/bla*" ? -- Barney Wolff I never met a computer I didn't like. From lehmann at ans-netz.de Thu Oct 8 06:23:28 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Thu Oct 8 06:23:35 2009 Subject: samba - SIGABRT In-Reply-To: References: <20091007200959.3c93904f.lehmann@ans-netz.de> Message-ID: <20091008062326.11720.qmail@avocado.salatschuessel.net> jhell writes: Hi, > This was caused by your setting of the following: > > security.bsd.map_at_zero=0 > > You can reset that value to 1 and you should be alright to operate like > normal otherwise you will have to compile samba over again with the above > mentioned configure options. Yeah this caused the problem. I wonder how I could have find this by myself (google is not counting ;)) I mean, the Abort message is not very verbose what the problem is here. From jhell at DataIX.net Thu Oct 8 07:38:11 2009 From: jhell at DataIX.net (jhell) Date: Thu Oct 8 07:38:18 2009 Subject: r197748 - base/stable/7/bin/sh/ 7.2-STABLE i386 In-Reply-To: <20091008052946.GA42664@pit.databus.com> References: <20091008052946.GA42664@pit.databus.com> Message-ID: On Thu, 8 Oct 2009 01:29 -0400, barney@ wrote: > I believe you are wrong about prior behavior. sudo is from a port and > is in /usr/local/bin. Any shell is going to expand the list of args > *before* giving control to the executable. So the system will churn > for a while before sudo gets to ask for the password. > > On Thu, Oct 08, 2009 at 12:59:36AM -0400, jhell wrote: >> >> ------------------------------------------------------------------------ >> r197748 | jilles | 2009-10-04 13:16:11 -0400 (Sun, 04 Oct 2009) | 7 lines >> >> MFC r197371: Mention that NUL characters are not allowed in sh(1) input. >> >> I do not consider this a bug because POSIX permits it and argument strings >> and environment variables cannot contain '\0' anyway. >> >> PR: bin/25542 >> >> ------------------------------------------------------------------------ >> >> Recently I have been noticing strange happenings of what I believe to be >> coming from the latest revision of /bin/sh. Prior to this revision it had >> not happened to the following examples. I am taking this as it could just >> be a following behavior in sudo due to fixing the first behavior in sh(1) >> but I am not sure and looking for feedback. >> >> How to repeat: ( Let me know if this is only me. ) >> # sudo rm -rf /usr/ports/*/*/work >> >> After issuing the above command the process waits for the list of (work) >> directories to be collected and ends by bombing out with pam timeout >> error. This could probably be easier seen with higher IO load but it has >> struck me kind of odd since I have not seen it at all till now. Also once >> it gets started you can not ^C the process until it has run the full >> directory tree. >> >> Behavior before, you could issue the command and it would ask you for your >> password before it would issue any IO to the disk. Is the new behavior >> called for adjusting your command to sh -c "rm -rf /usr/blah/bloo/bla*" ? > > Yeah, maybe. I might be just mixing up that I actually ran this as root instead of sudo from a user account. Its late and it had confused me as I had not seen a pam timeout error like that before that sh revision. My belief behind it was just that it was a subshell starting using sh but not handing it self back to sudo in time for authentication or something like that... "IDK" Ill keep investigating it later. Maybe something else is actually going on with my system that has not yielded its ugly head yet. Thanks for the feedback. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From tinderbox at freebsd.org Thu Oct 8 12:12:46 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 8 12:13:00 2009 Subject: [releng_8 tinderbox] failure on i386/pc98 Message-ID: <200910081212.n98CCjI9073077@freebsd-current.sentex.ca> TB --- 2009-10-08 11:23:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-08 11:23:56 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2009-10-08 11:23:56 - cleaning the object tree TB --- 2009-10-08 11:24:17 - cvsupping the source tree TB --- 2009-10-08 11:24:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2009-10-08 11:24:44 - building world TB --- 2009-10-08 11:24:44 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-08 11:24:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-08 11:24:44 - TARGET=pc98 TB --- 2009-10-08 11:24:44 - TARGET_ARCH=i386 TB --- 2009-10-08 11:24:44 - TZ=UTC TB --- 2009-10-08 11:24:44 - __MAKE_CONF=/dev/null TB --- 2009-10-08 11:24:44 - cd /src TB --- 2009-10-08 11:24:44 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 8 11:24:44 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/sbin/ddb/ddb.8 > ddb.8.gz ===> sbin/devd (all) c++ -O2 -pipe -I. -I/src/sbin/devd -fstack-protector -c /src/sbin/devd/devd.cc /src/sbin/devd/devd.cc: In member function 'virtual bool media::do_match(config&)': /src/sbin/devd/devd.cc:223: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/sbin/devd. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-08 12:12:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-08 12:12:45 - ERROR: failed to build world TB --- 2009-10-08 12:12:45 - 2188.95 user 463.45 system 2928.93 real http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-i386-pc98.full From rwatson at FreeBSD.org Thu Oct 8 14:43:28 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Oct 8 14:43:35 2009 Subject: samba - SIGABRT In-Reply-To: <20091008062326.11720.qmail@avocado.salatschuessel.net> References: <20091007200959.3c93904f.lehmann@ans-netz.de> <20091008062326.11720.qmail@avocado.salatschuessel.net> Message-ID: On Thu, 8 Oct 2009, Oliver Lehmann wrote: >> This was caused by your setting of the following: >> security.bsd.map_at_zero=0 You can reset that value to 1 and you should be >> alright to operate like normal otherwise you will have to compile samba >> over again with the above mentioned configure options. > > Yeah this caused the problem. I wonder how I could have find this by myself > (google is not counting ;)) I mean, the Abort message is not very verbose > what the problem is here Hi Oliver-- While it's probably a bug that the Samba port compiles --pie, it's also a bug that our linking bits aren't handling PIE properly either. The goal is to fix PIE with the non-NULL mapping feature in the immediate future, so with any luck the abort message won't matter too much longer. Robert From deischen at freebsd.org Thu Oct 8 14:59:47 2009 From: deischen at freebsd.org (Daniel Eischen) Date: Thu Oct 8 14:59:54 2009 Subject: samba - SIGABRT In-Reply-To: References: <20091007200959.3c93904f.lehmann@ans-netz.de> <20091008062326.11720.qmail@avocado.salatschuessel.net> Message-ID: On Thu, 8 Oct 2009, Robert Watson wrote: > > On Thu, 8 Oct 2009, Oliver Lehmann wrote: > >>> This was caused by your setting of the following: >>> security.bsd.map_at_zero=0 You can reset that value to 1 and you should be >>> alright to operate like normal otherwise you will have to compile samba >>> over again with the above mentioned configure options. >> >> Yeah this caused the problem. I wonder how I could have find this by myself >> (google is not counting ;)) I mean, the Abort message is not very verbose >> what the problem is here > > Hi Oliver-- > > While it's probably a bug that the Samba port compiles --pie, it's also a bug > that our linking bits aren't handling PIE properly either. The goal is to > fix PIE with the non-NULL mapping feature in the immediate future, so with > any luck the abort message won't matter too much longer. How about reverting this change or defaulting security.bsd.map_at_zero=1 until either ports can handle this properly or our -pie is fixed, and we've had at least a release with pre-built packages that don't have the problem? -- DE From olli at lurza.secnetix.de Thu Oct 8 16:19:26 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Oct 8 16:19:35 2009 Subject: kbdcontrol: map Backspace key to '\' fails In-Reply-To: <20090826154741.GA18965@zardoc.esmtp.org> Message-ID: <200910081619.n98GJ3JE077316@lurza.secnetix.de> Claus Assmann wrote: > On FreeBSD 7.2-STABLE it seems to be impossible to map the Backspace > key to '\' and '|'. Here's what I did: > > Change /usr/share/syscons/keymaps/us.unix.kbd: > [...] The diff looks good and should work fine. > and run: > kbdcontrol -k /dev/console -l /usr/share/syscons/keymaps/us.unix.kbd That -k options doesn't make sense at all. Actually I'm surprised that it doesn't give you an error message. Please use this command: kbdcontrol -l us.unix.kbd < /dev/ttyv0 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 PI: int f[9814],b,c=9814,g,i;long a=1e4,d,e,h; main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a) while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;} From olli at lurza.secnetix.de Thu Oct 8 17:13:31 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Oct 8 17:13:38 2009 Subject: openssh concerns In-Reply-To: <460A3E92-37D5-49CA-A079-EC08867B8DD4@danielbond.org> Message-ID: <200910081713.n98HD0kj079775@lurza.secnetix.de> > Doug Barton wrote: > > Daniel Bond wrote: > > > However, I'm concerned about the suggestion of using an > > > unprivileged port > > > > Please explain your reasoning, and how it's relevant in a world where > > the vast majority of Internet users have complete administrative > > control over the systems they use. There are shell machines with lots of user accounts, none of which have administrative control of the system. In fact I'm running such a machine myself. Suppose there is a security hole in sshd that enables a DoS attack, i.e. some use is able to kill the sshd daemon. Or maybe the sshd daemon dies because of some other, unrelated reason. If it was running on an unprivileged, a normal user would now be able to start up his own (probably modified) sshd daemon on the very same port. He won't have the correct host key, of course, but I can tell you that many users ignore the warning and innocently type "yes" when asked whether to accept the fingerprint. "Probably the admin reinstalled something, this happened before, don't worry." If you run the sshd daemon on a privileged port < 1024 (or one protected by mac_portacl(4)), that security problem does not exist at all. Normal users can't start up a fake daemon on such a port if the real daemon dies. Even if there are no user accounts, it's not worth taking chances. It's always possible that there will be some hole in some silly, unrelated daemon that enables remote execution ... then you have a "user account" without knowing. Successful attacks are often the result of two or more unrelated holes, so it's definitely worth to plug every sinlge hole, even small ones that seem unimportant. Running a critical daemon like sshd in an unprivileged port is such a hole, in my opinion. 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 From dougb at FreeBSD.org Thu Oct 8 17:22:17 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Thu Oct 8 17:22:24 2009 Subject: openssh concerns In-Reply-To: <200910081713.n98HD0kj079775@lurza.secnetix.de> References: <200910081713.n98HD0kj079775@lurza.secnetix.de> Message-ID: <4ACE1FC5.2060409@FreeBSD.org> Oliver Fromme wrote: > There are shell machines with lots of user accounts, none > of which have administrative control of the system. Sure there are, but they make up only a tiny fraction of the systems on the network today. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From edhoprima at gmail.com Thu Oct 8 17:23:53 2009 From: edhoprima at gmail.com (Edho P Arief) Date: Thu Oct 8 17:24:01 2009 Subject: openssh concerns In-Reply-To: <4ACE1FC5.2060409@FreeBSD.org> References: <200910081713.n98HD0kj079775@lurza.secnetix.de> <4ACE1FC5.2060409@FreeBSD.org> Message-ID: On Fri, Oct 9, 2009 at 12:22 AM, Doug Barton wrote: > Oliver Fromme wrote: >> There are shell machines with lots of user accounts, none >> of which have administrative control of the system. > > Sure there are, but they make up only a tiny fraction of the systems > on the network today. > > shared webhost? -- O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From stefan at fafoe.narf.at Thu Oct 8 17:32:27 2009 From: stefan at fafoe.narf.at (Stefan Farfeleder) Date: Thu Oct 8 17:32:34 2009 Subject: Bug in 7.2-STABLE's /bin/sh? In-Reply-To: <20091001191219.GA77569@curry.mchp.siemens.de> References: <20091001144946.GA75477@curry.mchp.siemens.de> <4AC4CE48.3080803@icyb.net.ua> <20091001183101.GB76820@curry.mchp.siemens.de> <20091001191219.GA77569@curry.mchp.siemens.de> Message-ID: <20091008173221.GA1704@lizard.fafoe.narf.at> On Thu, Oct 01, 2009 at 09:12:19PM +0200, Andre Albsmeier wrote: > On Thu, 01-Oct-2009 at 20:31:01 +0200, Andre Albsmeier wrote: > > On Thu, 01-Oct-2009 at 18:44:08 +0300, Andriy Gapon wrote: > > > on 01/10/2009 17:49 Andre Albsmeier said the following: > > > > Hello all, > > > > > > > > is it correct to print OK here? > > > > > > > > ------------------ snip ------------------ > > > > > > > > #!/bin/sh > > > > > > > > if false || ! echo bla | grep -q bla; then > > > > echo OK > > > > fi > > > > > > > > ------------------ snap ------------------- > > > > > > > > 7.2-STABLE (can't check others at the moment) > > > > does which I think is wrong... > > > > > > This looks like a bug and it seems to be fixed in head. > > > Forgotten MFC? > > > > Have you got a PR# handy? > > Found it myself: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/parser.c.diff?r1=1.60;r2=1.61 > > seems to be it. Could someone please MFC that to 7.2? > > Thanks, Done! (to stable/7, that is) From rwatson at FreeBSD.org Thu Oct 8 18:05:28 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Oct 8 18:05:35 2009 Subject: samba - SIGABRT In-Reply-To: References: <20091007200959.3c93904f.lehmann@ans-netz.de> <20091008062326.11720.qmail@avocado.salatschuessel.net> Message-ID: On Thu, 8 Oct 2009, Daniel Eischen wrote: >> While it's probably a bug that the Samba port compiles --pie, it's also a >> bug that our linking bits aren't handling PIE properly either. The goal is >> to fix PIE with the non-NULL mapping feature in the immediate future, so >> with any luck the abort message won't matter too much longer. > > How about reverting this change or defaulting security.bsd.map_at_zero=1 > until either ports can handle this properly or our -pie is fixed, and we've > had at least a release with pre-built packages that don't have the problem? Sorry, I should have been more clear: the problem is with run-time linking, not compile-time linking. Kostik has just posted patches for the run-time linker to current@, which should allow the existing binaries to work with map_at_zero=0. If we aren't able to get the run-time linker fixes into 8.0, we will definitely revert the default change for map_at_zero so that it is enabled. However, since there is a significant security benefit to shipping with map_at_zero disabled, I think we should try hard to ship 8.0 with a fixed rtld. Robert From olli at lurza.secnetix.de Thu Oct 8 18:23:44 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Thu Oct 8 18:23:51 2009 Subject: openssh concerns In-Reply-To: <4ACE1FC5.2060409@FreeBSD.org> Message-ID: <200910081823.n98INRVZ082461@lurza.secnetix.de> Doug Barton wrote: > Oliver Fromme wrote: > > There are shell machines with lots of user accounts, none > > of which have administrative control of the system. > > Sure there are, but they make up only a tiny fraction of the systems > on the network today. Are you sure? The majority of BSD machines in my vicinity have multiple accounts. And even if there's only one account, there is no reason to be careless with potential port-takeover risks. Therefore I advise against running critical daemons on unprivileged ports, especially on machines with shell accounts. And if you need to bind to a port >= 1024, use mac_portacl(4) to protect it. It's easy to use. Alternatively you can increase the value of the sysctl net.inet.ip.portrange.reservedhigh, but this is less flexible and might have unwanted side effects. 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 the only current language making COBOL look good." -- Bertrand Meyer From bap-fbsd-stable at a1.org.uk Thu Oct 8 18:24:06 2009 From: bap-fbsd-stable at a1.org.uk (Bap) Date: Thu Oct 8 18:24:15 2009 Subject: openssh concerns In-Reply-To: <4ACE1FC5.2060409@FreeBSD.org> References: <200910081713.n98HD0kj079775@lurza.secnetix.de> <4ACE1FC5.2060409@FreeBSD.org> Message-ID: <20091008192355.13355kndz7u7rtog@mail.gwork.org> Quoting Doug Barton : > Oliver Fromme wrote: >> There are shell machines with lots of user accounts, none >> of which have administrative control of the system. > > Sure there are, but they make up only a tiny fraction of the systems > on the network today. wow > > > Doug > > -- > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From alexz at visp.ru Fri Oct 9 07:21:38 2009 From: alexz at visp.ru (Alexander Zagrebin) Date: Fri Oct 9 07:22:17 2009 Subject: igmp problems on 8.0-RC1 Message-ID: After upgrading from 7.2-RELEASE to 8.0-RC1 i have noticed problems with igmp. xorp sees IGMP_V2_LEAVE_GROUP, but not IGMP_V2_MEMBERSHIP_REPORT. igmpproxy has the same behavior. xorp_rtrmgr.log contains only: [ TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.0.10 to 224.0.0.2 on vif rl0 [ TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.0.10 to 224.0.0.2 on vif rl0 [ TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.0.10 to 224.0.0.2 on vif rl0 [ TRACE xorp_igmp MLD6IGMP ] RX IGMP_V2_LEAVE_GROUP from 192.168.0.10 to 224.0.0.2 on vif rl0 but /var/log/messages (KTR and KTR_VERBOSE enabled): kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group e0000002 ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc494f900,24) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group ef20013a ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc4072300,24) kernel: cpu1 process v2 report 239.32.1.58 on ifp 0xc3e99400(rl0) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group ef20013a ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc4073500,24) kernel: cpu1 process v2 report 239.32.1.58 on ifp 0xc3e99400(rl0) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group ef20013a ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc429cc00,24) kernel: cpu1 process v2 report 239.32.1.58 on ifp 0xc3e99400(rl0) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group e0000002 ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc4926500,24) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group ef200139 ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc429fe00,24) kernel: cpu1 process v2 report 239.32.1.57 on ifp 0xc3e99400(rl0) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group ef200139 ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc4242a00,24) kernel: cpu1 process v2 report 239.32.1.57 on ifp 0xc3e99400(rl0) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group e0000002 ifp 0xc3e99400 kernel: cpu1 igmp_input: called w/mbuf (0xc491f700,24) kernel: cpu1 ip_mforward: delete mfc orig 192.168.0.10 group ef200108 ifp 0xc3e99400 ... So the kernel processes igmp v2 reports, but user space daemons doesn't recieve it. Any suggestions? PS: It is not ipfw issue (when testing, the first ipfw rule is "allow ip from any to any") -- Alexander Zagrebin From pjd at FreeBSD.org Fri Oct 9 09:55:01 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Fri Oct 9 09:55:09 2009 Subject: glabel+gmirror (8.0-RC1 problem) In-Reply-To: <20091005193340.cd84f0ec.lehmann@ans-netz.de> References: <20090927170244.0980d699.lehmann@ans-netz.de> <20090927223725.5893371f.lehmann@ans-netz.de> <20090928084035.GB1659@garage.freebsd.pl> <20090928203756.ef70e0c6.lehmann@ans-netz.de> <20090928184926.GA2016@garage.freebsd.pl> <20091005193340.cd84f0ec.lehmann@ans-netz.de> Message-ID: <20091009095453.GE1725@garage.freebsd.pl> On Mon, Oct 05, 2009 at 07:33:40PM +0200, Oliver Lehmann wrote: > gjorunal is also affected. I tried to use one partition of my gmirror > disk as journal device for my 3ware raid-5 device which works until I > reboot - the journal is then gone as well. > Is this patch likly to fix this as well? Will it be included in a future > RC? Until now I've stayed away using glabel+gmirror but I didn't knew > that gjournal is affected as well so I'm now left with warning that the > journal provider is gone wile booting - and more tragically I'm left > without journaling at all (which hurts on a 2.7TB partition when the > system was not cleanly shut down) I just committed the patch. Yes, it should fix gjournal case as well. I want to merge it before 8.0-RELEASE. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- 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-stable/attachments/20091009/4bc11807/attachment.pgp From mailinglist at ucwv.edu Fri Oct 9 13:06:18 2009 From: mailinglist at ucwv.edu (mailinglist) Date: Fri Oct 9 13:06:25 2009 Subject: Problems Compiling KDE4 from ports Message-ID: <93C575B79E9B01449EBBB084032BC57011F84E7A55@mail.ucwv.edu> I'm trying to install the KDE4 "meta" port on an up-to-date install of Freebsd 7.2. When it tries to build a dependency, kdebindings4-python-pykde4, I get the following build error: /usr/ports/kdebindings4-python-pykde4/work/kdebindings-4.3.1/python/pykde4/sip/soprano/languagetag.sip:27:33 error: soprano/language.h: no such file for directory I'm updated my ports collection, done a "make clean" and tried it again. I still get the same thing. Any ideas? From amvandemore at gmail.com Fri Oct 9 13:38:35 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Fri Oct 9 13:38:43 2009 Subject: Problems Compiling KDE4 from ports In-Reply-To: <93C575B79E9B01449EBBB084032BC57011F84E7A55@mail.ucwv.edu> References: <93C575B79E9B01449EBBB084032BC57011F84E7A55@mail.ucwv.edu> Message-ID: <6201873e0910090638r5564ba93sdd7b4aca530218e0@mail.gmail.com> On Fri, Oct 9, 2009 at 8:06 AM, mailinglist wrote: > I'm trying to install the KDE4 "meta" port on an up-to-date install of > Freebsd 7.2. When it tries to build a dependency, > kdebindings4-python-pykde4, I get the following build error: > > /usr/ports/kdebindings4-python-pykde4/work/kdebindings-4.3.1/python/pykde4/sip/soprano/languagetag.sip:27:33 > error: soprano/language.h: no such file for directory > > I'm updated my ports collection, done a "make clean" and tried it again. I > still get the same thing. Any > ideas?_______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > I hope you're continuing to use a port tool like portmaster or portupgrade. The line you posted is an invalid path. The port dir is /usr/ports/devel/kdebindings4-python-pykde4/ -- Adam Vande More From mailinglist at ucwv.edu Fri Oct 9 13:59:51 2009 From: mailinglist at ucwv.edu (mailinglist) Date: Fri Oct 9 13:59:58 2009 Subject: Problems Compiling KDE4 from ports In-Reply-To: <6201873e0910090638r5564ba93sdd7b4aca530218e0@mail.gmail.com> References: <93C575B79E9B01449EBBB084032BC57011F84E7A55@mail.ucwv.edu>, <6201873e0910090638r5564ba93sdd7b4aca530218e0@mail.gmail.com> Message-ID: <93C575B79E9B01449EBBB084032BC57011F84E7A56@mail.ucwv.edu> ________________________________________ From: Adam Vande More [amvandemore@gmail.com] Sent: Friday, October 09, 2009 9:38 AM To: mailinglist Cc: freebsd-stable@freebsd.org Subject: Re: Problems Compiling KDE4 from ports On Fri, Oct 9, 2009 at 8:06 AM, mailinglist > wrote: I'm trying to install the KDE4 "meta" port on an up-to-date install of Freebsd 7.2. When it tries to build a dependency, kdebindings4-python-pykde4, I get the following build error: /usr/ports/kdebindings4-python-pykde4/work/kdebindings-4.3.1/python/pykde4/sip/soprano/languagetag.sip:27:33 error: soprano/language.h: no such file for directory I'm updated my ports collection, done a "make clean" and tried it again. I still get the same thing. Any ideas?_______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" I hope you're continuing to use a port tool like portmaster or portupgrade. The line you posted is an invalid path. The port dir is /usr/ports/devel/kdebindings4-python-pykde4/ -- Adam Vande More ------------------------------------------------------------------ Sorry, I couldn't get copy/paste to work. I had to type everything in by hand, I made a mistake. The port dir you listed is correct. All I'm doing is going into the kdebindings4-python-pykde4 folder and running "make". Is that not the way I should be doing it? From amvandemore at gmail.com Fri Oct 9 14:26:05 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Fri Oct 9 14:26:12 2009 Subject: Problems Compiling KDE4 from ports In-Reply-To: <93C575B79E9B01449EBBB084032BC57011F84E7A56@mail.ucwv.edu> References: <93C575B79E9B01449EBBB084032BC57011F84E7A55@mail.ucwv.edu> <6201873e0910090638r5564ba93sdd7b4aca530218e0@mail.gmail.com> <93C575B79E9B01449EBBB084032BC57011F84E7A56@mail.ucwv.edu> Message-ID: <6201873e0910090726l70d73029pae087eddebce70cb@mail.gmail.com> On Fri, Oct 9, 2009 at 8:56 AM, mailinglist wrote: > > ________________________________________ > From: Adam Vande More [amvandemore@gmail.com] > Sent: Friday, October 09, 2009 9:38 AM > To: mailinglist > Cc: freebsd-stable@freebsd.org > Subject: Re: Problems Compiling KDE4 from ports > > On Fri, Oct 9, 2009 at 8:06 AM, mailinglist mailinglist@ucwv.edu>> wrote: > I'm trying to install the KDE4 "meta" port on an up-to-date install of > Freebsd 7.2. When it tries to build a dependency, > kdebindings4-python-pykde4, I get the following build error: > > /usr/ports/kdebindings4-python-pykde4/work/kdebindings-4.3.1/python/pykde4/sip/soprano/languagetag.sip:27:33 > error: soprano/language.h: no such file for directory > > I'm updated my ports collection, done a "make clean" and tried it again. I > still get the same thing. Any > ideas?_______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > > I hope you're continuing to use a port tool like portmaster or portupgrade. > The line you posted is an invalid path. The port dir is > /usr/ports/devel/kdebindings4-python-pykde4/ > > -- > Adam Vande More > > ------------------------------------------------------------------ > > Sorry, I couldn't get copy/paste to work. I had to type everything in by > hand, I made a mistake. The port dir you listed is correct. > > All I'm doing is going into the kdebindings4-python-pykde4 folder and > running "make". Is that not the way I should be doing it? > That method is OK if you're doing a clean install ie only freebsd is installed no ports. However, if you're upgrading an existing system after updating your ports tree then you need to worry about dependencies. make doesn't like when old versions of dependencies are already installed. That's what tools like portmaster and portupgrade are for. Read /usr/ports/UPDATING after every ports tree update for new info. To properly upgrade kde4 you should do something like this: portmaster -D x11/kde4 -- Adam Vande More From mailinglist at ucwv.edu Fri Oct 9 14:47:14 2009 From: mailinglist at ucwv.edu (mailinglist) Date: Fri Oct 9 14:47:20 2009 Subject: Problems Compiling KDE4 from ports In-Reply-To: <6201873e0910090726l70d73029pae087eddebce70cb@mail.gmail.com> References: <93C575B79E9B01449EBBB084032BC57011F84E7A55@mail.ucwv.edu> <6201873e0910090638r5564ba93sdd7b4aca530218e0@mail.gmail.com> <93C575B79E9B01449EBBB084032BC57011F84E7A56@mail.ucwv.edu>, <6201873e0910090726l70d73029pae087eddebce70cb@mail.gmail.com> Message-ID: <93C575B79E9B01449EBBB084032BC57011F84E7A57@mail.ucwv.edu> ________________________________________ From: Adam Vande More [amvandemore@gmail.com] Sent: Friday, October 09, 2009 10:26 AM To: mailinglist Cc: freebsd-stable@freebsd.org Subject: Re: Problems Compiling KDE4 from ports On Fri, Oct 9, 2009 at 8:56 AM, mailinglist > wrote: ________________________________________ From: Adam Vande More [amvandemore@gmail.com] Sent: Friday, October 09, 2009 9:38 AM To: mailinglist Cc: freebsd-stable@freebsd.org Subject: Re: Problems Compiling KDE4 from ports On Fri, Oct 9, 2009 at 8:06 AM, mailinglist >> wrote: I'm trying to install the KDE4 "meta" port on an up-to-date install of Freebsd 7.2. When it tries to build a dependency, kdebindings4-python-pykde4, I get the following build error: /usr/ports/kdebindings4-python-pykde4/work/kdebindings-4.3.1/python/pykde4/sip/soprano/languagetag.sip:27:33 error: soprano/language.h: no such file for directory I'm updated my ports collection, done a "make clean" and tried it again. I still get the same thing. Any ideas?_______________________________________________ freebsd-stable@freebsd.org> mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org>" I hope you're continuing to use a port tool like portmaster or portupgrade. The line you posted is an invalid path. The port dir is /usr/ports/devel/kdebindings4-python-pykde4/ -- Adam Vande More ------------------------------------------------------------------ Sorry, I couldn't get copy/paste to work. I had to type everything in by hand, I made a mistake. The port dir you listed is correct. All I'm doing is going into the kdebindings4-python-pykde4 folder and running "make". Is that not the way I should be doing it? That method is OK if you're doing a clean install ie only freebsd is installed no ports. However, if you're upgrading an existing system after updating your ports tree then you need to worry about dependencies. make doesn't like when old versions of dependencies are already installed. That's what tools like portmaster and portupgrade are for. Read /usr/ports/UPDATING after every ports tree update for new info. To properly upgrade kde4 you should do something like this: portmaster -D x11/kde4 -- Adam Vande More ---------------------------------------------------- I've upgraded the base system, but is a new install of KDE/X Windows. That said, why would I be getting this "file not found error"? From freebsd+stable at esmtp.org Fri Oct 9 15:11:46 2009 From: freebsd+stable at esmtp.org (Claus Assmann) Date: Fri Oct 9 15:11:53 2009 Subject: kbdcontrol: map Backspace key to '\' fails In-Reply-To: <200910081619.n98GJ3JE077316@lurza.secnetix.de> References: <20090826154741.GA18965@zardoc.esmtp.org> <200910081619.n98GJ3JE077316@lurza.secnetix.de> Message-ID: <20091009151145.GA19192@zardoc.esmtp.org> On Thu, Oct 08, 2009, Oliver Fromme wrote: > Claus Assmann wrote: > > On FreeBSD 7.2-STABLE it seems to be impossible to map the Backspace > > key to '\' and '|'. Here's what I did: > > Change /usr/share/syscons/keymaps/us.unix.kbd: > > [...] > The diff looks good and should work fine. > Please use this command: > kbdcontrol -l us.unix.kbd < /dev/ttyv0 Thanks, but that still doesn't give me '\' when I hit Backspace. Does it work for you? From arnaud.houdelette at tzim.net Fri Oct 9 15:34:11 2009 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Fri Oct 9 15:34:19 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACBC1C8.5060400@h3q.com> References: <4ACB2BE0.8080809@h3q.com> <4ACBC1C8.5060400@h3q.com> Message-ID: <4ACF57EC.5010003@tzim.net> Philipp Wuensche a ?crit : > Philipp Wuensche wrote: > >> Feel free to send bugreports to me. >> > > Thanks for the bug-reports and feature suggestions! > > There is a new version available: > http://anonsvn.h3q.com/projects/freebsd-patches/export/48/manageBE/create-zfsboot-gpt_livecd.sh > > New stuff: > - support for installing the distribution packages from a local > directory, like /dist/8.0-RC1 on the install-DVD > - untested support for raidz, I can't test this because virtualbox only > provides one BIOS disk to the bootloader and raidz needs at least two > disks for booting :-/ > - some minor fixes and tunes > > greetings, > philipp > > Tried on QEMU (with kvm) : Works OK with mirror. Fails to boot with ZFS : missing fragments ( kvm BIOS sees all 3 drives ). Should we not use the raidz patch which was proposed on the list ? And why the raidz setup got the system on root fs. is it mandatory ? greets Arnaud From cryx-freebsd at h3q.com Fri Oct 9 16:11:44 2009 From: cryx-freebsd at h3q.com (Philipp Wuensche) Date: Fri Oct 9 16:11:58 2009 Subject: 8.0-RC1 ZFS-root installscript In-Reply-To: <4ACF57EC.5010003@tzim.net> References: <4ACB2BE0.8080809@h3q.com> <4ACBC1C8.5060400@h3q.com> <4ACF57EC.5010003@tzim.net> Message-ID: <4ACF60BD.5070307@h3q.com> Arnaud Houdelette wrote: >> > > Tried on QEMU (with kvm) : Works OK with mirror. > Fails to boot with ZFS : missing fragments ( kvm BIOS sees all 3 drives > ). Should we not use the raidz patch which was proposed on the list ? Any pointer to that? I thought this patch is already integrated with 8.0-RC1. > And why the raidz setup got the system on root fs. is it mandatory ? This is what I need to test, there where some problems with having the rootfs in a seperate filesystem afair. But I'm not sure. You could edit the script and try out. Would be very interested in your findings as I have no testhardware at the moment. greetings, philipp From olli at lurza.secnetix.de Fri Oct 9 17:23:29 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Fri Oct 9 17:23:37 2009 Subject: kbdcontrol: map Backspace key to '\' fails In-Reply-To: <20091009151145.GA19192@zardoc.esmtp.org> Message-ID: <200910091723.n99HN7q9029522@lurza.secnetix.de> Claus Assmann <> wrote: > On Thu, Oct 08, 2009, Oliver Fromme wrote: > > Claus Assmann wrote: > > > On FreeBSD 7.2-STABLE it seems to be impossible to map the Backspace > > > key to '\' and '|'. Here's what I did: > > > > Change /usr/share/syscons/keymaps/us.unix.kbd: > > > [...] > > > The diff looks good and should work fine. > > > Please use this command: > > > kbdcontrol -l us.unix.kbd < /dev/ttyv0 > > Thanks, but that still doesn't give me '\' when I hit Backspace. > Does it work for you? I don't have a syscons console on a 7.2 machine in front of me right now. But I've tested in on a 8-current machine, and it does indeed work. 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 "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal From killing at multiplay.co.uk Sun Oct 11 01:53:59 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Sun Oct 11 01:54:13 2009 Subject: 6.2-RELEASE does not use second CPU on pentium D References: <462F15B4.4010201@webmail.sub.ru> Message-ID: <261B324A16A2457899A46641FC6A0499@multiplay.co.uk> 6.2 is really quite old now, does 7.x or even 8.x work? Regards Steve ----- Original Message ----- From: "Alex Povolotsky" > I have a Pentium D box, running 6.2-RELEASE. In dmesg, I see CPU#1 > launched, but I never see any process running on it, and mptable shows ... ================================================ 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 jrhett at netconsonance.com Sun Oct 11 06:58:12 2009 From: jrhett at netconsonance.com (Jo Rhett) Date: Sun Oct 11 06:58:49 2009 Subject: how to get more logging from GEOM? In-Reply-To: <200807151535.m6FFZH4P044840@lurza.secnetix.de> References: <200807151535.m6FFZH4P044840@lurza.secnetix.de> Message-ID: On Jul 15, 2008, at 8:35 AM, Oliver Fromme wrote: > I had exactly the same problems on a machine a few months > ago. It had also been running for about two years, then > started freezing when there was high CPU + disk activity. > > It turned out that the power supply went weak (either the > power supply itself or the voltage regulators on the main- > board). Replacing PS + mainboard solved the problem. I have removed these drives and installed them in another machine and had exactly the same symptoms. I built a new machine fresh with 7.2 (in case it was due to the upgrade process) and installed these ports and experienced the exact same problem. That's why I am here. Physical or localized issues have already been ruled out. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness From to.my.trociny at gmail.com Sun Oct 11 10:51:15 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Sun Oct 11 10:51:21 2009 Subject: can't change tty speed and buffer size on 8.0 Message-ID: <861vla2ogy.fsf@kopusha.onet> Hi, On 8.0-RC1 if you run this command: cat > /dev/null and try to input a long line, the maximum length you can input is 1920 characters. I have investigated a bit how I can increase a tty buffer as this is a problem for me (I have logs with very long lines and I used to copy&past a particular line into input of some script to structure it). According to kern/tty.c:tty_watermarks() the input buffer size is set as ispeed / 5. The default speed is 9600 that is rather low: /usr/include/sys/ttydefaults.h:#define TTYDEF_SPEED (B9600) So to increase the buffer size I need to decrease tty speed. But this does not work: zhuzha:/tmp% stty speed 9600 baud; lflags: echoe echok echoke echoctl iflags: -ixany -imaxbel oflags: tab0 cflags: cs8 parenb eol2 erase status ^@ ^H zhuzha:/tmp% stty ispeed 38400 zhuzha:/tmp% stty speed 9600 baud; lflags: echoe echok echoke echoctl iflags: -ixany -imaxbel oflags: tab0 cflags: cs8 parenb eol2 erase status ^@ ^H I can change tty speed on 7.X but can't on 8.0. I ran this simple dtrace program to see what is going on: tty*:entry /execname == "stty"/ { printf("%s entered; args0-4: %d %d %d %d %d\n", probefunc, arg0, arg1, arg2, arg3, arg4); } tty*:return /execname == "stty"/ { printf("%s returned %d\n", probefunc, arg1); } And here is the relevant part of the output: ttydev_ioctl entered; arguments: 3313875456 2150396948 3363021248 3 3357835264 tty_wait_background entered; arguments: 3354367492 0 3234498062 158 0 tty_wait_background returned 0 tty_ioctl entered; arguments: 3354367488 2150396948 3363021248 3357835264 0 ttydevsw_defioctl entered; arguments: 3354367488 2150396948 3363021248 3357835264 0 ttydevsw_defioctl returned 4294967293 ttydevsw_defparam entered; arguments: 3354367488 3363021248 3363021248 3357835264 0 ttydevsw_defparam returned 0 tty_watermarks entered; arguments: 3354367488 3363021248 3363021248 3357835264 0 ttyinq_setsize entered; arguments: 3354367528 3354367488 1920 0 3875601352 ttyinq_setsize returned 15 ttyoutq_setsize entered; arguments: 3354367572 3354367488 1920 0 3875601352 ttyoutq_setsize returned 3545052638 tty_watermarks returned 858997088 ttydisc_optimize entered; arguments: 3354367488 3363021264 20 3357835264 0 ttydisc_optimize returned 0 tty_ioctl returned 0 ttydev_ioctl returned 0 As you can see, before calling tty_watermarks() and ttyinq_setsize(), ttydevsw_defparam() is called that do only this thing: /* Use a fake baud rate, we're not a real device. */ t->c_ispeed = t->c_ospeed = TTYDEF_SPEED; As a result the speed of terminal is always set to TTYDEF_SPEED and ttyinq_setsize() is always called with size=1920 (TTYDEF_SPEED/5). This all happens in tty_generic_ioctl() in this part: /* * Only call param() when the flags really change. */ if ((t->c_cflag & CIGNORE) == 0 && (tp->t_termios.c_cflag != t->c_cflag || tp->t_termios.c_ispeed != t->c_ispeed || tp->t_termios.c_ospeed != t->c_ospeed)) { error = ttydevsw_param(tp, t); if (error) return (error); /* XXX: CLOCAL? */ tp->t_termios.c_cflag = t->c_cflag & ~CIGNORE; tp->t_termios.c_ispeed = t->c_ispeed; tp->t_termios.c_ospeed = t->c_ospeed; /* Baud rate has changed - update watermarks. */ tty_watermarks(tp); } AFAIR ttydevsw_param() runs tty hooks and ttydevsw_defparam() among them. So you can't change the speed of terminal and the size of input buffer on running system. Only by recompiling the kernel with updated TTYDEF_SPEED. Is this intentional or does it look rather like a bug? -- Mikolaj Golub From to.my.trociny at gmail.com Sun Oct 11 10:54:07 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Sun Oct 11 10:54:14 2009 Subject: can't change tty speed and buffer size on 8.0 In-Reply-To: <861vla2ogy.fsf@kopusha.onet> (Mikolaj Golub's message of "Sun\, 11 Oct 2009 13\:51\:09 +0300") References: <861vla2ogy.fsf@kopusha.onet> Message-ID: <86ws3219rp.fsf@kopusha.onet> On Sun, 11 Oct 2009 13:51:09 +0300 Mikolaj Golub wrote: MG> So to increase the buffer size I need to decrease tty speed. Sorry, of course I meant "to increase tty speed" :-). -- Mikolaj Golub From rwatson at FreeBSD.org Sun Oct 11 14:52:39 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Oct 11 14:52:46 2009 Subject: openssh concerns In-Reply-To: <200910081823.n98INRVZ082461@lurza.secnetix.de> References: <200910081823.n98INRVZ082461@lurza.secnetix.de> Message-ID: On Thu, 8 Oct 2009, Oliver Fromme wrote: > Are you sure? The majority of BSD machines in my vicinity have multiple > accounts. > > And even if there's only one account, there is no reason to be careless with > potential port-takeover risks. > > Therefore I advise against running critical daemons on unprivileged ports, > especially on machines with shell accounts. And if you need to bind to a > port >= 1024, use mac_portacl(4) to protect it. It's easy to use. > Alternatively you can increase the value of the sysctl > net.inet.ip.portrange.reservedhigh, but this is less flexible and might have > unwanted side effects. And, for those that haven't already noticed, "options MAC" is compiled into GENERIC on 8.0, so working with MAC policies no longer requires a recompile (or in many cases, even a reboot). Robert N M Watson Computer Laboratory University of Cambridge From danger at FreeBSD.org Sun Oct 11 17:54:29 2009 From: danger at FreeBSD.org (Daniel Gerzo) Date: Sun Oct 11 17:54:46 2009 Subject: FreeBSD Status Reports April - September, 2009 Message-ID: <20091011175428.GA3626@freefall.freebsd.org> FreeBSD Quarterly Status Report Introduction This report covers FreeBSD related projects between April and September 2009. During that time a lot of work has been done on wide variety of projects, including the Google Summer of Code projects. The BSDCan conference was held in Ottawa, CA, in May. The EuroBSDCon conference was held in Cambridge, UK, in September. Both events were very successful. A new major version of FreeBSD, 8.0 is to be released soon. If you are wondering what's new in this long-awaited release, read Ivan Voras' excellent summary. Thanks to all the reporters for the excellent work! We hope you enjoy the reading. Please note that the next deadline for submissions covering reports between October and December 2009 is January 15th, 2010. __________________________________________________________________ Google Summer of Code * About Google Summer of Code 2009 * BSD-licensed iconv (Summer of Code 2009) * BSD-licensed text-processing tools (Summer of Code 2008) * Ext2fs Status report (Summer of Code 2009) * libnetstat(3) - networking statistics (Summer of Code 2009) * pefs - stacked cryptographic filesystem (Summer of Code 2009) Projects * BSD# Project * Clang replacing GCC in the base system * FreeBSD TDM Framework * Grand Central Dispatch - FreeBSD port * libprocstat(3) - process statistics * New BSD licensed debugger * NFSv4 ACLs * The Newcons project * VirtualBox on FreeBSD FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD KDE Team * FreeBSD Ports Management Team * Release Engineering Status Report * The FreeBSD Foundation Status Report Network Infrastructure * Enhancing the FreeBSD TCP Implementation * Modular Congestion Control * Network Stack Virtualization * Stream Control Transmission Protocol (SCTP) Kernel * FreeBSD/ZFS * hwpmc for MIPS Documentation * The FreeBSD Dutch Documentation Project * The FreeBSD German Documentation Project * The FreeBSD Hungarian Documentation Project * The FreeBSD Spanish Documentation Project Architectures * FreeBSD/sparc64 Ports * FreeBSD Gecko Project * Portmaster - utility to assist users with managing ports * Valgrind suite on FreeBSD Miscellaneous * EuroBSDcon 2009 * FreeBSD Developer Summit, Cambridge UK * New approach to the locale database * The FreeBSD Forums __________________________________________________________________ About Google Summer of Code 2009 URL: http://socghop.appspot.com/org/home/google/gsoc2009/freebsd URL: http://wiki.freebsd.org/SummerOfCode2009Projects Contact: Brooks Davis Contact: Tim Kientzle Contact: Robert Watson 2009 was The FreeBSD Project's fifth year of participation in the Google Summer of Code. We had a total of 17 successful projects. Some GSoC code will be shipping with FreeBSD 8.0-RELEASE and others will be integrated into future releases. The FreeBSD GSoC admin team would like to thank Google and our students and mentors of another great year! __________________________________________________________________ BSD# Project URL: http://code.google.com/p/bsd-sharp/ URL: http://www.mono-project.org/ Contact: Romain Tarti?re The BSD# Project is devoted to porting the Mono .NET framework and applications to the FreeBSD operating system. During the past year, the BSD# Team continued to track the Mono development and the lang/mono port have almost always been up-to-date (we however had to skip mono-2.2 because of some regression issues in this release). Most of our patches have been merged in the mono trunk upstream, and should be included in the upcoming mono-2.6 release. In the meantime, a few more .NET related ports have been updated or added to the FreeBSD ports tree. These ports include: * www/xsp and www/mod_mono that make it possible to use FreeBSD for hosting ASP.NET application; * lang/boo, a CLI-targeted programming language similar to Python; * lang/mono-basic, the Visual Basic .NET Framework for Mono; * devel/monodevelop, an Integrated Development Environment for .NET; * and much more... Open tasks: 1. Test mono ports and send feedback (we are especially interested in tests where NOPORTDOCS / WITH_DEBUG is enabled). 2. Port the mono-debugger to FreeBSD. 3. Build a debug live-image of FreeBSD so that Mono hackers without a FreeBSD box can help us fixing bugs more efficiently. __________________________________________________________________ BSD-licensed iconv (Summer of Code 2009) URL: http://wiki.freebsd.org/G%C3%A1borSoC2009 Contact: G?bor K?vesd?n The code has been extracted from NetBSD and has been transformed into an independent shared library. The basic encodings are well supported. Almost all forward conversions (foo -> UTF-32) are compatible with GNU but the reverse ones are not so accurate because of GNU's advanced transliteration. Some extra encodings have also been added. There are two modules, which segfault; they need some debugging. I can keep working on this project as part of my BSc thesis, so I hope to be able to solve the remaining issues. Improved GNU compatibility is also very desired (extra command line options for iconv(1), iconvctl(), private interfaces, etc.). Open tasks: 1. Fix segfaults in Big5 and HZ modules 2. Improve transliteration in reverse encodings 3. Improve GNU compatibility by implementing extra features 4. Verify POSIX compatibility 5. Verify GNU compatibility 6. Check performance __________________________________________________________________ BSD-licensed text-processing tools (Summer of Code 2008) URL: http://wiki.freebsd.org/G%C3%A1borSoC2008 Contact: G?bor K?vesd?n This project was started as part of Google Summer of Code 2008 but there is still a bit of work to complete some missing parts. The BSD-licensed grep implementation is feature-complete and has a good level of GNU compatibility. Our only current concern about the BSD-licensed version is to improve its performance. The GNU variant is much more complex, has about 8 KSLOC, while BSD grep is tiny, has only 1.5 KSLOC. GNU uses some shortcuts and optimizations to speed-up calls to the regex library; that is why it is significantly faster. My point of view is that such optimizations must be implemented in the regex library, keeping the dependent utilities clean and easy to read. BSD grep is so tiny that there is hardly any optimization opportunity by simplifying the code, so the regex library is the next important TODO. There is another issue with the current regex library. It does not support some invalid regular expressions, which work in GNU. We need to maintain compatibility, so we cannot just drop this feature. Actually, BSD grep is linked to the GNU regex library to maintain this feature but due to the lack of the mentioned shortcuts, it is still slower than GNU. Anyway, if we can live with this little performance hit until we get a modern regex library, I think grep is ready to enter HEAD. As for the regex library, NetBSD's result of the last SoC is worth taking a look. The sort utility has been rewritten from scratch. The existing BSD-licensed implementation could not deal with wide characters by design. The new implementation is still lacking some features but is quite complete. There is a performance issue, though. Sorting is a typical algorithmic subject but I am not an algorithmic expert, so my implementation is not completely optimal. Some help would be welcome with this part. The bc/dc utilities have been ported from OpenBSD. They pass OpenBSD's and GNU's regression tests but they arrived too late to catch 8.X, so they will go to HEAD after the release. Open tasks: 1. Improve sort's sorting and file merging algorithms 2. Complete missing features for sort 3. Get a modern regex library for FreeBSD __________________________________________________________________ Clang replacing GCC in the base system URL: http://wiki.freebsd.org/BuildingFreeBSDWithClang Contact: Ed Schouten Contact: Roman Divacky Contact: Brooks Davis Contact: Pawel Worach The clang@FreeBSD team presents the status of clang/LLVM being able to compile FreeBSD system. The current status is: * i386 - kernel boots, world needs little hacks but works * amd64 - kernel boots, world needs little hacks but works * ppc - broken because of unknown RTLD bug * other - unknown All other platforms are untested. A lot has happened over the spring/summer: amd64 got proper mcmodel=kernel support, compiler-rt has been introduced (paving the way for libgcc replacement), we have run two experimental port builds to see how clang does there. The C++ support is able to parse devd.cc without warnings. We have got the kernel working with -O2. FreeBSD has been promoted to be an officially supported plaform in LLVM. As a result of all this work, many parts of FreeBSD that did not compile before now build without problems. Open tasks: 1. The "ClangBSD" branch of FreeBSD got a little stale and has not been updated for a while. 2. We also need to get some important fixes into LLVM to get libc compiling and some other smaller issues. 3. We can still appreciate more testers on minor platforms (mostly on ARM, PPC and MIPS, but testing on other platforms is also welcome). __________________________________________________________________ Enhancing the FreeBSD TCP Implementation URL: http://caia.swin.edu.au/freebsd/etcp09/ URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://www.freebsdfoundation.org/projects.shtml URL: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/ Contact: Lawrence Stewart TCP appropriate byte counting (RFC 3465) support has been merged into the FreeBSD 8 branch and will ship in FreeBSD 8.0-RELEASE. The reassembly queue auto-tuning and SIFTR work was not ready in time to safely integrate for 8.0-RELEASE. Padding has been added to necessary TCP structs to facilitate MFCing features back to the 8-STABLE branch after 8.0 is released. Candidate patches against FreeBSD-CURRENT will be ready for wider testing in the coming weeks. The freebsd-net mailing list will be solicited for testing/feedback when everything is ready. Open tasks: 1. Solicit review/testing and integrate the ALQ kld and variable length message support patch into FreeBSD-CURRENT. 2. Solicit review/testing and integrate the SIFTR tool into FreeBSD-CURRENT. 3. Complete dynamic reassembly queue auto-tuning patch for FreeBSD-CURRENT. 4. Fix an identified bug in the SACK implementation's fast retransmit/fast recovery behavior. 5. Profit! __________________________________________________________________ EuroBSDcon 2009 URL: http://2009.eurobsdcon.org/ URL: http://2010.eurobsdcon.org/ Contact: Sam Smith Contact: Robert Watson EuroBSDcon 2009 happened in Cambridge, with over 160 users, developers, friends and others. Slides, papers and audio are now up on the website for those who could not make it to Cambridge. Next year's event in 2010 will take place in Karlsruhe from 8 to 10 October 2010. If you are interested in what you missed in 2009, or to join the mailing list so you do not miss out next year, visit http://2009.eurosbsdcon.org. __________________________________________________________________ Ext2fs Status report (Summer of Code 2009) URL: http://wiki.freebsd.org/SOC2009AdityaSarawgi Contact: Aditya Sarawgi FreeBSD's ext2fs had some parts under GPL. The aim of my project was to rewrite those parts and free ext2fs from GPL. I have been successful in rewriting the parts and NetBSD's ext2fs was a great help in this. Certain critical parts under GPL were also removed due to which the write performance suffered. I also implemented Orlov Block Allocator for ext2fs. Currently I am planning to make ext2fs Multiprocessor Safe (MPSAFE). My work resides in truncs_ext2fs branch of Perforce. Open tasks: 1. Ext4 support for FreeBSD 2. Directory indexing for ext2fs 3. Journaling in ext2fs using gjournal __________________________________________________________________ FreeBSD Bugbusting Team URL: http://www.FreeBSD.org/support.html#gnats URL: http://wiki.FreeBSD.org/BugBusting URL: http://people.FreeBSD.org/~linimon/studies/prs/ URL: http://people.FreeBSD.org/~linimon/studies/prs/recommended_prs.html Contact: Gavin Atkinson Contact: Mark Linimon Contact: Remko Lodder Contact: Volker Werth We continue to classify PRs as they arrive, adding 'tags' to the subject lines corresponding to the kernel subsystem involved, or man page references for userland PRs. These tags, in turn, produce lists of PRs sorted both by tag and by manpage. The list of PRs recommended for committer evaluation by the Bugbusting Team continues to receive new additions. This list contains PRs, mostly with patches, that the Bugbusting Team feel are probably ready to be committed as-is, or are probably trivially resolved in the hands of a committer with knowledge of the particular subsystem. All committers are invited to take a look at this list whenever they have a spare 5 minutes and wish to close a PR. A full list of all the automatically generated reports is also available at one of the cited URLs. Any recommendations for reports which not currently exist but which would be beneficial are welcomed. Gavin Atkinson gave a presentation on "The PR Collection Status" at the EuroBSDCon 2009 DevSummit, and discussed with other participants several other ideas to make the PR database more useful and usable. Several good ideas came from this, and will hopefully lead to more useful tools in the near future. Discussions also took place on how it may be possible to automatically classify non-ports PRs with a view towards notifying interested parties, although investigations into this have not yet begun. Mark Linimon also continues attempting to define the general problem and investigating possible new workflow models, and presented work on this at BSDCan 2009. Since the last status report, the number of open bugs has increased to around the 5900 mark, partially because of an increased focus on getting more information into the existing PRs, in an attempt to make sure all the information required is now available. As a result, although the number of open PRs has increased, they are hopefully of better quality. As always, more help is appreciated, and committers and non-committers alike are always invited to join us on #freebsd-bugbusters on EFnet and help close stale PRs or commit patches from valid PRs. Open tasks: 1. Work on suggestions from developers who were at the EuroBSDCon DevSummit. 2. Try to find ways to get more committers helping us with closing the PRs that the team has already analyzed. __________________________________________________________________ FreeBSD Developer Summit, Cambridge UK URL: http://wiki.FreeBSD.org/200909DevSummit Contact: Robert Watson Around 70 FreeBSD developers and guests attended the FreeBSD developer summit prior to EuroBSDCon 2009 in Cambridge, UK. Hosted at the University of Cambridge Computer Laboratory, the workshop-style event consisted of prepared presentations, as well as group hacking and discussion sessions. Talks covered topics including 802.11 mesh networking, virtual network stacks and kernels, a new BSD-licensed debugger, benchmarking, bugbusting, NetFPGA, a port of Apple's GCD (Grand Central Dispatch) to FreeBSD, security policy work, cryptographic signatures, FreeBSD.org system administration, time geeks, a new console driver, and the FreeBSD subversion migration. Slides for many talks are now available on the wiki page. A good time was had by all, including a punting outing on the River Cam! __________________________________________________________________ FreeBSD Gecko Project URL: https://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO Contact: Beat Gaetzi Contact: Martin Wilke Contact: Andreas Tobler Andreas Tobler made the classic mistake of sending us a lot of powerpc and sparc64 related patches. The usual punishment, of giving him a commit bit to the Gecko repository, has been applied. We currently have some old ports in the ports tree: * www/mozilla is 5 year old now, no longer supported upstream, and has a lot of security vulnerabilities. We can use www/seamonkey instead. * www/xulrunner is superseeded by www/libxul. A patch that includes the following changes has been tested on pointyhat and is ready for commit: * Remove references to www/mozilla/Makefile.common and www/mozilla/bsd.gecko.mk * Switch USE_GECKO= xulrunner firefox mozilla to USE_GECKO= libxul and remove www/xulrunner We are also working on Firefox 3.6 (Alpha 2), Thunderbird 3.0 (Beta 4), new libxul 1.9.1.3 and Seamonkey 2.0 (Beta 2) ports. All of them are already committed to our Gecko repository. A current status and todo list can be found at http://trillian.chruetertee.ch/freebsd-gecko/wiki/TODO. Open tasks: 1. Remove mozilla, xulrunner and firefox2 from the ports tree. 2. The www/firefox35 port should be moved to www/firefox. 3. The old (and somewhat stale) Gecko providers mozilla, nvu, xulrunner, flock and firefox also need to be removed. __________________________________________________________________ FreeBSD KDE Team URL: http://freebsd.kde.org URL: http://miwi.bsdcrew.de/category/kde/ URL: http://blogs.freebsdish.org/tabthorpe/category/kde Contact: Thomas Abthorpe Contact: Max Brazhnikov Contact: Martin Wilke Since the spring, the FreeBSD KDE team has been busy upgrading KDE from 4.2.0 up through to 4.3.1. As part of the ongoing maintenance of KDE, the team also updated Qt4 from 4.4.3 through to 4.5.2 We added two new committers/maintainers to the team, Kris Moore (kmoore@) and Dima Panov (fluffy@). We also granted enhanced area51 access to contributors Alberto Villa and Raphael Kubo da Costa. Alberto has been our key contributor updating and testing Qt 4.6.0-tp1. Raphael is a KDE developer, who has become our Gitorious liaison, he has been responsible for getting FreeBSD Qt patches merged in upstream. Markus Br?ffer (markus@) spent a lot of time patching widgets and system plugins so they would work under FreeBSD. We would like to thank him for all his effort! Open tasks: 1. Update to Qt 4.6.0 2. Update to KDE 4.4.0 3. Work with our userbase on fixing an EOL for KDE3 in the ports tree __________________________________________________________________ FreeBSD Ports Management Team URL: http://www.freebsd.org/ports/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/ URL: http://portsmon.FreeBSD.org/index.html URL: http://www.freebsd.org/portmgr/index.html URL: http://tinderbox.marcuscom.com Contact: Mark Linimon The ports count has soared to over 20,700. The PR count had been driven below 800 by some extraordinary effort, but once again is back to its usual count of around 900. We are currently building packages for amd64-6, amd64-7, amd64-8, i386-6, i386-7, i386-8, sparc64-7, and sparc64-8. There have been preliminary runs of i386-9; however, to be able to continue builds on -9, we will either need to find places to host a number of new machines, or drop package building for -6. The mailing list discussion of the latter proved quite controversial. We have added some new i386 machines to help speed up the builds, but this only makes up for the disk failures on some of our older, slower, i386 nodes. We also appreciate the loan of more package build machines from several committers, including pgollucci@, gahr@, erwin@, Boris Kochergin, and Craig Butler. The portmgr@ team has also welcomed new members Ion-Mihai Tetcu (itetcu@) and Martin Wilke (miwi@). We also thank departing member Kirill Ponomarew (krion@) for his long service. Ion-Mihai has spent much time working on a system that does automatic Quality Assurance on new commits, called QAT. A second tinderbox called QATty has helped us to fix many problems, especially those involving custom PREFIX and LOCALBASE settings, and documentation inclusion options. Ports conformance to documented features / non-default configuration will follow. Between pav and miwi, over 2 dozen experimental ports runs have been completed and committed. We have added 5 new committers since the last report, and 2 older ones have rejoined. Open tasks: 1. We are currently trying to set up ports tinderboxes that can be made available to committers for pre-testing; those who can loan machines for this should contact Ion-Mihai (itetcu@) with details regarding the hardware and bandwidth. 2. Most of the remaining ports PRs are "existing port/PR assigned to committer". Although the maintainer-timeout policy is helping to keep the backlog down, we are going to need to do more to get the ports in the shape they really need to be in. 3. Although we have added many maintainers, we still have almost 4,700 unmaintained ports (see, for instance, the list on portsmon). (The percentage is down to 22%.) We are always looking for dedicated volunteers to adopt at least a few unmaintained ports. As well, the packages on amd64 and sparc64 lag behind i386, and we need more testers for those. __________________________________________________________________ FreeBSD TDM Framework Contact: Rafal Czubak Contact: Michal Hajduk This work's purpose is a generic and flexible framework for systems equipped with Time Division Multiplexing (TDM) units, often found on embedded telecom chips. The framework is designed to support various controllers and many types of TDM channels e.g. voiceband, sound and miscellaneous data channels. Currently, voiceband infrastructure is being developed on Marvell RD-88F6281 reference board. It will serve as an example of how to use the TDM framework for other channel types. The direct objective of using TDM with voiceband channels is bringing a FreeBSD based VoIP system, capable of bridging analog telephone world with digital IP telephony. Together with third party VoIP software (e.g. Asterisk), the design can serve as VoIP Private Branch Exchange (PBX). Current state highlights: * TDM controller interface * TDM channel interface * TDM channel API for kernel modules * codec interface * voiceband channel character device driver * TDM controller driver for Marvell Kirkwood and Discovery SoCs * Si3215 SLIC driver * Si3050 DAA driver Open tasks: 1. Develop demo application showing example usage of voiceband channel. 2. Integrate voiceband infrastructure with Zaptel/DAHDI telephony hardware drivers. __________________________________________________________________ FreeBSD/sparc64 Contact: Marius Strobl Noteworthy developments regarding FreeBSD/sparc64 since the last Status Reports are: * Cas(4), a driver for Sun Cassini/Cassini+, as well as National Semiconductor DP83065 Saturn Gigabit NICs has been committed and thus will be part of FreeBSD beginning with 8.0-RELEASE and 7.3-RELEASE, respectively. This means that the on-board NICs found in Fire V440, as well as the add-on cards based on these chips, are now supported, including on non-sparc64 machines. Unfortunately, the cas(4) driver triggers what seem to be secondary problems with the on-board NICs found in B100 blades and Fire V480, which due to lack of access to such systems could not be fixed so far. * Initial support for sun4u machines based on the "Fire" Host-PCI-Express bridge like Fire V215, V245, etc. has been completed (including support for the on-board ATA controller, which caused several problems at first, and MSI/MSI-X). Some code like the quirk handling for the ALi/ULi chips found in these machines needs to be revisited though and no stability tests have been conducted so far. If all goes well, the code will hit HEAD some time after FreeBSD 8.0-RELEASE has been released. In theory, machines based on the "Oberon" Host-PCI-Express bridge, at least for the most part, should also be supported with these changes, but due to lack of access to a Mx000 series machine the code could not be tested with these so far. * Some bugs in the snd_t4dwave(4) driver have been fixed, as well as some special handling for sparc64 has been added so it does 32-bit DMA and now generally works with the on-board ALi M5451 found for example in Blade 100 and Blade 1500. Unfortunately, it was only tested to work correctly in two out of three Blade 100. Why it still does not work correctly in the remaining one is currently unknown but at least no longer causes IOMMU-panics so testing snd_t4dwave(4) on sparc64 is no longer harmful. These changes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * Ata-marvell(4) has been fixed to work on sparc64 (actually also on anything that is not x86 with less than 4GB of RAM). These fixes will be part of FreeBSD 8.0-RELEASE and 7.3-RELEASE. * A proper and machine-independent fix for the old problem that the loader leaves the NIC opened by the firmware, which could lead to panics during boot when netbooting, has been developed but not committed yet. Open tasks: __________________________________________________________________ FreeBSD/ZFS Contact: Pawel Dawidek We believe that the ZFS file system is now production-ready in FreeBSD 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer tagged as experimental. There is also ongoing work in Perforce to bring the latest ZFS version (v19) to FreeBSD. Open tasks: 1. Download 8.0 release candidates and test, test, test and report any problems to the freebsd-fs@FreeBSD.org mailing list. __________________________________________________________________ Grand Central Dispatch - FreeBSD port URL: http://libdispatch.macosforge.org/ Contact: Robert Watson Contact: Stacey Son Contact: libdispatch mailing list We have ported libdispatch, Apple's Grand Central Dispatch event and concurrency framework to FreeBSD: * Added new kqueue primitives required to support GCD, such as EVFILT_USER and EV_TRIGGER * Created autoconf and automake build framework for libdispatch * Modified libdispatch to use POSIX semaphores instead of Mach semaphores * Adapted libdispatch to use portable POSIX time routines Jordan Hubbard has also prepared a blocks-aware clang compiler package for FreeBSD. When compiled with clang, libdispatch provides blocks-based, as well as function-based callbacks. The port was presented at the FreeBSD Developer Summit in Cambridge, UK in September, and slides are online on the devsummit wiki page. A FreeBSD port is now available in the Ports Collection. After FreeBSD 8.0-RELEASE has shipped, the new kqueue primitives will be MFC'd so that libdispatch works out of the box on FreeBSD 8.1-RELEASE. Open tasks: 1. Complete porting of libdispatch test suite to FreeBSD. 2. Investigate pthread work queue implementation for FreeBSD. 3. Evaluate performance impact of some machine-dependent and OS-dependent optimizations present in the Mac OS X version of libdispatch to decide if they should be done for other platforms and OS's. 4. Explore whether FreeBSD base operating system tools would benefit from being modified to use libdispatch. __________________________________________________________________ hwpmc for MIPS URL: http://wiki.freebsd.org/FreeBSD/mips URL: http://wiki.freebsd.org/FreeBSD/mips/UBNT-RouterStationPro Contact: George Neville-Neil Currently working on board bringup. I have looked over the docs for how MIPS provides performance counters and will begin adding code soon. __________________________________________________________________ libnetstat(3) - networking statistics (Summer of Code 2009) URL: http://wiki.FreeBSD.org/PGJSoc2009 URL: http://p4web.freebsd.org/@md=d&cd=//&c=McZ@//depot/projects/soc2009/pgj _libstat/?ac=83 Contact: G?bor P?li The libnetstat(3) project provides a user-space library API to monitor networking functions with the following benefits: * ABI-robust interface making use of accessor functions in order to divorce monitoring applications from kernel or user ABI changes. * Supports running 32-bit monitoring tools on top of a 64-bit kernel. * Improved consistency for both kvm(3) and sysctl(3) when retrieving information. The supported abstractions are as follows: * Active sockets and socket buffers * Network interfaces and multicast interfaces * mbuf(9) statistics * bpf(4) statistics * Routing statistics, routing tables, multicast routing * Protocol-dependent statistics There is a sample application, called nettop(8), which provides a simple ncurses-based top(1)-like interface for monitoring active connections and network buffer allocations via the library. A modified version of netstat(1) has also been created to use libnetstat(3) as much as possible. __________________________________________________________________ libprocstat(3) - process statistics URL: http://svn.freebsd.org/viewvc/base/projects/libprocstat/ Contact: Stanislav Sedov Contact: Ulf Lilleengen The libprocstat project is an ongoing effort to develop a library that can be used to retrieve information about running processes and open files in the uniform and platform-independent way both from a running system or from core files. This will facilitate the implementation of file- or process-monitoring applications like lsof(1), fstat(1), fuser, etc. The libprocstat repository contains a preliminary version of the library. It also includes rewrites of the fstat and the fuser utilities ported to use this library instead of retrieving all the required information via the kvm(3) interface; one of the important advantages of the versions that use libprocstat is that these utilities are ABI independent. Open tasks: 1. Implement KVM-based namecache lookup to retrieve filesystem paths associated with file descriptors and VM objects. 2. Analyze possible ways of exporting file and process information from the kernel in an extensible and ABI-independent way. __________________________________________________________________ Modular Congestion Control URL: http://caia.swin.edu.au/urp/newtcp/ URL: http://svn.freebsd.org/viewvc/base/projects/tcp_cc_8.x/ Contact: Lawrence Stewart The patch has received some significant rototilling in the past few months to prepare it for merging to FreeBSD-CURRENT. Additionally, I completed an implementation of the CUBIC congestion control algorithm to complement the existing NewReno and H-TCP algorithm implementations already available. I have one further intrusive change to make, which will allow congestion control modules to be shared between the TCP and SCTP stacks. Once this is complete, I will be soliciting for review/testing in the hope of committing the patch to FreeBSD-CURRENT in time to be able to backport it for 8.1-RELEASE. Open tasks: 1. Abstract the congestion control specific variables out of the TCP and SCTP control blocks into a new struct that can be passed into the API instead of the control block itself. __________________________________________________________________ Network Stack Virtualization URL: http://wiki.freebsd.org/Image URL: http://wiki.freebsd.org/200909DevSummit Contact: Bjoern A. Zeeb Contact: Marko Zec Contact: Robert Watson The network stack virtualization project aims at extending the FreeBSD kernel to maintain multiple independent instances of networking state. This allows for networking independence between jail environment, each maintaining its private network interfaces, IPv4 and IPv6 network and port address space, routing tables, IPSec configuration, firewalls, and more. During the last months the remaining pieces of the VIMAGE work were merged by Marko, Julian and Bjoern. Robert Watson developed a vnet allocator to overcome ABI issues. Jamie Gritton merged his hierachical jail framework that now also is the management interface for virtual network stacks. During the FreeBSD Developer Summit that took place at EuroBSDCon 2009 in Cambridge, UK, people virtualized more code. As a result SCTP and another accept filter were virtualized and more people became familiar with the design of VImage and the underlying concepts. Finally getting more hands involved was a crucial first step for the long term success of kernel virtualization. The next steps will be to finish the network stack virtualization, generalize the allocator framework before thinking of virtualizing further subsystems and to update the related documentation. Along with that a proper jail management framework will be worked on. Long term goals, amongst others, will be to virtualize more subsystems like SYS-V IPC, better privilege handling, and resource limits. In the upcoming FreeBSD 8.0 Release, vnets are treated as an experimental feature. As a result, they are not yet recommended for use in production environments. There was lots of time spent to finalize the infrastructure for vnets though, so that further changes can be merged and we are aiming to have things production ready for 8.2. In case you want to help to achieve this goal, feel free to contact us and support or help virtualizing outstanding parts like two firewalls, appletalk, netipx, ... as well as generating regression tests. __________________________________________________________________ New approach to the locale database URL: http://wiki.freebsd.org/LocaleNewApproach URL: svn://svn.freebsd.org/base/user/edwin/locale Contact: Edwin Groothuis Contact: i18n mailinglist Problem: Over the years the FreeBSD locale database (share/colldef, share/monetdef, share/msgdef, share/numericdef, share/timedef) has accumulated a total of 165 definitions (language - country-code - character-set triplets). The contents of the files for Western European languages are often low-ASCII but for Eastern European and Asian languages partly or fully high-ASCII. Without knowing how to display or interpret the character-sets, it is difficult to make sure by the general audience that the local language (language - country-code) definitions are displayed properly in various character-sets. Suggested approach: With the combination of the data in the Unicode project (whose goal is to define all the possible written characters and symbols on this planet) and the Common Locale Data Repository (whose goal is to document all the different data and definitions needed for the locale database), we can easily keep track of the data, without the need of being able to display the data in the required character sets or understand them fully when updates are submitted by third parties. Current status: Conversion of share/monetdef, share/msgdef, share/numericdef, share/timedef to the new design is completed. The Makefile infrastructure is converted. Regression checks are done. Most of the tools are in place, waiting on the import of bsdiconv to the base system. Open tasks: 1. At this moment the system is not self-hosted yet, because of the lack of an iconv-kind of program in the base operating system. Gabor@ is working on bsdiconv as a GSoC project and once that has been imported we will be able to perform a clean install from the definitions in Unicode text format to the required formats and character sets. __________________________________________________________________ New BSD licensed debugger URL: http://wiki.freebsd.org/TheBsdDebugger URL: http://people.freebsd.org/~dfr/ngdb.git URL: http://wiki.freebsd.org/200909DevSummit?action=AttachFile&do=view&targe t=NGDB-200909.pdf Contact: Doug Rabson <> I have been working recently on writing a new debugger, primarily for the FreeBSD platform. For various reasons, I have been writing it in a relatively obscure C-like language called D. So far, I have a pretty useful (if a little raw at the edges) command line debugger which supports ELF, Dwarf debugging information and (currently) 32 bit FreeBSD and Linux. The engine includes parsing and evaluation of arbitrary C expressions along with the usual debugging tools such as breakpoints, source code listing, single-step etc. All the code is new and BSD licensed. Currently, the thing supports userland debugging of i386 targets via ptrace and post-mortem core file debugging of the same. I will be adding amd64 support real soon (TM) and maybe support for GDB's remote debugging protocol later. __________________________________________________________________ NFSv4 ACLs URL: http://wiki.freebsd.org/NFSv4_ACLs Contact: Edward Tomasz Napierala During Google Summer of Code 2008, I have implemented native support for NFSv4 ACLs for both ZFS and UFS. Most of the code has already been merged to CURRENT. NFSv4 ACLs are unconditionally enabled in ZFS and the usual tools, like getfacl(1) and setfacl(1) can be used to view and change them. I plan to merge the remaining bits (UFS support) this month. It should be possible to MFC it in order to ship in FreeBSD 8.1-RELEASE. Open tasks: 1. UFS changes review 2. Support for NFSv4 ACLs in tar(1) __________________________________________________________________ pefs - stacked cryptographic filesystem (Summer of Code 2009) URL: http://blogs.freebsdish.org/gleb/ URL: http://wiki.freebsd.org/SOC2009GlebKurtsov Contact: Gleb Kurtsou Contact: Stanislav Sedov Pefs is a kernel level filesystem for transparently encrypting files on top of other filesystems (like zfs or ufs). It adds no extra information into files (unlike others), doesn't require cipher block sized io operations, supports per directory/file keys and key chaining, uses unique per file tweak for encryption. Supported algorithms: AES, Camellia, Salsa20. The code is ready for testing. Open tasks: 1. Implement encrypted name lookup/readir cache 2. Optimize sparse files handling and file resizing __________________________________________________________________ Portmaster - utility to assist users with managing ports URL: http://dougbarton.us/portmaster.html Contact: Doug Barton I am currently seeking funding for further development work on portmaster. There are several features that are regularly requested by the community (such as support for installing packages) that I would very much like to implement but that will take more time than I can reasonably volunteer to implement correctly. There is information about the funding proposal available at the link above. Meanwhile I have recently completed another round of bug fixes and feature enhancements. The often-requested ability to specify the -x (exclude) option more than once on the command line was added in version 2.12. Also in that version I added the --list-origins option to make it easier to reinstall ports after a major version upgrade, or install the same set of ports on another system. Open tasks: 1. See the funding proposal. __________________________________________________________________ Release Engineering Status Report URL: http://www.FreeBSD.org/releng/ Contact: Release Engineering Team The Release Engineering Team continues to work on FreeBSD 8.0-RELEASE. Public testing has turned up quite a few problems, many related to the low-level network (routing/ARP table) changes and their interactions with IPv6. Progress continues to be made on fixing up the issues that have been identified during the public testing. At this point in time we are shooting for two more public test builds (RC2 and RC3) followed by the release late October or early November. __________________________________________________________________ Stream Control Transmission Protocol (SCTP) Contact: Randall Stewart SCTP continues to have minor fixes added to it as well as some new features. First and foremost, we now have VIMAGE and SCTP working and playing together. This goal was accomplished with the help of bz@, my new mentee tuexen@ and myself working together at the FreeBSD DevSummit in Cambridge, UK. Also the non-renegable SACK feature contributed by the university of Delaware was fixed so that now its safe to turn on (its sysctl). If you are using SCTP with CMT (Conncurrent Multipath Transfer) you will want to enable this option (CMT is also a sysctl). With CMT enabled you will be able to send data to all the destinations of an SCTP peer. We welcomed a new mentee (soon to be a commiter) to FreeBSD. Michael Tuexen is now a mentee of rrs@. Michael has been contributing to the SCTP work for quite some time and also moonlights as a Professor at the University of Muenster in Germany (when not doing SCTP coding). __________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/docproj/translations.html#dutch Contact: Ren? Ladan Contact: Remko Lodder The current translations (Handbook and some articles) are kept up to date with the English versions. Some parts of the website have been translated, more work is in progress. Open tasks: 1. Find more volunteers for translating the remaining parts of the website and the FAQ. __________________________________________________________________ The FreeBSD Forums URL: http://forums.freebsd.org/ Contact: FreeBSD Forums Admins Contact: FreeBSD Forums Moderators Since their public launch in November 2008, the FreeBSD Forums (the most recent addition to the user community and support channels for the FreeBSD Operating System) have witnessed a healthy and steady growth. The user population is now at over 8,000 registered users, who have participated in over 6,000 topics, containing over 40,000 posts in total. The sign-up rate hovers between 50-100 each week. The total number of visitors (including 'guests') is hard to gauge but is likely to be a substantial multiple of the registered userbase. New topics and posts are actively 'pushed out' to search engines. This in turn makes the Forums show up in search results more and more often, making it a valuable and very accessible source of information for the FreeBSD community. One of the contributing factors to the Forums' success is their 'BSD-style' approach when it comes to administration and moderation. The Forums have a strong and unified identity, they are neatly divided into sub-forums (like 'Networking', 'Installing & Upgrading', etc.), very actively moderated, spam-free, and with a core group of very active and helpful members, dispensing many combined decades' worth of knowledge to starting, intermediate and professional users of FreeBSD. We expect the Forums to be, and to remain, a central hub in FreeBSD's community and support efforts. __________________________________________________________________ The FreeBSD Foundation Status Report URL: http://www.freebsdfoundation.org Contact: Deb Goodkin Kicking off our fall fund-raising campaign! Find out more at http://www.freebsdfoundation.org/donate/. We were a sponsor for EuroBSDCon 2009, and provided travel grants to 8 FreeBSD developers and users. We sponsored Kyiv BSD 2009, in Kiev Ukraine. We were also a sponsor of BSDCan, and sponsored 7 developers. We funded three new projects, New Console Driver by Ed Schouten, AVR32 Support by Arnar Mar Sig, and Wireless Mesh Support by Rui Paulo, which has completed. We continued funding a project that is making improvements to the FreeBSD TCP Stack by Lawrence Stewart. The project that made removing disk devices with mounted filesystems on them safe, by Edward Napierala, is now complete. We recognized the following FreeBSD developers at EuroBSDCon 2009: Poul-Henning Kamp, Bjoern Zeeb, and Simon Nielsen. These developers received limited edition FreeBSD Foundation vests. Follow us on Twitter now! __________________________________________________________________ The FreeBSD German Documentation Project URL: https://doc.bsdgroup.de URL: http://code.google.com/p/bsdcg-trans/wiki/BSDPJTAdede Contact: Johann Kois Contact: Benedict Reuschling Contact: Martin Wilke In May 2009, Benedict Reuschling received his commit bit to the www/de and doc/de_DE.ISO8859-1 trees under the mentorship of Johann Kois. Since then, he has been working primarily on the Handbook, updating existing chapters and translating new ones. Most notably, the filesystems and DTrace chapters have been recently translated. Bugs found in the original documents along the way were reported back so that the other translation teams could incorporate them, as well. Christoph Sold has put his time in translating the wiki pages of the BSD Certification Group into the German language. This is very helpful for all German people who want to take the exam and like to read the information about it in their native language. Daniel Seuffert has sent valuable corrections and bugfixes. Thanks to both of them for their time and efforts! The website is translated and updated constantly. Missing parts will be translated as time permits. We appreciate any help from volunteers in proofreading documents, translating new ones and keeping them up to date. Even small error reports are of great help for us. You can find contact information at the above URL. Open tasks: 1. Update the existing documentation set (especially the Handbook). 2. Translate more articles to German. 3. Read the translations. Check for problems and mistakes. Send feedback. __________________________________________________________________ The FreeBSD Hungarian Documentation Project URL: http://www.FreeBSD.org/hu URL: http://www.FreeBSD.org/doc/hu URL: http://wiki.FreeBSD.org/HungarianDocumentationProject URL: http://p4web.freebsd.org/@md=d&cd=//depot/projects/docproj_hu/&c=aXw@// depot/projects/docproj_hu/?ac=83 Contact: G?bor K?vesd?n Contact: G?bor P?li In the last months, we have not added new translations, although we have been working on the existing ones to have them updated. We need more translators and volunteers to keep the amount of the translated documentation growing, so feel free to contribute. Every line of submission or feedback is appreciated and highly welcome. If you want to join our work, please read the introduction to the project as well as the FDP Primer (both of them are available in Hungarian). Open tasks: 1. Translate news entries, press releases 2. Translate Release Notes for -CURRENT and 8.X 3. Translate articles 4. Translate web pages 5. Read the translations, send feedback __________________________________________________________________ The FreeBSD Spanish Documentation Project URL: http://www.FreeBSD.org/es URL: http://www.FreeBSD.org/doc/es URL: http://www.freebsd.org/doc/es/articles/fdp-es/ Contact: Jos? Vicente Carrasco Vay? Contact: G?bor K?vesd?n Recently, we have added one new article translation. The existing translations have not been updated, though. We need more human resources to keep up with the work and keep the translations up-to-date. Open tasks: 1. Update the Handbook translation 2. Update the web page translation __________________________________________________________________ The Newcons project URL: http://wiki.FreeBSD.org/Newcons URL: http://people.freebsd.org/~ed/newcons/patches/ Contact: Ed Schouten Some time ago I started writing a new driver for the FreeBSD kernel called vt(4), which is basically a replacement of syscons. There is still a lot of work that needs to be done but it is probably useful to mention what it does (and what does not). Right now there are just two graphics drivers for vt(4), namely a VGA driver for i386 and amd64 and a Microsoft Xbox graphics driver (because it was so easy to implement). I still have to figure out what I am going to do with VESA, because maybe it is better to just ignore VESA and figure out how hard it is to extend DRM to interact with vt(4). Some random features: it already supports both Unicode (UTF-8) input and output, it is MPSAFE and supports per-window graphical fonts of variable dimensions, containing an almost infinite amount of glyphs (both bold and regular). Open tasks: 1. Research needs to be done on DRM's codebase. 2. Syscons should already be migrated to TERM=xterm to make switching between drivers a bit easier. __________________________________________________________________ Valgrind suite on FreeBSD URL: http://wiki.freebsd.org/Valgrind Contact: Stanislav Sedov The Valgrind suite in the FreeBSD ports collection has been updated to version 3.5.0 (the latest available version). Most of the issues of the previous version should be resolved now: we expect memcheck, callgrind and cachegrind to be fully functional on both i386 and amd64 platforms as well as for i386 binaries running on amd64 system. DRD/hellgrind should work too, though they generate a lot of false-positives for now, so their output is a bit messy. Open tasks: 1. Port exp-ptrcheck valgrind tool and fix outstanding issues that show up in memcheck/helgrind/DRD in the Valgrind regression tests suite. 2. More testing (please, help). 3. Integrate our patches upstream. __________________________________________________________________ VirtualBox on FreeBSD URL: http://wiki.freebsd.org/VirtualBox Contact: Beat Gaetzi Contact: Bernhard Froehlich Contact: Dennis Herrmann Contact: Juergen Lock Contact: Martin Wilke VirtualBox has been committed to the Ports tree and synchronized with the latest trunk version from Sun. Several known problems are already fixed and some new features have been added: * VT-x support * Bridging support (Big Thanks to Fredrik Lindberg) * Host Serial Support * ACPI Support * Host DVD/CD access * SMP Support We would like to say thanks to all the people who helped us by reporting bugs and submitting fixes. We also thank the VirtualBox developers for their help with the ongoing effort to port VirtualBox on FreeBSD. From ed at 80386.nl Sun Oct 11 20:17:17 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Oct 11 20:17:25 2009 Subject: can't change tty speed and buffer size on 8.0 Message-ID: <20091011201715.GY71731@hoeg.nl> Hello Mikolaj, It is indeed true that the new TTY layer restricts the baud rate to 9600. We could consider clamping the baud rate between a certain range, to prevent the TTY buffer size from growing excessively. So what kind of buffer size are you interested in? Would 115200 / 5 be enough? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091011/326c3573/attachment.pgp From cliftonr at lava.net Mon Oct 12 01:55:44 2009 From: cliftonr at lava.net (Clifton Royston) Date: Mon Oct 12 01:55:51 2009 Subject: Any recommended Intel server motherboards? Message-ID: <20091012015542.GB2096@lava.net> A client is asking me to recommend hardware for a mailserver; they're an OEM and whitebox builder, and would prefer to use an Intel server board which seems reasonable. Are there any particularly recommended current models? I seem to recall that Intel's RAID hardware is not that reliable, so I am assuming I should either recommend they use plain SATA or SAS drives, or steer them to an external RAID system with dedicated controller. If that's changed, it would be nice to know. Parameters: The system will not be very high-throughput, primarily fronting and acting as relay and storage queue for initially about 5000 mailboxes in 100+ domains. All spam filtering will be handled on another box. -- Clifton -- Clifton Royston -- cliftonr@iandicomputing.com / cliftonr@lava.net President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services From kris.weston at gmail.com Mon Oct 12 06:00:08 2009 From: kris.weston at gmail.com (Kris Weston) Date: Mon Oct 12 06:00:20 2009 Subject: corrupt GPT tables on open solaris zfs import Message-ID: <72d267bc0910112234v62d2ca79h7aeea8d25789d0cc@mail.gmail.com> hi guys n gals, im getting a problem about corrupt GPT tables upon trying to import my solaris mirror. should i just overwrite the GPT ? and if anyone can tell me how that would be awesome ? im on 7.2 stable zfs v13 ive seen its a known issue on the forums but cant see a solution ? thanks -- )) (( c[_] From to.my.trociny at gmail.com Mon Oct 12 06:10:42 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Mon Oct 12 06:10:48 2009 Subject: can't change tty speed and buffer size on 8.0 In-Reply-To: <20091011201715.GY71731@hoeg.nl> (Ed Schouten's message of "Sun\, 11 Oct 2009 22\:17\:15 +0200") References: <20091011201715.GY71731@hoeg.nl> Message-ID: <81k4z1p3fj.fsf@zhuzha.ua1> On Sun, 11 Oct 2009 22:17:15 +0200 Ed Schouten wrote: > Hello Mikolaj, > > It is indeed true that the new TTY layer restricts the baud rate to > 9600. We could consider clamping the baud rate between a certain range, > to prevent the TTY buffer size from growing excessively. > > So what kind of buffer size are you interested in? Would 115200 / 5 be > enough? I have reviewed my logs for the last period and the line with maximum length I have found was 6521 characters. And if I filter only those lines that I am usually interested in then the maximum lenght has been 3288. So 115200/5=23040 would be more then enough for me :-) Thanks, -- Mikolaj Golub From ed at 80386.nl Mon Oct 12 07:08:31 2009 From: ed at 80386.nl (Ed Schouten) Date: Mon Oct 12 07:08:38 2009 Subject: can't change tty speed and buffer size on 8.0 In-Reply-To: <81k4z1p3fj.fsf@zhuzha.ua1> References: <20091011201715.GY71731@hoeg.nl> <81k4z1p3fj.fsf@zhuzha.ua1> Message-ID: <20091012070829.GA71731@hoeg.nl> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091012/4aed2591/attachment.pgp From to.my.trociny at gmail.com Mon Oct 12 09:01:29 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Mon Oct 12 09:01:35 2009 Subject: can't change tty speed and buffer size on 8.0 In-Reply-To: <20091012070829.GA71731@hoeg.nl> (Ed Schouten's message of "Mon\, 12 Oct 2009 09\:08\:29 +0200") References: <20091011201715.GY71731@hoeg.nl> <81k4z1p3fj.fsf@zhuzha.ua1> <20091012070829.GA71731@hoeg.nl> Message-ID: <81iqelhtp7.fsf@zhuzha.ua1> On Mon, 12 Oct 2009 09:08:29 +0200 Ed Schouten wrote: > * Mikolaj Golub wrote: >> So 115200/5=23040 would be more then enough for me :-) > > Great. I've attached a patch that should allow the buffer size to be > configured. Unfortunately gettytab currently sets the baud rate to > 115200, which means we'll always use buffer sizes. I think we'd better > just remove the baud rate assignment and let the kernel decide which > default baud rate for the console is the best. > > I'll commit the patch within the next couple of days. Let me know > whether you experience any problems with it. Applied and it works for me. Thanks. If I notice any issues I will let you know :-) -- Mikolaj Golub From daniel at roe.ch Mon Oct 12 09:45:24 2009 From: daniel at roe.ch (Daniel Roethlisberger) Date: Mon Oct 12 09:45:31 2009 Subject: openssh concerns In-Reply-To: References: <200910081823.n98INRVZ082461@lurza.secnetix.de> Message-ID: <20091012094519.GA29445@calvin.ustdmz.roe.ch> Robert Watson 2009-10-11: > On Thu, 8 Oct 2009, Oliver Fromme wrote: > >Are you sure? The majority of BSD machines in my vicinity > >have multiple accounts. > > > >And even if there's only one account, there is no reason to be > >careless with potential port-takeover risks. > > > >Therefore I advise against running critical daemons on > >unprivileged ports, especially on machines with shell > >accounts. And if you need to bind to a port >= 1024, use > >mac_portacl(4) to protect it. It's easy to use. > >Alternatively you can increase the value of the sysctl > >net.inet.ip.portrange.reservedhigh, but this is less flexible > >and might have unwanted side effects. > > And, for those that haven't already noticed, "options MAC" is > compiled into GENERIC on 8.0, so working with MAC policies no > longer requires a recompile (or in many cases, even a reboot). If your situation allows running pf, then there's an alternative method: bind sshd normally to port 22, but use pf to deny direct connections to port 22, redirecting connections to some high port X to port 22 using a `rdr pass' rule. You can even make exceptions for trusted IP address ranges which are then allowed to SSH in directly on port 22. That way, an unprivileged process will gain nothing by listening on high port X; it won't get to accept() any SSH connections. -- Daniel Roethlisberger http://daniel.roe.ch/ From howard at leadmon.net Mon Oct 12 11:50:31 2009 From: howard at leadmon.net (Howard Leadmon) Date: Mon Oct 12 11:50:39 2009 Subject: Kernel Build Issues with latest cvsup of both a 7.2 system, and a 6.4 system.. Message-ID: <002001ca4b2f$8aa3fef0$9febfcd0$@net> Not sure if I am just having a run of bad luck here, but I have a bunch of various free BSD boxen on both 6.4-STABLE, and on 7.2-STABLE. I try and make it a point to do a cvsup and update the machines every month or so to keep things current and any updates/patches installed. I decided a couple days ago, it was again time to do this again. So I ran cvsup on the machines, and set out to rebuild, first doing a 'make buildworld', then a 'make installworld', and finally a 'mergemaster' on the servers. That all went well, then time for a kernel update, so I performed a 'make buildkernel KERNCONF=GENERIC' to create the new kernel, which is where things went bad. On my 6.4-STABLE x86 machine, I received the following: cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/em -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/kern/kern_event.c /usr/src/sys/kern/kern_event.c:408: warning: no previous prototype for 'knote_fork' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. On my 7.2-STABLE amd64 machine, I received the following: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding /usr/src/sys/amd64/amd64/genassym.c In file included from /usr/src/sys/vm/pmap.h:82, from /usr/src/sys/amd64/amd64/genassym.c:61: ./machine/pmap.h:323: error: expected declaration specifiers or '...' before 'vm_memattr_t' *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 I have rebuilt the above servers many times over, and I must say it's worked great, so was really thrown that not only one version on a server would blow up, but two different versions of the OS would pop at the same moment. Needless to say I haven't tried to rebuild any of my other 6.4 or 7.2 boxen yet, as I want to get the above two attempts sorted out first. Has something changed I am forgetting to do that is not biting me in the backside, or has some bug been introduced I am now aware of currently causing issues?? If anyone can help sort this out, or if you need additional info, please let me know.. --- Howard Leadmon From lists at mawer.org Mon Oct 12 12:38:45 2009 From: lists at mawer.org (Antony Mawer) Date: Mon Oct 12 12:38:54 2009 Subject: Any recommended Intel server motherboards? In-Reply-To: <20091012015542.GB2096@lava.net> References: <20091012015542.GB2096@lava.net> Message-ID: The Intel boards all in all tend to be pretty well supported... we run a number of S3200SHL boards (about to be EOL'd I believe) and older S2000 series in production without any hitches. The basic Intel soft-RAID on the entry level boards should be avoided (use gmirror or similar if need be). If you are looking at any of the boards with onboard SAS, this is usually an LSI Logic based chipset (mfi driver from memory) and is fine as far as RAID reliability goes (at least in our experience, YMMV)... -- Antony On Mon, Oct 12, 2009 at 12:55 PM, Clifton Royston wrote: > ?A client is asking me to recommend hardware for a mailserver; they're > an OEM and whitebox builder, and would prefer to use an Intel server > board which seems reasonable. ?Are there any particularly recommended > current models? > > ?I seem to recall that Intel's RAID hardware is not that reliable, so > I am assuming I should either recommend they use plain SATA or SAS > drives, or steer them to an external RAID system with dedicated > controller. ?If that's changed, it would be nice to know. > > Parameters: > > ?The system will not be very high-throughput, primarily fronting and > acting as relay and storage queue for initially about 5000 mailboxes in > 100+ domains. ?All spam filtering will be handled on another box. > > ?-- Clifton > > -- > ? ?Clifton Royston ?-- ?cliftonr@iandicomputing.com / cliftonr@lava.net > ? ? ? President ?- I and I Computing * http://www.iandicomputing.com/ > ?Custom programming, network design, systems and network consulting services > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From olli at lurza.secnetix.de Mon Oct 12 13:42:19 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Mon Oct 12 13:42:30 2009 Subject: openssh concerns In-Reply-To: <20091012094519.GA29445@calvin.ustdmz.roe.ch> Message-ID: <200910121342.n9CDg19g066566@lurza.secnetix.de> Daniel Roethlisberger wrote: > If your situation allows running pf, then there's an alternative > method: bind sshd normally to port 22, but use pf to deny direct > connections to port 22, redirecting connections to some high port > X to port 22 using a `rdr pass' rule. You can even make > exceptions for trusted IP address ranges which are then allowed > to SSH in directly on port 22. That way, an unprivileged process > will gain nothing by listening on high port X; it won't get to > accept() any SSH connections. Just for completeness sake, the same can be done easily with IPFW and "fwd" rules, of course. 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 serenity at exscape.org Mon Oct 12 19:49:14 2009 From: serenity at exscape.org (Thomas Backman) Date: Mon Oct 12 19:49:24 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: Message-ID: I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. In other words: I want to hear about your experiences, *good or bad*! Here's the original thread (not from the beginning, though): http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial console. How to reproduce/test: 1) time file /etc/* > /dev/null a few times, or something similar that uses the disk; write down a common/average/median/whatever time. 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's uncompressed, since ZFS with lzjb/gzip enabled will squish this into a kilobyte-sized file, thus creating virtually *no* IO. 3) When cat has been running say 10 seconds, re-time command #1 and do some interactive stuff - run commands, edit files, etc. I couldn't actually reproduce the *completely* horrific increase in latency I posted about below just now (I did update my sources and rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had no major IO changes in 8-STABLE), and the "time file /etc/*" test "only" jumped by about 3x (compared to 20-60x+ previously), but it's still bad enough: commands such as "ls" and "w" take 2-3 seconds to run, as opposed to 0.005s for ls without the added IO... On Linux, the increase in latency is closer to 4%. A bit better than, oh, 400 times. ;) Oh, and again: this post is not a complaint; this is a post asking for your experiences. I know I'm not alone in having these issues - I just want to know if there are a lot of people that *don't* too, and what could cause them. I can't possibly switch to FreeBSD in production with this behaviour - and I've been looking forward to doing so for quite a while now. Regards, Thomas PS. I'll leave my post to the original discussion below. (I don't usually top post, but I don't consider this a reply, more of a new post with an addition below.) On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > Hey everyone, > I'm having serious trouble with the same thing, and just found this > thread while looking for the correct place to post. Looks like I > found it. (I wrote most of the post before finding the thread, so > some of it will seem a bit odd.) > > I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old > 80GB 7200rpm disk. > > My problem is that I get completely unacceptable latency on console > IO (both via SSH and serial console) when the system is performing > disk IO. The worst case I've noticed yet was when I tried copying a > core dump from a lzjb compressed ZFS file system to a gzip-9 > compressed one, to compare the file size/compression ratio. screen > (1) took at LEAST ten seconds - probably a bit more - I'm not > exaggerating here - to switch to another window, and an "ls" in an > empty directory also about 5-10 seconds. > Doing some silly CPU load with two instances of "yes >/dev/null" (on > a single core, remember) doesn't change anything, the system remains > very responsive. "cat /dev/zero > /uncompressed_fs/..." however > produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the > file ends up extremely small - a kilobyte or so - even after a > while, thus performing minimal IO). > > I'm thinking about switching to FreeBSD on my beefier "production" > system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, > single-core, 2GB RAM, 80GB disk), but unless I feel assured this > won't happen there as well, I'm not so sure anymore. I can do any > kind of heavy IO/compilation/whatever on that box, currently running > Linux, and it's always unnoticable. In this case it's impossible > *not* to notice that your key input is lagging behind 5-10 > seconds... I thought multiple times that the box must have panicked. > I do realize that the hardware isn't the best, especially the disks, > but this is far worse than it should be! > > Here's some of the testing done in this thread (or at least > something like it): > > [root@chaos ~]# time file /etc/* >/dev/null > real 0m1.725s > user 0m0.993s > sys 0m0.021s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m1.008s > user 0m0.990s > sys 0m0.015s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m1.008s > user 0m0.967s > sys 0m0.038s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m1.015s > user 0m0.998s > sys 0m0.008s > > So, pretty much exactly 1 second every time once the cache is warmed > up. Now, let's try it 10 seconds after starting heavy disk writing... > > [root@chaos ~]# cat /dev/zero > /DELETE_ME & > (wait for 10 seconds) > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m13.217s > user 0m1.004s > sys 0m0.023s > [root@chaos ~]# time file /etc/* >/dev/null > > real 0m24.012s > user 0m1.020s > sys 0m0.008s > > ... the numbers speak for themselves. FWIW I tried the same on the > Linux box: "file" took 0.8 seconds the first time, 0.125s subsequent > times. While running cat, 0.13-0.21 seconds (0.21 being the first, > subsequent runs took 0.13s). The system remained completely > responsive, which cannot be said for the FreeBSD one! > > Any advice? Info below - please ask if you need more! > > Regards, > Thomas > > ----------------------------------------------------------------------------- > > Basic info: > > [root@chaos ~]# uname -a > FreeBSD chaos.exscape.org 8.0-RC1 FreeBSD 8.0-RC1 #1 r197613M: Tue > Sep 29 15:04:44 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/ > src/sys/DTRACE amd64 > (KDB/DDB enabled, WITNESS/INVARIANTS *disabled*) > > [root@chaos ~]# mount > tank/root on / (zfs, local, noatime) > devfs on /dev (devfs, local, multilabel) > /dev/ad0s1a on /bootdir (ufs, local, soft-updates) > tank/export on /export (zfs, NFS exported, local, noatime) > tank/tmp on /tmp (zfs, local, noatime) > tank/usr on /usr (zfs, local, noatime) > tank/usr/obj on /usr/obj (zfs, local, noatime) > tank/usr/ports on /usr/ports (zfs, local, noatime) > tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) > tank/usr/src on /usr/src (zfs, local, noatime) > tank/usr/src_r196905 on /usr/src_r196905 (zfs, local, noatime, read- > only) > tank/var on /var (zfs, local, noatime) > tank/var/crash on /var/crash (zfs, local, noatime) > tank/var/log on /var/log (zfs, local, noatime) > tank/var/tmp on /var/tmp (zfs, local, noatime) > > dmesg: > > ----------------------------------------------------------------------------- > Copyright (c) 1992-2009 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 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 > root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 > > Features > = > 0x78bfbff > < > FPU > ,VME > ,DE > ,PSE > ,TSC > ,MSR > ,PAE > ,MCE > ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > AMD Features=0xe2500800 > AMD Features2=0x1 > real memory = 2147483648 (2048 MB) > avail memory = 2052362240 (1957 MB) > ACPI APIC Table: > 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, 7fef0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > isab0: at device 1.0 on pci0 > isa0: on isab0 > pci0: at device 1.1 (no driver attached) > ohci0: mem 0xfe02f000-0xfe02ffff irq > 21 at device 2.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ehci0: mem 0xfe02e000-0xfe02e0ff > irq 22 at device 2.1 on pci0 > ehci0: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem > 0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem > 0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 > atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > pcib1: at device 9.0 on pci0 > pci1: on pcib1 > vgapci0: mem 0xfcff8000-0xfcffbfff, > 0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 on > pci1 > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem > 0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 > miibus0: on xl0 > xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl0: Ethernet address: 00:50:da:44:c0:4a > xl0: [ITHREAD] > nfe0: port > 0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on pci0 > miibus1: on nfe0 > e1000phy0: PHY 1 on miibus1 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-FDX, auto > nfe0: Ethernet address: 00:13:d3:a2:aa:0f > nfe0: [FILTER] > pcib2: at device 11.0 on pci0 > pci2: on pcib2 > pcib3: at device 12.0 on pci0 > pci3: on pcib3 > pcib4: at device 13.0 on pci0 > pci4: on pcib4 > pcib5: at device 14.0 on pci0 > pci5: on pcib5 > amdtemp0: on hostb3 > acpi_tz0: on acpi0 > atrtc0: port 0x70-0x73 irq 8 on acpi0 > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > acpi0 > uart0: [FILTER] > uart0: console (115200,n,8,1) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > cpu0: on acpi0 > powernow0: on cpu0 > device_attach: powernow0 attach returned 6 > orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff, > 0xcc000-0xcc7ff 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 > ZFS NOTICE: system has less than 4GB and prefetch enable is not > set... disabling. > ZFS filesystem version 13 > ZFS storage pool version 13 > Timecounter "TSC" frequency 2009269513 Hz quality 800 > Timecounters tick every 1.000 msec > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > ad0: 76318MB at ata0-master UDMA100 > ugen0.1: at usbus0 > uhub0: on > usbus0 > ugen1.1: at usbus1 > uhub1: on > usbus1 > ad2: 9768MB at ata1-master UDMA100 > GEOM: ad2s1: geometry does not match label (255h,63s != 16h,63s). > Root mount waiting for: usbus1 usbus0 > uhub0: 10 ports with 10 removable, self powered > Root mount waiting for: usbus1 > Root mount waiting for: usbus1 > Root mount waiting for: usbus1 > uhub1: 10 ports with 10 removable, self powered > Trying to mount root from zfs:tank/root > netsmb_dev: loaded > > ----------------------------------------------------------------------------- > The 80GB disk is used for everything except swap (aka. dump device) > for which the 10GB disk is used, exclusively. > > loader.conf has nothing of value (just loading a few modules and a > vfs.root.mountfrom, plus serial console settings). From killing at multiplay.co.uk Mon Oct 12 21:41:14 2009 From: killing at multiplay.co.uk (Steven Hartland) Date: Mon Oct 12 21:41:22 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) References: Message-ID: <43727653B60248EEA363AA3A886DC42C@multiplay.co.uk> We're not running 8 yet but we do have a 7.x box which its under fairly high IO load doing mrtg graphs which has similar behaviour. When typing a command on ssh it will freeze for may seconds. I even went to far as to write a little C app which just prints out the time to screen and even that sees the big delay. Its always been like and I've never managed to get to the bottom of it, there's something in the IO / disk subsystem which can totally lock up the system under high IO load. Regards Steve ----- Original Message ----- From: "Thomas Backman" To: "freebsd-stable" Sent: Monday, October 12, 2009 8:48 PM Subject: Extreme console latency during disk IO (8.0-RC1,previous releases also affected according to others) > I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the problems *I* am > having, but rather to check whether the problem is universal or not, and if not, find a possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > Long story short, my version: when the disk is stressed hard enough, console IO becomes COMPLETELY unbearable. 10+ seconds to > switch between windows in screen(1), running (or even typing) simple commands, etc. This happens both via SSH and the serial > console. > > How to reproduce/test: > 1) time file /etc/* > /dev/null a few times, or something similar that uses the disk; write down a > common/average/median/whatever time. > 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's uncompressed, since ZFS with lzjb/gzip enabled will > squish this into a kilobyte-sized file, thus creating virtually *no* IO. > 3) When cat has been running say 10 seconds, re-time command #1 and do some interactive stuff - run commands, edit files, etc. > > I couldn't actually reproduce the *completely* horrific increase in latency I posted about below just now (I did update my > sources and rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had no major IO changes in 8-STABLE), and the > "time file /etc/*" test "only" jumped by about 3x (compared to 20-60x+ previously), but it's still bad enough: commands such > as "ls" and "w" take 2-3 seconds to run, as opposed to 0.005s for ls without the added IO... On Linux, the increase in latency > is closer to 4%. A bit better than, oh, 400 times. ;) > > Oh, and again: this post is not a complaint; this is a post asking for your experiences. I know I'm not alone in having these > issues - I just want to know if there are a lot of people that *don't* too, and what could cause them. I can't possibly switch > to FreeBSD in production with this behaviour - and I've been looking forward to doing so for quite a while now. > > Regards, > Thomas > > PS. > > I'll leave my post to the original discussion below. (I don't usually top post, but I don't consider this a reply, more of a > new post with an addition below.) > > On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > >> Hey everyone, >> I'm having serious trouble with the same thing, and just found this thread while looking for the correct place to post. Looks >> like I found it. (I wrote most of the post before finding the thread, so some of it will seem a bit odd.) >> >> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old 80GB 7200rpm disk. >> >> My problem is that I get completely unacceptable latency on console IO (both via SSH and serial console) when the system is >> performing disk IO. The worst case I've noticed yet was when I tried copying a core dump from a lzjb compressed ZFS file >> system to a gzip-9 compressed one, to compare the file size/compression ratio. screen (1) took at LEAST ten seconds - probably >> a bit more - I'm not exaggerating here - to switch to another window, and an "ls" in an empty directory also about 5-10 >> seconds. >> Doing some silly CPU load with two instances of "yes >/dev/null" (on a single core, remember) doesn't change anything, the >> system remains very responsive. "cat /dev/zero > /uncompressed_fs/..." however produces the extreme slowdown. (On a gzip-1 FS >> it doesn't, since the file ends up extremely small - a kilobyte or so - even after a while, thus performing minimal IO). >> >> I'm thinking about switching to FreeBSD on my beefier "production" system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to >> this one, single-core, 2GB RAM, 80GB disk), but unless I feel assured this won't happen there as well, I'm not so sure >> anymore. I can do any kind of heavy IO/compilation/whatever on that box, currently running Linux, and it's always >> unnoticable. In this case it's impossible *not* to notice that your key input is lagging behind 5-10 seconds... I thought >> multiple times that the box must have panicked. >> I do realize that the hardware isn't the best, especially the disks, but this is far worse than it should be! >> >> Here's some of the testing done in this thread (or at least something like it): >> >> [root@chaos ~]# time file /etc/* >/dev/null >> real 0m1.725s >> user 0m0.993s >> sys 0m0.021s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m1.008s >> user 0m0.990s >> sys 0m0.015s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m1.008s >> user 0m0.967s >> sys 0m0.038s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m1.015s >> user 0m0.998s >> sys 0m0.008s >> >> So, pretty much exactly 1 second every time once the cache is warmed up. Now, let's try it 10 seconds after starting heavy >> disk writing... >> >> [root@chaos ~]# cat /dev/zero > /DELETE_ME & >> (wait for 10 seconds) >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m13.217s >> user 0m1.004s >> sys 0m0.023s >> [root@chaos ~]# time file /etc/* >/dev/null >> >> real 0m24.012s >> user 0m1.020s >> sys 0m0.008s >> >> ... the numbers speak for themselves. FWIW I tried the same on the Linux box: "file" took 0.8 seconds the first time, 0.125s >> subsequent times. While running cat, 0.13-0.21 seconds (0.21 being the first, subsequent runs took 0.13s). The system >> remained completely responsive, which cannot be said for the FreeBSD one! >> >> Any advice? Info below - please ask if you need more! >> >> Regards, >> Thomas >> >> ----------------------------------------------------------------------------- >> >> Basic info: >> >> [root@chaos ~]# uname -a >> FreeBSD chaos.exscape.org 8.0-RC1 FreeBSD 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 >> root@chaos.exscape.org:/usr/obj/usr/ src/sys/DTRACE amd64 >> (KDB/DDB enabled, WITNESS/INVARIANTS *disabled*) >> >> [root@chaos ~]# mount >> tank/root on / (zfs, local, noatime) >> devfs on /dev (devfs, local, multilabel) >> /dev/ad0s1a on /bootdir (ufs, local, soft-updates) >> tank/export on /export (zfs, NFS exported, local, noatime) >> tank/tmp on /tmp (zfs, local, noatime) >> tank/usr on /usr (zfs, local, noatime) >> tank/usr/obj on /usr/obj (zfs, local, noatime) >> tank/usr/ports on /usr/ports (zfs, local, noatime) >> tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) >> tank/usr/src on /usr/src (zfs, local, noatime) >> tank/usr/src_r196905 on /usr/src_r196905 (zfs, local, noatime, read- only) >> tank/var on /var (zfs, local, noatime) >> tank/var/crash on /var/crash (zfs, local, noatime) >> tank/var/log on /var/log (zfs, local, noatime) >> tank/var/tmp on /var/tmp (zfs, local, noatime) >> >> dmesg: >> >> ----------------------------------------------------------------------------- >> Copyright (c) 1992-2009 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 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 >> root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 >> Features = 0x78bfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE >> ,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> >> AMD Features=0xe2500800 >> AMD Features2=0x1 >> real memory = 2147483648 (2048 MB) >> avail memory = 2052362240 (1957 MB) >> ACPI APIC Table: >> 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, 7fef0000 (3) failed >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: at device 0.0 (no driver attached) >> isab0: at device 1.0 on pci0 >> isa0: on isab0 >> pci0: at device 1.1 (no driver attached) >> ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 >> ohci0: [ITHREAD] >> usbus0: on ohci0 >> ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 >> ehci0: [ITHREAD] >> usbus1: EHCI version 1.0 >> usbus1: on ehci0 >> atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on >> pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> ata1: on atapci0 >> ata1: [ITHREAD] >> atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem >> 0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 >> atapci1: [ITHREAD] >> ata2: on atapci1 >> ata2: [ITHREAD] >> ata3: on atapci1 >> ata3: [ITHREAD] >> atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem >> 0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 >> atapci2: [ITHREAD] >> ata4: on atapci2 >> ata4: [ITHREAD] >> ata5: on atapci2 >> ata5: [ITHREAD] >> pcib1: at device 9.0 on pci0 >> pci1: on pcib1 >> vgapci0: mem 0xfcff8000-0xfcffbfff, 0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 >> on pci1 >> xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem 0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 >> miibus0: on xl0 >> xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 >> xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> xl0: Ethernet address: 00:50:da:44:c0:4a >> xl0: [ITHREAD] >> nfe0: port 0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on >> pci0 >> miibus1: on nfe0 >> e1000phy0: PHY 1 on miibus1 >> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto >> nfe0: Ethernet address: 00:13:d3:a2:aa:0f >> nfe0: [FILTER] >> pcib2: at device 11.0 on pci0 >> pci2: on pcib2 >> pcib3: at device 12.0 on pci0 >> pci3: on pcib3 >> pcib4: at device 13.0 on pci0 >> pci4: on pcib4 >> pcib5: at device 14.0 on pci0 >> pci5: on pcib5 >> amdtemp0: on hostb3 >> acpi_tz0: on acpi0 >> atrtc0: port 0x70-0x73 irq 8 on acpi0 >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> uart0: console (115200,n,8,1) >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> cpu0: on acpi0 >> powernow0: on cpu0 >> device_attach: powernow0 attach returned 6 >> orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff, 0xcc000-0xcc7ff 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 >> ZFS NOTICE: system has less than 4GB and prefetch enable is not set... disabling. >> ZFS filesystem version 13 >> ZFS storage pool version 13 >> Timecounter "TSC" frequency 2009269513 Hz quality 800 >> Timecounters tick every 1.000 msec >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 480Mbps High Speed USB v2.0 >> ad0: 76318MB at ata0-master UDMA100 >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ad2: 9768MB at ata1-master UDMA100 >> GEOM: ad2s1: geometry does not match label (255h,63s != 16h,63s). >> Root mount waiting for: usbus1 usbus0 >> uhub0: 10 ports with 10 removable, self powered >> Root mount waiting for: usbus1 >> Root mount waiting for: usbus1 >> Root mount waiting for: usbus1 >> uhub1: 10 ports with 10 removable, self powered >> Trying to mount root from zfs:tank/root >> netsmb_dev: loaded >> >> ----------------------------------------------------------------------------- >> The 80GB disk is used for everything except swap (aka. dump device) for which the 10GB disk is used, exclusively. >> >> loader.conf has nothing of value (just loading a few modules and a vfs.root.mountfrom, plus serial console settings). > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ================================================ 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 rizzo at iet.unipi.it Mon Oct 12 22:28:38 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Oct 12 22:28:48 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: Message-ID: <20091012223529.GA77733@onelab2.iet.unipi.it> On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: > I'm copying this over from the freebsd-performance list, as I'm > looking for a few more opinions - not on the problems *I* am having, > but rather to check whether the problem is universal or not, and if > not, find a possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > Long story short, my version: when the disk is stressed hard enough, > console IO becomes COMPLETELY unbearable. 10+ seconds to switch > between windows in screen(1), running (or even typing) simple > commands, etc. This happens both via SSH and the serial console. hi, this issue (not specific to FreeBSD, and not new -- it has been like this forever) is discussed in some detail here http://www.bsdcan.org/2009/schedule/events/122.en.html The following code (a bit outdated) can help http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html cheers luigi > How to reproduce/test: > 1) time file /etc/* > /dev/null a few times, or something similar that > uses the disk; write down a common/average/median/whatever time. > 2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's > uncompressed, since ZFS with lzjb/gzip enabled will squish this into a > kilobyte-sized file, thus creating virtually *no* IO. > 3) When cat has been running say 10 seconds, re-time command #1 and do > some interactive stuff - run commands, edit files, etc. > > I couldn't actually reproduce the *completely* horrific increase in > latency I posted about below just now (I did update my sources and > rebuild, but I'm pretty sure the delta between ~Sep 29 and Oct 6 had > no major IO changes in 8-STABLE), and the "time file /etc/*" test > "only" jumped by about 3x (compared to 20-60x+ previously), but it's > still bad enough: commands such as "ls" and "w" take 2-3 seconds to > run, as opposed to 0.005s for ls without the added IO... On Linux, the > increase in latency is closer to 4%. A bit better than, oh, 400 > times. ;) > > Oh, and again: this post is not a complaint; this is a post asking for > your experiences. I know I'm not alone in having these issues - I just > want to know if there are a lot of people that *don't* too, and what > could cause them. I can't possibly switch to FreeBSD in production > with this behaviour - and I've been looking forward to doing so for > quite a while now. > > Regards, > Thomas > > PS. > > I'll leave my post to the original discussion below. (I don't usually > top post, but I don't consider this a reply, more of a new post with > an addition below.) > > On Oct 5, 2009, at 10:45 AM, Thomas Backman wrote: > > >Hey everyone, > >I'm having serious trouble with the same thing, and just found this > >thread while looking for the correct place to post. Looks like I > >found it. (I wrote most of the post before finding the thread, so > >some of it will seem a bit odd.) > > > >I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old > >80GB 7200rpm disk. > > > >My problem is that I get completely unacceptable latency on console > >IO (both via SSH and serial console) when the system is performing > >disk IO. The worst case I've noticed yet was when I tried copying a > >core dump from a lzjb compressed ZFS file system to a gzip-9 > >compressed one, to compare the file size/compression ratio. screen > >(1) took at LEAST ten seconds - probably a bit more - I'm not > >exaggerating here - to switch to another window, and an "ls" in an > >empty directory also about 5-10 seconds. > >Doing some silly CPU load with two instances of "yes >/dev/null" (on > >a single core, remember) doesn't change anything, the system remains > >very responsive. "cat /dev/zero > /uncompressed_fs/..." however > >produces the extreme slowdown. (On a gzip-1 FS it doesn't, since the > >file ends up extremely small - a kilobyte or so - even after a > >while, thus performing minimal IO). > > > >I'm thinking about switching to FreeBSD on my beefier "production" > >system (dual-core amd64, 4GB RAM, 4x1TB disks, compared to this one, > >single-core, 2GB RAM, 80GB disk), but unless I feel assured this > >won't happen there as well, I'm not so sure anymore. I can do any > >kind of heavy IO/compilation/whatever on that box, currently running > >Linux, and it's always unnoticable. In this case it's impossible > >*not* to notice that your key input is lagging behind 5-10 > >seconds... I thought multiple times that the box must have panicked. > >I do realize that the hardware isn't the best, especially the disks, > >but this is far worse than it should be! > > > >Here's some of the testing done in this thread (or at least > >something like it): > > > >[root@chaos ~]# time file /etc/* >/dev/null > >real 0m1.725s > >user 0m0.993s > >sys 0m0.021s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m1.008s > >user 0m0.990s > >sys 0m0.015s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m1.008s > >user 0m0.967s > >sys 0m0.038s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m1.015s > >user 0m0.998s > >sys 0m0.008s > > > >So, pretty much exactly 1 second every time once the cache is warmed > >up. Now, let's try it 10 seconds after starting heavy disk writing... > > > >[root@chaos ~]# cat /dev/zero > /DELETE_ME & > >(wait for 10 seconds) > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m13.217s > >user 0m1.004s > >sys 0m0.023s > >[root@chaos ~]# time file /etc/* >/dev/null > > > >real 0m24.012s > >user 0m1.020s > >sys 0m0.008s > > > >... the numbers speak for themselves. FWIW I tried the same on the > >Linux box: "file" took 0.8 seconds the first time, 0.125s subsequent > >times. While running cat, 0.13-0.21 seconds (0.21 being the first, > >subsequent runs took 0.13s). The system remained completely > >responsive, which cannot be said for the FreeBSD one! > > > >Any advice? Info below - please ask if you need more! > > > >Regards, > >Thomas > > > >----------------------------------------------------------------------------- > > > >Basic info: > > > >[root@chaos ~]# uname -a > >FreeBSD chaos.exscape.org 8.0-RC1 FreeBSD 8.0-RC1 #1 r197613M: Tue > >Sep 29 15:04:44 CEST 2009 root@chaos.exscape.org:/usr/obj/usr/ > >src/sys/DTRACE amd64 > >(KDB/DDB enabled, WITNESS/INVARIANTS *disabled*) > > > >[root@chaos ~]# mount > >tank/root on / (zfs, local, noatime) > >devfs on /dev (devfs, local, multilabel) > >/dev/ad0s1a on /bootdir (ufs, local, soft-updates) > >tank/export on /export (zfs, NFS exported, local, noatime) > >tank/tmp on /tmp (zfs, local, noatime) > >tank/usr on /usr (zfs, local, noatime) > >tank/usr/obj on /usr/obj (zfs, local, noatime) > >tank/usr/ports on /usr/ports (zfs, local, noatime) > >tank/usr/ports/distfiles on /usr/ports/distfiles (zfs, local, noatime) > >tank/usr/src on /usr/src (zfs, local, noatime) > >tank/usr/src_r196905 on /usr/src_r196905 (zfs, local, noatime, read- > >only) > >tank/var on /var (zfs, local, noatime) > >tank/var/crash on /var/crash (zfs, local, noatime) > >tank/var/log on /var/log (zfs, local, noatime) > >tank/var/tmp on /var/tmp (zfs, local, noatime) > > > >dmesg: > > > >----------------------------------------------------------------------------- > >Copyright (c) 1992-2009 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 8.0-RC1 #1 r197613M: Tue Sep 29 15:04:44 CEST 2009 > > root@chaos.exscape.org:/usr/obj/usr/src/sys/DTRACE > >Timecounter "i8254" frequency 1193182 Hz quality 0 > >CPU: AMD Athlon(tm) 64 Processor 3200+ (2009.27-MHz K8-class CPU) > > Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 > > > >Features > >= > >0x78bfbff > >< > >FPU > >,VME > >,DE > >,PSE > >,TSC > >,MSR > >,PAE > >,MCE > >,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2> > > AMD Features=0xe2500800 > > AMD Features2=0x1 > >real memory = 2147483648 (2048 MB) > >avail memory = 2052362240 (1957 MB) > >ACPI APIC Table: > >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, 7fef0000 (3) failed > >Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > >acpi_button0: on acpi0 > >pcib0: port 0xcf8-0xcff on acpi0 > >pci0: on pcib0 > >pci0: at device 0.0 (no driver attached) > >isab0: at device 1.0 on pci0 > >isa0: on isab0 > >pci0: at device 1.1 (no driver attached) > >ohci0: mem 0xfe02f000-0xfe02ffff irq > >21 at device 2.0 on pci0 > >ohci0: [ITHREAD] > >usbus0: on ohci0 > >ehci0: mem 0xfe02e000-0xfe02e0ff > >irq 22 at device 2.1 on pci0 > >ehci0: [ITHREAD] > >usbus1: EHCI version 1.0 > >usbus1: on ehci0 > >atapci0: port > >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfb00-0xfb0f at device 6.0 on > >pci0 > >ata0: on atapci0 > >ata0: [ITHREAD] > >ata1: on atapci0 > >ata1: [ITHREAD] > >atapci1: port > >0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf600-0xf60f mem > >0xfe02b000-0xfe02bfff irq 23 at device 7.0 on pci0 > >atapci1: [ITHREAD] > >ata2: on atapci1 > >ata2: [ITHREAD] > >ata3: on atapci1 > >ata3: [ITHREAD] > >atapci2: port > >0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf100-0xf10f mem > >0xfe02a000-0xfe02afff irq 21 at device 8.0 on pci0 > >atapci2: [ITHREAD] > >ata4: on atapci2 > >ata4: [ITHREAD] > >ata5: on atapci2 > >ata5: [ITHREAD] > >pcib1: at device 9.0 on pci0 > >pci1: on pcib1 > >vgapci0: mem 0xfcff8000-0xfcffbfff, > >0xfd000000-0xfd7fffff,0xfc000000-0xfc7fffff irq 17 at device 7.0 on > >pci1 > >xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xdf00-0xdf7f mem > >0xfcfff000-0xfcfff07f irq 18 at device 9.0 on pci1 > >miibus0: on xl0 > >xlphy0: <3c905C 10/100 internal PHY> PHY 24 on miibus0 > >xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >xl0: Ethernet address: 00:50:da:44:c0:4a > >xl0: [ITHREAD] > >nfe0: port > >0xf000-0xf007 mem 0xfe029000-0xfe029fff irq 22 at device 10.0 on pci0 > >miibus1: on nfe0 > >e1000phy0: PHY 1 on miibus1 > >e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > >1000baseT, 1000baseT-FDX, auto > >nfe0: Ethernet address: 00:13:d3:a2:aa:0f > >nfe0: [FILTER] > >pcib2: at device 11.0 on pci0 > >pci2: on pcib2 > >pcib3: at device 12.0 on pci0 > >pci3: on pcib3 > >pcib4: at device 13.0 on pci0 > >pci4: on pcib4 > >pcib5: at device 14.0 on pci0 > >pci5: on pcib5 > >amdtemp0: on hostb3 > >acpi_tz0: on acpi0 > >atrtc0: port 0x70-0x73 irq 8 on acpi0 > >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on > >acpi0 > >uart0: [FILTER] > >uart0: console (115200,n,8,1) > >atkbdc0: port 0x60,0x64 irq 1 on acpi0 > >atkbd0: irq 1 on atkbdc0 > >kbd0 at atkbd0 > >atkbd0: [GIANT-LOCKED] > >atkbd0: [ITHREAD] > >cpu0: on acpi0 > >powernow0: on cpu0 > >device_attach: powernow0 attach returned 6 > >orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff, > >0xcc000-0xcc7ff 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 > >ZFS NOTICE: system has less than 4GB and prefetch enable is not > >set... disabling. > >ZFS filesystem version 13 > >ZFS storage pool version 13 > >Timecounter "TSC" frequency 2009269513 Hz quality 800 > >Timecounters tick every 1.000 msec > >usbus0: 12Mbps Full Speed USB v1.0 > >usbus1: 480Mbps High Speed USB v2.0 > >ad0: 76318MB at ata0-master UDMA100 > >ugen0.1: at usbus0 > >uhub0: on > >usbus0 > >ugen1.1: at usbus1 > >uhub1: on > >usbus1 > >ad2: 9768MB at ata1-master UDMA100 > >GEOM: ad2s1: geometry does not match label (255h,63s != 16h,63s). > >Root mount waiting for: usbus1 usbus0 > >uhub0: 10 ports with 10 removable, self powered > >Root mount waiting for: usbus1 > >Root mount waiting for: usbus1 > >Root mount waiting for: usbus1 > >uhub1: 10 ports with 10 removable, self powered > >Trying to mount root from zfs:tank/root > >netsmb_dev: loaded > > > >----------------------------------------------------------------------------- > >The 80GB disk is used for everything except swap (aka. dump device) > >for which the 10GB disk is used, exclusively. > > > >loader.conf has nothing of value (just loading a few modules and a > >vfs.root.mountfrom, plus serial console settings). > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From dougb at FreeBSD.org Mon Oct 12 23:26:56 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Oct 12 23:27:03 2009 Subject: can't change tty speed and buffer size on 8.0 In-Reply-To: <861vla2ogy.fsf@kopusha.onet> References: <861vla2ogy.fsf@kopusha.onet> Message-ID: <4AD3BB3E.5000809@FreeBSD.org> Mikolaj Golub wrote: > Hi, > > On 8.0-RC1 if you run this command: > > cat > /dev/null > > and try to input a long line, the maximum length you can input is 1920 > characters. > > I have investigated a bit how I can increase a tty buffer as this is a problem > for me (I have logs with very long lines and I used to copy&past a particular > line into input of some script to structure it). I have no useful input on the buffer size issue, but if you wanted to post a bit of your script we may be able to help you find a different solution that doesn't involve cat. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From eugen at kuzbass.ru Tue Oct 13 03:55:09 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Tue Oct 13 03:55:18 2009 Subject: FreeBSD Status Reports April - September, 2009 In-Reply-To: <20091011175428.GA3626@freefall.freebsd.org> References: <20091011175428.GA3626@freefall.freebsd.org> Message-ID: <20091013035504.GA72620@svzserv.kemerovo.su> On Sun, Oct 11, 2009 at 05:54:29PM +0000, Daniel Gerzo wrote: > FreeBSD/ZFS > > Contact: Pawel Dawidek > > We believe that the ZFS file system is now production-ready in FreeBSD > 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer > tagged as experimental. There is also ongoing work in Perforce to bring > the latest ZFS version (v19) to FreeBSD. That's great news. However, my experience says me not place dot-zero relese under business-critical tasks and load. What about status of ZFS in 7.2? Does 7.2 contain the same ZFS code? Eugene Grosbein From to.my.trociny at gmail.com Tue Oct 13 05:32:52 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Oct 13 05:32:58 2009 Subject: can't change tty speed and buffer size on 8.0 In-Reply-To: <4AD3BB3E.5000809@FreeBSD.org> (Doug Barton's message of "Mon\, 12 Oct 2009 16\:26\:54 -0700") References: <861vla2ogy.fsf@kopusha.onet> <4AD3BB3E.5000809@FreeBSD.org> Message-ID: <817huzj1ts.fsf@zhuzha.ua1> On Mon, 12 Oct 2009 16:26:54 -0700 Doug Barton wrote: > Mikolaj Golub wrote: >> Hi, >> >> On 8.0-RC1 if you run this command: >> >> cat > /dev/null >> >> and try to input a long line, the maximum length you can input is 1920 >> characters. >> >> I have investigated a bit how I can increase a tty buffer as this is a problem >> for me (I have logs with very long lines and I used to copy&past a particular >> line into input of some script to structure it). > > I have no useful input on the buffer size issue, but if you wanted to > post a bit of your script we may be able to help you find a different > solution that doesn't involve cat. :) Thanks, but cat was taken as a simple example just to illustrate the problem. The real scripts are usually on perl with 'while(<>)' loop or 'perl -ne' one liners. And sure I could find ways to workaround the problem and actually this is what I did until ed@ provided the solution. -- Mikolaj Golub From serenity at exscape.org Tue Oct 13 07:58:31 2009 From: serenity at exscape.org (Thomas Backman) Date: Tue Oct 13 07:58:38 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <20091012223529.GA77733@onelab2.iet.unipi.it> References: <20091012223529.GA77733@onelab2.iet.unipi.it> Message-ID: <3C775420-9B3D-4971-BDA8-4D2FD507587F@exscape.org> On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote: > On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. > > hi, > this issue (not specific to FreeBSD, and not new -- it has been > like this forever) is discussed in some detail here > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > The following code (a bit outdated) can help > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > cheers > luigi Hmm, how stable would you say the code is? (And/or has there been any progress since March?) I'd prefer something that I feel confident in using in production, and the warning in the README clearly says "stay away!". Regards, Thomas From kris at FreeBSD.org Tue Oct 13 10:13:20 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Tue Oct 13 10:13:27 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <20091012223529.GA77733@onelab2.iet.unipi.it> References: <20091012223529.GA77733@onelab2.iet.unipi.it> Message-ID: <4AD452CB.7040703@FreeBSD.org> Luigi Rizzo wrote: > On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. > > hi, > this issue (not specific to FreeBSD, and not new -- it has been > like this forever) is discussed in some detail here > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > The following code (a bit outdated) can help > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html Are you certain? The reported symptoms sound very unusual. Can you reproduce the problem with the provided instructions yourself? Kris From ivoras at freebsd.org Tue Oct 13 12:14:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 13 12:14:15 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: Message-ID: Thomas Backman wrote: > I'm copying this over from the freebsd-performance list, as I'm looking > for a few more opinions - not on the problems *I* am having, but rather > to check whether the problem is universal or not, and if not, find a > possible common factor. > In other words: I want to hear about your experiences, *good or bad*! > > Here's the original thread (not from the beginning, though): > http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > > > Long story short, my version: when the disk is stressed hard enough, > console IO becomes COMPLETELY unbearable. 10+ seconds to switch between > windows in screen(1), running (or even typing) simple commands, etc. > This happens both via SSH and the serial console. Hmm, this looks familiar - I've noticed it before on the physical (VGA) console and I notice it all the time under VMWare. It sort of looks like disk IO really blocks network IO in this case - I use the VMs over ssh. From rizzo at iet.unipi.it Tue Oct 13 12:17:06 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Tue Oct 13 12:17:14 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <4AD452CB.7040703@FreeBSD.org> References: <20091012223529.GA77733@onelab2.iet.unipi.it> <4AD452CB.7040703@FreeBSD.org> Message-ID: <20091013122357.GA91034@onelab2.iet.unipi.it> On Tue, Oct 13, 2009 at 11:13:31AM +0100, Kris Kennaway wrote: > Luigi Rizzo wrote: > >On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote: > >>I'm copying this over from the freebsd-performance list, as I'm > >>looking for a few more opinions - not on the problems *I* am having, > >>but rather to check whether the problem is universal or not, and if > >>not, find a possible common factor. > >>In other words: I want to hear about your experiences, *good or bad*! > >> > >>Here's the original thread (not from the beginning, though): > >>http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html > >> > >>Long story short, my version: when the disk is stressed hard enough, > >>console IO becomes COMPLETELY unbearable. 10+ seconds to switch > >>between windows in screen(1), running (or even typing) simple > >>commands, etc. This happens both via SSH and the serial console. > > > >hi, > >this issue (not specific to FreeBSD, and not new -- it has been > >like this forever) is discussed in some detail here > > > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > > >The following code (a bit outdated) can help > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > Are you certain? The reported symptoms sound very unusual. Can you > reproduce the problem with the provided instructions yourself? sure -- with ATA/SATA disks, the test in the original post is enough to trigger cwpart of the problem time file /etc/* # this one is fast cat /dev/zero > /same_disk_as_etc/somedir/somefile & sleep enough_to_flush_disk_cache # 10-30 sec time file /etc/* # this one takes forever Now, getting sluggish behaviour on the console might need something more such as dependencies between the program being run and disk activity (logging, etc.) but the 'capture effect' on the disk is completely reproducible. Perhaps SCSI and various RAID incarnations may have a better behaviour or need a larger number of greedy clients to trigger the problem. cheers luigi From svein-listmail at stillbilde.net Tue Oct 13 12:35:42 2009 From: svein-listmail at stillbilde.net (Svein Skogen (listmail account)) Date: Tue Oct 13 12:35:49 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: Message-ID: <4AD4741E.3080108@stillbilde.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ivan Voras wrote: > Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm >> looking for a few more opinions - not on the problems *I* am having, >> but rather to check whether the problem is universal or not, and if >> not, find a possible common factor. >> In other words: I want to hear about your experiences, *good or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch >> between windows in screen(1), running (or even typing) simple >> commands, etc. This happens both via SSH and the serial console. > > Hmm, this looks familiar - I've noticed it before on the physical (VGA) > console and I notice it all the time under VMWare. It sort of looks like > disk IO really blocks network IO in this case - I use the VMs over ssh. I've seen some similar behaviour here with my zfs/istgt backend. I "resolved" the issue by reducing the arc_max so that each disk-io cycle would be "short enough" not to cause the istgt to generate timeouts towards my two vmware hosts. The io-backend for the box is a megaraid 8308 (mfi) card with 8 disks on it. This box is running RELENG_7 now (I tried running it with RELENG_8 but it had a nasty tendency of simply locking up, dragging down both my ESXi hosts with it). //Svein - -- - --------+-------------------+------------------------------- /"\ |Svein Skogen | svein@d80.iso100.no \ / |Solberg ?stli 9 | PGP Key: 0xE5E76831 X |2020 Skedsmokorset | svein@jernhuset.no / \ |Norway | PGP Key: 0xCE96CE13 | | svein@stillbilde.net ascii | | PGP Key: 0x58CD33B6 ribbon |System Admin | svein-listmail@stillbilde.net Campaign|stillbilde.net | PGP Key: 0x22D494A4 +-------------------+------------------------------- |msn messenger: | Mobile Phone: +47 907 03 575 |svein@jernhuset.no | RIPE handle: SS16503-RIPE - --------+-------------------+------------------------------- If you really are in a hurry, mail me at svein-mobile@stillbilde.net This mailbox goes directly to my cellphone and is checked even when I'm not in front of my computer. - ------------------------------------------------------------ Picture Gallery: https://gallery.stillbilde.net/v/svein/ - ------------------------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrUdB4ACgkQODUnwSLUlKQjtwCcDWA7BqDdwQ6w8zo0shNJDpJW shkAoKK1hN5QVrmg59J4lGV3V45ooiPj =nUay -----END PGP SIGNATURE----- From rwatson at FreeBSD.org Tue Oct 13 13:14:16 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Oct 13 13:14:22 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: Message-ID: On Tue, 13 Oct 2009, Ivan Voras wrote: > Thomas Backman wrote: >> I'm copying this over from the freebsd-performance list, as I'm looking for >> a few more opinions - not on the problems *I* am having, but rather to >> check whether the problem is universal or not, and if not, find a possible >> common factor. In other words: I want to hear about your experiences, *good >> or bad*! >> >> Here's the original thread (not from the beginning, though): >> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >> >> Long story short, my version: when the disk is stressed hard enough, >> console IO becomes COMPLETELY unbearable. 10+ seconds to switch between >> windows in screen(1), running (or even typing) simple commands, etc. This >> happens both via SSH and the serial console. > > Hmm, this looks familiar - I've noticed it before on the physical (VGA) > console and I notice it all the time under VMWare. It sort of looks like > disk IO really blocks network IO in this case - I use the VMs over ssh. Real hardware and virtual hardware have vastly different performance properties, so I'd be careful not to assume that the issue described by the original reporter and the issue you're experiencing are the same. In our kernel, low level network protocols will essentially always take precedence over disk I/O activity. So on face value "disk IO really blocks network IO" is highly unlikely. There are two much more likely possibilities: (1) poor VM implementation causes the virtual CPU to be suspended behind synchronous host OS I/O or (2) the network stack is running fine but the interactive user application is getting I/O or locks scheduled behind a bulk process. A useful diagnostic here is to compare the behavior of three kinds of network latency tests: (1) ping from the host OS to the guest OS (2) netperf TCP_RR from the host OS to the guest OS (3) ssh interactive latency If (1) is highly variable during I/O, it's almost certainly a property of the VM technology you're using, and there's nought to be done about it in the guest OS. If (2) but not (1) is highly variable, it may well be a scheduling issue, although under high memory pressure you couldn't rule out paging out of netserver pages/etc causing latency. If (3) but not (1) or (2) is highly variable, it's most likely an I/O scheduling issue, perhaps caused by priority inversion on lockmgr locks on a vnode, disk I/O scheduling leading to starvation, etc. Robert From ivan.anyukov at googlemail.com Tue Oct 13 13:33:58 2009 From: ivan.anyukov at googlemail.com (ivan anyukov) Date: Tue Oct 13 13:34:05 2009 Subject: Spinlock called when not threaded Message-ID: <962bea8e0910130606j20db1b61xc5fb8f8f0f333c28@mail.gmail.com> Hello, while compiling seamonkey 2.0 rc1 (source tbz from seamonkey website) on freebsd 8.0 rc1 I'm getting this error: Fatal error 'Spinlock called when not threaded.' at line 78 in file /usr/src/lib/libthr/thread/thr_spinlock.c (errno = 2) Abort trap (core dumped) gmake[5]: *** [/tmp/seamonkey/comm-central/mozilla/dist/lib/libsoftokn3.chk] Error 134 gmake[5]: Leaving directory `/tmp/seamonkey/comm-central/mozilla/security/nss/cmd/shlibsign' gmake[4]: *** [libs] Error 2 gmake[4]: Leaving directory `/tmp/seamonkey/comm-central/mozilla/security/manager' gmake[3]: *** [libs_tier_toolkit] Error 2 gmake[3]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake[2]: *** [tier_toolkit] Error 2 gmake[2]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake[1]: *** [default] Error 2 gmake[1]: Leaving directory `/tmp/seamonkey/comm-central/mozilla' gmake: *** [default] Error 2 I'm using following configure arguments: --enable-application=suite --disable-ogg --disable-wave Any ideas how to fix this problem? Thanks From ivoras at freebsd.org Tue Oct 13 13:34:18 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 13 13:34:25 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: Message-ID: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> 2009/10/13 Robert Watson : > > On Tue, 13 Oct 2009, Ivan Voras wrote: > >> Thomas Backman wrote: >>> >>> I'm copying this over from the freebsd-performance list, as I'm looking >>> for a few more opinions - not on the problems *I* am having, but rather to >>> check whether the problem is universal or not, and if not, find a possible >>> common factor. In other words: I want to hear about your experiences, *good >>> or bad*! >>> >>> Here's the original thread (not from the beginning, though): >>> http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >>> >>> Long story short, my version: when the disk is stressed hard enough, >>> console IO becomes COMPLETELY unbearable. 10+ seconds to switch between >>> windows in screen(1), running (or even typing) simple commands, etc. This >>> happens both via SSH and the serial console. >> >> Hmm, this looks familiar - I've noticed it before on the physical (VGA) >> console and I notice it all the time under VMWare. It sort of looks like >> disk IO really blocks network IO in this case - I use the VMs over ssh. > > Real hardware and virtual hardware have vastly different performance > properties, so I'd be careful not to assume that the issue described by the > original reporter and the issue you're experiencing are the same. ?In our > kernel, low level network protocols will essentially always take precedence > over disk I/O activity. ?So on face value "disk IO really blocks network IO" > is highly unlikely. Yes, I agree for both reasons and that is why I wasn't complaining until encountering this thread. > There are two much more likely possibilities: (1) poor VM implementation > causes the virtual CPU to be suspended behind synchronous host OS I/O or (2) > the network stack is running fine but the interactive user application is > getting I/O or locks scheduled behind a bulk process. > > A useful diagnostic here is to compare the behavior of three kinds of > network latency tests: > > (1) ping from the host OS to the guest OS > (2) netperf TCP_RR from the host OS to the guest OS > (3) ssh interactive latency > > If (1) is highly variable during I/O, it's almost certainly a property of > the VM technology you're using, and there's nought to be done about it in > the guest OS. Here's an example of a ping session with 0.1s resolution during a few seconds-stall in ssh: 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms note huge packet loss. It looks like it's VM fault or something like it. From rwatson at freebsd.org Tue Oct 13 13:42:35 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Tue Oct 13 13:42:42 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Message-ID: On 13 Oct 2009, at 14:33, Ivan Voras wrote: >> If (1) is highly variable during I/O, it's almost certainly a >> property of >> the VM technology you're using, and there's nought to be done about >> it in >> the guest OS. > > Here's an example of a ping session with 0.1s resolution during a few > seconds-stall in ssh: > > 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms > 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms > 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms > > 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms > 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms > 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms > > note huge packet loss. It looks like it's VM fault or something like > it. It sounds like the VM is failing to execute the guest during certain types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go amiss to confirm that the VM really is suspending the guest at about the same time ICMP latency goes up. However, given the above I think I you can reasonable assume that the 4ms jump you're seeing there is due to global host OS/VM scheduling, and not FreeBSD scheduling. Robert From ivoras at freebsd.org Tue Oct 13 14:26:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 13 14:26:13 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Message-ID: Robert N. M. Watson wrote: > > On 13 Oct 2009, at 14:33, Ivan Voras wrote: > >>> If (1) is highly variable during I/O, it's almost certainly a >>> property of >>> the VM technology you're using, and there's nought to be done about >>> it in >>> the guest OS. >> >> Here's an example of a ping session with 0.1s resolution during a few >> seconds-stall in ssh: >> >> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms >> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms >> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms >> >> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms >> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms >> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms >> >> note huge packet loss. It looks like it's VM fault or something like it. > > It sounds like the VM is failing to execute the guest during certain > types of I/O. A bit of scheduler tracing in the host OS probably > wouldn't go amiss to confirm that the VM really is suspending the guest > at about the same time ICMP latency goes up. However, given the above I > think I you can reasonable assume that the 4ms jump you're seeing there > is due to global host OS/VM scheduling, and not FreeBSD scheduling. Btw. it's not a "4 ms jump" - there are 726 lost packets in between. From ivoras at freebsd.org Tue Oct 13 14:42:04 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 13 14:42:10 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Message-ID: Robert N. M. Watson wrote: > > On 13 Oct 2009, at 14:33, Ivan Voras wrote: > >>> If (1) is highly variable during I/O, it's almost certainly a >>> property of >>> the VM technology you're using, and there's nought to be done about >>> it in >>> the guest OS. >> >> Here's an example of a ping session with 0.1s resolution during a few >> seconds-stall in ssh: >> >> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms >> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms >> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms >> >> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms >> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms >> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms >> >> note huge packet loss. It looks like it's VM fault or something like it. > > It sounds like the VM is failing to execute the guest during certain > types of I/O. A bit of scheduler tracing in the host OS probably > wouldn't go amiss to confirm that the VM really is suspending the guest It's VMWare ESXi underneath, which is *Officially Not Linux* though some ducks may disagree - anyway, I suspect tracing the host in this way is next to impossible without some kind of diamondium-level contract. From jhb at freebsd.org Tue Oct 13 14:42:15 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Oct 13 14:42:45 2009 Subject: 6.2-RELEASE does not use second CPU on pentium D In-Reply-To: <462F15B4.4010201@webmail.sub.ru> References: <462F15B4.4010201@webmail.sub.ru> Message-ID: <200910131040.55465.jhb@freebsd.org> On Wednesday 25 April 2007 4:47:48 am Alex Povolotsky wrote: > Hello! > > I have a Pentium D box, running 6.2-RELEASE. In dmesg, I see CPU#1 > launched, but I never see any process running on it, and mptable shows > > cluster-one# mptable -verbose > > =============================================================================== > > MPTable > > looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009e800 > searching CMOS 'top of mem' @ 0x0009e400 (633K) > searching default 'top of mem' @ 0x0009fc00 (639K) > searching BIOS @ 0x000f0000 > > MP FPS found in BIOS @ physical addr: 0x000fe200 > > ------------------------------------------------------------------------------- > > MP Floating Pointer Structure: > > location: BIOS > physical address: 0x000fe200 > signature: '_MP_' > length: 16 bytes > version: 1.4 > checksum: 0x9f > mode: Virtual Wire > > ------------------------------------------------------------------------------- > > MP Config Table Header: > > physical address: 0x000fe210 > signature: 'PCMP' > base table length: 64 > version: 1.4 > checksum: 0x7f > OEM ID: '' > Product ID: '' > OEM table pointer: 0x00000000 > OEM table size: 0 > entry count: 1 > local APIC address: 0xfee00000 > extended table length: 0 > extended table checksum: 0 > > ------------------------------------------------------------------------------- > > MP Config Base Table Entries: > > -- > Processors: APIC ID Version State Family Model Step > Flags > 0 0x14 BSP, usable 15 6 4 > 0xbfebfbff > > =============================================================================== > > while in dmesg > > Copyright (c) 1992-2007 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.2-RELEASE-p3 #2: Thu Apr 19 00:19:54 MSD 2007 > tarkhil@cluster-one.zinester.com:/usr/obj/usr/src/sys/P4D > WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant > WARNING: MPSAFE network stack disabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2808.41-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 > > Features=0xbfebfbff ,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Features2=0xe49d,> > AMD Features=0x20100000 > AMD Features2=0x1 > real memory = 1046757376 (998 MB) > avail memory = 1015095296 (968 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > > [...] > SMP: AP CPU #1 Launched! > > The kernel is, of course, SMP. > > What can I do, where can I search for solution? > > Second core IS enabled in BIOS > cluster-one# sysctl hw | grep cpu > hw.ncpu: 2 > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: C1 > hw.acpi.cpu.cx_usage: 100.00% > cluster-one# sysctl machdep | grep cpu > machdep.cpu_idle_hlt: 1 > machdep.hlt_cpus: 2 > machdep.hlt_logical_cpus: 0 > machdep.logical_cpus_mask: 2 > > so second CPU is halted, attempt to start it with sysctl does not help > Alex. What does 'sysctl machdep | grep hyper' show? -- John Baldwin From ler at lerctr.org Tue Oct 13 15:16:32 2009 From: ler at lerctr.org (Larry Rosenman) Date: Tue Oct 13 15:16:39 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Message-ID: On Tue, 13 Oct 2009, Ivan Voras wrote: > Robert N. M. Watson wrote: >> >> On 13 Oct 2009, at 14:33, Ivan Voras wrote: >> >>>> If (1) is highly variable during I/O, it's almost certainly a property of >>>> the VM technology you're using, and there's nought to be done about it in >>>> the guest OS. >>> >>> Here's an example of a ping session with 0.1s resolution during a few >>> seconds-stall in ssh: >>> >>> 64 bytes from 161.53.72.188: icmp_seq=1576 ttl=64 time=0.383 ms >>> 64 bytes from 161.53.72.188: icmp_seq=1577 ttl=64 time=0.405 ms >>> 64 bytes from 161.53.72.188: icmp_seq=1578 ttl=64 time=0.360 ms >>> >>> 64 bytes from 161.53.72.188: icmp_seq=2304 ttl=64 time=4.194 ms >>> 64 bytes from 161.53.72.188: icmp_seq=2305 ttl=64 time=0.454 ms >>> 64 bytes from 161.53.72.188: icmp_seq=2306 ttl=64 time=0.376 ms >>> >>> note huge packet loss. It looks like it's VM fault or something like it. >> >> It sounds like the VM is failing to execute the guest during certain types >> of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >> amiss to confirm that the VM really is suspending the guest > > It's VMWare ESXi underneath, which is *Officially Not Linux* though some > ducks may disagree - anyway, I suspect tracing the host in this way is next > to impossible without some kind of diamondium-level contract. > What information do you need? I have a platinum VMWare contract. What version of ESXi? LER > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From fjwcash at gmail.com Tue Oct 13 15:57:07 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Tue Oct 13 15:57:19 2009 Subject: FreeBSD Status Reports April - September, 2009 In-Reply-To: <20091013035504.GA72620@svzserv.kemerovo.su> References: <20091011175428.GA3626@freefall.freebsd.org> <20091013035504.GA72620@svzserv.kemerovo.su> Message-ID: On Mon, Oct 12, 2009 at 8:55 PM, Eugene Grosbein wrote: > On Sun, Oct 11, 2009 at 05:54:29PM +0000, Daniel Gerzo wrote: > > FreeBSD/ZFS > > > > Contact: Pawel Dawidek > > > > We believe that the ZFS file system is now production-ready in FreeBSD > > 8.0. Most (if not all) reported bugs were fixed and ZFS is no longer > > tagged as experimental. There is also ongoing work in Perforce to > bring > > the latest ZFS version (v19) to FreeBSD. > > That's great news. However, my experience says me not place dot-zero > relese under business-critical tasks and load. > > What about status of ZFS in 7.2? Does 7.2 contain the same ZFS code? > > 7.2-RELEASE includes ZFSv6. 7-STABLE (after the release of 7.2) includes ZFSv13. 8.0-RELEASE will include ZFSv13. IOW, 8.0 and 7.3 will have roughly the same ZFS code, although I believe the plan is to leave it marked as "experimental" in 7.x and only remove that warning in 8.x. -- Freddie Cash fjwcash@gmail.com From ivoras at freebsd.org Tue Oct 13 17:57:40 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 13 17:57:51 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> Message-ID: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> 2009/10/13 Larry Rosenman : >>>> note huge packet loss. It looks like it's VM fault or something like it. >>> >>> It sounds like the VM is failing to execute the guest during certain >>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>> amiss to confirm that the VM really is suspending the guest >> >> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >> ducks may disagree - anyway, I suspect tracing the host in this way is next >> to impossible without some kind of diamondium-level contract. >> > What information do you need? ?I have a platinum VMWare contract. > > What version of ESXi? Hi, It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, SATA drives on ICH9. As for what data is needed, it depends on what you can get - from this discussion thread it looks like it would be enough to verify that disk IO doesn't leave VM processes waiting (i.e. that disk IO doesn't interfere with CPU-bound or idle virtual machines). Though now when I think of it - doesn't Linux ATA driver poll IO in some funky way, expecting to get lower latency that way? From ler at lerctr.org Tue Oct 13 18:30:06 2009 From: ler at lerctr.org (Larry Rosenman) Date: Tue Oct 13 18:30:13 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Message-ID: On Tue, 13 Oct 2009, Ivan Voras wrote: > 2009/10/13 Larry Rosenman : > >>>>> note huge packet loss. It looks like it's VM fault or something like it. >>>> >>>> It sounds like the VM is failing to execute the guest during certain >>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>>> amiss to confirm that the VM really is suspending the guest >>> >>> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >>> ducks may disagree - anyway, I suspect tracing the host in this way is next >>> to impossible without some kind of diamondium-level contract. >>> >> What information do you need? I have a platinum VMWare contract. >> >> What version of ESXi? > > Hi, > > It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone > could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, > SATA drives on ICH9. > > As for what data is needed, it depends on what you can get - from this > discussion thread it looks like it would be enough to verify that disk > IO doesn't leave VM processes waiting (i.e. that disk IO doesn't > interfere with CPU-bound or idle virtual machines). Though now when I > think of it - doesn't Linux ATA driver poll IO in some funky way, > expecting to get lower latency that way? > Have you looked at the information available via the performance tab(s) in the client pointing at the ESXi server? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 From grarpamp at gmail.com Tue Oct 13 19:21:18 2009 From: grarpamp at gmail.com (grarpamp) Date: Tue Oct 13 19:21:26 2009 Subject: 8.0 RC1 cd boot problem [btx/bios] Message-ID: Played with this some more. Both the add in cards have their own bios. Their bios can't be disabled. Their raid is not configured so they act as dumb paddles. All bios are up to date. Referring to the below map... - If I swap the position of the cards it won't boot from cd. - If I swap the position of the cards and yank the drives off the 20269, its bios doesn't load and the system boots from cd. - Of course removing the 20269 boots from cd. Booting off the hard drive works fine in all combinations. So I'm pretty sure this is a BTX loader problem involving bios scans? BTX stops right after detecting the ich4 devices... bios cd is cd0 bios drive a: is disk0 bios drive c: is disk1 _ This config boots fine from cd and is now in use: mobo: dell bluford onboard pata: pri m: udma66 s: - sec m: cdr s: dvdrw pci nearest cpu: 1: drive 2: - 3: drive 4: - 5: - 6: - 7: - 8: - pci next nearest cpu: pri m: udma100 s: - sec m: - s: - Prior message-id: d2e731a10909301617l1bad5dcbi7e5681e17fde1a04 From grarpamp at gmail.com Tue Oct 13 19:24:52 2009 From: grarpamp at gmail.com (grarpamp) Date: Tue Oct 13 19:24:59 2009 Subject: 8.0 RC1 cd sysinstall install.cfg fd0 missing Message-ID: I'm not seeing the menu option to load an install.cfg from the floppy anymore. The kernel does detect fdc0 and fd0. Regression? From ivoras at freebsd.org Wed Oct 14 11:16:59 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Oct 14 11:17:10 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Message-ID: Larry Rosenman wrote: > On Tue, 13 Oct 2009, Ivan Voras wrote: >> As for what data is needed, it depends on what you can get - from this >> discussion thread it looks like it would be enough to verify that disk >> IO doesn't leave VM processes waiting (i.e. that disk IO doesn't >> interfere with CPU-bound or idle virtual machines). Though now when I >> think of it - doesn't Linux ATA driver poll IO in some funky way, >> expecting to get lower latency that way? >> > Have you looked at the information available via the performance tab(s) > in the > client pointing at the ESXi server? The 20 second time resolution I get in performance charts isn't nearly enough to diagnose something like this. I've now been running iostat in the virtual console (not ssh) during disk IO and I can't seem to get the characteristic "stutter" / pause behaviour so I think that it's very likely there is too much going on in the VM software to accurately conclude anything. From kris at FreeBSD.org Wed Oct 14 11:25:33 2009 From: kris at FreeBSD.org (Kris Kennaway) Date: Wed Oct 14 11:25:40 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Message-ID: <4AD5B536.5030507@FreeBSD.org> Ivan Voras wrote: > 2009/10/13 Larry Rosenman : > >>>>> note huge packet loss. It looks like it's VM fault or something like it. >>>> It sounds like the VM is failing to execute the guest during certain >>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>>> amiss to confirm that the VM really is suspending the guest >>> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >>> ducks may disagree - anyway, I suspect tracing the host in this way is next >>> to impossible without some kind of diamondium-level contract. >>> >> What information do you need? I have a platinum VMWare contract. >> >> What version of ESXi? > > Hi, > > It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone > could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, > SATA drives on ICH9. I recall others having various weird problems in 3.5 that went away when they upgraded to 4.0. Kris From ivoras at freebsd.org Wed Oct 14 12:26:44 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Oct 14 12:26:51 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <4AD5B536.5030507@FreeBSD.org> References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> <4AD5B536.5030507@FreeBSD.org> Message-ID: Kris Kennaway wrote: > Ivan Voras wrote: > > I recall others having various weird problems in 3.5 that went away when > they upgraded to 4.0. It would be a good idea except that apparently my installation is unupgradeable because of "unsupported boot disk" (a SCSI RAID volume). From rizzo at iet.unipi.it Wed Oct 14 12:51:23 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Wed Oct 14 12:51:31 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <3C775420-9B3D-4971-BDA8-4D2FD507587F@exscape.org> References: <20091012223529.GA77733@onelab2.iet.unipi.it> <3C775420-9B3D-4971-BDA8-4D2FD507587F@exscape.org> Message-ID: <20091014125816.GB42021@onelab2.iet.unipi.it> On Tue, Oct 13, 2009 at 09:58:09AM +0200, Thomas Backman wrote: > > On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote: ... > >hi, > >this issue (not specific to FreeBSD, and not new -- it has been > >like this forever) is discussed in some detail here > > > > http://www.bsdcan.org/2009/schedule/events/122.en.html > > > >The following code (a bit outdated) can help > > > >http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048704.html > > > >cheers > >luigi > Hmm, how stable would you say the code is? (And/or has there been any > progress since March?) > I'd prefer something that I feel confident in using in production, and > the warning in the README clearly says "stay away!". Maybe not for production but if you want to use it on a test box to see if it helps then it is definitely reliable (as long as you don't exercise too much the plugging and unplugging schedulers on a mounted filesystems). I have been using the code for perhaps a couple of months on my desktop machine and no data loss, the only reason it is not loaded now is that it is not loaded by default at boot time. cheers luigi From howard at leadmon.net Wed Oct 14 13:39:44 2009 From: howard at leadmon.net (Howard Leadmon) Date: Wed Oct 14 13:39:51 2009 Subject: Kernel Build Issues with latest cvsup of both a 7.2 system, and a 6.4 system.. In-Reply-To: <002001ca4b2f$8aa3fef0$9febfcd0$@net> References: <002001ca4b2f$8aa3fef0$9febfcd0$@net> Message-ID: <012f01ca4cd3$c8a57ee0$59f07ca0$@net> As a follow-up to my original message, and I thank the couple people that did respond with suggestions. I seem to have found the issue, which is apparently cvsup17.FreeBSD.org and some file inconsistency. I was using cvsup17 as it was a very close site hop/ping wise on my various servers, in fact I even ran the cvsup several times against cvsup17 over a couple different days (this has always been fine in the past). Still neither my 7.2 or 6.4 server would compile a kernel without the errors show in my original message. I then changed my cvsup to point to cvsup8.FreeBSD.org, and of course ran a cvsup against the cvsup8 server which did make a batch of updates. After that I then attempted to build a kernel on both my 7.2 and my 6.4 servers, and bingo it all worked perfectly. So I can only assume from this, something is out of sync and not right with the cvsup17 server, not sure if any others are using cvsup17 and having any issues, but I apparently am. Not sure who this should be reported to, so someone can check on the integrity of cvsup17.. --- Howard Leadmon > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Howard Leadmon > Sent: Monday, October 12, 2009 7:31 AM > To: freebsd-stable@freebsd.org > Subject: Kernel Build Issues with latest cvsup of both a 7.2 system,and a > 6.4 system.. > > Not sure if I am just having a run of bad luck here, but I have a bunch > of > various free BSD boxen on both 6.4-STABLE, and on 7.2-STABLE. I try and > make it a point to do a cvsup and update the machines every month or so to > keep things current and any updates/patches installed. I decided a > couple > days ago, it was again time to do this again. > > > > So I ran cvsup on the machines, and set out to rebuild, first doing a > 'make > buildworld', then a 'make installworld', and finally a 'mergemaster' on > the > servers. That all went well, then time for a kernel update, so I > performed > a 'make buildkernel KERNCONF=GENERIC' to create the new kernel, which is > where things went bad. > > > > > > On my 6.4-STABLE x86 machine, I received the following: > > > > cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. > -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/dev/em > -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -ffreestanding -Werror /usr/src/sys/kern/kern_event.c > > /usr/src/sys/kern/kern_event.c:408: warning: no previous prototype for > 'knote_fork' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > Stop in /usr/src. > > > > > > > > > > On my 7.2-STABLE amd64 machine, I received the following: > > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=nocona > -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb - > D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 > --param inline-unit-growth=100 --param large-function-growth=1000 > -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > /usr/src/sys/amd64/amd64/genassym.c > > In file included from /usr/src/sys/vm/pmap.h:82, > > from /usr/src/sys/amd64/amd64/genassym.c:61: > > ./machine/pmap.h:323: error: expected declaration specifiers or '...' > before > 'vm_memattr_t' > > *** Error code 1 > > > > Stop in /usr/obj/usr/src/sys/GENERIC. > > *** Error code 1 > > > > Stop in /usr/src. > > *** Error code 1 > > > > > > > > > > I have rebuilt the above servers many times over, and I must say it's > worked > great, so was really thrown that not only one version on a server would > blow > up, but two different versions of the OS would pop at the same moment. > Needless to say I haven't tried to rebuild any of my other 6.4 or 7.2 > boxen > yet, as I want to get the above two attempts sorted out first. > > > > Has something changed I am forgetting to do that is not biting me in the > backside, or has some bug been introduced I am now aware of currently > causing issues?? If anyone can help sort this out, or if you need > additional info, please let me know.. > > > > > > > > --- > > Howard Leadmon > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From michal at sharescope.co.uk Wed Oct 14 15:01:26 2009 From: michal at sharescope.co.uk (Michal) Date: Wed Oct 14 15:01:36 2009 Subject: UVNC Repeater Message-ID: <4AD5E3CF.2060902@sharescope.co.uk> Good afternoon, I am having a few niggly problems setting up a VNC repeater on my FreeBSD box and I am finding it very hard to find any information anywhere. I freshly installed FreeBSD on the box today and updated ports and system. I then make && make build && make install /usr/ports/net/repeater/ and made a few customer modifications to the uvncrepeater.ini script, I supplied it bellow. I also set-up the UVNC single click app, it was very simple while I testing, also supplied bellow. When I run the listener on my PC, I see these errors in the repeater.log file (please note IP address's have been changed, but they are public) UltraVnc Wed Oct 14 15:29:30 2009 > acceptConnection(): connection accepted ok from ip: 1.2.3.4 UltraVnc Wed Oct 14 15:29:31 2009 > findServerList(): server not found (code = 7001) So when my tester outside my network starts the single click and tries to connect, it just fails. Has anyone seen this, or point me in the right direction?? Many Thanks Chris helpdesk.txt (for singleclick.exe) ----------------------------------- [TITLE] UltraVnc SC [HOST] Internet support -connect 1.2.3.10:5500 -noregistry -id 7001 uvncrepeater.ini ---------------- [general] ;Ports viewerport = 5900 serverport = 5500 ;Repeater's own ip address in case your server happens to have several ;ip addresses (for example, one physical machine running several virtual ;machines each having their own ip address) ;default (0.0.0.0 = INADDR_ANY = uses all addresses) is the same that ;older repeater versions (before 0.12) did --> listens to all interfaces ;Notice ! This IS NOT address of server or viewer, but repeater itself ! ownipaddress = 1.2.3.10 ;How many sessions can we have active at the same time ? ;values can be [1...1000] ;Notice: If you actually *have* computer(s) capable ;of 1000 simultaneous sessions, you are probably a *very big company*, ;so please invite me to visit and admire your server(s) ;-) maxsessions = 100 ;If program is started as root (to allow binding ports below 1024), ;it changes to this user after ports have been bound in startup ;You need to create a suitable (normal, non-privileged) user/group and change name here runasuser = uvncrep ;Allowed modes for repeater ;0=None, 1=Only Mode 1, 2=Only Mode 2, 3=Both modes ;Notice: If you set allowedmodes = 0, repeater will run without listening to any ports, ;it will just wait for your ctlr + c ;-) allowedmodes = 3 ;Logging level ;0 = Very little (fatal() messages, relaying done) ;1 = 0 + Important messages + Connections opened / closed ;2 = 1 + Ini values + exceptions in logic flow ;3 = 2 + Everything else (very detailed and exhaustive logging == BIG log files) logginglevel = 2 [mode1] ;0=All allowedmode1serverport = 0 ;0=Allow connections to all server addressess, ;1=Require that server address (or range of addresses) is listed in ;srvListAllow[0]...srvListAllow[SERVERS_LIST_SIZE-1] requirelistedserver = 0 ;List of allowed server addresses / ranges ;Ranges can be defined by setting corresponding number to 0, e.g. 10.0.0.0 allows all addresses 10.x.x.x ;Address 255.255.255.255 (default) does not allow any connections ;Address 0.0.0.0 allows all connections ;Only IP addresses can be used here, not DNS names ;There can be max SERVERS_LIST_SIZE (default 50) srvListAllow lines srvListAllow0 = 10.0.0.0 ;Allow network 10.x.x.x srvListAllow1 = 192.168.0.0 ;Allow network 192.168.x.x ;List of denied server addresses / ranges ;Ranges can be defined by setting corresponding number to 0, e.g. 10.0.0.0 denies all addresses 10.x.x.x ;Address 255.255.255.255 (default) does not deny any connections ;Address 0.0.0.0 denies all connections ;Only IP addresses can be used here, not DNS names ;If addresss/range is both allowed and denied, it will be denied (deny is stronger) ;There can be max SERVERS_LIST_SIZE (default 50) srvListDeny lines srvListDeny0 = 10.0.0.0 ;Deny network 10.x.x.x srvListDeny1 = 192.168.2.22 ;Deny host 192.168.2.22 [mode2] ;0=Allow all IDs, 1=Allow only IDs listed in idList[0]...idList[ID_LIST_SIZE-1] requirelistedid = 0 ;List of allowed ID: numbers ;Value 0 means "this authenticates negatively" ;If value is not listed, default is 0 ;Values should be between [1...LONG_MAX-1] ;There can be max ID_LIST_SIZE (default 100) idList lines idlist0 = 7000 idlist1 = 7001 idlist2 = 7002 idlist3 = 7003 idlist4 = 7004 idlist5 = 7005 idlist6 = 7006 idlist7 = 7007 idlist8 = 7008 idlist9 = 7009 [eventinterface] ;Use event interface (for reporting repeater events to outside world) ? ;This could be used to send email, write webpage, update database etc. ;Possible values: true/false useeventinterface = false ;Hostname/Ip address + port of event listener we send events to eventlistenerhost = localhost eventlistenerport = 2002 ;Make HTTP/1.0 GET request to event listener (instead of normal write dump) ;Somebody wanted this for making a PHP event listener usehttp = false From grarpamp at gmail.com Wed Oct 14 22:02:34 2009 From: grarpamp at gmail.com (grarpamp) Date: Wed Oct 14 22:02:41 2009 Subject: ZFS repeatable reboot 8.0-RC1 Message-ID: Hi. I'm running i386 on i386, single P4 cpu, 1GiB RAM. SiI 3114 -> SATA [single disk] -> GELI [AES-128] -> ZFS [sha256] Straight RELENG_8 as of cvsup Oct 12 14:49:00 aka 8.0-RC1 plus. ZFS pool is at v13, ZFS fs is at v3. Hardware seems stable. The only modification to config defaults is: loader.conf.local: vfs.zfs.arc_max=100663296 After boot -v, geli, zpool import, xf86, browser, etc my mem looks like: Mem: 33M Active, 22M Inact, 105M Wired, 676K Cache, 37M Buf, 827M Free When putting load on ZFS it usually grows to about: Mem: 95M Active, 22M Inact, 302M Wired, 468K Cache, 37M Buf, 569M Free Ls -l in one of the dirs takes 10min plus and I get: PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11 root 171 ki31 0K 8K RUN 21:24 47.27% idle 1092 user 76 0 77328K 76116K zio->i 3:25 37.89% ls 802 root -8 - 0K 8K geli:w 1:42 8.98% g_eli[0] ad6 9 root -8 - 0K 128K arc_re 0:23 4.88% {arc_reclaim_thre} I did not watch these during rm. I have 1 parent dir holding 4 subdirs. The file count in each subdir is respectively: 256363, 254086, 256017, 178054 Two thirds of files are about 14KiB in size, not many are more than a few MiB nor less than 1KiB though a third are 1 byte. I issue rm -r and after maybe 30 seconds the machine reboots. No syslog, panic or console messages. Dmesg from the prior boot is still present in ram to prove kernel didn't emit any message. memtest86 passes. There are maybe 10 seconds of complete GUI hangup before the reboot occurs. I also see it when make release'ing. Usually during what I _think_ is distributeworld or rolling up the tarballs under /R. This is a big repeatable problem. How can I debug or fix it? Can someone else create some mega sized dirs as above and replicate? Thanks. From grarpamp at gmail.com Wed Oct 14 22:55:55 2009 From: grarpamp at gmail.com (grarpamp) Date: Wed Oct 14 22:56:07 2009 Subject: ZFS repeatable reboot 8.0-RC1 Message-ID: Happened again :) So some more notes... Watched it this time, it jumped from about 29xMiB straight to 366MiB, then hung and rebooted itself. The first zpool import after reboot takes about a minute more than the usual ten seconds to import. And uses up to maybe 125MiB instead of maybe 40MiB. Could be ZFS fscking itself? Second and further manual reboots are all normal speed and mem use. The fs is fine, I can do all sorts of normal ops on it. Even rm -r , ^C after a few seconds, and repeat ad nauseum until the tree is removed. Only continuous rm -r reboots. I have 1 more GiB RAM I can put in. Sorry to break threads, I'm not on list. From jhell at DataIX.net Thu Oct 15 01:15:14 2009 From: jhell at DataIX.net (jhell) Date: Thu Oct 15 01:15:22 2009 Subject: ZFS repeatable reboot 8.0-RC1 In-Reply-To: References: Message-ID: On Wed, 14 Oct 2009 18:55, grarpamp@ wrote: > Happened again :) So some more notes... > > Watched it this time, it jumped from about 29xMiB straight to 366MiB, > then hung and rebooted itself. > > The first zpool import after reboot takes about a minute more than > the usual ten seconds to import. And uses up to maybe 125MiB instead > of maybe 40MiB. Could be ZFS fscking itself? Second and further > manual reboots are all normal speed and mem use. > > The fs is fine, I can do all sorts of normal ops on it. Even rm -r > , ^C after a few seconds, and repeat ad nauseum until the > tree is removed. Only continuous rm -r reboots. > > I have 1 more GiB RAM I can put in. > > Sorry to break threads, I'm not on list. > Your machine is starving! what you can do to improve upon performance of the pool is add a separate disk to the machine in which you can configure your ZIL(ZFS Intent Log) and a Cache. Those two things can improve greatly upon performance and reduce eating up so much ram that your system starts to starve itself. Add that other 1G of RAM if you have it just sitting around then put it to good use it will certainly help. The disk that your doing your remove operation on ? is that being done on a ZFS GELI ? PS: You can use thumb drives as caches and intent logs but beware I have had them stop and disappear in my system to only appear again on reboot. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From grarpamp at gmail.com Thu Oct 15 06:47:02 2009 From: grarpamp at gmail.com (grarpamp) Date: Thu Oct 15 06:47:15 2009 Subject: ZFS repeatable reboot 8.0-RC1 In-Reply-To: References: Message-ID: > Your machine is starving! How can this be, there is over 500MiB free ram at all times? I'm running literally no userland apps other than X and xterms when it reboots. I think I may be hitting some limit with this 366MiB and reboot bit. How can I tell what my kernel limits are on this platform? Don't I have to limit ARC to ( kern + kern headroom + ARC = kern addressablility limit ) or something like that? Anything I should use for that besides sysctl -a and vmstat -z? I thought I looked at my wired history before using zfs and set arc_max to 96MiB so wired wouldn't even get close 512. > what you can do to improve upon performance of the pool Performance is not the problem. Yes, it's dog slow, but it's usable, sortof :) The issue is that it's rebooting spontaneously. No OS should do that. Though unlike a userland process that the kernel kills when out of ram, I don't know how the kernel would recover when its own processes bloat up. I expect slow performance with this setup. Especially if I'm blowing out some cache somewhere. Take UFS2 with dirhash for example. If the size of the directory inode is much bigger than vfs.ufs.dirhash_maxmem, it just slows down to spindle speed ... not reboot, no big deal. > is add a separate disk to the machine in which you can configure > your ZIL(ZFS Intent Log) and a Cache. Those two things can ... > reduce eating up so much ram that your system starts to starve > itself. Reduce ram?, how so? I already have a ZIL in the main pool by default, presumably using just as much ram as a separate one would, so no need for a separate log. Similarly for cache, which is in core in the default case. They just help speed if on 'faster than spindles' devices. I suppose I could as easily set vfs.zfs.zil_disable=0 as a test if it wouldn't risk loss of the entire pool. > Add that other 1G of RAM Isn't that a game of whack a mole? What happens when I rm a dir with 1M files in it? Add more ram? 2M files? ... > The disk that your doing your remove operation on ? is that being > done on a ZFS GELI ? As mentioned, yes. > PS: You can use thumb drives as caches and intent logs I would presume their bit error rate is higher than platters. There was a time when SSD's meant RAM drives, not flash drives. # vmstat -m | egrep -i 'requests|zfs|zil|zio|arc|solaris|geom|eli' Type InUse MemUse HighUse Requests Size(s) GEOM 208 27K - 1708 16,32,64,128,512,1024,2048,4096 solaris 145673 135033K - 3413390 16,32,64,128,256,512,1024,2048,4096 eli data 8 5K - 23628 32,256,512,1024,2048,4096 # vmstat -z | egrep -i 'requests|zfs|zil|zio|arc|solaris|geom|eli' ITEM SIZE LIMIT USED FREE REQUESTS FAILURES zio_cache: 596, 0, 0, 4596, 489861, 0 arc_buf_hdr_t: 136, 0, 9367, 29, 15769, 0 arc_buf_t: 40, 0, 2128, 264, 19641, 0 zil_lwb_cache: 176, 0, 3, 85, 488, 0 zfs_znode_cache: 232, 0, 19298, 473, 62000, 0 # sysctl -a vfs.zfs kstat.zfs vfs.zfs.arc_meta_limit: 25165824 vfs.zfs.arc_meta_used: 39459076 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 16777216 vfs.zfs.arc_max: 100663296 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 1 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 kstat.zfs.misc.arcstats.hits: 102514 kstat.zfs.misc.arcstats.misses: 12662 kstat.zfs.misc.arcstats.demand_data_hits: 8150 kstat.zfs.misc.arcstats.demand_data_misses: 741 kstat.zfs.misc.arcstats.demand_metadata_hits: 94364 kstat.zfs.misc.arcstats.demand_metadata_misses: 11921 kstat.zfs.misc.arcstats.prefetch_data_hits: 0 kstat.zfs.misc.arcstats.prefetch_data_misses: 0 kstat.zfs.misc.arcstats.prefetch_metadata_hits: 0 kstat.zfs.misc.arcstats.prefetch_metadata_misses: 0 kstat.zfs.misc.arcstats.mru_hits: 49617 kstat.zfs.misc.arcstats.mru_ghost_hits: 2511 kstat.zfs.misc.arcstats.mfu_hits: 52897 kstat.zfs.misc.arcstats.mfu_ghost_hits: 1193 kstat.zfs.misc.arcstats.deleted: 1429 kstat.zfs.misc.arcstats.recycle_miss: 5314 kstat.zfs.misc.arcstats.mutex_miss: 0 kstat.zfs.misc.arcstats.evict_skip: 3645 kstat.zfs.misc.arcstats.hash_elements: 9362 kstat.zfs.misc.arcstats.hash_elements_max: 9363 kstat.zfs.misc.arcstats.hash_collisions: 8135 kstat.zfs.misc.arcstats.hash_chains: 2042 kstat.zfs.misc.arcstats.hash_chain_max: 5 kstat.zfs.misc.arcstats.p: 57449472 kstat.zfs.misc.arcstats.c: 100663296 kstat.zfs.misc.arcstats.c_min: 16777216 kstat.zfs.misc.arcstats.c_max: 100663296 kstat.zfs.misc.arcstats.size: 99728132 kstat.zfs.misc.arcstats.hdr_size: 1273504 kstat.zfs.misc.arcstats.l2_hits: 0 kstat.zfs.misc.arcstats.l2_misses: 0 kstat.zfs.misc.arcstats.l2_feeds: 0 kstat.zfs.misc.arcstats.l2_rw_clash: 0 kstat.zfs.misc.arcstats.l2_writes_sent: 0 kstat.zfs.misc.arcstats.l2_writes_done: 0 kstat.zfs.misc.arcstats.l2_writes_error: 0 kstat.zfs.misc.arcstats.l2_writes_hdr_miss: 0 kstat.zfs.misc.arcstats.l2_evict_lock_retry: 0 kstat.zfs.misc.arcstats.l2_evict_reading: 0 kstat.zfs.misc.arcstats.l2_free_on_write: 0 kstat.zfs.misc.arcstats.l2_abort_lowmem: 0 kstat.zfs.misc.arcstats.l2_cksum_bad: 0 kstat.zfs.misc.arcstats.l2_io_error: 0 kstat.zfs.misc.arcstats.l2_size: 0 kstat.zfs.misc.arcstats.l2_hdr_size: 0 kstat.zfs.misc.arcstats.memory_throttle_count: 0 kstat.zfs.misc.vdev_cache_stats.delegations: 961 kstat.zfs.misc.vdev_cache_stats.hits: 8593 kstat.zfs.misc.vdev_cache_stats.misses: 3377 From giovanni.trematerra at gmail.com Thu Oct 15 09:29:56 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Thu Oct 15 09:30:04 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) Message-ID: <4e6cba830910150229h7f9c4ccbp2f679ca344a7faed@mail.gmail.com> On Oct 12, 2009, at 10:45 AM, Thomas Backman wrote: >Here's the original thread (not from the beginning, though): >http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html >Long story short, my version: when the disk is stressed hard enough, >console IO becomes COMPLETELY unbearable. 10+ seconds to switch >between windows in screen(1), running (or even typing) simple >commands, etc. This happens both via SSH and the serial console. >How to reproduce/test: >1) time file /etc/* > /dev/null a few times, or something similar that >uses the disk; write down a common/average/median/whatever time. >2) cat /dev/zero > /uncompressed_fs/filename # please make *sure* it's >uncompressed, since ZFS with lzjb/gzip enabled will squish this into a >kilobyte-sized file, thus creating virtually *no* IO. >3) When cat has been running say 10 seconds, re-time command #1 and do >some interactive stuff - run commands, edit files, etc. Hi Thomas, I'm trying to reproduce the issue though I don't have any ZFS filesystems. I'm not using SSH neither serial console. My system is quite responsive. I'm using a VmWare system with 2 cpu support, 1MB RAM with FreeBSD 7.2-RELEASE. I don't know if the issue is related to ZFS or your hardware configuration but can you report what top(1) say during the slowdown? -- Giovanni Trematerra From pluknet at gmail.com Thu Oct 15 09:51:22 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 15 09:51:30 2009 Subject: mfi(4) endless loop kernel output on attach Message-ID: Hi. This is 7.2-R. Seen on IBM x3650M2. During the boot I get those endless looping kernel messages while on mfi(4) attach phase. It's getting more odd since 7.2 booted and worked fine on exactly this server model months ago (on different box though).. Any hints? mfi0: 5428 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5429 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5430 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5431 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5432 (boot + 64s/0x0008/info) - Battery Present mfi0: 5433 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5434 (boot + 64s/0x0020/info) - Board Revision mfi0: 5435 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5436 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5437 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5438 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5439 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5440 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5441 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5442 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5443 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5444 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5445 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5446 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5447 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5448 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5449 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5450 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5451 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5452 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5453 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5454 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5455 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5456 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5457 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5458 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5459 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5460 (308390540s/0x0020/info) - Time established as 10/09/09 8:02:20; (256 seconds since power on) mfi0: 5461 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5462 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5463 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5464 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5465 (boot + 64s/0x0008/info) - Battery Present mfi0: 5466 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5467 (boot + 64s/0x0020/info) - Board Revision mfi0: 5468 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5469 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5470 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5471 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5472 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5473 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5474 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5475 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5476 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5477 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5478 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5479 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5480 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5481 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5482 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5483 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5484 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5485 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5486 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5487 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5488 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5489 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5490 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5491 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5492 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5493 (308391152s/0x0020/info) - Time established as 10/09/09 8:12:32; (256 seconds since power on) mfi0: 5494 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5495 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5496 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5497 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5498 (boot + 64s/0x0008/info) - Battery Present mfi0: 5499 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5500 (boot + 64s/0x0020/info) - Board Revision mfi0: 5501 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5502 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5503 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5504 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5505 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5506 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5507 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5508 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5509 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5510 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5511 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5512 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5513 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5514 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5515 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5516 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5517 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5518 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5519 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5520 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5521 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5522 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5523 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5524 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5525 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5526 (308391765s/0x0020/info) - Time established as 10/09/09 8:22:45; (257 seconds since power on) mfi0: 5527 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5528 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5529 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5530 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5531 (boot + 64s/0x0008/info) - Battery Present mfi0: 5532 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5533 (boot + 64s/0x0020/info) - Board Revision mfi0: 5534 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5535 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5536 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5537 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5538 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5539 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5540 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5541 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5542 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5543 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5544 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5545 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5546 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5547 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5548 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5549 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5550 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5551 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5552 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5553 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5554 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5555 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5556 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5557 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5558 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5559 (308392379s/0x0020/info) - Time established as 10/09/09 8:32:59; (258 seconds since power on) mfi0: 5560 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5561 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5562 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 006 0/1000/0364/1014) mfi0: 5563 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5564 (boot + 64s/0x0008/info) - Battery Present mfi0: 5565 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5566 (boot + 64s/0x0020/info) - Board Revision mfi0: 5567 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5568 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5569 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5570 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5571 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5572 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5573 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5574 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5575 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5576 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5577 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5578 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5579 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5580 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5581 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5582 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5583 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5584 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5585 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5586 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5587 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5588 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5589 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5590 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5591 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5592 (308392995s/0x0020/info) - Time established as 10/09/09 8:43:15; (259 seconds since power on) mfi0: 5593 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5594 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5595 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5596 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5597 (boot + 64s/0x0008/info) - Battery Present mfi0: 5598 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5599 (boot + 64s/0x0020/info) - Board Revision mfi0: 5600 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5601 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5602 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5603 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5604 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5605 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5606 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5607 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5608 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5609 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5610 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5611 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5612 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5613 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5614 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5615 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5616 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5617 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5618 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5619 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5620 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5621 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5622 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5623 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5624 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5625 (308393612s/0x0020/info) - Time established as 10/09/09 8:53:32; (261 seconds since power on) mfi0: 5626 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5627 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5628 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5629 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5630 (boot + 64s/0x0008/info) - Battery Present mfi0: 5631 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5632 (boot + 64s/0x0020/info) - Board Revision mfi0: 5633 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5634 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 5635 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 5636 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 5637 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 5638 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 5639 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 5640 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 5641 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 5642 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 5643 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 5644 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 5645 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 5646 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 5647 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 5648 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 5649 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 5650 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 5651 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 5652 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 5653 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 5654 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 5655 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 5656 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 5657 (boot + 144s/0x0008/info) - Battery temperature is normal mfi0: 5658 (308394231s/0x0020/info) - Time established as 10/09/09 9:03:51; (262 seconds since power on) mfi0: 5659 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5660 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5661 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 5662 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 5663 (boot + 64s/0x0008/info) - Battery Present mfi0: 5664 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 5665 (boot + 64s/0x0020/info) - Board Revision mfi0: 5666 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 5667 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 So on. -- wbr, pluknet From ivoras at freebsd.org Thu Oct 15 09:55:27 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Oct 15 09:55:35 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Message-ID: Ivan Voras wrote: > 2009/10/13 Larry Rosenman : > >>>>> note huge packet loss. It looks like it's VM fault or something like it. >>>> It sounds like the VM is failing to execute the guest during certain >>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go >>>> amiss to confirm that the VM really is suspending the guest >>> It's VMWare ESXi underneath, which is *Officially Not Linux* though some >>> ducks may disagree - anyway, I suspect tracing the host in this way is next >>> to impossible without some kind of diamondium-level contract. >>> >> What information do you need? I have a platinum VMWare contract. >> >> What version of ESXi? > > Hi, > > It is ESXi 3.5 - but if the problem is really in ESXi I presume anyone > could reproduce it. My setup is nothing special - Xeon 5405, 8 GB RAM, > SATA drives on ICH9. > > As for what data is needed, it depends on what you can get - from this > discussion thread it looks like it would be enough to verify that disk > IO doesn't leave VM processes waiting (i.e. that disk IO doesn't > interfere with CPU-bound or idle virtual machines). Though now when I > think of it - doesn't Linux ATA driver poll IO in some funky way, > expecting to get lower latency that way? Another data point - the OS in the VM in question hanged today sometime after 5 AM in the following way: * console nonresponsive (also to ctrl-alt-del) * ssh login nonresponsive (timeout) * ping works (!) Judging by the last seen timestamp, the machine should have been in the process of receiving rsync backups - so IO-bound. From pluknet at gmail.com Thu Oct 15 10:38:11 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 15 10:38:19 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: References: Message-ID: 2009/10/15 pluknet : > Hi. > > This is 7.2-R. Seen on IBM x3650M2. > > During the boot I get those endless looping kernel messages while on > mfi(4) attach phase. > It's getting more odd since 7.2 booted and worked fine on exactly this > server model > months ago (on different box though).. Any hints? > After the looked endless loop the kernel eventually finished the mfi(4) initialization and continued its booting. Is it expected to do so long initialization? Almost at the end of kernel boot / near to multiuser start it panicked with: panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia Though that's offtopic here. >From last part of dmesg: mfi0: 29365 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/0364/1014) mfi0: 29366 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 mfi0: 29367 (boot + 64s/0x0008/info) - Battery Present mfi0: 29368 (boot + 64s/0x0020/info) - BBU FRU is mfi0: 29369 (boot + 64s/0x0020/info) - Board Revision mfi0: 29370 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) mfi0: 29371 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: enclPd=ffff, scsiType=0, portMap=00, sasAddr=5000c500138d46b5,0000000000000000 mfi0: 29372 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 mfi0: 29373 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) mfi0: 29374 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: enclPd=ffff, scsiType=0, portMap=01, sasAddr=5000c500138d842d,0000000000000000 mfi0: 29375 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 mfi0: 29376 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) mfi0: 29377 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: enclPd=ffff, scsiType=0, portMap=04, sasAddr=5000c500138d7d75,0000000000000000 mfi0: 29378 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 mfi0: 29379 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) mfi0: 29380 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: enclPd=ffff, scsiType=0, portMap=05, sasAddr=5000c500138d7835,0000000000000000 mfi0: 29381 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 mfi0: 29382 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) mfi0: 29383 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: enclPd=ffff, scsiType=0, portMap=02, sasAddr=5000c500138d60b5,0000000000000000 mfi0: 29384 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 mfi0: 29385 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) mfi0: 29386 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: enclPd=ffff, scsiType=0, portMap=03, sasAddr=5000c500138d7bdd,0000000000000000 mfi0: 29387 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 mfi0: 29388 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) mfi0: 29389 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: enclPd=ffff, scsiType=0, portMap=06, sasAddr=5000c500138d6839,0000000000000000 mfi0: 29390 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 mfi0: 29391 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) mfi0: 29392 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: enclPd=ffff, scsiType=0, portMap=07, sasAddr=5000c500138d5e8d,0000000000000000 mfi0: 29393 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 mfi0: 29394 (boot + 144s/0x0008/info) - Battery temperature is normal ioapic0: routing intpin 16 (PCI IRQ 16) to vector 52 mfi0: [MPSAFE] mfi0: [ITHREAD] pcib8: irq 16 at device 28.4 on pci0 pcib8: domain 0 pcib8: secondary bus 6 pcib8: subordinate bus 10 pcib8: I/O decode 0xf000-0xfff pcib8: memory decode 0x97000000-0x978fffff pcib8: prefetched decode 0x96000000-0x96ffffff pci6: on pcib8 pci6: domain=0, physical bus=6 found-> vendor=0x101b, dev=0x0452, revid=0x01 domain=0, bus=6, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0047, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, 64 bit pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 pcib8: slot 0 INTA is routed to irq 16 pcib9: irq 16 at device 0.0 on pci6 pcib9: domain 0 pcib9: secondary bus 7 pcib9: subordinate bus 7 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0x97000000-0x978fffff pcib9: prefetched decode 0x96000000-0x96ffffff pci7: on pcib9 pci7: domain=0, physical bus=7 found-> vendor=0x102b, dev=0x0530, revid=0x00 domain=0, bus=7, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0x96000000, size 24, enabled pcib9: requested memory range 0x96000000-0x96ffffff: good pcib8: requested memory range 0x96000000-0x96ffffff: good map[14]: type Memory, range 32, base 0x97800000, size 14, enabled pcib9: requested memory range 0x97800000-0x97803fff: good pcib8: requested memory range 0x97800000-0x97803fff: good map[18]: type Memory, range 32, base 0x97000000, size 23, enabled pcib9: requested memory range 0x97000000-0x977fffff: good pcib8: requested memory range 0x97000000-0x977fffff: good pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 16 pcib8: slot 0 INTA is routed to irq 16 pcib9: slot 0 INTA is routed to irq 16 vgapci0: mem 0x96000000-0x96ffffff,0x97800000-0x97803fff,0x97000000-0x977fffff irq 16 at device 0.0 on pci7 uhci2: port 0x2060-0x207f irq 17 at device 29.0 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb3: on uhci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered uhci3: port 0x2040-0x205f irq 18 at device 29.1 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0x2020-0x203f irq 19 at device 29.2 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered ehci1: mem 0x97a21000-0x97a213ff irq 17 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0x97a21000 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb6: EHCI version 1.0 usb6: companion controllers, 2 ports each: usb3 usb4 usb5 usb6: on ehci1 usb6: USB revision 2.0 uhub6: on usb6 uhub6: 6 ports with 6 removable, self powered usb6: handing over full speed device on port 2 to usb3 uhub6: port 2, device disappeared after reset pcib10: at device 30.0 on pci0 pcib10: domain 0 pcib10: secondary bus 41 pcib10: subordinate bus 45 pcib10: I/O decode 0x0-0x0 pcib10: no prefetched decode pcib10: Subtractively decoded bridge. pci41: on pcib10 pci41: domain=0, physical bus=41 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x20f0-0x20ff,0x20e0-0x20ef irq 16 at device 31.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x20f0 atapci0: Reserved 0x10 bytes for rid 0x24 type 4 at 0x20e0 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0xc ioapic0: routing intpin 14 (ISA IRQ 14) to vector 53 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=7f ostat1=7f ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat1=0x7f err=0xff lsb=0xff msb=0xff ata1: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to vector 54 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0x2108-0x210f,0x2124-0x2127,0x2100-0x2107,0x2120-0x2123,0x20d0-0x20df,0x20c0-0x20cf irq 21 at device 31.5 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x20d0 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 55 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x10 bytes for rid 0x24 type 4 at 0x20c0 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2108 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x2124 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2100 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2120 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 57 sio1: [FILTER] cpu0: on acpi0 cpu0: switching to generic Cx mode est0: on cpu0 est0: Invalid id16 (set, cur) = (16, 17) est0: Invalid freq 2128, ignored. est0: Invalid id16 (set, cur) = (15, 17) est0: Invalid freq 1995, ignored. est0: Invalid id16 (set, cur) = (14, 17) est0: Invalid freq 1862, ignored. est0: Invalid id16 (set, cur) = (13, 17) est0: Invalid freq 1729, ignored. est0: Invalid id16 (set, cur) = (12, 17) est0: Invalid freq 1596, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (16, 17) est1: Invalid freq 2128, ignored. est1: Invalid id16 (set, cur) = (15, 17) est1: Invalid freq 1995, ignored. est1: Invalid id16 (set, cur) = (14, 17) est1: Invalid freq 1862, ignored. est1: Invalid id16 (set, cur) = (13, 17) est1: Invalid freq 1729, ignored. est1: Invalid id16 (set, cur) = (12, 17) est1: Invalid freq 1596, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (16, 17) est2: Invalid freq 2128, ignored. est2: Invalid id16 (set, cur) = (15, 17) est2: Invalid freq 1995, ignored. est2: Invalid id16 (set, cur) = (14, 17) est2: Invalid freq 1862, ignored. est2: Invalid id16 (set, cur) = (13, 17) est2: Invalid freq 1729, ignored. est2: Invalid id16 (set, cur) = (12, 17) est2: Invalid freq 1596, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (16, 17) est3: Invalid freq 2128, ignored. est3: Invalid id16 (set, cur) = (15, 17) est3: Invalid freq 1995, ignored. est3: Invalid id16 (set, cur) = (14, 17) est3: Invalid freq 1862, ignored. est3: Invalid id16 (set, cur) = (13, 17) est3: Invalid freq 1729, ignored. est3: Invalid id16 (set, cur) = (12, 17) est3: Invalid freq 1596, ignored. p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 est4: Invalid id16 (set, cur) = (16, 17) est4: Invalid freq 2128, ignored. est4: Invalid id16 (set, cur) = (15, 17) est4: Invalid freq 1995, ignored. est4: Invalid id16 (set, cur) = (14, 17) est4: Invalid freq 1862, ignored. est4: Invalid id16 (set, cur) = (13, 17) est4: Invalid freq 1729, ignored. est4: Invalid id16 (set, cur) = (12, 17) est4: Invalid freq 1596, ignored. p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est5: Invalid id16 (set, cur) = (16, 17) est5: Invalid freq 2128, ignored. est5: Invalid id16 (set, cur) = (15, 17) est5: Invalid freq 1995, ignored. est5: Invalid id16 (set, cur) = (14, 17) est5: Invalid freq 1862, ignored. est5: Invalid id16 (set, cur) = (13, 17) est5: Invalid freq 1729, ignored. est5: Invalid id16 (set, cur) = (12, 17) est5: Invalid freq 1596, ignored. p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 est6: Invalid id16 (set, cur) = (16, 17) est6: Invalid freq 2128, ignored. est6: Invalid id16 (set, cur) = (15, 17) est6: Invalid freq 1995, ignored. est6: Invalid id16 (set, cur) = (14, 17) est6: Invalid freq 1862, ignored. est6: Invalid id16 (set, cur) = (13, 17) est6: Invalid freq 1729, ignored. est6: Invalid id16 (set, cur) = (12, 17) est6: Invalid freq 1596, ignored. p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est7: Invalid id16 (set, cur) = (16, 17) est7: Invalid freq 2128, ignored. est7: Invalid id16 (set, cur) = (15, 17) est7: Invalid freq 1995, ignored. est7: Invalid id16 (set, cur) = (14, 17) est7: Invalid freq 1862, ignored. est7: Invalid id16 (set, cur) = (13, 17) est7: Invalid freq 1729, ignored. est7: Invalid id16 (set, cur) = (12, 17) est7: Invalid freq 1596, ignored. p4tcc7: on cpu7 cpu8: on acpi0 est8: on cpu8 est8: Invalid id16 (set, cur) = (16, 17) est8: Invalid freq 2128, ignored. est8: Invalid id16 (set, cur) = (15, 17) est8: Invalid freq 1995, ignored. est8: Invalid id16 (set, cur) = (14, 17) est8: Invalid freq 1862, ignored. est8: Invalid id16 (set, cur) = (13, 17) est8: Invalid freq 1729, ignored. est8: Invalid id16 (set, cur) = (12, 17) est8: Invalid freq 1596, ignored. p4tcc8: on cpu8 cpu9: on acpi0 est9: on cpu9 est9: Invalid id16 (set, cur) = (16, 17) est9: Invalid freq 2128, ignored. est9: Invalid id16 (set, cur) = (15, 17) est9: Invalid freq 1995, ignored. est9: Invalid id16 (set, cur) = (14, 17) est9: Invalid freq 1862, ignored. est9: Invalid id16 (set, cur) = (13, 17) est9: Invalid freq 1729, ignored. est9: Invalid id16 (set, cur) = (12, 17) est9: Invalid freq 1596, ignored. p4tcc9: on cpu9 cpu10: on acpi0 est10: on cpu10 est10: Invalid id16 (set, cur) = (16, 17) est10: Invalid freq 2128, ignored. est10: Invalid id16 (set, cur) = (15, 17) est10: Invalid freq 1995, ignored. est10: Invalid id16 (set, cur) = (14, 17) est10: Invalid freq 1862, ignored. est10: Invalid id16 (set, cur) = (13, 17) est10: Invalid freq 1729, ignored. est10: Invalid id16 (set, cur) = (12, 17) est10: Invalid freq 1596, ignored. p4tcc10: on cpu10 cpu11: on acpi0 est11: on cpu11 est11: Invalid id16 (set, cur) = (16, 17) est11: Invalid freq 2128, ignored. est11: Invalid id16 (set, cur) = (15, 17) est11: Invalid freq 1995, ignored. est11: Invalid id16 (set, cur) = (14, 17) est11: Invalid freq 1862, ignored. est11: Invalid id16 (set, cur) = (13, 17) est11: Invalid freq 1729, ignored. est11: Invalid id16 (set, cur) = (12, 17) est11: Invalid freq 1596, ignored. p4tcc11: on cpu11 cpu12: on acpi0 est12: on cpu12 est12: Invalid id16 (set, cur) = (16, 17) est12: Invalid freq 2128, ignored. est12: Invalid id16 (set, cur) = (15, 17) est12: Invalid freq 1995, ignored. est12: Invalid id16 (set, cur) = (14, 17) est12: Invalid freq 1862, ignored. est12: Invalid id16 (set, cur) = (13, 17) est12: Invalid freq 1729, ignored. est12: Invalid id16 (set, cur) = (12, 17) est12: Invalid freq 1596, ignored. p4tcc12: on cpu12 cpu13: on acpi0 est13: on cpu13 est13: Invalid id16 (set, cur) = (16, 17) est13: Invalid freq 2128, ignored. est13: Invalid id16 (set, cur) = (15, 17) est13: Invalid freq 1995, ignored. est13: Invalid id16 (set, cur) = (14, 17) est13: Invalid freq 1862, ignored. est13: Invalid id16 (set, cur) = (13, 17) est13: Invalid freq 1729, ignored. est13: Invalid id16 (set, cur) = (12, 17) est13: Invalid freq 1596, ignored. p4tcc13: on cpu13 cpu14: on acpi0 est14: on cpu14 est14: Invalid id16 (set, cur) = (16, 17) est14: Invalid freq 2128, ignored. est14: Invalid id16 (set, cur) = (15, 17) est14: Invalid freq 1995, ignored. est14: Invalid id16 (set, cur) = (14, 17) est14: Invalid freq 1862, ignored. est14: Invalid id16 (set, cur) = (13, 17) est14: Invalid freq 1729, ignored. est14: Invalid id16 (set, cur) = (12, 17) est14: Invalid freq 1596, ignored. p4tcc14: on cpu14 cpu15: on acpi0 est15: on cpu15 est15: Invalid id16 (set, cur) = (16, 17) est15: Invalid freq 2128, ignored. est15: Invalid id16 (set, cur) = (15, 17) est15: Invalid freq 1995, ignored. est15: Invalid id16 (set, cur) = (14, 17) est15: Invalid freq 1862, ignored. est15: Invalid id16 (set, cur) = (13, 17) est15: Invalid freq 1729, ignored. est15: Invalid id16 (set, cur) = (12, 17) est15: Invalid freq 1596, ignored. p4tcc15: on cpu15 ex_isa_identify() sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff,0xca800-0xd8fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 004d atkbd: keyboard ID 0xffffffff (1) kbdc: RESET_KBD return code:ffffffff kbdc: RESET_KBD return code:ffffffff kbdc: RESET_KBD return code:ffffffff kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 atkbd: failed to reset the keyboard. kbd0 at atkbd0 kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:004d kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:ffffffff kbdc: RESET_AUX return code:ffffffff kbdc: RESET_AUX return code:ffffffff kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices cdce0: on uhub3 cdce0: faking MAC address cdce0: WARNING: using obsoleted IFF_NEEDSGIANT flag cdce0: bpf attached cdce0: Ethernet address: 2a:00:00:00:00:00 Device configuration finished. Reducing kern.maxvnodes 382450 -> 100000 procfs registered lapic: Divisor 2, Frequency 66669284 hz Timecounter "TSC" frequency 2266755720 Hz quality -100 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding enabled, default to accept, logging limited to 500 packets/entry by default lo0: bpf attached hptrr: no controller detected. bce0: link state changed to DOWN bce1: link state changed to DOWN ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0xc ata0: reinit done .. Expensive timeout(9) function: 0xffffffff80267220(0xffffff000414c000) 1.400657904 s ata0: reiniting channel .. ata0: reset tp1 mask=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=00 stat1=00 devices=0xc ata0: reinit done .. ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: CDRW drive at ata0 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc mfi0: 29395 (308927984s/0x0020/info) - Time established as 10/15/09 13:19:44; (210 seconds since power on) ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #4 Launched! cpu4 AP: ID: 0x04000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #10 Launched! cpu10 AP: ID: 0x12000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #13 Launched! cpu13 AP: ID: 0x15000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x05000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #7 Launched! cpu7 AP: ID: 0x07000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #15 Launched! cpu15 AP: ID: 0x17000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #14 Launched! cpu14 AP: ID: 0x16000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x06000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #9 Launched! cpu9 AP: ID: 0x11000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #12 Launched! cpu12 AP: ID: 0x14000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #8 Launched! cpu8 AP: ID: 0x10000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 SMP: AP CPU #11 Launched! cpu11 AP: ID: 0x13000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 3 to local APIC 2 ioapic0: Assigning ISA IRQ 4 to local APIC 4 ioapic0: Assigning ISA IRQ 9 to local APIC 6 ioapic0: Assigning ISA IRQ 14 to local APIC 16 ioapic0: Assigning ISA IRQ 15 to local APIC 18 ioapic0: Assigning PCI IRQ 16 to local APIC 20 ioapic0: Assigning PCI IRQ 17 to local APIC 22 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 2 ioapic0: Assigning PCI IRQ 21 to local APIC 4 msi: Assigning MSI IRQ 256 to local APIC 6 msi: Assigning MSI IRQ 257 to local APIC 16 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from nfs:194.190.130.130:/home/jails/freebsd7.2 panic: invalid ife->ifm_data (0xa) in mii_phy_setmedia cpuid = 15 KDB: enter: panic [thread pid 1 tid 100001 ] Stopped at kdb_enter_why+0x3d: movq $0,0x649838(%rip) > mfi0: 5428 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5429 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5430 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5431 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5432 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5433 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5434 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5435 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5436 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5437 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5438 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5439 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5440 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5441 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5442 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5443 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5444 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5445 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5446 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5447 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5448 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5449 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5450 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5451 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5452 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5453 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5454 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5455 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5456 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5457 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5458 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5459 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5460 (308390540s/0x0020/info) - Time established as 10/09/09 > 8:02:20; (256 seconds since power on) > mfi0: 5461 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5462 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5463 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5464 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5465 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5466 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5467 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5468 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5469 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5470 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5471 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5472 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5473 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5474 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5475 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5476 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5477 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5478 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5479 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5480 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5481 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5482 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5483 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5484 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5485 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5486 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5487 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5488 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5489 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5490 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5491 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5492 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5493 (308391152s/0x0020/info) - Time established as 10/09/09 > 8:12:32; (256 seconds since power on) > mfi0: 5494 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5495 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5496 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5497 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5498 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5499 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5500 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5501 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5502 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5503 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5504 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5505 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5506 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5507 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5508 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5509 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5510 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5511 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5512 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5513 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5514 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5515 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5516 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5517 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5518 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5519 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5520 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5521 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5522 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5523 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5524 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5525 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5526 (308391765s/0x0020/info) - Time established as 10/09/09 > 8:22:45; (257 seconds since power on) > mfi0: 5527 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5528 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5529 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5530 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5531 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5532 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5533 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5534 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5535 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5536 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5537 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5538 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5539 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5540 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5541 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5542 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5543 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5544 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5545 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5546 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5547 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5548 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5549 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5550 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5551 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5552 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5553 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5554 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5555 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5556 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5557 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5558 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5559 (308392379s/0x0020/info) - Time established as 10/09/09 > 8:32:59; (258 seconds since power on) > mfi0: 5560 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5561 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5562 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 006 > 0/1000/0364/1014) > mfi0: 5563 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5564 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5565 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5566 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5567 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5568 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5569 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5570 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5571 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5572 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5573 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5574 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5575 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5576 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5577 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5578 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5579 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5580 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5581 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5582 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5583 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5584 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5585 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5586 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5587 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5588 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5589 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5590 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5591 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5592 (308392995s/0x0020/info) - Time established as 10/09/09 > 8:43:15; (259 seconds since power on) > mfi0: 5593 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5594 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5595 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5596 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5597 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5598 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5599 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5600 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5601 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5602 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5603 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5604 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5605 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5606 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5607 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5608 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5609 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5610 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5611 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5612 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5613 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5614 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5615 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5616 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5617 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5618 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5619 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5620 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5621 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5622 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5623 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5624 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5625 (308393612s/0x0020/info) - Time established as 10/09/09 > 8:53:32; (261 seconds since power on) > mfi0: 5626 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5627 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5628 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5629 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5630 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5631 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5632 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5633 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5634 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > mfi0: 5635 (boot + 89s/0x0002/info) - PD 08(e0xff/s8) FRU is 42D0422 > mfi0: 5636 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) > mfi0: 5637 (boot + 89s/0x0002/info) - Inserted: PD 09(e0xff/s9) Info: > enclPd=ffff, scsiType=0, portMap=01, > sasAddr=5000c500138d842d,0000000000000000 > mfi0: 5638 (boot + 89s/0x0002/info) - PD 09(e0xff/s9) FRU is 42D0422 > mfi0: 5639 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) > mfi0: 5640 (boot + 89s/0x0002/info) - Inserted: PD 0a(e0xff/s10) Info: > enclPd=ffff, scsiType=0, portMap=04, > sasAddr=5000c500138d7d75,0000000000000000 > mfi0: 5641 (boot + 89s/0x0002/info) - PD 0a(e0xff/s10) FRU is 42D0422 > mfi0: 5642 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) > mfi0: 5643 (boot + 89s/0x0002/info) - Inserted: PD 0b(e0xff/s11) Info: > enclPd=ffff, scsiType=0, portMap=05, > sasAddr=5000c500138d7835,0000000000000000 > mfi0: 5644 (boot + 89s/0x0002/info) - PD 0b(e0xff/s11) FRU is 42D0422 > mfi0: 5645 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) > mfi0: 5646 (boot + 89s/0x0002/info) - Inserted: PD 0c(e0xff/s12) Info: > enclPd=ffff, scsiType=0, portMap=02, > sasAddr=5000c500138d60b5,0000000000000000 > mfi0: 5647 (boot + 89s/0x0002/info) - PD 0c(e0xff/s12) FRU is 42D0422 > mfi0: 5648 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) > mfi0: 5649 (boot + 89s/0x0002/info) - Inserted: PD 0d(e0xff/s13) Info: > enclPd=ffff, scsiType=0, portMap=03, > sasAddr=5000c500138d7bdd,0000000000000000 > mfi0: 5650 (boot + 89s/0x0002/info) - PD 0d(e0xff/s13) FRU is 42D0422 > mfi0: 5651 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) > mfi0: 5652 (boot + 89s/0x0002/info) - Inserted: PD 0e(e0xff/s14) Info: > enclPd=ffff, scsiType=0, portMap=06, > sasAddr=5000c500138d6839,0000000000000000 > mfi0: 5653 (boot + 89s/0x0002/info) - PD 0e(e0xff/s14) FRU is 42D0422 > mfi0: 5654 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) > mfi0: 5655 (boot + 89s/0x0002/info) - Inserted: PD 0f(e0xff/s15) Info: > enclPd=ffff, scsiType=0, portMap=07, > sasAddr=5000c500138d5e8d,0000000000000000 > mfi0: 5656 (boot + 89s/0x0002/info) - PD 0f(e0xff/s15) FRU is 42D0422 > mfi0: 5657 (boot + 144s/0x0008/info) - Battery temperature is normal > mfi0: 5658 (308394231s/0x0020/info) - Time established as 10/09/09 > 9:03:51; (262 seconds since power on) > mfi0: 5659 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5660 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5661 (boot + 3s/0x0020/info) - Firmware initialization started > (PCI ID 0060/1000/0364/1014) > mfi0: 5662 (boot + 3s/0x0020/info) - Firmware version 1.40.62-0691 > mfi0: 5663 (boot + 64s/0x0008/info) - Battery Present > mfi0: 5664 (boot + 64s/0x0020/info) - BBU FRU is > mfi0: 5665 (boot + 64s/0x0020/info) - Board Revision > mfi0: 5666 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) > mfi0: 5667 (boot + 89s/0x0002/info) - Inserted: PD 08(e0xff/s8) Info: > enclPd=ffff, scsiType=0, portMap=00, > sasAddr=5000c500138d46b5,0000000000000000 > > So on. > -- wbr, pluknet From borjam at sarenet.es Thu Oct 15 11:34:36 2009 From: borjam at sarenet.es (Borja Marcos) Date: Thu Oct 15 11:34:43 2009 Subject: 8.0-RC1/amd64, ZFS panic Message-ID: <0854E733-5DCB-4850-9644-2949893C6E65@sarenet.es> panic: mtx_lock() of destroyed mutex @ /usr/src/sys/kern/vfs_subrc:2467 cpuid = 1 I was doing a zfs destroy -r of a dataset. The dataset has had many snapshot receives done. # uname -a FreeBSD 8.0-RC1 FreeBSD 8.0-RC1 #1: Tue Oct 13 14:11:08 CEST 2009 root@:/usr/obj/usr/src/sys/DEBUG amd64 (kernel config: added WITNESS, etc to have debugging information, doing some ZFS send/receive tests) It's a VMWare virtual machine, and I've frozen it. Borja. From pluknet at gmail.com Thu Oct 15 12:46:19 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 15 12:46:29 2009 Subject: [bce] panic on boot in bce(4) on 7.2: invalid ife->ifm_data (0xa) In-Reply-To: <4A7A3A4D.2080105@delphij.net> References: <4A7A3A4D.2080105@delphij.net> Message-ID: 2009/8/6 Xin LI : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > pluknet wrote: >> Hi. >> >> I got the following kernel panic on boot: >> invalid ife->ifm_data (0xa) in mii_phy_setmedia >> >> This is near /sys/dev/mii/mii_physubr.c:126 >> ? ? ? ? KASSERT(ife->ifm_data >=0 && ife->ifm_data < MII_NMEDIA, >> ? ? ? ? ? ? ("invalid ife->ifm_data (0x%x) in mii_phy_setmedia", >> ? ? ? ? ? ? ife->ifm_data)); > > I believe that this was because the (un)merged brgphy bits. ?Is it > possible for you to use 7.2-STABLE instead? ?Otherwise you will need a > patched kernel: > > ? ? ? ?http://people.freebsd.org/~delphij/misc/bce-5709phy.diff > > Please make sure that you have a full kernel build. > I see no panic with this patch on 7.2. Thanks. -- wbr, pluknet From pluknet at gmail.com Thu Oct 15 12:53:08 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 15 12:53:26 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: References: Message-ID: >> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? >> > > After the looked endless loop the kernel eventually finished > the mfi(4) initialization and continued its booting. > Is it expected to do so long initialization? > Replying to myself. As someone pointed out in the private email, that's due to the large log contained on non-volatile memory in the controller. MegaCli -AdpEventLog -GetEventLogInfo -aAll cleaned up 'em all. Sorry for noise. -- wbr, pluknet From jhb at freebsd.org Thu Oct 15 13:32:48 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 15 13:33:00 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: References: Message-ID: <200910150853.49850.jhb@freebsd.org> On Thursday 15 October 2009 5:51:19 am pluknet wrote: > Hi. > > This is 7.2-R. Seen on IBM x3650M2. > > During the boot I get those endless looping kernel messages while on > mfi(4) attach phase. > It's getting more odd since 7.2 booted and worked fine on exactly this > server model > months ago (on different box though).. Any hints? We just had some boxes die like this (but spewing a different loop of messages on boot related to continuously scheduling patrol reads and consistency checks that finished immediately) at work. We fixed them by swapping out the controller. We might try stick them in a different box and reflashing them using mfiutil(8) to see if it's some sort of corrupted state that flashing the adapter fixes. In your case it looks lik the firmware keeps crashing and restarting. -- John Baldwin From pluknet at gmail.com Thu Oct 15 15:16:25 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 15 15:16:31 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: <200910150853.49850.jhb@freebsd.org> References: <200910150853.49850.jhb@freebsd.org> Message-ID: 2009/10/15 John Baldwin : > On Thursday 15 October 2009 5:51:19 am pluknet wrote: >> Hi. >> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? > > We just had some boxes die like this (but spewing a different loop of messages > on boot related to continuously scheduling patrol reads and consistency > checks that finished immediately) at work. ?We fixed them by swapping out the > controller. ?We might try stick them in a different box and reflashing them > using mfiutil(8) to see if it's some sort of corrupted state that flashing > the adapter fixes. > > In your case it looks lik the firmware keeps crashing and restarting. Probably it is. Though clearing logs helped me. -- wbr, pluknet From netgeek at bgp4.net Thu Oct 15 18:18:35 2009 From: netgeek at bgp4.net (Janet Sullivan) Date: Thu Oct 15 18:18:42 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: <43727653B60248EEA363AA3A886DC42C@multiplay.co.uk> References: <43727653B60248EEA363AA3A886DC42C@multiplay.co.uk> Message-ID: <4AD75F94.20000@bgp4.net> Steven Hartland wrote: > We're not running 8 yet but we do have a 7.x box which its under fairly > high IO load doing mrtg graphs which has similar behaviour. When typing > a command on ssh it will freeze for may seconds. We have a FreeBSD 7.2 cacti box running on a dell 1950 that has the same problems. RRDs are disk i/o hogs, and when disk i/o shoots up, the box becomes non-responsive for a few seconds. From jhb at freebsd.org Thu Oct 15 19:18:27 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 15 19:18:39 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: References: <200910150853.49850.jhb@freebsd.org> Message-ID: <200910151135.04382.jhb@freebsd.org> On Thursday 15 October 2009 11:16:23 am pluknet wrote: > 2009/10/15 John Baldwin : > > On Thursday 15 October 2009 5:51:19 am pluknet wrote: > >> Hi. > >> > >> This is 7.2-R. Seen on IBM x3650M2. > >> > >> During the boot I get those endless looping kernel messages while on > >> mfi(4) attach phase. > >> It's getting more odd since 7.2 booted and worked fine on exactly this > >> server model > >> months ago (on different box though).. Any hints? > > > > We just had some boxes die like this (but spewing a different loop of messages > > on boot related to continuously scheduling patrol reads and consistency > > checks that finished immediately) at work. ?We fixed them by swapping out the > > controller. ?We might try stick them in a different box and reflashing them > > using mfiutil(8) to see if it's some sort of corrupted state that flashing > > the adapter fixes. > > > > In your case it looks lik the firmware keeps crashing and restarting. > > Probably it is. Though clearing logs helped me. Well, from your other e-mail it seems it was just dumping lots of old logs since the previous clean shutdown. (I almost mentioned that case in my original e-mail). In that case you can simply let it finish walking through all the logs or you can set loader tunables to raise the minimum class of message so it skips all the lower priority info messages when walking the log. -- John Baldwin From grarpamp at gmail.com Thu Oct 15 22:15:20 2009 From: grarpamp at gmail.com (grarpamp) Date: Thu Oct 15 22:15:26 2009 Subject: ZFS repeatable reboot 8.0-RC1 In-Reply-To: <43425103-6DAE-43FD-82E7-9B71BAB862B0@gothic.net.au> References: <43425103-6DAE-43FD-82E7-9B71BAB862B0@gothic.net.au> Message-ID: Note: I tried setting vfs.zfs.arc_max=32M and zfs mem usage still grew past its limits and the machine rebooted. Forwarding a note I received... """"" >> Your machine is starving! > How can this be, there is over 500MiB free ram at all times? I'm sysctl vm.kmem_size_max I've got the following in my kernel configuration file options KVA_PAGES=512 and in /boot/loader.conf vm.kmem_size_max=1536M vm.kmem_size=1536M On two machines with 2G of RAM....both 8.0-RC1/i386 the ZFS tuning guide gives a better idea of how to play with things like that http://wiki.freebsd.org/ZFSTuningGuide """"" Some questions... Am I reading correctly that vm.kmem_size is how much ram the kernel initially allocates for itself on boot? And that vm.kmem_size_min and vm.kmem_size_max are the range that vm.kmem_size is allowed to float naturally within at runtime? Is KVA_PAGES the hard max space the kern is allowed/capable of addressing/using at runtime? Such that I could set kmem_size_max to the KVA_PAGES limit and then vm.kmem_size will grow into it as needed? With the caveat of course that with the below defaults and hardware, if I just bumped vm.kmem_size_max to 1GiB [as per KVA_PAGES limit] I'd have to add maybe another 1GiB ram so that this new vm.kmem_size_max kernel reservation wouldn't conflict with userland memory needs when vm.kmem_size grows to it? And KVA_PAGES is typically say 1/3 of installed ram? If vm.kmem_size starts out being under vm.kmem_size_max, can user apps use the unused space (vm.kmem_size_max - vm.kmem_size) until vm.kmem_size grows to vm.kmem_size_max and the kernel kills them off? Or can user apps only use (ram = user apps + [KVA_PAGES hard limit and/or vm.kmem_size_max])? What is the idea behind setting vm.kmem_size = vm.kmem_size_max? Should not just vm.kmem_size_max be set and allow vm.kmem_size [unset] to grow up to vm.kmem_size_max instead of allocating it all at boot with vm.kmem_size? Maybe someone can wikify these answers? I think I need to find more to read and then test one by one to see what changes. With untuned defaults and 1GiB ram I have: #define KVA_PAGES 256 # gives 1GiB kern address space vm.kmem_size_max: 335544320 # auto calculated by the kernel at boot? Less than KVA_PAGES? vm.kmem_size_min: 0 vm.kmem_size: 335544320 # amount in use at runtime? I'm still figuring out how to find and add all the kernel memory. Here's zfs: vfs.zfs.arc_meta_limit: 52428800 vfs.zfs.arc_meta_used: 56241732 # greater than meta_limit? vfs.zfs.arc_min: 26214400 vfs.zfs.arc_max: 209715200 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 kstat.zfs.misc.arcstats.p: 20589785 # was 104857600 on boot kstat.zfs.misc.arcstats.c: 128292242 # was 209715200 on boot kstat.zfs.misc.arcstats.c_min: 26214400 kstat.zfs.misc.arcstats.c_max: 209715200 loader(8) vm.kmem_size Sets the size of kernel memory (bytes). This overrides the value determined when the kernel was compiled. Modifies VM_KMEM_SIZE. vm.kmem_size_min vm.kmem_size_max Sets the minimum and maximum (respectively) amount of ker- nel memory that will be automatically allocated by the ker- nel. These override the values determined when the kernel was compiled. Modifies VM_KMEM_SIZE_MIN and VM_KMEM_SIZE_MAX. sys/i386/include/pmap.h /* * Size of Kernel address space. This is the number of page table pages * (4MB each) to use for the kernel. 256 pages == 1 Gigabyte. * This **MUST** be a multiple of 4 (eg: 252, 256, 260, etc). * For PAE, the page table page unit size is 2MB. This means that 512 pages * is 1 Gigabyte. Double everything. It must be a multiple of 8 for PAE. */ #ifndef KVA_PAGES #ifdef PAE #define KVA_PAGES 512 #else #define KVA_PAGES 256 #endif #endif sys/i386/conf/NOTES # Change the size of the kernel virtual address space. Due to # constraints in loader(8) on i386, this must be a multiple of 4. # 256 = 1 GB of kernel address space. Increasing this also causes # a reduction of the address space in user processes. 512 splits # the 4GB cpu address space in half (2GB user, 2GB kernel). For PAE # kernels, the value will need to be double non-PAE. A value of 1024 # for PAE kernels is necessary to split the address space in half. # This will likely need to be increased to handle memory sizes >4GB. # PAE kernels default to a value of 512. # options KVA_PAGES=260 From tinderbox at freebsd.org Fri Oct 16 15:57:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 16 15:57:30 2009 Subject: [releng_8 tinderbox] failure on powerpc/powerpc Message-ID: <200910161557.n9GFvMY7094686@freebsd-current.sentex.ca> TB --- 2009-10-16 07:46:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 07:46:09 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2009-10-16 07:46:09 - cleaning the object tree TB --- 2009-10-16 07:46:25 - cvsupping the source tree TB --- 2009-10-16 07:46:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2009-10-16 15:57:17 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2009-10-16 15:57:17 - ERROR: unable to cvsup the source tree TB --- 2009-10-16 15:57:17 - 0.83 user 7.98 system 29467.89 real http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From tinderbox at freebsd.org Fri Oct 16 16:18:22 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 16 16:18:35 2009 Subject: [releng_8 tinderbox] failure on sparc64/sparc64 Message-ID: <200910161618.n9GGIL6F094756@freebsd-current.sentex.ca> TB --- 2009-10-16 08:08:09 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-10-16 08:08:09 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2009-10-16 08:08:09 - cleaning the object tree TB --- 2009-10-16 08:08:21 - cvsupping the source tree TB --- 2009-10-16 08:08:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2009-10-16 16:18:21 - WARNING: /usr/bin/csup returned exit code 1 TB --- 2009-10-16 16:18:21 - ERROR: unable to cvsup the source tree TB --- 2009-10-16 16:18:21 - 0.70 user 6.87 system 29411.67 real http://tinderbox.des.no/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From ben at altesco.nl Fri Oct 16 16:33:55 2009 From: ben at altesco.nl (Ben Stuyts) Date: Fri Oct 16 16:34:03 2009 Subject: ZFS v13 on FreeBSD 7 release/fixit iso's? Message-ID: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> Hi, I've recently upgraded a few FreeBSD-7-stable servers, and I see ZFS v13 has made it into the tree. From what I can tell, the existing 7.2 release & fixit cd's do not support v13 yet. I'd rather not upgrade the pools without a rescue cd available... Are there any 7-stable iso's available which support zfs v13? Ben From mike at jellydonut.org Fri Oct 16 17:10:06 2009 From: mike at jellydonut.org (Michael Proto) Date: Fri Oct 16 17:10:14 2009 Subject: ZFS v13 on FreeBSD 7 release/fixit iso's? In-Reply-To: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> Message-ID: <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: > Hi, > > I've recently upgraded a few FreeBSD-7-stable servers, and I see ZFS v13 has > made it into the tree. From what I can tell, the existing 7.2 release & > fixit cd's do not support v13 yet. > > I'd rather not upgrade the pools without a rescue cd available... Are there > any 7-stable iso's available which support zfs v13? > > Ben > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? -Proto From vince at unsane.co.uk Fri Oct 16 18:57:21 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Fri Oct 16 18:57:29 2009 Subject: ZFS v13 on FreeBSD 7 release/fixit iso's? In-Reply-To: <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> Message-ID: <4AD8C203.2020008@unsane.co.uk> Michael Proto wrote: > On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: > >> Hi, >> >> I've recently upgraded a few FreeBSD-7-stable servers, and I see ZFS v13 has >> made it into the tree. From what I can tell, the existing 7.2 release & >> fixit cd's do not support v13 yet. >> >> I'd rather not upgrade the pools without a rescue cd available... Are there >> any 7-stable iso's available which support zfs v13? >> >> Ben >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> > > How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? > > > or indeed from http://pub.allbsd.org/FreeBSD-snapshots/ > -Proto > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From ben at altesco.nl Fri Oct 16 19:15:35 2009 From: ben at altesco.nl (Ben Stuyts) Date: Fri Oct 16 19:15:42 2009 Subject: ZFS v13 on FreeBSD 7 release/fixit iso's? In-Reply-To: <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> Message-ID: On 16 okt 2009, at 18:47, Michael Proto wrote: > On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: >> >> I've recently upgraded a few FreeBSD-7-stable servers, and I see >> ZFS v13 has >> made it into the tree. From what I can tell, the existing 7.2 >> release & >> fixit cd's do not support v13 yet. >> >> I'd rather not upgrade the pools without a rescue cd available... >> Are there >> any 7-stable iso's available which support zfs v13? > > How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? Thanks! Ben From randy at iij.ad.jp Sat Oct 17 01:13:53 2009 From: randy at iij.ad.jp (Randy Bush) Date: Sat Oct 17 01:14:00 2009 Subject: bootless! Message-ID: i386 running 7.2 as of aug 29 twe, gmirrored boot partition, zfs universe cvsupped 24 hours ago new kernel world will not boot. get beastie but stops at first twirly can boot old kernel -s, but not new kernel can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs start am desperate enough that i am flying from dc to seattle see if i can get it revved back to aug 29 with a fixit any clues appreciated. please use From: address, as my normal email is guess where. randy From ken.clifford at mirror-image.com Sat Oct 17 03:27:20 2009 From: ken.clifford at mirror-image.com (Clifford, Ken) Date: Sat Oct 17 03:27:27 2009 Subject: bootless! In-Reply-To: References: Message-ID: Take me off this fucking list!@ ________________________________________ From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] On Behalf Of Randy Bush [randy@iij.ad.jp] Sent: Friday, October 16, 2009 9:13 PM To: FreeBSD-STABLE Mailing List Subject: bootless! i386 running 7.2 as of aug 29 twe, gmirrored boot partition, zfs universe cvsupped 24 hours ago new kernel world will not boot. get beastie but stops at first twirly can boot old kernel -s, but not new kernel can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs start am desperate enough that i am flying from dc to seattle see if i can get it revved back to aug 29 with a fixit any clues appreciated. please use From: address, as my normal email is guess where. randy _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From randy at psg.com Sat Oct 17 04:53:33 2009 From: randy at psg.com (Randy Bush) Date: Sat Oct 17 04:53:40 2009 Subject: bootless! In-Reply-To: References: Message-ID: > i386 running 7.2 as of aug 29 > twe, gmirrored boot partition, zfs universe > cvsupped 24 hours ago > new kernel & world > will not boot. get beastie but stops at first twirly > > can boot old kernel -s, but not new kernel > > can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs > start > > am desperate enough that i am flying from dc to seattle see if i can get > it revved back to aug 29 with a fixit > > any clues appreciated. please use From: address, as my normal email is > guess where. oh, and yes, i did try verbose boot OK boot -v | randy From v.velox at vvelox.net Sat Oct 17 05:14:35 2009 From: v.velox at vvelox.net (Zane C.B.) Date: Sat Oct 17 05:14:42 2009 Subject: USB keyboards and extra keys Message-ID: <20091016235440.69675c10@vixen42.vulpes> Any one ever manage to get extra keys to work on a USB keyboard in the RELENG_7 branch? Just looking into it for the first time since switching to 7 and it is still appearing to be non-workable still. From torfinn.ingolfsen at broadpark.no Sat Oct 17 10:38:34 2009 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sat Oct 17 10:38:41 2009 Subject: USB keyboards and extra keys In-Reply-To: <20091016235440.69675c10@vixen42.vulpes> References: <20091016235440.69675c10@vixen42.vulpes> Message-ID: <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> On Fri, 16 Oct 2009 23:54:40 -0500 "Zane C.B." wrote: > Any one ever manage to get extra keys to work on a USB keyboard in > the RELENG_7 branch? In the past, I have used hotkeys[1] from ports for this. I don't have that keyboard now, so I can't test if it still works. HTH References: 1) http://www.freshports.org/misc/hotkeys/ -- Torfinn From ben at altesco.nl Sat Oct 17 11:51:53 2009 From: ben at altesco.nl (Ben Stuyts) Date: Sat Oct 17 11:52:01 2009 Subject: ZFS v13 on FreeBSD 7 release/fixit iso's? In-Reply-To: <4AD8C203.2020008@unsane.co.uk> References: <09DD5432-F45A-4F87-9FA1-0021DF12B2F4@altesco.nl> <1de79840910160947o21b7fb7fv7229bc8da0293fca@mail.gmail.com> <4AD8C203.2020008@unsane.co.uk> Message-ID: <877E4A5A-0566-44D4-828A-CD8BF54D8C77@altesco.nl> On 16 okt 2009, at 20:57, Vincent Hoffman wrote: > Michael Proto wrote: >> On Fri, Oct 16, 2009 at 11:58 AM, Ben Stuyts wrote: >> >>> I've recently upgraded a few FreeBSD-7-stable servers, and I see >>> ZFS v13 has >>> made it into the tree. From what I can tell, the existing 7.2 >>> release & >>> fixit cd's do not support v13 yet. >>> >>> I'd rather not upgrade the pools without a rescue cd available... >>> Are there >>> any 7-stable iso's available which support zfs v13? >> >> How about ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200906/ ? >> > or indeed from > http://pub.allbsd.org/FreeBSD-snapshots/ Hey, that's neat, thanks! The second site is a lot more up to date than the former. Ben From mi+thun at aldan.algebra.com Sat Oct 17 16:46:43 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sat Oct 17 16:46:50 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? Message-ID: <4AD9F4ED.2050002@aldan.algebra.com> Hello! I'm investigating a problem caused by (what seems like a spurious) SIGPIPE. The program creates a child process using pipe, exchanges a few messages with the child (via write and read) and closes the pipe. Some times -- in about 60% of the cases -- this causes a SIGPIPE to be delivered to the parent... Now, it is quite possible for the child to have already exited by the time the parent closes its end of the pipe -- but why should that cause a SIGPIPE, unless the parent tries to write something to the widowed pipe, which it does not? >From pipe(2): A pipe that has had an end closed is considered widowed. Writing on such a pipe causes the writing process to receive a SIGPIPE signal. There is no other mention of SIGPIPE in that manual page... I set SIGPIPE on ignore around the pipe-closing as a work-around, but I think, this is a bug... The thing is part of TclX' self-test (test signal-3.0) -- and it was not dying from SIGPIPE before the FreeBSD-7.x, as far as I can remember... It still seems to be fine on Linux... Have there been any changes in this area in FreeBSD? Thanks! -mi From kostikbel at gmail.com Sat Oct 17 17:27:39 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Oct 17 17:27:46 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <4AD9F4ED.2050002@aldan.algebra.com> References: <4AD9F4ED.2050002@aldan.algebra.com> Message-ID: <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> On Sat, Oct 17, 2009 at 12:46:37PM -0400, Mikhail T. wrote: > Hello! > > I'm investigating a problem caused by (what seems like a spurious) > SIGPIPE. The program creates a child process using pipe, exchanges a few > messages with the child (via write and read) and closes the pipe. > > Some times -- in about 60% of the cases -- this causes a SIGPIPE to be > delivered to the parent... > > Now, it is quite possible for the child to have already exited by the > time the parent closes its end of the pipe -- but why should that cause > a SIGPIPE, unless the parent tries to write something to the widowed > pipe, which it does not? > > >From pipe(2): > > A pipe that has had an end closed is considered widowed. Writing > on such > a pipe causes the writing process to receive a SIGPIPE signal. > > There is no other mention of SIGPIPE in that manual page... > > I set SIGPIPE on ignore around the pipe-closing as a work-around, but I > think, this is a bug... > > The thing is part of TclX' self-test (test signal-3.0) -- and it was not > dying from SIGPIPE before the FreeBSD-7.x, as far as I can remember... > It still seems to be fine on Linux... > > Have there been any changes in this area in FreeBSD? Thanks! Take ktrace of both parent and child. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091017/c0395706/attachment.pgp From mi+thun at aldan.algebra.com Sat Oct 17 17:41:32 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sat Oct 17 17:41:38 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> Message-ID: <4ADA01C2.3000303@aldan.algebra.com> Kostik Belousov ???????(??): > Take ktrace of both parent and child. > Great idea! Here is the kdump's listing for both (after ktrace -i): http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt (it is large, so be sure to use a compressing browser). Once loaded, look for substring: Error SIGPIPE signal received while closing file5. The parent process-ID is 92722. The child -- 92723. Thanks! Yours, -mi From mi+thun at aldan.algebra.com Sat Oct 17 17:54:00 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sat Oct 17 17:54:07 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> Message-ID: <4ADA04B3.1000704@aldan.algebra.com> Kostik Belousov ???????(??): > Take ktrace of both parent and child. > I can see the curious piece right here: The child exits: 92723 tclsh8.5 CALL exit(0) The parent masks SIGPIPE (as part of my workaround): 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffffffa9e0,0) 92722 tclsh8.5 RET sigaction 0 This 0-size write must be part of the pipe-closing -- descriptors 4 and 5 must be the pipe's: 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, perhaps, didn't use to? Thanks! -mi From jilles at stack.nl Sat Oct 17 17:55:57 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Oct 17 17:56:03 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <4ADA01C2.3000303@aldan.algebra.com> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA01C2.3000303@aldan.algebra.com> Message-ID: <20091017175555.GA76378@stack.nl> On Sat, Oct 17, 2009 at 01:41:22PM -0400, Mikhail T. wrote: > Kostik Belousov wrote: > > Take ktrace of both parent and child. > Great idea! Here is the kdump's listing for both (after ktrace -i): > http://aldan.algebra.com/~mi/tmp/tclx-kdump.txt > (it is large, so be sure to use a compressing browser). Once loaded, > look for substring: > Error SIGPIPE signal received while closing file5. > The parent process-ID is 92722. The child -- 92723. Thanks! Yours, The interesting part of the ktrace: 92723 tclsh8.5 CALL exit(0) 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffffffa9e0,0) 92722 tclsh8.5 RET sigaction 0 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) 92722 tclsh8.5 RET write -1 errno 32 Broken pipe 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) 92722 tclsh8.5 RET sigreturn JUSTRETURN 92722 tclsh8.5 CALL close(0x5) 92722 tclsh8.5 RET close 0 92722 tclsh8.5 CALL close(0x4) 92722 tclsh8.5 RET close 0 It seems unwise to assume that a write(2) of 0 bytes is a noop. Even if it is, doing it is a waste of a system call. -- Jilles Tjoelker From mi+thun at aldan.algebra.com Sat Oct 17 17:58:59 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sat Oct 17 17:59:06 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <20091017175555.GA76378@stack.nl> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA01C2.3000303@aldan.algebra.com> <20091017175555.GA76378@stack.nl> Message-ID: <4ADA05DD.2080207@aldan.algebra.com> Jilles Tjoelker ???????(??): > It seems unwise to assume that a write(2) of 0 bytes is a noop. > Even if it is, doing it is a waste of a system call. This is not my code -- it is part of the implementation of Tcl's "close" command. I'm trying to unravel, where this write coming from, but, meanwhile, it would be useful to find out, if FreeBSD's handling of such writes changed recently, wouldn't it? Because this self-test used to pass cleanly before, so either FreeBSD changed, or the Tcl did (not the TclX extension, which did not change in years). Thanks for your help... -mi From kostikbel at gmail.com Sat Oct 17 17:59:48 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sat Oct 17 17:59:55 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <4ADA04B3.1000704@aldan.algebra.com> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA04B3.1000704@aldan.algebra.com> Message-ID: <20091017175941.GK2160@deviant.kiev.zoral.com.ua> On Sat, Oct 17, 2009 at 01:53:55PM -0400, Mikhail T. wrote: > Kostik Belousov ???????(??): > > Take ktrace of both parent and child. > > > I can see the curious piece right here: > > The child exits: > > 92723 tclsh8.5 CALL exit(0) > > The parent masks SIGPIPE (as part of my workaround): > > 92722 tclsh8.5 CALL sigaction(SIGPIPE,0x7fffffffa9e0,0) > 92722 tclsh8.5 RET sigaction 0 > > This 0-size write must be part of the pipe-closing -- descriptors 4 and > 5 must be the pipe's: > > 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) > 92722 tclsh8.5 RET write -1 errno 32 Broken pipe > 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 > 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) > 92722 tclsh8.5 RET sigreturn JUSTRETURN > 92722 tclsh8.5 CALL close(0x5) > 92722 tclsh8.5 RET close 0 > 92722 tclsh8.5 CALL close(0x4) > 92722 tclsh8.5 RET close 0 > > Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, > perhaps, didn't use to? Obviously, I cannot answer the question. This is something that should be read from source code or asked by authors. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091017/0da6e310/attachment.pgp From v.velox at vvelox.net Sat Oct 17 18:03:12 2009 From: v.velox at vvelox.net (Zane C.B.) Date: Sat Oct 17 18:03:19 2009 Subject: USB keyboards and extra keys In-Reply-To: <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> References: <20091016235440.69675c10@vixen42.vulpes> <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> Message-ID: <20091017130252.5ecce621@vixen42.vulpes> On Sat, 17 Oct 2009 12:38:10 +0200 Torfinn Ingolfsen wrote: > On Fri, 16 Oct 2009 23:54:40 -0500 > "Zane C.B." wrote: > > > Any one ever manage to get extra keys to work on a USB keyboard in > > the RELENG_7 branch? > > In the past, I have used hotkeys[1] from ports for this. I don't > have that keyboard now, so I can't test if it still works. Unfortunately that does not work. The extra keys on USB keyboards don't result in any thing visible to xev. Also usbhidctl does not show any thing happening on the uhid device that is created by the keyboard. From utisoft at googlemail.com Sat Oct 17 18:50:26 2009 From: utisoft at googlemail.com (Chris Rees) Date: Sat Oct 17 18:50:32 2009 Subject: bootless! In-Reply-To: References: Message-ID: 2009/10/17 Clifford, Ken : > Take me off this fucking list!@ >From the bottom of the email you just sent: freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" You're welcome. Chris -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in a mailing list? From tom at tomjudge.com Sat Oct 17 19:02:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Sat Oct 17 19:02:52 2009 Subject: bootless! In-Reply-To: References: Message-ID: <4ADA1018.4050808@tomjudge.com> Look at the footers of this email for how to remove yourself. Swearing will not get you any where, and is likely to result in people not helping you. Clifford, Ken wrote: > Take me off this fucking list!@ > ________________________________________ > From: owner-freebsd-stable@freebsd.org [owner-freebsd-stable@freebsd.org] On Behalf Of Randy Bush [randy@iij.ad.jp] > Sent: Friday, October 16, 2009 9:13 PM > To: FreeBSD-STABLE Mailing List > Subject: bootless! > > i386 running 7.2 as of aug 29 > twe, gmirrored boot partition, zfs universe > cvsupped 24 hours ago > new kernel world > will not boot. get beastie but stops at first twirly > > can boot old kernel -s, but not new kernel > > can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs > start > > am desperate enough that i am flying from dc to seattle see if i can get > it revved back to aug 29 with a fixit > > any clues appreciated. please use From: address, as my normal email is > guess where. > > randy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From randy at iij.ad.jp Sat Oct 17 21:07:24 2009 From: randy at iij.ad.jp (Randy Bush) Date: Sat Oct 17 21:07:31 2009 Subject: bootless! Message-ID: is there a recipe for making a 7.2 usb? randy From torfinn.ingolfsen at broadpark.no Sat Oct 17 22:00:36 2009 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Sat Oct 17 22:00:44 2009 Subject: USB keyboards and extra keys In-Reply-To: <20091017130252.5ecce621@vixen42.vulpes> References: <20091016235440.69675c10@vixen42.vulpes> <20091017123810.fce6c96a.torfinn.ingolfsen@broadpark.no> <20091017130252.5ecce621@vixen42.vulpes> Message-ID: <20091018000034.f46371ce.torfinn.ingolfsen@broadpark.no> On Sat, 17 Oct 2009 13:02:52 -0500 "Zane C.B." wrote: > Unfortunately that does not work. The extra keys on USB keyboards > don't result in any thing visible to xev. Well, it did on mine. YMMV. > Also usbhidctl does not show any thing happening on the uhid device > that is created by the keyboard. Perhaps that particular keyboard is broken by design? -- Torfinn From spawk at acm.poly.edu Sat Oct 17 22:01:02 2009 From: spawk at acm.poly.edu (Boris Kochergin) Date: Sat Oct 17 22:01:09 2009 Subject: bootless! In-Reply-To: References: Message-ID: <4ADA3E39.2090200@acm.poly.edu> Randy Bush wrote: > is there a recipe for making a 7.2 usb? > > randy > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > If you mean for converting the ISOs to images you can dd to USB flash drives, http://acm.poly.edu/~spawk/image.sh. I found it somewhere else a long time ago, but it works. Note that you cannot install distributions from it, so you'll have to get those using FTP, another local filesystem, etc. -Boris From mi+thun at aldan.algebra.com Sat Oct 17 22:04:55 2009 From: mi+thun at aldan.algebra.com (Mikhail T.) Date: Sat Oct 17 22:05:02 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <20091017175941.GK2160@deviant.kiev.zoral.com.ua> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA04B3.1000704@aldan.algebra.com> <20091017175941.GK2160@deviant.kiev.zoral.com.ua> Message-ID: <4ADA3F7E.1070208@aldan.algebra.com> Kostik Belousov ???????(??): >> This 0-size write must be part of the pipe-closing -- descriptors 4 and >> 5 must be the pipe's: >> >> 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) >> 92722 tclsh8.5 RET write -1 errno 32 Broken pipe >> 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 >> 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) >> 92722 tclsh8.5 RET sigreturn JUSTRETURN >> 92722 tclsh8.5 CALL close(0x5) >> 92722 tclsh8.5 RET close 0 >> 92722 tclsh8.5 CALL close(0x4) >> 92722 tclsh8.5 RET close 0 >> >> Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, >> perhaps, didn't use to? >> > > Obviously, I cannot answer the question. This is something that should > be read from source code or asked by authors. > You -- or someone else -- could comment like: a) Yeah, the meaning of write-ing 0 bytes changed in version such and such to conform to such and such standard. or b) No, nothing changed in that area of FreeBSD for years -- there must be something in Tcl itself. Yours, -mi From kostikbel at gmail.com Sun Oct 18 12:15:57 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Oct 18 12:16:05 2009 Subject: Can close-ing a pipe trigger a SIGPIPE? In-Reply-To: <4ADA3F7E.1070208@aldan.algebra.com> References: <4AD9F4ED.2050002@aldan.algebra.com> <20091017172718.GJ2160@deviant.kiev.zoral.com.ua> <4ADA04B3.1000704@aldan.algebra.com> <20091017175941.GK2160@deviant.kiev.zoral.com.ua> <4ADA3F7E.1070208@aldan.algebra.com> Message-ID: <20091018121545.GO2160@deviant.kiev.zoral.com.ua> On Sat, Oct 17, 2009 at 06:04:46PM -0400, Mikhail T. wrote: > Kostik Belousov ???????(??): > >> This 0-size write must be part of the pipe-closing -- descriptors 4 and > >> 5 must be the pipe's: > >> > >> 92722 tclsh8.5 CALL write(0x4,0x800e24028,0) > >> 92722 tclsh8.5 RET write -1 errno 32 Broken pipe > >> 92722 tclsh8.5 PSIG SIGPIPE caught handler=0x800f126d0 mask=0x0 code=0x0 > >> 92722 tclsh8.5 CALL sigreturn(0x7fffffffa0c0) > >> 92722 tclsh8.5 RET sigreturn JUSTRETURN > >> 92722 tclsh8.5 CALL close(0x5) > >> 92722 tclsh8.5 RET close 0 > >> 92722 tclsh8.5 CALL close(0x4) > >> 92722 tclsh8.5 RET close 0 > >> > >> Why would it write 0 bytes? Is doing so triggering a SIGPIPE now -- but, > >> perhaps, didn't use to? > >> > > > > Obviously, I cannot answer the question. This is something that should > > be read from source code or asked by authors. Source code of the application, this is probably unclear from the above sentence. > > > You -- or someone else -- could comment like: > > a) Yeah, the meaning of write-ing 0 bytes changed in version such and > such to conform to such and such standard. > > or > > b) No, nothing changed in that area of FreeBSD for years -- there must > be something in Tcl itself. It cannot be stated in this way, since application started to issue zero-length writes. Why it started doing this, either some buggy ABI change in the base system, or buggy application noted and reacted inconsitently to the ABI addition etc cannot be even theoretized. This is why I made that formulation noting the reason should be read from the app source code. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091018/fa627e1e/attachment.pgp From cperciva at freebsd.org Sun Oct 18 12:36:27 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Sun Oct 18 12:36:42 2009 Subject: HEADS UP: FreeBSD 6.3 EoL coming soon Message-ID: <4ADB0BCA.8050904@freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, On January 31st, FreeBSD 6.3 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of this release are strongly encouraged to upgrade to a newer release before that date -- more conservative users will probably wish to upgrade to FreeBSD 6.4 or FreeBSD 7.1 (which are both extended-support branches), while others will probably wish to upgrade to FreeBSD 7.2 or the upcoming FreeBSD 8.0. The freebsd-update(8) utility can be used to upgrade i386 and amd64 systems from 6.3-RELEASE (or 6.3-RELEASE-pX for some X) to 6.4-RELEASE using binary updates (i.e., without compiling from source) as described in the 6.4-RELEASE announcement; given an adequate internet connection, this process usually takes 15 minutes or less. The current supported branches and expected EoL dates are: +---------------------------------------------------------------------+ | Branch | Release | Type | Release date | Estimated EoL | |-----------+------------+--------+-----------------+-----------------| |RELENG_6 |n/a |n/a |n/a |November 30, 2010| |-----------+------------+--------+-----------------+-----------------| |RELENG_6_3 |6.3-RELEASE |Extended|January 18, 2008 |January 31, 2010 | |---------------------------------------------------------------------| |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010| |---------------------------------------------------------------------| |RELENG_7 |n/a |n/a |n/a |last release + 2y| |-----------+------------+--------+-----------------+-----------------| |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | |-----------+------------+--------+-----------------+-----------------| |RELENG_7_2 |7.2-RELEASE |Normal |May 4, 2009 |May 31, 2010 | +---------------------------------------------------------------------+ When FreeBSD 8.0-RELEASE is released, it will receive "Normal" support, i.e., it will be supported for at least 12 months. - -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkrbC8oACgkQFdaIBMps37KQOQCgmnXQGtI/hKlFCT+dKAXzGX90 gi4An0uC5y3SLNtrTxOvYD6HqpnrR99k =fl+f -----END PGP SIGNATURE----- From huubsch at xs4all.nl Sun Oct 18 15:12:12 2009 From: huubsch at xs4all.nl (Huub Schuurmans) Date: Sun Oct 18 15:12:20 2009 Subject: ifconfig channel assignment for wi hostap interface Message-ID: <1255877588.7383.30.camel@localhost> I have a problem with the channel configuration of wi-interfaces in rc.conf. In hostap mode the interface is always using channel 1. The statement: ifconfig_wi0="inet 172.17.16.1/26 ssid ap.huub.wleiden.net media DS/11Mbps mediaopt hostap channel 7" results in an ap-interface running at channel 1. I found that splitting the statement in the startup script is effective in setting the proper channel: ifconfig_wi0="inet 172.17.16.1/26 ssid ap.huub.wleiden.net media DS/11Mbps mediaopt hostap" ifconfig_wi0_alias0="channel 7" Now the ap is indeed using channel 7. I am running 7.2-RELEASE-p4 A bug in the wi-driver? Kind regards, Huub From marck at rinet.ru Sun Oct 18 18:53:24 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Sun Oct 18 18:53:32 2009 Subject: Adaptec 1420SA identification trouble (again) Message-ID: Dear colleagues, I'm having trouble attaching 1420SA controller (just one KBOD disk attached to it) with fresh stable/7: none4@pci0:3:0:0: class=0x010400 card=0x02419005 chip=0x02419005 rev=0x01 hdr=0x00 vendor = 'Adaptec Inc' device = 'Serial ATA II RAID 1420SA' class = mass storage subclass = RAID No references to device 3.0 at pci0 in verbose dmesg. AFAICS, ddf sources have been merged to releng/7. Any hints? Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From jhell at DataIX.net Sun Oct 18 23:16:58 2009 From: jhell at DataIX.net (jhell) Date: Sun Oct 18 23:17:05 2009 Subject: Make release process for 7.2-STABLE @ r198084 Message-ID: I have just been setting up a release cycle for making some iso's of my own for a modified revision of the source that I am going to be using for offline use and run into a repetitive copy that I am hoping someone could shed some light on. Output from a make release run. "Portion in question" ----------------------------------------------------------------- [...] cd /usr/obj/RELENG/usr && cp -R -H /usr/src src rm -rf /usr/obj/RELENG/usr/ports cd /usr/obj/RELENG/usr && cp -R -H /usr/ports ports # If there are distfiles downloaded removing them rm -rf ports/distfiles/* rm -rf /usr/obj/RELENG/usr/doc cd /usr/obj/RELENG/usr && cp -R -H /usr/doc doc if [ -d /usr/src/release/../../ports/distfiles/ ]; then cp -rp /usr/src/release/../../ports/distfiles /usr/obj/RELENG/usr/ports/distfiles; else mkdir -p /usr/obj/RELENG/usr/ports/distfiles; fi ---------------------------------------------------------------- >From the above output and what happened my ports tree was copied over along with the distfiles the first time cp was issued on the ports directory. Then shortly after that it removes the copied distfiles and issues the next command to copy the docs over. After it does a test for ../../ports/distfiles from the release directory which happens to be the same directory it previously copied over and then removed and is now issuing a command to copy over again?. Is there a problem with the layout of directories from which I started this process maybe? Fault in the script for make release possibly ? Did I miss some tunable for the make release ? >From this setup for a make release everything is a default type of structure/setup/layout for ports and source and doc from a install. If I have to do this again I don't want to copy over 4+ GiB of distfiles twice. Thanks. -- ;; dataix.net!jhell 2048R/89D8547E 2009-09-30 ;; BSD since FreeBSD 4.2 Linux since Slackware 2.1 ;; 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E From kama at pvp.se Mon Oct 19 11:24:08 2009 From: kama at pvp.se (kama) Date: Mon Oct 19 11:24:21 2009 Subject: FreeBSD 7.2-STABLE boot freeze In-Reply-To: <20091002212626.O37424@ns1.as.pvp.se> References: <20090921140345.H37424@ns1.as.pvp.se> <20090922103150.V37424@ns1.as.pvp.se> <4AB8A95E.3060307@icyb.net.ua> <20090922142526.P37424@ns1.as.pvp.se> <4AB8E082.8050100@icyb.net.ua> <20090922215700.V37424@ns1.as.pvp.se> <4ABA1D1F.3080704@icyb.net.ua> <20090923171004.Q37424@ns1.as.pvp.se> <4ABA457E.3060800@freebsd.org> <20090924141927.Y37424@ns1.as.pvp.se> <20090925110209.E37424@ns1.as.pvp.se> <4ABC894E.7040204@freebsd.org> <20090928092026.B37424@ns1.as.pvp.se> <4AC06ED6.7030402@freebsd.org> <20090928235136.F37424@ns1.as.pvp.se> <20090929085000.B37424@ns1.as.pvp.se> <4AC211AC.1070404@freebsd.org> <20090929204651.G37424@ns1.as.pvp.se> <4AC34952.9010508@freebsd.org> <20090930151542.G37424@ns1.as.pvp.se> <4AC35CC6.1020103@freebsd.org> <20091002132218.P37424@ns1.as.pvp.se> <20091002212626.O37424@ns1.as.pvp.se> Message-ID: <20091019131327.U33520@ns1.as.pvp.se> On Fri, 2 Oct 2009, kama wrote: > > > Do you get this message in all cases? That is, every time you tried? > > > Or only with ACPI_DEBUG defined? > > > > I cant recall. I have tried so many things lately. But I believe I get it > > on a verbose boot without ACPI_DEBUG. > > > > Im currently rebuilding the system to 8.0. > > Just upgrading to 8.0 did not help regarding the freezes. > > I ran into the bge freeze bug too when disabling acpi. > > I then read the acpi-manpage abit more carefully. > > With ACPI_DEBUG and debug.acpi.disabled="timer" in loader.conf and verbose > boot seems to help against the freeze and freezes again if I dont run it > in verbose mode. But thats just after 5 starts. Anyhow its better. > > loader.conf: > debug.acpi.disabled="timer" > debug.acpi.layer="ACPI_ALL_COMPONENTS" > debug.acpi.level="ACPI_LV_VERBOSE,ACPI_LV_VERBOSITY3,ACPI_LV_VERBOSITY1,ACPI_LV_ALL_EXCEPTIONS" > I just wanted to bump this. After the checkout yesterday and installation today I still get these freezes. # cat /boot/loader.conf hw.bge.allow_asf="0" hw.acpi.verbose="1" debug.acpi.max_threads="1" debug.acpi.disabled="timer" debug.acpi.layer="ACPI_ALL_COMPONENTS" debug.acpi.level="ACPI_LV_VERBOSE,ACPI_LV_VERBOSITY3,ACPI_LV_VERBOSITY1,ACPI_LV_ALL_EXCEPTIONS" # With this setup and with an GENERIC kernel I am able to boot if I choose a verbose boot. I dont know why it should work with these. If I only use debug.acpi.disabled="timer" it will freeze. Is there anyway for me to get more info when it exactly freezes. Like having it print out to the screen when it enters and leaves functions or something. Im not to familiar with where to put these and its "quite" a large project for me to start to understand where everything goes. If someone wants to give me patches or specify which files to alter and how I print to the screen during boot I might be able to pinpoint where it freezes and mail in the results. /Bjorn From ivoras at freebsd.org Mon Oct 19 11:55:17 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Oct 19 11:55:23 2009 Subject: Extreme console latency during disk IO (8.0-RC1, previous releases also affected according to others) In-Reply-To: References: <9bbcef730910130633w150571a0k461fb4e67a51fb1d@mail.gmail.com> <9bbcef730910131057i71db846et1f0d4aeadef5e302@mail.gmail.com> Message-ID: Ivan Voras wrote: > Another data point - the OS in the VM in question hanged today sometime > after 5 AM in the following way: > > * console nonresponsive (also to ctrl-alt-del) > * ssh login nonresponsive (timeout) > * ping works (!) > > Judging by the last seen timestamp, the machine should have been in the > process of receiving rsync backups - so IO-bound. It looks like something really could be fishy in this area, at least with VMWare. The same thing happened again, and I have an additional data point: I left 'top' running on the console and when I attached the VMWare console to the VM, the top was still running ok, but as soon as I hit a key on the keyboard, the OS console locked up. All other symptoms were as I enumerated above. From gavin.atkinson at ury.york.ac.uk Mon Oct 19 14:22:53 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Mon Oct 19 14:23:00 2009 Subject: bootless! In-Reply-To: References: Message-ID: <1255962160.3225.22.camel@buffy.york.ac.uk> On Fri, 2009-10-16 at 21:13 -0400, Randy Bush wrote: > i386 running 7.2 as of aug 29 > twe, gmirrored boot partition, zfs universe > cvsupped 24 hours ago > new kernel world > will not boot. get beastie but stops at first twirly > > can boot old kernel -s, but not new kernel > > can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs > start A few questions: Have you cvsupped to 7-STABLE or 8? Are you using ZFS root? Do you get anything extra with "boot -v"? Have you tried your old loader (/boot/loader.old)? Gavin From jhb at freebsd.org Mon Oct 19 17:34:37 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Oct 19 17:34:45 2009 Subject: Make release process for 7.2-STABLE @ r198084 In-Reply-To: References: Message-ID: <200910191334.31137.jhb@freebsd.org> On Sunday 18 October 2009 7:16:41 pm jhell wrote: > > I have just been setting up a release cycle for making some iso's of my > own for a modified revision of the source that I am going to be using for > offline use and run into a repetitive copy that I am hoping someone could > shed some light on. > > Output from a make release run. "Portion in question" > ----------------------------------------------------------------- > [...] > cd /usr/obj/RELENG/usr && cp -R -H /usr/src src > rm -rf /usr/obj/RELENG/usr/ports > cd /usr/obj/RELENG/usr && cp -R -H /usr/ports ports > # If there are distfiles downloaded removing them > rm -rf ports/distfiles/* > rm -rf /usr/obj/RELENG/usr/doc > cd /usr/obj/RELENG/usr && cp -R -H /usr/doc doc > if [ -d /usr/src/release/../../ports/distfiles/ ]; then cp -rp > /usr/src/release/../../ports/distfiles > /usr/obj/RELENG/usr/ports/distfiles; else mkdir -p > /usr/obj/RELENG/usr/ports/distfiles; fi > ---------------------------------------------------------------- > > >From the above output and what happened my ports tree was copied over > along with the distfiles the first time cp was issued on the ports > directory. Then shortly after that it removes the copied distfiles and > issues the next command to copy the docs over. After it does a test for > ../../ports/distfiles from the release directory which happens to be the > same directory it previously copied over and then removed and is now > issuing a command to copy over again?. > > Is there a problem with the layout of directories from which I started > this process maybe? > > Fault in the script for make release possibly ? > > Did I miss some tunable for the make release ? > > >From this setup for a make release everything is a default type of > structure/setup/layout for ports and source and doc from a install. If I > have to do this again I don't want to copy over 4+ GiB of distfiles twice. > > Thanks. I think this is a property of using EXTPORTSDIR. Generally releases are built against a CVS repo and the ports tree is checked out from that. I would suggestion changing the 'cp' of ports from EXTPORTSDIR to instead do something fancier that excludes copying distfiles in the first place. -- John Baldwin From oberman at es.net Mon Oct 19 19:37:46 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 19 19:38:04 2009 Subject: Regression in dhclient? Message-ID: <20091019193744.E84031CC37@ptavv.es.net> I just noticed that my dhclient.conf file seems to be ignored in 8.0. Worked fine in 7.2. interface "ath0" { send host-name "slan.XXX.YYY"; prepend domain-name "XXX.YYY "; append domain-name-servers 198.128.W.ZZ; } When I look at /etc/resolv.conf, neither the domain-name is added nor te dns-server. No errors or anything else in the logs. Anyone else see this or do I have a local problem? -- 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 From oberman at es.net Mon Oct 19 19:58:05 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Oct 19 19:58:12 2009 Subject: Regression in dhclient? In-Reply-To: Your message of "Mon, 19 Oct 2009 19:49:33 -0000." <4ADCC2CD.5000904@tomjudge.com> Message-ID: <20091019195803.BB4F21CC37@ptavv.es.net> > Date: Mon, 19 Oct 2009 19:49:33 +0000 > From: Tom Judge > > Kevin Oberman wrote: > > I just noticed that my dhclient.conf file seems to be ignored in > > 8.0. Worked fine in 7.2. > > > > interface "ath0" { > > send host-name "slan.XXX.YYY"; > > prepend domain-name "XXX.YYY "; > > append domain-name-servers 198.128.W.ZZ; > > } > > > > Your interface is wrong, it should be wlanX not athX > > When I look at /etc/resolv.conf, neither the domain-name is added nor te > > dns-server. No errors or anything else in the logs. > > > > Anyone else see this or do I have a local problem? /me hangs head in shame. This change to the use of wlan0 has bitten me several places, but this is the first time I did not eventually spot it myself. Thanks, Tom. -- 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 From tom at tomjudge.com Mon Oct 19 20:07:45 2009 From: tom at tomjudge.com (Tom Judge) Date: Mon Oct 19 20:07:53 2009 Subject: Regression in dhclient? In-Reply-To: <20091019193744.E84031CC37@ptavv.es.net> References: <20091019193744.E84031CC37@ptavv.es.net> Message-ID: <4ADCC2CD.5000904@tomjudge.com> Kevin Oberman wrote: > I just noticed that my dhclient.conf file seems to be ignored in > 8.0. Worked fine in 7.2. > > interface "ath0" { > send host-name "slan.XXX.YYY"; > prepend domain-name "XXX.YYY "; > append domain-name-servers 198.128.W.ZZ; > } > Your interface is wrong, it should be wlanX not athX > When I look at /etc/resolv.conf, neither the domain-name is added nor te > dns-server. No errors or anything else in the logs. > > Anyone else see this or do I have a local problem? > Tom From randy at iij.ad.jp Tue Oct 20 02:09:06 2009 From: randy at iij.ad.jp (Randy Bush) Date: Tue Oct 20 02:09:14 2009 Subject: bootless! In-Reply-To: <1255962160.3225.22.camel@buffy.york.ac.uk> References: <1255962160.3225.22.camel@buffy.york.ac.uk> Message-ID: >> i386 running 7.2 as of aug 29 >> twe, gmirrored boot partition, zfs universe >> cvsupped 24 hours ago >> new kernel world >> will not boot. get beastie but stops at first twirly >> >> can boot old kernel -s, but not new kernel >> >> can not use old kernel with new world, hangs if i try to /etc/rc.d/zfs >> start > > A few questions: Have you cvsupped to 7-STABLE or 8? Are you using ZFS > root? Do you get anything extra with "boot -v"? Have you tried your > old loader (/boot/loader.old)? really dead ended with old systems. no, root not zfs. the post mortem by a friend: friday morning, while trying to solve some other problem (i no longer remember what), randy did a "make installworld" that broke psg.com's ability to use its zfs filesystems. obvious answer was to revert, but that turns out to be easier to say than to do with /usr offline. friday's attempts to roll back via net and remote hands failed, so randy diverted to seattle. after further whackiness on saturday with randy in the westin with a crash cart, it became clear that, even using the pre-zfs filesystems that had been sitting idle since the move to zfs, the machine was too messed up to be able to run "make world". many programs (eg, "ln") were failing with sigsys errors due to some kind of mismatch between userland and kernel. so we installed freebsd 7.2 from distro media onto a blank usb hard drive, whacked the bios with a club until it admitted to being able to boot from usb, and used that disk as a stable build platform capable of running csup and make world. this didn't solve the problem, but got us far enough that randy could check out of the westin. after further antics, gyrations, sacrifices of rubber chickens, and some sleep, we finally got zfs back up, installed new world and kernel, fixed all the things we had broken (well, that we could remember or had logged), and got the machine back up and running on its filesystems, with just enough time left for randy to eat dinner and head for the ferry to catch a red eye bound for nanog. so that's where we are now: randy's in transit and everything seems back to normal. initially exim was groaning under the load of a weekend's mail backlog, but that looks to be calming down. -30- From avg at icyb.net.ua Tue Oct 20 11:03:43 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Oct 20 11:03:53 2009 Subject: bootless! In-Reply-To: References: <1255962160.3225.22.camel@buffy.york.ac.uk> Message-ID: <4ADD9906.1040205@icyb.net.ua> Randy, just something possibly useful for the future. Not sure if it really could have helped you here but perhaps it could: http://anonsvn.h3q.com/projects/freebsd-patches/wiki/manageBE I personally don't use manageBE, but I have a very similar setup/config. I perform all the boot-environment actions by hand rather than by a script. I do it that way because I perform major upgrades very infrequently (like once a month) and I like an additional exercise in keyboard punching :-) -- Andriy Gapon From korvus at comcast.net Tue Oct 20 18:48:46 2009 From: korvus at comcast.net (Steve Polyack) Date: Tue Oct 20 18:48:58 2009 Subject: FreeBSD and SATA Port Multipliers Message-ID: <4ADE060C.5050605@comcast.net> I have a system running FreeBSD 8.0-RC1 that contains 3x Sil3124 PCI-E SATA controller cards. Each card has 3x Sil3726 Port Multipliers attached (5 slots per SATA PM). The problem is that the disks are often not all detected by FreeBSD, even though the controller Option ROMs list all of the installed physical disks. Which drive(s) are not detected seems to vary with each boot. All of the port multipliers are detected every boot, it's just the drives which aren't getting probed. I've tried the following patch, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129784 , which may have helped - it picks up 6-8 out of 9 disks, but obviously that's not ideal. The motherboard BIOS version is current, as is the firmware for the SATA controllers. Does anyone have any ideas or other patches that I may try? Thanks, Steve Polyack From korvus at comcast.net Tue Oct 20 20:53:51 2009 From: korvus at comcast.net (Steve Polyack) Date: Tue Oct 20 20:54:04 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4ADE060C.5050605@comcast.net> References: <4ADE060C.5050605@comcast.net> Message-ID: <4ADE235D.6050208@comcast.net> Steve Polyack wrote: > I have a system running FreeBSD 8.0-RC1 that contains 3x Sil3124 PCI-E > SATA controller cards. Each card has 3x Sil3726 Port Multipliers > attached (5 slots per SATA PM). The problem is that the disks are > often not all detected by FreeBSD, even though the controller Option > ROMs list all of the installed physical disks. Which drive(s) are not > detected seems to vary with each boot. All of the port multipliers > are detected every boot, it's just the drives which aren't getting > probed. This was mostly fixed by loading the siis(4) module at boot. However, if I attach 5 drives to a port multiplier board and reboot, only 4 of the drives attached to that port multiplier are detected. From dmesg: siisch4: Timeout on slot 25 siisch4: siis_timeout is 00000000 ss 02000000 rs 02000000 es 00000000 sts 80192000 serr 00000000 (aprobe0:siisch4:0:1:0): SIGNATURE: 0000 (aprobe0:siisch4:0:2:0): SIGNATURE: 0000 (aprobe0:siisch4:0:3:0): SIGNATURE: 0000 (aprobe0:siisch4:0:4:0): SIGNATURE: 0000 ada0 at siisch4 bus 0 target 1 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at siisch4 bus 0 target 2 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled ada2 at siisch4 bus 0 target 3 lun 0 ada2: ATA/ATAPI-8 SATA 2.x device ada2: 300.000MB/s transfers ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada2: Native Command Queueing enabled ada3 at siisch4 bus 0 target 4 lun 0 ada3: ATA/ATAPI-8 SATA 2.x device ada3: 300.000MB/s transfers ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada3: Native Command Queueing enabled The disk at siisch4 bus 0 target 0 lun 0 is what's missing - it looks like there's some kind of timeout during the detection. A 'camcontrol rescan all' does not help. In fact, the camcontrol rescan appears to lose all of the SATA drives attached to port-multipliers with a similar timeout message: siisch4: Timeout on slot 17 siisch4: siis_timeout is 00040000 ss 00020000 rs 00020000 es 00000000 sts 80112000 serr 00000000 (ada0:siisch4:0:1:0): lost device (ada0:siisch4:0:1:0): removing device entry siisch4: Timeout on slot 19 siisch4: siis_timeout is 00040000 ss 00080000 rs 00080000 es 00000000 sts 80132000 serr 00000000 siisch4: Timeout on slot 20 siisch4: siis_timeout is 00040000 ss 00100000 rs 00100000 es 00000000 sts 80142000 serr 00000000 (ada1:siisch4:0:2:0): lost device (ada1:siisch4:0:2:0): removing device entry siisch4: Timeout on slot 21 siisch4: siis_timeout is 00040000 ss 00200000 rs 00200000 es 00000000 sts 80152000 serr 00000000 siisch4: Timeout on slot 22 siisch4: siis_timeout is 00040000 ss 00400000 rs 00400000 es 00000000 sts 80162000 serr 00000000 (ada2:siisch4:0:3:0): lost device (ada2:siisch4:0:3:0): removing device entry I can provide more info on request. From ivoras at freebsd.org Tue Oct 20 21:36:14 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 20 21:36:22 2009 Subject: Interesting problem updating samba after 7->8 transition Message-ID: I upgraded (via source) a system from 7-stable to 8-stable and Samba now fails in a strange way. Starting the executable results in an immediate ABORT: ursaminor:/usr/local/sbin# ./smbd Abort And running ktrace on it results in an extremely short ktrace.out: ursaminor:/usr/local/sbin# ktrace ./smbd Abort ursaminor:/usr/local/sbin# ll ktrace.out -rw------- 1 root wheel 166 Oct 20 23:32 ktrace.out ursaminor:/usr/local/sbin# kdump -f ./ktrace.out 93873 ktrace RET ktrace 0 93873 ktrace CALL execve(0xbfbfed7f,0xbfbfec44,0xbfbfec4c) 93873 ktrace NAMI "./smbd" I have no idea how to interpret this dump. OTOH ldd says everything looks fine: ursaminor:/usr/local/sbin# ldd ./smbd ./smbd: libcrypt.so.5 => /lib/libcrypt.so.5 (0x281a1000) libpam.so.5 => /usr/lib/libpam.so.5 (0x281ba000) libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x281c1000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28845000) librt.so.1 => /usr/lib/librt.so.1 (0x281cc000) libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x281da000) libc.so.7 => /lib/libc.so.7 (0x2808f000) libm.so.5 => /lib/libm.so.5 (0x281e3000) libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2893b000) Any suggestion where to dig further? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091020/cb2f77a8/signature.pgp From kostikbel at gmail.com Tue Oct 20 21:44:51 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Oct 20 21:44:58 2009 Subject: Interesting problem updating samba after 7->8 transition In-Reply-To: References: Message-ID: <20091020214445.GK2160@deviant.kiev.zoral.com.ua> On Tue, Oct 20, 2009 at 11:35:39PM +0200, Ivan Voras wrote: > I upgraded (via source) a system from 7-stable to 8-stable and Samba now > fails in a strange way. Starting the executable results in an immediate > ABORT: > > ursaminor:/usr/local/sbin# ./smbd > Abort > > And running ktrace on it results in an extremely short ktrace.out: > > ursaminor:/usr/local/sbin# ktrace ./smbd > Abort > ursaminor:/usr/local/sbin# ll ktrace.out > -rw------- 1 root wheel 166 Oct 20 23:32 ktrace.out > ursaminor:/usr/local/sbin# kdump -f ./ktrace.out > 93873 ktrace RET ktrace 0 > 93873 ktrace CALL execve(0xbfbfed7f,0xbfbfec44,0xbfbfec4c) > 93873 ktrace NAMI "./smbd" > > I have no idea how to interpret this dump. > > OTOH ldd says everything looks fine: > > ursaminor:/usr/local/sbin# ldd ./smbd > ./smbd: > libcrypt.so.5 => /lib/libcrypt.so.5 (0x281a1000) > libpam.so.5 => /usr/lib/libpam.so.5 (0x281ba000) > libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x281c1000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28845000) > librt.so.1 => /usr/lib/librt.so.1 (0x281cc000) > libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x281da000) > libc.so.7 => /lib/libc.so.7 (0x2808f000) > libm.so.5 => /lib/libm.so.5 (0x281e3000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2893b000) > > Any suggestion where to dig further? > > Upgrade to at least r198284. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091020/bb727841/attachment.pgp From ronald-freebsd8 at klop.yi.org Tue Oct 20 21:45:22 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Tue Oct 20 21:45:34 2009 Subject: Interesting problem updating samba after 7->8 transition In-Reply-To: References: Message-ID: On Tue, 20 Oct 2009 23:35:39 +0200, Ivan Voras wrote: > I upgraded (via source) a system from 7-stable to 8-stable and Samba now > fails in a strange way. Starting the executable results in an immediate > ABORT: > > ursaminor:/usr/local/sbin# ./smbd > Abort > > And running ktrace on it results in an extremely short ktrace.out: > > ursaminor:/usr/local/sbin# ktrace ./smbd > Abort > ursaminor:/usr/local/sbin# ll ktrace.out > -rw------- 1 root wheel 166 Oct 20 23:32 ktrace.out > ursaminor:/usr/local/sbin# kdump -f ./ktrace.out > 93873 ktrace RET ktrace 0 > 93873 ktrace CALL execve(0xbfbfed7f,0xbfbfec44,0xbfbfec4c) > 93873 ktrace NAMI "./smbd" > > I have no idea how to interpret this dump. > > OTOH ldd says everything looks fine: > > ursaminor:/usr/local/sbin# ldd ./smbd > ./smbd: > libcrypt.so.5 => /lib/libcrypt.so.5 (0x281a1000) > libpam.so.5 => /usr/lib/libpam.so.5 (0x281ba000) > libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x281c1000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28845000) > librt.so.1 => /usr/lib/librt.so.1 (0x281cc000) > libpopt.so.0 => /usr/local/lib/libpopt.so.0 (0x281da000) > libc.so.7 => /lib/libc.so.7 (0x2808f000) > libm.so.5 => /lib/libm.so.5 (0x281e3000) > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x2893b000) > > Any suggestion where to dig further? Read about the latest ERRATA NOTICES's. There is something with PIE-library's (which are used by Samba) which defaults to doesn't-work in 8 and still works in 7. People are working on a real fix for 8. In the ERRATA NOTICES is a setting which you can set to does-work. http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc Ronald. From ivoras at freebsd.org Tue Oct 20 21:50:24 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Oct 20 21:50:31 2009 Subject: Interesting problem updating samba after 7->8 transition In-Reply-To: References: Message-ID: Ronald Klop wrote: > Read about the latest ERRATA NOTICES's. There is something with > PIE-library's (which are used by Samba) which defaults to doesn't-work > in 8 and still works in 7. People are working on a real fix for 8. > In the ERRATA NOTICES is a setting which you can set to does-work. > > http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc Ouch, stupid of me... and I noticed the advisory thinking that I'll need it soon. I guess I thought I'll get it by default with RELENG_8 but I see the patch was MFC-ed today :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091020/4b3eaaa8/signature.pgp From mav at FreeBSD.org Tue Oct 20 22:51:55 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Oct 20 22:52:06 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <1256075840.00175367.1256064602@10.7.7.3> References: <1256075840.00175367.1256064602@10.7.7.3> Message-ID: <4ADE3F06.9050508@FreeBSD.org> Steve Polyack wrote: > I have a system running FreeBSD 8.0-RC1 that contains 3x Sil3124 PCI-E > SATA controller cards. Each card has 3x Sil3726 Port Multipliers > attached (5 slots per SATA PM). The problem is that the disks are often > not all detected by FreeBSD, even though the controller Option ROMs list > all of the installed physical disks. Which drive(s) are not detected > seems to vary with each boot. All of the port multipliers are detected > every boot, it's just the drives which aren't getting probed. > > I've tried the following patch, > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/129784 , which may have > helped - it picks up 6-8 out of 9 disks, but obviously that's not > ideal. The motherboard BIOS version is current, as is the firmware for > the SATA controllers. > > Does anyone have any ideas or other patches that I may try? Have you tried new CAM-based ATA subsystem present in 8.x by siis(4) driver? Work is still in progress there, but it should work with port multipliers much better then previous implementation. -- Alexander Motin From grarpamp at gmail.com Wed Oct 21 06:03:37 2009 From: grarpamp at gmail.com (grarpamp) Date: Wed Oct 21 06:03:44 2009 Subject: FreeBSD and SATA Port Multipliers Message-ID: In the somewhat related dept... The SiI3124 and SiI3726 seem to be *really* popular chipsets for low cost JBOD setups so I'm sure any work done towards this will be a win. The only other chip I see a lot of is the Marvell 88SX6041 and 88SX6081. Any others, particularly of the eight port generic card variety or other multipliers??? I'm not sure if JMicron ever got into the 4/8 port game. A somewhat related diversion: http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/ And without the fab... you'd be amazed what a bicycle inner tube, scrap pc case lids, tin snips, hammer, anvil, drill bit, and a pop rivet tool will yield ;-) From dean at fragfest.com.au Wed Oct 21 06:39:54 2009 From: dean at fragfest.com.au (Dean Hamstead) Date: Wed Oct 21 06:40:01 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: References: Message-ID: <4ADEA668.9000401@fragfest.com.au> FWIW you can buy the case and accessories for a very reasonable cost. just click further through the blog and they link the manufacturer. its extremely cheap 90tb of zfs.... Dean grarpamp wrote: > In the somewhat related dept... > > The SiI3124 and SiI3726 seem to be *really* > popular chipsets for low cost JBOD setups > so I'm sure any work done towards this > will be a win. The only other chip I see > a lot of is the Marvell 88SX6041 and 88SX6081. > Any others, particularly of the eight port > generic card variety or other multipliers??? > I'm not sure if JMicron ever got into the 4/8 port > game. > > A somewhat related diversion: > http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/ > > And without the fab... you'd be amazed what a > bicycle inner tube, scrap pc case lids, tin snips, > hammer, anvil, drill bit, and a pop rivet tool will yield ;-) > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > -- http://fragfest.com.au From lists at c0mplx.org Wed Oct 21 06:52:34 2009 From: lists at c0mplx.org (Kurt Jaeger) Date: Wed Oct 21 06:52:41 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: References: Message-ID: <20091021065232.GD93084@home.opsec.eu> Hello, > A somewhat related diversion: > http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/ And the quite reasonable Sun answer to that: http://www.c0t0d0s0.org/archives/5899-Some-perspective-to-this-DIY-storage-server-mentioned-at-Storagemojo.html http://www.c0t0d0s0.org/archives/5906-Thoughts-about-this-DIY-Thumper-and-storage-in-general.html -- pi@opsec.eu +49 171 3101372 11 years to go ! From is at rambler-co.ru Wed Oct 21 10:31:19 2009 From: is at rambler-co.ru (Igor Sysoev) Date: Wed Oct 21 10:31:26 2009 Subject: interrupt threads CPU usage in FreeBSD 8.0 Message-ID: <20091021101243.GE3199@rambler-co.ru> Hi, for some reason in 8.0 top always shows 0% CPU usage for intr kernel process and active interrupt thread, "irq19 bge0" in my case. 8-0 RC1 top -PS: CPU 0: 27.8% user, 0.0% nice, 7.1% system, 0.0% interrupt, 65.0% idle CPU 1: 3.0% user, 0.0% nice, 2.3% system, 7.1% interrupt, 87.6% idle PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 2 171 ki31 0K 32K RUN 0 140.7H 152.54% idle 61371 nobody 1 69 -10 384M 289M kqread 0 105:56 17.77% nginx 61372 nobody 1 67 -10 384M 293M CPU0 0 106:15 16.99% nginx 12 root 15 -60 - 0K 240K WAIT 0 54:50 0.00% intr 8.0 RC1 top -PSH: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 171 ki31 0K 32K RUN 1 71.5H 81.05% {idle: cpu1} 11 root 171 ki31 0K 32K CPU0 0 69.3H 69.19% {idle: cpu0} 61372 nobody 68 -10 384M 294M kqread 0 107:06 18.99% nginx 61371 nobody 68 -10 384M 291M kqread 0 106:45 16.99% nginx 12 root -68 - 0K 240K WAIT 1 50:48 0.00% {irq19: bge0} 17 root 44 - 0K 16K syncer 1 5:23 0.00% syncer 12 root -32 - 0K 240K WAIT 1 3:06 0.00% {swi4: clock} 7.2-STABLE top -PS: CPU 0: 9.0% user, 0.0% nice, 7.9% system, 9.0% interrupt, 74.1% idle CPU 1: 23.3% user, 0.0% nice, 8.3% system, 0.0% interrupt, 68.4% idle PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K RUN 0 275.0H 83.59% idle: cpu0 11 root 1 171 ki31 0K 16K RUN 1 264.2H 76.27% idle: cpu1 16109 nobody 1 68 -10 376M 307M CPU0 1 28:05 21.97% nginx 16110 nobody 1 4 -10 376M 316M RUN 0 28:05 20.17% nginx 26 root 1 -68 - 0K 16K WAIT 0 902:39 6.69% irq19: bge0 -- Igor Sysoev http://sysoev.ru/en/ From sergey.aleynikov at gmail.com Wed Oct 21 10:59:08 2009 From: sergey.aleynikov at gmail.com (Sergey Aleynikov) Date: Wed Oct 21 10:59:16 2009 Subject: Processes stuck in *unp_mtx state Message-ID: I'm running FreeBSD 7.1-RELEASE and have application that spawnes some children and (heavily) communicates between them using pipes. But under load parent and one child both get stuck in unp_mtx state, they can't be killed (killing them puts whole system on hang). This is reproducable (i've written client emulation that causes this situation after ~5 min run). Everything else keeps running, but trying to access these stuck porcesses puts whole system on hang, so i have to perform reboot. Panic is not invoked, so i've set up ddb panic autocollecting script and had manually put system into panic. Is this a known issue in 7.1, so upgrade to 7.2 would help? I list below some info about system+ddb output: begom% uname -a FreeBSD begom.com 7.1-RELEASE FreeBSD 7.1-RELEASE #1: Mon Sep 14 07:37:56 MSD 2009 inferno@begom.com:/usr/obj/usr/src/release-7.1/sys/BEGOM i386 db:0:kdb.enter.panic> show pcpu cpuid = 1 curthread = 0x84d00d20: pid 1 "init" curpcb = 0xa940bd90 fpcurthread = none idlethread = 0x84d00af0: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x50 db:0:kdb.enter.panic> show allpcpu Current CPU: 1 cpuid = 0 curthread = 0x850e08c0: pid 1078 "mysqld" curpcb = 0xae5d4d90 fpcurthread = none idlethread = 0x84d008c0: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x50 cpuid = 1 curthread = 0x84d00d20: pid 1 "init" curpcb = 0xa940bd90 fpcurthread = none idlethread = 0x84d00af0: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x50 db:0:kdb.enter.panic> ps pid ppid pgrp uid state wmesg wchan cmd ... 89782 89764 89764 1013 L *unp_mtx 0x850b9b40 perl5.8.8 89764 1 89764 1013 Ls *unp_mtx 0x856a70f0 perl5.8.8 db:0:kdb.enter.panic> alltrace ... Tracing command perl5.8.8 pid 89764 tid 100434 td 0x85672690 sched_switch(85672690,0,1,23f76982,201f8b,...) at sched_switch+0x43b mi_switch(1,0,80831849,2d9,85bf2000,...) at mi_switch+0x146 turnstile_wait(856a70f0,85bf2000,0,8675d690,87087690,...) at turnstile_wait+0x2ec _mtx_lock_sleep(8675d720,85672690,0,0,0,...) at _mtx_lock_sleep+0x10e uipc_peeraddr(8bb431a0,ae6cac70,85672690,ae6cac80,86b74b94,...) at uipc_peeraddr+0xc5 kern_getpeername(85672690,11,ae6cac70,ae6cac6c,100,...) at kern_getpeername+0x60 getpeername(85672690,ae6cacfc,c,16,ae6cad2c,...) at getpeername+0x52 syscall(ae6cad38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (31, FreeBSD ELF32, getpeername), eip = 0x282b88db, esp = 0x7fbfeb5c, ebp = 0x7fbfeba8 --- Tracing command perl5.8.8 pid 89782 tid 100248 td 0x85bf2000 sched_switch(85bf2000,0,1,23f73c9c,201f8b,...) at sched_switch+0x43b mi_switch(1,0,80831849,2d9,805d7233,...) at mi_switch+0x146 turnstile_wait(850b9b40,85672690,0,87087690,8675d690,...) at turnstile_wait+0x2ec _mtx_lock_sleep(87087720,85bf2000,0,0,0,...) at _mtx_lock_sleep+0x10e uipc_peeraddr(8f1a8d00,ae3f4c70,ae3f4c44,4aded50c,84ff5da8,...) at uipc_peeraddr+0xc5 kern_getpeername(85bf2000,6,ae3f4c70,ae3f4c6c,100,...) at kern_getpeername+0x60 getpeername(85bf2000,ae3f4cfc,c,16,ae3f4d2c,...) at getpeername+0x52 syscall(ae3f4d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (31, FreeBSD ELF32, getpeername), eip = 0x282b88db, esp = 0x7fbfeb5c, ebp = 0x7fbfeba8 --- db:0:kdb.enter.panic> show locks No such command db:0:kdb.enter.panic> show alllocks No such command db:0:kdb.enter.panic> show lockedvnods Locked vnodes options CONFIG_AUTOGENERATED ident BEGOM machine i386 cpu I686_CPU makeoptions DEBUG=-g options ATA_STATIC_ID options SMP options AUDIT options STOP_NMI options ADAPTIVE_GIANT options KBD_INSTALL_CDEV options _KPOSIX_PRIORITY_SCHEDULING options SYSVSEM options SYSVMSG options SYSVSHM options KTRACE options SCSI_DELAY=5000 options COMPAT_FREEBSD6 options COMPAT_FREEBSD5 options COMPAT_FREEBSD4 options COMPAT_43TTY options GEOM_LABEL options GEOM_PART_GPT options PSEUDOFS options PROCFS options CD9660 options MD_ROOT options UFS_GJOURNAL options UFS_DIRHASH options UFS_ACL options SOFTUPDATES options FFS options INET options PREEMPTION options SCHED_ULE options KVA_PAGES=512 options DEVICE_POLLING options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL options INCLUDE_CONFIG_FILE options ALT_BREAK_TO_DEBUGGER options KDB_UNATTENDED options DDB options KDB options KSE options GEOM_MBR options GEOM_BSD options ISAPNP Loaded kernel modules are: linux, acpi, aio (but i've seen this both with and without aio). (part from fstat) game perl5.8.8 89764 root / 2 drwxr-xr-x 512 r game perl5.8.8 89764 wd /home 15191040 drwxr-x--x 3072 r game perl5.8.8 89764 text /usr 615835 -rwxr-xr-x 29935 r game perl5.8.8 89764 0 /dev 117 crw--w---- ttyp1 rw game perl5.8.8 89764 1 /dev 117 crw--w---- ttyp1 rw game perl5.8.8 89764 2 /dev 117 crw--w---- ttyp1 rw game perl5.8.8 89764 3* local dgram 86a8e3f0 <-> 852dc0a8 game perl5.8.8 89764 4 /var 329768 -rw-r--r-- 6 rw game perl5.8.8 89764 5 /usr 733593 -r--r--r-- 6611 r game perl5.8.8 89764 7* local stream 8678cc78 <-> 8579bc78 game perl5.8.8 89764 8* local stream 8579b000 <-> 8579bbd0 game perl5.8.8 89764 9* local stream 8678c000 <-> 86e07150 game perl5.8.8 89764 10* local stream 86e07888 <-> 86e07d20 game perl5.8.8 89764 11* local stream 865ca0a8 <-> 875d5a80 game perl5.8.8 89764 12* local stream 8678c0a8 <-> 865ca738 game perl5.8.8 89764 13* local stream 8736b540 <-> 8678c690 game perl5.8.8 89764 14* local stream 8579bdc8 <-> 8736bbd0 game perl5.8.8 89764 15* local stream 85a5a498 <-> 875d5498 game perl5.8.8 89764 16* local stream 85c2a3f0 <-> 85c2a348 game perl5.8.8 89764 17* local stream 87087690 <-> 8675d690 game perl5.8.8 89764 18* local stream 85a5a888 <-> 865ca2a0 game perl5.8.8 89764 19* local stream 852c79d8 <-> 8528e3f0 game perl5.8.8 89764 20* internet stream tcp 8d7d9570 game perl5.8.8 89764 21* internet stream tcp 85e021d0 game perl5.8.8 89764 22* internet stream tcp 899f71d0 game perl5.8.8 89764 23* internet stream tcp 8e8bd1d0 game perl5.8.8 89764 24* internet stream tcp 8c137000 game perl5.8.8 89764 25* internet stream tcp 8d39b3a0 game perl5.8.8 89764 26* internet stream tcp 85bc0000 game perl5.8.8 89764 27* internet stream tcp 8c78e570 game perl5.8.8 89764 28* internet stream tcp 8a7fa910 game perl5.8.8 89764 29* internet stream tcp 8dd6bcb0 game perl5.8.8 89764 30* internet stream tcp 8e801570 game perl5.8.8 89764 31* internet stream tcp 86635cb0 game perl5.8.8 89764 32* internet stream tcp 8cd50740 game perl5.8.8 89764 33* internet stream tcp 86656000 From kris.weston at gmail.com Wed Oct 21 12:11:33 2009 From: kris.weston at gmail.com (Kris Weston) Date: Wed Oct 21 12:11:40 2009 Subject: i am desperate over some GPT tables Message-ID: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> been looking for months now, trawled google no help, i just dont understand. do you need a GPT table with zfs ? i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to import my zpool into it exported fine on solaris , its definitely the same version (v13) but when i import into zfs it says GPT tables corrupt ? why ? and what does this mean ? please help me. pleeeeease. -- )) (( c[_] From bms at incunabulum.net Wed Oct 21 13:02:03 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Wed Oct 21 13:02:10 2009 Subject: bootless! In-Reply-To: References: Message-ID: <4ADF0648.70906@incunabulum.net> Randy Bush wrote: > is there a recipe for making a 7.2 usb? > Tried the UsbDevice command in NanoBSD? This won't give you a full FreeBSD installer, but you can build a 7.2 system with it just fine. From kostikbel at gmail.com Wed Oct 21 13:32:09 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Oct 21 13:34:32 2009 Subject: Processes stuck in *unp_mtx state In-Reply-To: References: Message-ID: <20091021133205.GQ2160@deviant.kiev.zoral.com.ua> On Wed, Oct 21, 2009 at 07:36:50PM +0900, Sergey Aleynikov wrote: > I'm running FreeBSD 7.1-RELEASE and have application that spawnes some > children and (heavily) communicates between them using pipes. But > under load parent and one child both get stuck in unp_mtx state, they > can't be killed (killing them puts whole system on hang). This is > reproducable (i've written client emulation that causes this situation > after ~5 min run). Everything else keeps running, but trying to access > these stuck porcesses puts whole system on hang, so i have to perform > reboot. Panic is not invoked, so i've set up ddb panic autocollecting > script and had manually put system into panic. > > Is this a known issue in 7.1, so upgrade to 7.2 would help? I list > below some info about system+ddb output: I believe this is fixed by r194460 in HEAD and merged to RELENG_7 by 194967at the end of June, that was after 7.2. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091021/5280f8e5/attachment.pgp From sergey.aleynikov at gmail.com Wed Oct 21 14:08:41 2009 From: sergey.aleynikov at gmail.com (Sergey Aleynikov) Date: Wed Oct 21 14:08:47 2009 Subject: Processes stuck in *unp_mtx state In-Reply-To: <20091021133205.GQ2160@deviant.kiev.zoral.com.ua> References: <20091021133205.GQ2160@deviant.kiev.zoral.com.ua> Message-ID: 2009/10/21 Kostik Belousov : > I believe this is fixed by r194460 in HEAD and merged to RELENG_7 by > 194967at the end of June, that was after 7.2. > I'll try to upgrade to RELENG_7 tomorrow and see if it helps. From marck at rinet.ru Wed Oct 21 16:29:18 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Oct 21 16:29:25 2009 Subject: Adaptec 1420SA identification trouble (again) In-Reply-To: References: Message-ID: On Sun, 18 Oct 2009, Dmitry Morozovsky wrote: DM> I'm having trouble attaching 1420SA controller (just one KBOD disk attached DM> to it) with fresh stable/7: DM> DM> none4@pci0:3:0:0: class=0x010400 card=0x02419005 chip=0x02419005 rev=0x01 hdr=0x00 DM> vendor = 'Adaptec Inc' DM> device = 'Serial ATA II RAID 1420SA' DM> class = mass storage DM> subclass = RAID DM> DM> No references to device 3.0 at pci0 in verbose dmesg. DM> DM> AFAICS, ddf sources have been merged to releng/7. DM> DM> Any hints? Thanks in advance. For the reference: As mav@ pointed out, HW support for Adaptec's variant of Marvell controller did not committed to stable/7; this is fixed by SVN rev 198334. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From korvus at comcast.net Wed Oct 21 17:28:48 2009 From: korvus at comcast.net (Steve Polyack) Date: Wed Oct 21 17:28:55 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4ADE060C.5050605@comcast.net> References: <4ADE060C.5050605@comcast.net> Message-ID: <4ADF44CE.3030605@comcast.net> Alexander Motin wrote: > Have you tried new CAM-based ATA subsystem present in 8.x by siis(4) > driver? Work is still in progress there, but it should work with port > multipliers much better then previous implementation. Indeed, the siis(4) driver works MUCH better. However, it's still not always detecting every drive if I fill a port multiplier with 5/5 drives. Sometimes it boots up with 4, sometimes with 5. Snippet from the dmesg in my other reply: siisch4: Timeout on slot 25 siisch4: siis_timeout is 00000000 ss 02000000 rs 02000000 es 00000000 sts 80192000 serr 00000000 (aprobe0:siisch4:0:1:0): SIGNATURE: 0000 (aprobe0:siisch4:0:2:0): SIGNATURE: 0000 (aprobe0:siisch4:0:3:0): SIGNATURE: 0000 (aprobe0:siisch4:0:4:0): SIGNATURE: 0000 ada0 at siisch4 bus 0 target 1 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled siisch4 bus 0 target 0 lun 0 is missing here, due to some kind of timeout. The drives are fine and the missing device does not follow a specific physical drive. Lastly, using camcontrol to rescan port multipliers and attached drives only leads to failure. Rescanning everythign simply loses all but one drive attached to each port multiplier. From alson+ml at alm.flutnet.org Wed Oct 21 18:01:12 2009 From: alson+ml at alm.flutnet.org (Alson van der Meulen) Date: Wed Oct 21 18:01:19 2009 Subject: fatal trap 12 in em1 taskq after upgrade to 7.2-REL Message-ID: <20091021180059.GB1847@tafi.alm.flutnet.org> Hello, I recently upgraded a server from RELENG_6_4 to RELENG_7_2 (both i386). Since then, the box has started crashing regularly. The longest uptime since the upgrade is 1d5h, the shortest is 2m35s. The backtrace is always similar: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x400 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0adc79e stack pointer = 0x28:0xe585fc10 frame pointer = 0x28:0xe585fc24 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 = 34 (em1 taskq) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c0ba8989,e585faac,c07f2ab9,c0bca1e0,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0bca1e0,0,c0b61aee,e585fab8,0,...) at kdb_backtrace+0x29 panic(c0b61aee,c0bcb510,c56294dc,1,1,...) at panic+0x119 trap_fatal(c0cd3ec0,0,1,0,14,...) at trap_fatal+0x333 trap_pfault(0,20111ac,0,0,c56292b8,...) at trap_pfault+0x270 trap(e585fbd0) at trap+0x3fa calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0adc79e, esp = 0xe585fc10, ebp = 0xe585fc24 --- _bus_dmamap_sync(c5615400,400,2,c5612690,0,...) at _bus_dmamap_sync+0xe em_rxeof(246,c5612690,e585fca4,c5612690,e585fc9c,...) at em_rxeof+0x14a em_handle_rxtx(c5635000,1,c5615380,c561539c,c0ba076a,...) at em_handle_rxtx+0x27 taskqueue_run(c5615380,c561539c,c0ba076a,0,e585fcf4,...) at taskqueue_run+0x175 taskqueue_thread_loop(c563935c,e585fd38,36626334,64636435,39396362,...) at taskqueue_thread_loop+0xc8 fork_exit(c08285a0,c563935c,e585fd38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe585fd70, ebp = 0 --- Uptime: 28m55s Physical memory: 2027 MB Dumping 194 MB: 179 163 147 131 115 99 83 67 51 35 19 3 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort em1: watchdog timeout -- resetting Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x400 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0adc79e stack pointer = 0x28:0xc53e0c00 frame pointer = 0x28:0xc53e0c14 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 = 14 (swi4: clock sio) trap number = 12 Rebooting... The second fatal trap output is usually corrupted in the serial console output. This box has been running 6.4 (and 6.3 and so on) without crashes for at least a year, so a sudden hardware failure seems unlikely. It's an Intel entry level server mainboard with a P4 (with HT) and dual onboard em(4). The server is currently mostly idle, especially em1. Dmesg: Copyright (c) 1992-2009 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.2-RELEASE-p4 #0: Tue Oct 20 04:15:46 CEST 2009 root@eraser.waalsdorp.nl:/usr/obj/usr/src/sys/ERASER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2992.71-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf43 Stepping = 3 Features=0xbfebfbff Features2=0x649d AMD Features=0x20000000 Logical CPUs per core: 2 real memory = 2138984448 (2039 MB) avail memory = 2083450880 (1986 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 500, 10 (4) failed acpi0: reservation of 560, 20 (4) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7f700000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xcb80-0xcb87 mem 0xdfd00000-0xdfd7ffff,0xc0000000-0xcfffffff,0xdfd80000-0xdfdbffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M pcib1: irq 16 at device 28.0 on pci0 pci2: on pcib1 pcib2: at device 0.0 on pci2 pci4: on pcib2 em0: port 0xef80-0xefbf mem 0xdffe0000-0xdfffffff irq 27 at device 3.0 on pci4 em0: [FILTER] em0: Ethernet address: 00:0e:0c:4b:4b:89 pcib3: at device 0.2 on pci2 pci3: on pcib3 uhci0: port 0xcc00-0xcc1f irq 23 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 0xcc80-0xcc9f irq 19 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 0xcd00-0xcd1f irq 18 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 ehci0: mem 0xdfdff800-0xdfdffbff irq 23 at device 29.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 pcib4: at device 30.0 on pci0 pci1: on pcib4 puc0: port 0xdf00-0xdf1f,0xde80-0xde87,0xde00-0xde07 irq 21 at device 2.0 on pci1 puc0: [FILTER] uart0: <16550 or compatible> on puc0 uart0: [FILTER] uart1: <16550 or compatible> on puc0 uart1: [FILTER] em1: port 0xdf80-0xdfbf mem 0xdfee0000-0xdfefffff irq 18 at device 3.0 on pci1 em1: [FILTER] em1: Ethernet address: 00:0e:0c:4b:4b:88 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376 at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xcf80-0xcf87,0xcf00-0xcf03,0xce80-0xce87,0xce00-0xce03,0xcd80-0xcd8f mem 0xdfdffc00-0xdfdfffff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.00 controller with 4 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ichsmb0: port 0x400-0x41f irq 19 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 ipmi0: on smbus0 ipmi0: SSIF mode found at address 0x42 on smbus acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr f2b00000f2b 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 f2b00000f2b device_attach: est1 attach returned 6 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc9800-0xca7ff,0xca800-0xcb7ff,0xcb800-0xcc7ff,0xdc000-0xdffff 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 acd0: CDRW at ata0-master UDMA33 ad4: 953869MB at ata2-master SATA150 ad6: 953869MB at ata3-master SATA150 ad8: 35304MB at ata4-master SATA150 ad10: 35304MB at ata5-master SATA150 ipmi0: IPMI device rev. 1, firmware rev. 2.81, version 1.5 ipmi0: Number of channels 0 ipmi0: Attached watchdog SMP: AP CPU #1 Launched! kernel config is GENERIC plus: device puc options ALT_BREAK_TO_DEBUGGER options DDB options KDB_TRACE options KDB_UNATTENDED device smbus device smb device ichsmb options ROUTETABLES=2 regards, Alson From mav at FreeBSD.org Wed Oct 21 20:58:06 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 21 20:58:14 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4ADF44CE.3030605@comcast.net> References: <4ADE060C.5050605@comcast.net> <4ADF44CE.3030605@comcast.net> Message-ID: <4ADF75DA.8040707@FreeBSD.org> Steve Polyack wrote: > Alexander Motin wrote: >> Have you tried new CAM-based ATA subsystem present in 8.x by siis(4) >> driver? Work is still in progress there, but it should work with port >> multipliers much better then previous implementation. > > Indeed, the siis(4) driver works MUCH better. However, it's still not > always detecting every drive if I fill a port multiplier with 5/5 > drives. Sometimes it boots up with 4, sometimes with 5. > > Snippet from the dmesg in my other reply: > siisch4: Timeout on slot 25 > siisch4: siis_timeout is 00000000 ss 02000000 rs 02000000 es 00000000 > sts 80192000 serr 00000000 > (aprobe0:siisch4:0:1:0): SIGNATURE: 0000 > (aprobe0:siisch4:0:2:0): SIGNATURE: 0000 > (aprobe0:siisch4:0:3:0): SIGNATURE: 0000 > (aprobe0:siisch4:0:4:0): SIGNATURE: 0000 > ada0 at siisch4 bus 0 target 1 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing enabled > > siisch4 bus 0 target 0 lun 0 is missing here, due to some kind of > timeout. The drives are fine and the missing device does not follow a > specific physical drive. Lastly, using camcontrol to rescan port > multipliers and attached drives only leads to failure. Rescanning > everythign simply loses all but one drive attached to each port multiplier. As I have said, infrastructure is not finished yet, especially part of recovery from timeout state. That's why probably rescan does not solve situation. From other side, this timeout may be called by some driver issue, as it looks too repeatable. If your conditions permit, you can try to upgrade to recent HEAD to look how will it go with newer code. I am periodically merging my work there from Perforce. Also I am going to generate new test patch for HEAD, which includes reworked PMP support, tomorrow. I will put it to http://people.freebsd.org/~mav/ as usual, so you can test it. -- Alexander Motin From sergey.aleynikov at gmail.com Thu Oct 22 03:53:43 2009 From: sergey.aleynikov at gmail.com (Sergey Aleynikov) Date: Thu Oct 22 03:53:50 2009 Subject: Processes stuck in *unp_mtx state In-Reply-To: <20091021133205.GQ2160@deviant.kiev.zoral.com.ua> References: <20091021133205.GQ2160@deviant.kiev.zoral.com.ua> Message-ID: 2009/10/21 Kostik Belousov : > I believe this is fixed by r194460 in HEAD and merged to RELENG_7 by > 194967at the end of June, that was after 7.2. After half an our of stress testing problem seams to disappear. Thanks for your advice. From mav at FreeBSD.org Thu Oct 22 09:55:36 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 22 09:55:48 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4ADF75DA.8040707@FreeBSD.org> References: <4ADE060C.5050605@comcast.net> <4ADF44CE.3030605@comcast.net> <4ADF75DA.8040707@FreeBSD.org> Message-ID: <4AE02C14.6060709@FreeBSD.org> Alexander Motin wrote: > If your conditions permit, you can try to upgrade to recent HEAD to look > how will it go with newer code. I am periodically merging my work there > from Perforce. Also I am going to generate new test patch for HEAD, > which includes reworked PMP support, tomorrow. You can try this patch against today's HEAD: http://people.freebsd.org/~mav/cam-ata.20091022.patch -- Alexander Motin From pluknet at gmail.com Thu Oct 22 14:30:25 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 22 14:30:38 2009 Subject: mfi(4) endless loop kernel output on attach In-Reply-To: <200910150853.49850.jhb@freebsd.org> References: <200910150853.49850.jhb@freebsd.org> Message-ID: 2009/10/15 John Baldwin : > On Thursday 15 October 2009 5:51:19 am pluknet wrote: >> Hi. >> >> This is 7.2-R. Seen on IBM x3650M2. >> >> During the boot I get those endless looping kernel messages while on >> mfi(4) attach phase. >> It's getting more odd since 7.2 booted and worked fine on exactly this >> server model >> months ago (on different box though).. Any hints? > > We just had some boxes die like this (but spewing a different loop of messages > on boot related to continuously scheduling patrol reads and consistency > checks that finished immediately) at work. ?We fixed them by swapping out the > controller. ?We might try stick them in a different box and reflashing them > using mfiutil(8) to see if it's some sort of corrupted state that flashing > the adapter fixes. > > In your case it looks lik the firmware keeps crashing and restarting. > Some more thoughts.. There was a problem I got with 'MegaCli -AdpBbuCmd -BbuLearn -aall' command. On 6.2-R process slept on mfiwait wchan: db> bt 14734 Tracing pid 14734 tid 100135 td 0xc93f8190 sched_switch(c93f8190,0,1) at sched_switch+0x143 mi_switch(1,0,c93f8190,f9a32acc,c06a43a4,...) at mi_switch+0x1ba sleepq_switch(c8c6b0d0) at sleepq_switch+0x87 sleepq_wait(c8c6b0d0,0,c93f8190,c8c6b0d0,c8c25800,...) at sleepq_wait+0x5c msleep(c8c6b0d0,c8c25954,4c,c090acbc,0) at msleep+0x269 mfi_wait_command(c8c25800,c8c6b0d0,0,0,cc382460,...) at mfi_wait_command+0xa8 mfi_ioctl(c8c31300,c1144d01,cc870a00,1,c93f8190,...) at mfi_ioctl+0x485 devfs_ioctl_f(c90a2750,c1144d01,cc870a00,c9048000,c93f8190) at devfs_ioctl_f+0xaf ioctl(c93f8190,f9a32d04) at ioctl+0x445 syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = 0xbfbfe88c, ebp = 0xbfbfe8b8 --- Then: mfi0: COMMAND 0xc8c6b0d0 TIMEOUT AFTER 51 SECONDS mfi0: COMMAND 0xc8c61d50 TIMEOUT AFTER 49 SECONDS mfi0: COMMAND 0xc8c61850 TIMEOUT AFTER 49 SECONDS On 6.4-R MegaCli throws a page fault due to NULL deref in mfi_data_cb():cm->cm_sg (see below). There was past 6.4 backport mentioning "fix some bugs in the API for the management ioctl." With this patch I have no longer panic and/or locks. Thanks to LSI now on 7.2-R (and on patched 6.4-R) it returns an error: # ./MegaCli -AdpBbuCmd -BbuLearn -aall Adapter 0: BBU Learn Failed Exit Code: 0x32 db> bt Tracing pid 43059 tid 101363 td 0xcf46e680 mfi_data_cb(c9cfae00,c9cc3e00,1,0) at mfi_data_cb+0x5e bus_dmamap_load(c9cd7c80,0,caf86270,0,c0597240,c9cfae00,0) at bus_dmamap_load+0x4a1 mfi_mapcmd(c9cc3800,c9cfae00) at mfi_mapcmd+0x31 mfi_startio(c9cc3800) at mfi_startio+0x9b mfi_wait_command(c9cc3800,c9cfae00,0,0,caf86270,...) at mfi_wait_command+0x89 mfi_ioctl(c9cf7200,c1144d01,d3fb6200,1,cf46e680,...) at mfi_ioctl+0x52a devfs_ioctl_f(d1a551b0,c1144d01,d3fb6200,cbf52c80,cf46e680) at devfs_ioctl_f+0xaf ioctl(cf46e680,fbd91d04) at ioctl+0x445 syscall(3b,3b,3b,0,bfbfedc0,...) at syscall+0x2bf Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x8177207, esp = 0xbfbfe88c, ebp = 0xbfbfe8b8 #9 0xc08cbb1a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, nsegs=1, ---Type to continue, or q to quit--- error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 #11 0xc08c7afd in bus_dmamap_load (dmat=0xc8a6f100, map=0xac89e000, buf=0xc8a5ac60, buflen=0, callback=0xc0597240 , callback_arg=0xc8a744b0, flags=0) at /usr/src/sys/i386/i386/busdma_machdep.c:733 #12 0xc059721d in mfi_mapcmd (sc=0xc8a49800, cm=0xc8a49e00) at /usr/src/sys/dev/mfi/mfi.c:1452 #13 0xc0597177 in mfi_startio (sc=0xc8a49800) at /usr/src/sys/dev/mfi/mfi.c:1436 #14 0xc0595f09 in mfi_wait_command (sc=0xc8a49800, cm=0xc8a744b0) at /usr/src/sys/dev/mfi/mfi.c:822 #15 0xc059840a in mfi_ioctl (dev=0xac89e000, cmd=0, arg=0xc8de8800 "", flag=1, td=0xc8a5ac60) at /usr/src/sys/dev/mfi/mfi.c:2061 #16 0xc06598b7 in devfs_ioctl_f (fp=0xc902dc18, com=3239333121, data=0xc8de8800, cred=0xc9052980, td=0xc8e2dd00) at /usr/src/sys/fs/devfs/devfs_vnops.c:480 #17 0xc06d3a11 in ioctl (td=0xc8e2dd00, uap=0xeb37bd04) at file.h:265 (kgdb) f 10 #10 0xc059729e in mfi_data_cb (arg=0xc8a744b0, segs=0xc8a49e00, nsegs=1, error=0) at /usr/src/sys/dev/mfi/mfi.c:1488 1488 sgl->sg32[i].addr = segs[i].ds_addr; (kgdb) list 1483 return; 1484 } 1485 1486 if ((sc->mfi_flags & MFI_FLAGS_SG64) == 0) { 1487 for (i = 0; i < nsegs; i++) { 1488 sgl->sg32[i].addr = segs[i].ds_addr; 1489 sgl->sg32[i].len = segs[i].ds_len; 1490 } 1491 } else { 1492 for (i = 0; i < nsegs; i++) { (kgdb) p i $1 = 0 (kgdb) p *segs $3 = {ds_addr = 2457600, ds_len = 65536} (kgdb) p sgl $4 = (union mfi_sgl *) 0x0 (kgdb) p *cm $6 = {cm_link = {tqe_next = 0x0, tqe_prev = 0xc8a49814}, cm_timestamp = 0, cm_sc = 0xc8a49800, cm_frame = 0xe8fee680, cm_frame_busaddr = 3748513408, cm_sense = 0xe904c780, cm_sense_busaddr = 3749103488, cm_dmamap = 0x0, cm_sg = 0x0, cm_data = 0xc8a5ac60, cm_len = 0, cm_total_frame_size = 0, cm_extra_frames = 0, cm_flags = 6, cm_aen_abort = 0, cm_complete = 0, cm_private = 0x0, cm_index = 15, cm_error = 0} -- wbr, pluknet From korvus at comcast.net Thu Oct 22 15:01:37 2009 From: korvus at comcast.net (Steve Polyack) Date: Thu Oct 22 15:01:43 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE04F73.1050703@comcast.net> References: <4AE04F73.1050703@comcast.net> Message-ID: <4AE073CF.40500@comcast.net> Alexander Motin wrote: >> If your conditions permit, you can try to upgrade to recent HEAD to look >> how will it go with newer code. I am periodically merging my work there >> from Perforce. Also I am going to generate new test patch for HEAD, >> which includes reworked PMP support, tomorrow. >> > > You can try this patch against today's HEAD: > http://people.freebsd.org/~mav/cam-ata.20091022.patch > > I tried the patch this morning against a fresh checkout of HEAD. Immediately after boot only one device per PM was detected (I have two hooked up at the moment, 5 drives on one, 1 on the other). However, about two minutes later all of the drives showed up! camcontrol also rescans the entire bus *very* quickly now, and discovers all changes (new/missing disks and port multipliers). Here's some verbose info from /var/log/messages immediately after boot: Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is 00000000 ss 08000000 rs 08000000 es 00000000 sts 801b2000 serr 00000000 Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout status=00000001 Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:52:05 lovepod kernel: siisch0: CONNECT requested Oct 22 10:52:05 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:05 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:05 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:05 lovepod kernel: siisch0: SATA connect time=0ms status=00000123 Oct 22 10:52:05 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:52:05 lovepod kernel: siisch0: SIIS reset done: devices=00000001 Oct 22 10:52:33 lovepod kernel: siisch0: Timeout on slot 28 Oct 22 10:52:33 lovepod kernel: siisch0: siis_timeout is 00000000 ss 10000000 rs 10000000 es 00000000 sts 801c2000 serr 00000000 Oct 22 10:52:33 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:33 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:33 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:33 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:33 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:33 lovepod kernel: siisch0: SATA connect timeout status=00000001 Oct 22 10:52:33 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:52:33 lovepod kernel: (aprobe0:siisch0:0:2:0): Command timed out Oct 22 10:52:33 lovepod kernel: (aprobe0:siisch0:0:2:0): error 5 Oct 22 10:52:33 lovepod kernel: (aprobe0:siisch0:0:2:0): Retries Exhausted Oct 22 10:52:33 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:52:35 lovepod kernel: siisch0: CONNECT requested Oct 22 10:52:35 lovepod kernel: siisch0: SIIS reset... Oct 22 10:52:35 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:52:35 lovepod kernel: siisch0: hardware reset ... Oct 22 10:52:35 lovepod kernel: siisch0: SATA connect time=0ms status=00000123 Oct 22 10:52:35 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:52:35 lovepod kernel: siisch0: SIIS reset done: devices=00000001 Oct 22 10:53:03 lovepod kernel: siisch0: Timeout on slot 29 Oct 22 10:53:03 lovepod kernel: siisch0: siis_timeout is 00000000 ss 20000000 rs 20000000 es 00000000 sts 801d2000 serr 00000000 Oct 22 10:53:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:03 lovepod kernel: siisch0: SIIS reset... Oct 22 10:53:03 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:03 lovepod kernel: siisch0: hardware reset ... Oct 22 10:53:03 lovepod kernel: siisch0: SATA connect timeout status=00000001 Oct 22 10:53:03 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:53:03 lovepod kernel: (aprobe0:siisch0:0:3:0): Command timed out Oct 22 10:53:03 lovepod kernel: (aprobe0:siisch0:0:3:0): error 5 Oct 22 10:53:03 lovepod kernel: (aprobe0:siisch0:0:3:0): Retries Exhausted Oct 22 10:53:03 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:53:05 lovepod kernel: siisch0: CONNECT requested Oct 22 10:53:05 lovepod kernel: siisch0: SIIS reset... Oct 22 10:53:05 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:05 lovepod kernel: siisch0: hardware reset ... Oct 22 10:53:05 lovepod kernel: siisch0: SATA connect time=0ms status=00000123 Oct 22 10:53:05 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:53:05 lovepod kernel: siisch0: SIIS reset done: devices=00000001 Oct 22 10:53:34 lovepod kernel: siisch0: Timeout on slot 30 Oct 22 10:53:34 lovepod kernel: siisch0: siis_timeout is 00000000 ss 40000000 rs 40000000 es 00000000 sts 801e2000 serr 00000000 Oct 22 10:53:34 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:34 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:34 lovepod kernel: siisch0: SIIS reset... Oct 22 10:53:34 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:34 lovepod kernel: siisch0: hardware reset ... Oct 22 10:53:34 lovepod kernel: siisch0: SATA connect timeout status=00000001 Oct 22 10:53:34 lovepod kernel: siisch0: SIIS reset done: phy reset found no device Oct 22 10:53:34 lovepod kernel: (aprobe0:siisch0:0:4:0): Command timed out Oct 22 10:53:34 lovepod kernel: (aprobe0:siisch0:0:4:0): error 5 Oct 22 10:53:34 lovepod kernel: (aprobe0:siisch0:0:4:0): Retries Exhausted Oct 22 10:53:34 lovepod kernel: siisch0: DISCONNECT requested Oct 22 10:53:36 lovepod kernel: siisch0: CONNECT requested Oct 22 10:53:36 lovepod kernel: siisch0: SIIS reset... Oct 22 10:53:36 lovepod kernel: siisch0: ready wait time=1ms Oct 22 10:53:36 lovepod kernel: siisch0: hardware reset ... Oct 22 10:53:36 lovepod kernel: siisch0: SATA connect time=0ms status=00000123 Oct 22 10:53:36 lovepod kernel: siisch0: ready wait time=0ms Oct 22 10:53:36 lovepod kernel: siisch0: SIIS reset done: devices=00000001 Oct 22 10:53:36 lovepod kernel: PMP freeze: 0 Oct 22 10:53:36 lovepod kernel: PMP freeze: 1 Oct 22 10:53:36 lovepod kernel: PMP freeze: 2 Oct 22 10:53:36 lovepod kernel: PMP freeze: 3 Oct 22 10:53:36 lovepod kernel: PMP freeze: 4 Oct 22 10:53:51 lovepod kernel: PM ports: 5 Oct 22 10:53:51 lovepod kernel: PM RESET 0 Oct 22 10:53:51 lovepod kernel: PM RESET 1 Oct 22 10:53:51 lovepod kernel: PM RESET 2 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: PM RESET 3 Oct 22 10:53:51 lovepod kernel: PM RESET 4 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: PM reset done Oct 22 10:53:51 lovepod kernel: PM connect done Oct 22 10:53:51 lovepod kernel: PM status: 0 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 1 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 2 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 3 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 4 - 00000123 Oct 22 10:53:51 lovepod kernel: PMP release: 0 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:0:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass4 at siisch0 bus 0 scbus0 target 0 lun 0 Oct 22 10:53:51 lovepod kernel: pass4: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass4: Serial Number 9VS2FJJR Oct 22 10:53:51 lovepod kernel: pass4: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada2 at siisch0 bus 0 scbus0 target 0 lun 0GEOM: new disk ada2 Oct 22 10:53:51 lovepod kernel: ada2: Oct 22 10:53:51 lovepod kernel: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada2: Serial Number 9VS2FJJR Oct 22 10:53:51 lovepod kernel: ada2: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Oct 22 10:53:51 lovepod kernel: ada2: Native Command Queueing enabled Oct 22 10:53:51 lovepod kernel: PMP release: 1 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:1:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass5 at siisch0 bus 0 scbus0 target 1 lun 0 Oct 22 10:53:51 lovepod kernel: pass5: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass5: Serial Number 9VS2DYEQ Oct 22 10:53:51 lovepod kernel: pass5: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada3 at siisch0 bus 0 scbus0 target 1 lun 0 Oct 22 10:53:51 lovepod kernel: ada3: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada3: Serial Number 9VS2DYEQ Oct 22 10:53:51 lovepod kernel: ada3: 300.000MB/s transfers Oct 22 10:53:36 lovepod kernel: PMP freeze: 4 Oct 22 10:53:51 lovepod kernel: PM ports: 5 Oct 22 10:53:51 lovepod kernel: PM RESET 0 Oct 22 10:53:51 lovepod kernel: PM RESET 1 Oct 22 10:53:51 lovepod kernel: PM RESET 2 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: PM RESET 3 Oct 22 10:53:51 lovepod kernel: PM RESET 4 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: siisch0: SNTF 0x0000 Oct 22 10:53:51 lovepod kernel: PM reset done Oct 22 10:53:51 lovepod kernel: PM connect done Oct 22 10:53:51 lovepod kernel: PM status: 0 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 1 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 2 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 3 - 00000123 Oct 22 10:53:51 lovepod kernel: PM status: 4 - 00000123 Oct 22 10:53:51 lovepod kernel: PMP release: 0 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:0:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass4 at siisch0 bus 0 scbus0 target 0 lun 0 Oct 22 10:53:51 lovepod kernel: pass4: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass4: Serial Number 9VS2FJJR Oct 22 10:53:51 lovepod kernel: pass4: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada2 at siisch0 bus 0 scbus0 target 0 lun 0GEOM: new disk ada2 Oct 22 10:53:51 lovepod kernel: ada2: Oct 22 10:53:51 lovepod kernel: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada2: Serial Number 9VS2FJJR Oct 22 10:53:51 lovepod kernel: ada2: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada2: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Oct 22 10:53:51 lovepod kernel: ada2: Native Command Queueing enabled Oct 22 10:53:51 lovepod kernel: PMP release: 1 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:1:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass5 at siisch0 bus 0 scbus0 target 1 lun 0 Oct 22 10:53:51 lovepod kernel: pass5: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass5: Serial Number 9VS2DYEQ Oct 22 10:53:51 lovepod kernel: pass5: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada3 at siisch0 bus 0 scbus0 target 1 lun 0 Oct 22 10:53:51 lovepod kernel: ada3: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada3: Serial Number 9VS2DYEQ Oct 22 10:53:51 lovepod kernel: ada3: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada3: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Oct 22 10:53:51 lovepod kernel: ada3: Native Command Queueing enabled Oct 22 10:53:51 lovepod kernel: PMP release: 2 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:2:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass6 at siisch0 bus 0 scbus0 target 2 lun 0 Oct 22 10:53:51 lovepod kernel: pass6: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass6: Serial Number 9VS2FJQ0 Oct 22 10:53:51 lovepod kernel: pass6: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada4 at siisch0 bus 0 scbus0 target 2 lun 0 Oct 22 10:53:51 lovepod kernel: ada4: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada4: Serial Number 9VS2FJQ0 Oct 22 10:53:51 lovepod kernel: ada4: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada4: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Oct 22 10:53:51 lovepod kernel: ada4: Native Command Queueing enabled Oct 22 10:53:51 lovepod kernel: PMP release: 3 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:3:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass7 at siisch0 bus 0 scbus0 target 3 lun 0 Oct 22 10:53:51 lovepod kernel: pass7: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass7: Serial Number 9VS2FG9C Oct 22 10:53:51 lovepod kernel: pass7: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada5 at siisch0 bus 0 scbus0 target 3 lun 0 Oct 22 10:53:51 lovepod kernel: ada5: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada5: Serial Number 9VS2FG9C Oct 22 10:53:51 lovepod kernel: ada5: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada5: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Oct 22 10:53:51 lovepod kernel: ada5: Native Command Queueing enabled Oct 22 10:53:51 lovepod kernel: PMP release: 4 Oct 22 10:53:51 lovepod kernel: (aprobe0:siisch0:0:4:0): SIGNATURE: 0000 Oct 22 10:53:51 lovepod kernel: pass8 at siisch0 bus 0 scbus0 target 4 lun 0 Oct 22 10:53:51 lovepod kernel: pass8: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: pass8: Serial Number 9VS2DH15 Oct 22 10:53:51 lovepod kernel: pass8: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada6 at siisch0 bus 0 scbus0 target 4 lun 0 Oct 22 10:53:51 lovepod kernel: ada6: ATA/ATAPI-8 SATA 2.x device Oct 22 10:53:51 lovepod kernel: ada6: Serial Number 9VS2DH15 Oct 22 10:53:51 lovepod kernel: ada6: 300.000MB/s transfers Oct 22 10:53:51 lovepod kernel: ada6: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Oct 22 10:53:51 lovepod kernel: ada6: Native Command Queueing enabled Oct 22 10:53:51 lovepod kernel: GEOM: new disk ada3 Oct 22 10:53:51 lovepod kernel: GEOM: new disk ada4 Oct 22 10:53:51 lovepod kernel: GEOM: new disk ada5 Oct 22 10:53:51 lovepod kernel: GEOM: new disk ada6 From Johan at double-l.nl Thu Oct 22 15:07:40 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Thu Oct 22 15:07:47 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> Hello all I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 server. It fails to detect the Broadcom network interface. Pciconf -lv gives me the following. none3@pci0:4:0:0: class=0x020000 card=0x705d10c chip=0x165b14e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' class = network Subclass = Ethernet Is there something I can do, other than install an other network card? Regards, Johan Hendriks From mav at FreeBSD.org Thu Oct 22 17:43:56 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 22 17:44:11 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE073CF.40500@comcast.net> References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> Message-ID: <4AE099D8.5060103@FreeBSD.org> Steve Polyack wrote: > Alexander Motin wrote: >>> If your conditions permit, you can try to upgrade to recent HEAD to look >>> how will it go with newer code. I am periodically merging my work there >>> from Perforce. Also I am going to generate new test patch for HEAD, >>> which includes reworked PMP support, tomorrow. >> >> You can try this patch against today's HEAD: >> http://people.freebsd.org/~mav/cam-ata.20091022.patch >> > I tried the patch this morning against a fresh checkout of HEAD. > Immediately after boot only one device per PM was detected (I have two > hooked up at the moment, 5 drives on one, 1 on the other). However, > about two minutes later all of the drives showed up! > > camcontrol also rescans the entire bus *very* quickly now, and discovers > all changes (new/missing disks and port multipliers). > > Here's some verbose info from /var/log/messages immediately after boot: > Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 > Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is 00000000 ss > 08000000 rs 08000000 es 00000000 sts 801b2000 serr 00000000 > Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms > Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms > Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... > Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms > Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... > Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout > status=00000001 > Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset > found no device > Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out > Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 > Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted > Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested What was before that? Can you send me full verbose boot messages? -- Alexander Motin From marius at nuenneri.ch Thu Oct 22 18:22:52 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Oct 22 18:22:59 2009 Subject: ale0 gets no carrier Message-ID: Hi Pyun, all, today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros nic: ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet ale0: flags=8802 metric 0 mtu 1500 options=319a ether 00:24:8c:a4:0a:b3 media: Ethernet autoselect (none) status: no carrier The nic gets no carrier at all. I tried against two known-working nics with a cross-over cable and against a dsl-modem. Any idea what to try? Will happily test patches. - Marius From pyunyh at gmail.com Thu Oct 22 18:36:50 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 22 18:36:57 2009 Subject: ale0 gets no carrier In-Reply-To: References: Message-ID: <20091022183643.GA1116@michelle.cdnetworks.com> On Thu, Oct 22, 2009 at 08:22:50PM +0200, Marius N?nnerich wrote: > Hi Pyun, all, > > today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros nic: > ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > class = network > subclass = ethernet > > ale0: flags=8802 metric 0 mtu 1500 > options=319a > ether 00:24:8c:a4:0a:b3 > media: Ethernet autoselect (none) > status: no carrier > > The nic gets no carrier at all. I tried against two known-working nics > with a cross-over cable and against a dsl-modem. > Any idea what to try? Will happily test patches. > Would you show me dmesg output related with ale(4)/atphy(4)? Also show me the output "devinfo -rv | grep phy". From marius at nuenneri.ch Thu Oct 22 18:39:58 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Oct 22 18:40:06 2009 Subject: ale0 gets no carrier In-Reply-To: <20091022183643.GA1116@michelle.cdnetworks.com> References: <20091022183643.GA1116@michelle.cdnetworks.com> Message-ID: On Thu, Oct 22, 2009 at 20:36, Pyun YongHyeon wrote: > On Thu, Oct 22, 2009 at 08:22:50PM +0200, Marius N?nnerich wrote: >> Hi Pyun, all, >> >> today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros nic: >> ale0@pci0:2:0:0: ? ? ? ?class=0x020000 card=0x831c1043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> ? ? vendor ? ? = 'Attansic (Now owned by Atheros)' >> ? ? device ? ? = 'PCI-E ETHERNET CONTROLLER ?(AR8121/AR8113 )' >> ? ? class ? ? ?= network >> ? ? subclass ? = ethernet >> >> ale0: flags=8802 metric 0 mtu 1500 >> ? ? ? ? options=319a >> ? ? ? ? ether 00:24:8c:a4:0a:b3 >> ? ? ? ? media: Ethernet autoselect (none) >> ? ? ? ? status: no carrier >> >> The nic gets no carrier at all. I tried against two known-working nics >> with a cross-over cable and against a dsl-modem. >> Any idea what to try? Will happily test patches. >> > > Would you show me dmesg output related with ale(4)/atphy(4)? > Also show me the output "devinfo -rv | grep phy". Sure: % dmesg|grep ale ale0: port 0xdc00-0xdc7f mem 0xfbec0000-0xfbefffff irq 18 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 ale0: Ethernet address: 00:24:8c:a4:0a:b3 ale0: [FILTER] ale0: link state changed to DOWN % dmesg|grep atphy atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto % devinfo -rv | grep phy atphy0 pnpinfo oui=0x1374 model=0x1 rev=0x9 at phyno=0 ip1000phy0 pnpinfo oui=0x90c3 model=0x8 rev=0x0 at phyno=24 It is a GENERIC kernel. From mike at sentex.net Thu Oct 22 19:05:41 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Oct 22 19:05:48 2009 Subject: ale0 gets no carrier In-Reply-To: References: Message-ID: <200910221905.n9MJ5dsO063534@lava.sentex.ca> At 02:22 PM 10/22/2009, Marius N?nnerich wrote: >Hi Pyun, all, > >today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros nic: >ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 chip=0x10261969 >rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > class = network > subclass = ethernet > >ale0: flags=8802 metric 0 mtu 1500 > >options=319a > ether 00:24:8c:a4:0a:b3 > media: Ethernet autoselect (none) > status: no carrier > >The nic gets no carrier at all. I tried against two known-working nics >with a cross-over cable and against a dsl-modem. >Any idea what to try? Will happily test patches. Did you try and give it an IP address so that its "UP" ? Some nics dont seem to have carrier until you put it in UP state with an IP. Try something simple like ifconfig ale0 192.168.255.254/30 ---Mike > - Marius >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From marius at nuenneri.ch Thu Oct 22 19:15:52 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Thu Oct 22 19:16:00 2009 Subject: ale0 gets no carrier In-Reply-To: <200910221905.n9MJ5dsO063534@lava.sentex.ca> References: <200910221905.n9MJ5dsO063534@lava.sentex.ca> Message-ID: On Thu, Oct 22, 2009 at 21:05, Mike Tancsa wrote: > At 02:22 PM 10/22/2009, Marius N?nnerich wrote: >> >> Hi Pyun, all, >> >> today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros >> nic: >> ale0@pci0:2:0:0: ? ? ? ?class=0x020000 card=0x831c1043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> ? ?vendor ? ? = 'Attansic (Now owned by Atheros)' >> ? ?device ? ? = 'PCI-E ETHERNET CONTROLLER ?(AR8121/AR8113 )' >> ? ?class ? ? ?= network >> ? ?subclass ? = ethernet >> >> ale0: flags=8802 metric 0 mtu 1500 >> >> >> options=319a >> ? ? ? ?ether 00:24:8c:a4:0a:b3 >> ? ? ? ?media: Ethernet autoselect (none) >> ? ? ? ?status: no carrier >> >> The nic gets no carrier at all. I tried against two known-working nics >> with a cross-over cable and against a dsl-modem. >> Any idea what to try? Will happily test patches. > > > Did you try and give it an IP address so that its "UP" ? Some nics dont seem > to have carrier until you put it in UP state with an IP. Try something > simple like > ifconfig ale0 192.168.255.254/30 > > ? ? ? ?---Mike Wow! Good idea, that did work! Thanks Marius From pluknet at gmail.com Thu Oct 22 19:17:40 2009 From: pluknet at gmail.com (pluknet) Date: Thu Oct 22 19:17:47 2009 Subject: 8.0RC1: panic: softdep_deallocate_dependencies: unrecovered I/O error Message-ID: Hi. I saw this panic just on?e during system shutdown, which runs under VirtualBox. Sorry, I don't remember more details. Unread portion of the kernel message buffer: ad0: FAILURE - device detached g_vfs_done():ad0s1e[WRITE(offset=7380582400, length=131072)]error = 6 /usr: got error 6 while accessing filesystem panic: softdep_deallocate_dependencies: unrecovered I/O error cpuid = 0 Uptime: 3h14m31s Physical memory: 1011 MB Dumping 160 MB: 145 129 113 97 81 65 49 33 17 1 #0 doadump () at pcpu.h:246 #1 0xc08827e7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0882ad9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0aad2cd in softdep_deallocate_dependencies (bp=Variable "bp" is not avail able. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:6367 #4 0xc08f2cd0 in brelse (bp=0xd8198180) at buf.h:418 #5 0xc08f5646 in bufdone_finish (bp=0xd8198180) at /usr/src/sys/kern/vfs_bio.c:3401 #6 0xc08f56bd in bufdone (bp=0xd8198180) at /usr/src/sys/kern/vfs_bio.c:3261 #7 0xc08f91d9 in cluster_callback (bp=0xd80dda30) at /usr/src/sys/kern/vfs_cluster.c:551 #8 0xc08f56a7 in bufdone (bp=0xd80dda30) at /usr/src/sys/kern/vfs_bio.c:3255 #9 0xc0823765 in g_vfs_done (bip=0xc5647dac) at /usr/src/sys/geom/geom_vfs.c:97 #10 0xc08efc69 in biodone (bp=0xc5647dac) at /usr/src/sys/kern/vfs_bio.c:3096 #11 0xc0820c0f in g_io_schedule_up (tp=0xc414a000) at /usr/src/sys/geom/geom_io.c:669 #12 0xc0820fc8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #13 0xc0858571 in fork_exit (callout=0xc0820f60 , arg=0x0, frame=0xc3ed2d38) at /usr/src/sys/kern/kern_fork.c:843 #14 0xc0b97350 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) f 3 #3 0xc0aad2cd in softdep_deallocate_dependencies (bp=Variable "bp" is not avail able. ) at /usr/src/sys/ufs/ffs/ffs_softdep.c:6367 6367 panic("softdep_deallocate_dependencies: unrecovered I/O error"); (kgdb) list 6362 { 6363 6364 if ((bp->b_ioflags & BIO_ERROR) == 0) 6365 panic("softdep_deallocate_dependencies: dangling deps"); 6366 softdep_error(bp->b_vp->v_mount->mnt_stat.f_mntonname, bp->b_err or); 6367 panic("softdep_deallocate_dependencies: unrecovered I/O error"); 6368 } 6369 6370 /* 6371 * Function to handle asynchronous write errors in the filesystem. -- wbr, pluknet From freebsd-stable at dino.sk Thu Oct 22 19:18:29 2009 From: freebsd-stable at dino.sk (Milan Obuch) Date: Thu Oct 22 19:18:36 2009 Subject: ale0 gets no carrier In-Reply-To: <200910221905.n9MJ5dsO063534@lava.sentex.ca> References: <200910221905.n9MJ5dsO063534@lava.sentex.ca> Message-ID: <200910222118.16927.freebsd-stable@dino.sk> On Thursday 22 October 2009 21:05:39 Mike Tancsa wrote: > At 02:22 PM 10/22/2009, Marius N?nnerich wrote: > >Hi Pyun, all, > > > >today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros > > nic: ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 > > chip=0x10261969 rev=0xb0 hdr=0x00 > > vendor = 'Attansic (Now owned by Atheros)' > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > > class = network > > subclass = ethernet > > > >ale0: flags=8802 metric 0 mtu 1500 > > > >options=319a >_MAGIC> ether 00:24:8c:a4:0a:b3 > > media: Ethernet autoselect (none) > > status: no carrier > > > >The nic gets no carrier at all. I tried against two known-working nics > >with a cross-over cable and against a dsl-modem. > >Any idea what to try? Will happily test patches. > > Did you try and give it an IP address so that its > "UP" ? Some nics dont seem to have carrier until > you put it in UP state with an IP. Try something simple like > ifconfig ale0 192.168.255.254/30 > In my case ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet (exactly the same, as I can see) when configuring interface manually, I need to do 'ifconfig ale0 up' before I can successfully acquire IP with 'dhclient ale0'. Everything works normally with 'ifconfig_ale0="DHCP"' line in /etc/rc.conf. Regards, Milan From pyunyh at gmail.com Thu Oct 22 19:38:22 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Oct 22 19:38:28 2009 Subject: ale0 gets no carrier In-Reply-To: <200910222118.16927.freebsd-stable@dino.sk> References: <200910221905.n9MJ5dsO063534@lava.sentex.ca> <200910222118.16927.freebsd-stable@dino.sk> Message-ID: <20091022193821.GB1116@michelle.cdnetworks.com> On Thu, Oct 22, 2009 at 09:18:15PM +0200, Milan Obuch wrote: > On Thursday 22 October 2009 21:05:39 Mike Tancsa wrote: > > At 02:22 PM 10/22/2009, Marius N?nnerich wrote: > > >Hi Pyun, all, > > > > > >today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros > > > nic: ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 > > > chip=0x10261969 rev=0xb0 hdr=0x00 > > > vendor = 'Attansic (Now owned by Atheros)' > > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > > > class = network > > > subclass = ethernet > > > > > >ale0: flags=8802 metric 0 mtu 1500 > > > > > >options=319a > >_MAGIC> ether 00:24:8c:a4:0a:b3 > > > media: Ethernet autoselect (none) > > > status: no carrier > > > > > >The nic gets no carrier at all. I tried against two known-working nics > > >with a cross-over cable and against a dsl-modem. > > >Any idea what to try? Will happily test patches. > > > > Did you try and give it an IP address so that its > > "UP" ? Some nics dont seem to have carrier until > > you put it in UP state with an IP. Try something simple like > > ifconfig ale0 192.168.255.254/30 > > > > In my case > > ale0@pci0:2:0:0: class=0x020000 card=0x831c1043 chip=0x10261969 > rev=0xb0 hdr=0x00 > vendor = 'Attansic (Now owned by Atheros)' > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > class = network > subclass = ethernet > > (exactly the same, as I can see) when configuring interface manually, I need > to do 'ifconfig ale0 up' before I can successfully acquire IP with 'dhclient > ale0'. Everything works normally with 'ifconfig_ale0="DHCP"' line > in /etc/rc.conf. > This is intended behavior as establishing a link requires negotiation with link-partner and the link state could be changed after the negotiation. So showing (fake/incorrect) link state before UPing the interface wouldn't be correct behavior. From marius at nuenneri.ch Fri Oct 23 10:04:39 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Oct 23 10:04:57 2009 Subject: i am desperate over some GPT tables In-Reply-To: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> Message-ID: On Wed, Oct 21, 2009 at 14:11, Kris Weston wrote: > been looking for months now, trawled google no help, i just dont understand. > do you need a GPT table with zfs ? > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to import > my zpool into it > exported fine on solaris , its definitely the same version (v13) > but when i import into zfs it says GPT tables corrupt ? > why ? and what does this mean ? > please help me. pleeeeease. Could you provide some more data? What is the error message for example? From the zpool command and maybe what geom says about the GPT in dmesg. From marius at nuenneri.ch Fri Oct 23 10:06:11 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Oct 23 10:06:17 2009 Subject: ale0 gets no carrier In-Reply-To: <20091022193821.GB1116@michelle.cdnetworks.com> References: <200910221905.n9MJ5dsO063534@lava.sentex.ca> <200910222118.16927.freebsd-stable@dino.sk> <20091022193821.GB1116@michelle.cdnetworks.com> Message-ID: On Thu, Oct 22, 2009 at 21:38, Pyun YongHyeon wrote: > On Thu, Oct 22, 2009 at 09:18:15PM +0200, Milan Obuch wrote: >> On Thursday 22 October 2009 21:05:39 Mike Tancsa wrote: >> > At 02:22 PM 10/22/2009, Marius N?nnerich wrote: >> > >Hi Pyun, all, >> > > >> > >today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros >> > > nic: ale0@pci0:2:0:0: ? ? ? ?class=0x020000 card=0x831c1043 >> > > chip=0x10261969 rev=0xb0 hdr=0x00 >> > > ? ? vendor ? ? = 'Attansic (Now owned by Atheros)' >> > > ? ? device ? ? = 'PCI-E ETHERNET CONTROLLER ?(AR8121/AR8113 )' >> > > ? ? class ? ? ?= network >> > > ? ? subclass ? = ethernet >> > > >> > >ale0: flags=8802 metric 0 mtu 1500 >> > > >> > >options=319a> > >_MAGIC> ether 00:24:8c:a4:0a:b3 >> > > ? ? ? ? media: Ethernet autoselect (none) >> > > ? ? ? ? status: no carrier >> > > >> > >The nic gets no carrier at all. I tried against two known-working nics >> > >with a cross-over cable and against a dsl-modem. >> > >Any idea what to try? Will happily test patches. >> > >> > Did you try and give it an IP address so that its >> > "UP" ? Some nics dont seem to have carrier until >> > you put it in UP state with an IP. Try something simple like >> > ifconfig ale0 192.168.255.254/30 >> > >> >> In my case >> >> ale0@pci0:2:0:0: ? ? ? ?class=0x020000 card=0x831c1043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> ? ? vendor ? ? = 'Attansic (Now owned by Atheros)' >> ? ? device ? ? = 'PCI-E ETHERNET CONTROLLER ?(AR8121/AR8113 )' >> ? ? class ? ? ?= network >> ? ? subclass ? = ethernet >> >> (exactly the same, as I can see) when configuring interface manually, I need >> to do 'ifconfig ale0 up' before I can successfully acquire IP with 'dhclient >> ale0'. Everything works normally with 'ifconfig_ale0="DHCP"' line >> in /etc/rc.conf. >> > > This is intended behavior as establishing a link requires > negotiation with link-partner and the link state could be changed > after the negotiation. So showing (fake/incorrect) link state > before UPing the interface wouldn't be correct behavior. Ok, sounds plausible. It's just that every other nic I have had worked the other way. From petefrench at ticketswitch.com Fri Oct 23 10:56:31 2009 From: petefrench at ticketswitch.com (Pete French) Date: Fri Oct 23 10:56:39 2009 Subject: problems with gmirror on ggate over slow link Message-ID: [ originally sent to geom, but am throwing it open to a wider audience as I didn;t get any replies there] I am using 7.2-STABLE from October 7th on all amchines, but this has been going on a while. Very simply I am mirroring together a pair of discs, one local, one remote. The remote disc is accessed using ggate. If the remote diisc is actually on a very close machine - e.g. a server plugged into the same ether net - then all works fine. If I make the remote disc somewhere actually substantially further away on the nbetwork, however, then when I attach the disc it starts to rebuild the mirror but then fails a fraction of a second later thus: GEOM_MIRROR: Device mysql0: rebuilding provider ggate1a. GEOM_MIRROR: Synchronization request failed (error=5). ggate1a[WRITE(offset=1310720, length=131072)] GEOM_MIRROR: Device mysql0: provider ggate1a disconnected. GEOM_MIRROR: Device mysql0: rebuilding provider ggate1a stopped. The interesting this is that the problem is only with gmirror, not with the underlying ggate disc which remains attached and accessible. I tested this by adding a second partition (ggate1b in the example above) and mounting a UFS filesystem on that. I've looked at the kernel code briefly, but it is not clear to me what is causing that write to fail. My conjecture would be that a buffer somewhere is filling up, causing a write to fail, and instead of gmirror waiting and retrying, instead it just fails the synchronisation. Any ideas ? Is this actually a bug ? I am wondering if it would also happen if mirroring a very fast disc against a very slow one (i.e. maybe it is independent of ggate) -pete. From kris.weston at gmail.com Fri Oct 23 11:51:43 2009 From: kris.weston at gmail.com (Kris Weston) Date: Fri Oct 23 11:51:50 2009 Subject: i am desperate over some GPT tables In-Reply-To: References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> Message-ID: <72d267bc0910230451u56b825c3p903388c4b5c657aa@mail.gmail.com> thanks for replying - my problem just got worse. i used to be able to import and see the pools by typing zpool import and then the specific name of the pool, in this case 'lakez' that used to work and i used to be able to see the solaris pool (although it gave me the error GPT table corrupt which i mentioned in last post) now though, i cant see any pools, after loading back into solaris and exporting again just to make sure the same thing happens a 'zpool import -f lakez' results in no pools under zpool status.. ive done nothing different in terms of commands and machine is the same... im a musician and i just use zfs to keep all my samples on so bear with me if i dont understand im not a proper geek yet but i want to be when i grow up... ad0: 238475MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 ad4: 953869MB at ata2-master SATA300 ad6: 953869MB at ata3-master SATA300 ad8: 953869MB at ata4-master SATA300 SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider acd0 is iso9660/OpenSolaris. GEOM_LABEL: Label for provider ad0s1a is ufsid/4492628cc2ddd2a5. GEOM_LABEL: Label for provider ad0s1d is ufsid/4492629556c9d23e. GEOM_LABEL: Label for provider ad0s1e is ufsid/4492628cbd104840. GEOM_LABEL: Label for provider ad0s1f is ufsid/4492628c56133c1f. GEOM: ad4: corrupt or invalid GPT detected. GEOM: ad4: GPT rejected -- may not be recoverable. GEOM: ad6: corrupt or invalid GPT detected. GEOM: ad6: GPT rejected -- may not be recoverable. GEOM: ad8: corrupt or invalid GPT detected. GEOM: ad8: GPT rejected -- may not be recoverable. GEOM_LABEL: Label for provider da0s1 is msdosfs/NEW VOLUME. Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted GEOM_LABEL: Label ufsid/4492628cc2ddd2a5 removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/4492628cc2ddd2a5. GEOM_LABEL: Label ufsid/4492628cc2ddd2a5 removed. GEOM_LABEL: Label ufsid/4492628cbdW1A0R4N8I4NG0: r/etmmopv ewda.s not properly dismounted GEOM_LABEL: Label ufsid/4492628c56133c1f removed.W ARNING: /usr was not properly dismounted GEOM_LABEL: Label ufsid/4492629556c9d23e removed. WARNING: /var was not properly dismounted This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior. Consider tuning vm.kmem_size and vm.kmem_size_max in /boot/loader.conf. ZFS filesystem version 13 ZFS storage pool version 13 -- )) (( c[_] 2009/10/23 Marius N?nnerich > On Wed, Oct 21, 2009 at 14:11, Kris Weston wrote: > > been looking for months now, trawled google no help, i just dont > understand. > > do you need a GPT table with zfs ? > > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to > import > > my zpool into it > > exported fine on solaris , its definitely the same version (v13) > > but when i import into zfs it says GPT tables corrupt ? > > why ? and what does this mean ? > > please help me. pleeeeease. > > Could you provide some more data? What is the error message for > example? From the zpool command and maybe what geom says about the GPT > in dmesg. > From ob at e-Gitt.NET Fri Oct 23 11:53:33 2009 From: ob at e-Gitt.NET (Oliver Brandmueller) Date: Fri Oct 23 11:53:40 2009 Subject: problems with gmirror on ggate over slow link In-Reply-To: References: Message-ID: <20091023115331.GE95002@e-Gitt.NET> Hi, On Fri, Oct 23, 2009 at 11:56:24AM +0100, Pete French wrote: > If the remote diisc is actually on a very close machine - e.g. a server > plugged into the same ether net - then all works fine. If I make > the remote disc somewhere actually substantially further away on the > nbetwork, however, then when I attach the disc it starts to rebuild the > mirror but then fails a fraction of a second later thus: > > GEOM_MIRROR: Device mysql0: rebuilding provider ggate1a. > GEOM_MIRROR: Synchronization request failed (error=5). ggate1a[WRITE(offset=1310720, length=131072)] > GEOM_MIRROR: Device mysql0: provider ggate1a disconnected. > GEOM_MIRROR: Device mysql0: rebuilding provider ggate1a stopped. > > The interesting this is that the problem is only with gmirror, not with > the underlying ggate disc which remains attached and accessible. I tested > this by adding a second partition (ggate1b in the example above) and > mounting a UFS filesystem on that. Just a wild guess, have you tried to set kern.geom.mirror.timeout to a higher value? - Olli -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From petefrench at ticketswitch.com Fri Oct 23 12:56:17 2009 From: petefrench at ticketswitch.com (Pete French) Date: Fri Oct 23 12:56:24 2009 Subject: problems with gmirror on ggate over slow link In-Reply-To: <20091023115331.GE95002@e-Gitt.NET> Message-ID: > Just a wild guess, have you tried to set kern.geom.mirror.timeout to a > higher value? Yes, I tried values all the way up to 600, no effect at all - plus the failure comes way before that timeout value (which is in seconds I assume). -pete. From rnoland at FreeBSD.org Fri Oct 23 13:19:08 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Oct 23 13:19:15 2009 Subject: i am desperate over some GPT tables In-Reply-To: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> Message-ID: <1256303940.2283.15.camel@balrog.2hip.net> On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: > been looking for months now, trawled google no help, i just dont understand. > do you need a GPT table with zfs ? > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to import > my zpool into it > exported fine on solaris , its definitely the same version (v13) > but when i import into zfs it says GPT tables corrupt ? > why ? and what does this mean ? > please help me. pleeeeease. Send me the fist 34 sectors of the disk and I will try to take a look. dd if= of=header.dmp bs=512 count=34 robert. > -- > > )) > (( > c[_] > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From jhb at freebsd.org Fri Oct 23 13:26:30 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 23 13:26:47 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> Message-ID: <200910230812.31166.jhb@freebsd.org> On Thursday 22 October 2009 11:07:23 am Johan Hendriks wrote: > Hello all > I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 > server. > It fails to detect the Broadcom network interface. > > > > Pciconf -lv gives me the following. > > none3@pci0:4:0:0: class=0x020000 card=0x705d10c chip=0x165b14e4 > rev=0x10 > hdr=0x00 > > vendor = 'Broadcom Corporation' > class = network > > Subclass = Ethernet > > > > Is there something I can do, other than install an other network card? I think you can just patch the bge(4) driver to add support for your adapter. It looks like a BCM5723 from the PCI ID. Support for it was just added in 9.0 as part of change 197832, but I suspect it might not need all the other patches from that change. Try this diff: Index: if_bgereg.h =================================================================== --- if_bgereg.h (revision 197831) +++ if_bgereg.h (revision 197832) @@ -2101,6 +2123,7 @@ #define BCOM_DEVICEID_BCM5720 0x1658 #define BCOM_DEVICEID_BCM5721 0x1659 #define BCOM_DEVICEID_BCM5722 0x165A +#define BCOM_DEVICEID_BCM5723 0x165B #define BCOM_DEVICEID_BCM5750 0x1676 #define BCOM_DEVICEID_BCM5750M 0x167C #define BCOM_DEVICEID_BCM5751 0x1677 Index: if_bge.c =================================================================== --- if_bge.c (revision 197831) +++ if_bge.c (revision 197832) @@ -170,6 +170,7 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, -- John Baldwin From jhb at freebsd.org Fri Oct 23 13:26:31 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 23 13:26:48 2009 Subject: 8.0RC1: panic: softdep_deallocate_dependencies: unrecovered I/O error In-Reply-To: References: Message-ID: <200910230813.28788.jhb@freebsd.org> On Thursday 22 October 2009 3:17:38 pm pluknet wrote: > Hi. > > I saw this panic just on?e during system shutdown, which > runs under VirtualBox. Sorry, I don't remember more details. > > Unread portion of the kernel message buffer: > ad0: FAILURE - device detached > g_vfs_done():ad0s1e[WRITE(offset=7380582400, length=131072)]error = 6 > /usr: got error 6 while accessing filesystem > panic: softdep_deallocate_dependencies: unrecovered I/O error Generally speaking UFS does not cope well with disk I/O errors and disks going away (note that ad0 failed and detached before your panic). -- John Baldwin From Johan at double-l.nl Fri Oct 23 15:17:38 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Fri Oct 23 15:17:47 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> On Thursday 22 October 2009 11:07:23 am Johan Hendriks wrote: >> Hello all >> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 >> server. >> It fails to detect the Broadcom network interface. >> >> >> >> Pciconf -lv gives me the following. >> >> none3@pci0:4:0:0: class=0x020000 card=0x705d10c chip=0x165b14e4 >> rev=0x10 >> hdr=0x00 >> >> vendor = 'Broadcom Corporation' >> class = network >> >> Subclass = Ethernet >> >> >> >> Is there something I can do, other than install an other network card? >I think you can just patch the bge(4) driver to add support for your >adapter. >It looks like a BCM5723 from the PCI ID. Support for it was just added in >9.0 as part of change 197832, but I suspect it might not need all the other >patches from that change. Try this diff: >Index: if_bgereg.h >=================================================================== >--- if_bgereg.h (revision 197831) >+++ if_bgereg.h (revision 197832) >@@ -2101,6 +2123,7 @@ > #define BCOM_DEVICEID_BCM5720 0x1658 > #define BCOM_DEVICEID_BCM5721 0x1659 > #define BCOM_DEVICEID_BCM5722 0x165A >+#define BCOM_DEVICEID_BCM5723 0x165B > #define BCOM_DEVICEID_BCM5750 0x1676 > #define BCOM_DEVICEID_BCM5750M 0x167C > #define BCOM_DEVICEID_BCM5751 0x1677 >Index: if_bge.c >=================================================================== >--- if_bge.c (revision 197831) >+++ if_bge.c (revision 197832) >@@ -170,6 +170,7 @@ > { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, >+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, Ok done that, and the card is found, only the server is not very stable right now. It does not continue the boot. It stops at setting the hostname Setting hostname: server01.mydomain.local And it stays there. -- John Baldwin No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.27/2452 - Release Date: 10/23/09 06:56:00 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.27/2452 - Release Date: 10/23/09 06:56:00 From oliver at FreeBSD.org Fri Oct 23 15:55:46 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Fri Oct 23 15:55:53 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <20091023173611.1d44c7a4.oliver@FreeBSD.org> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> Message-ID: <20091023175544.893049ad.oliver@FreeBSD.org> And one adition: I also have an external harddisk /dev/da1s1 which I labled with "backup" with RC1. I unfortunally got a /dev/ufs/backup as well as a /dev/ufs/backupd for the 4th partition of the 1st slide /dev/da1s1d. I wanted to fix this (label da1s1d as backup) and booted into the single user mode, and typed "glabel destroy backup". The two backup+backupd entries in /dev/ufs where gone. I then rebooted once more into the single user mode and now I have backup +backupd again. Something seems to be definitly broken here :( No - I have not mounted that filesystem at any time. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From oliver at FreeBSD.org Fri Oct 23 16:02:53 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Fri Oct 23 16:04:02 2009 Subject: 8.0: glabel on a gjournaled FS is broken Message-ID: <20091023173611.1d44c7a4.oliver@FreeBSD.org> Hi, I updated my RC1 box now to the latest RELENG_8 code to get my gmirror +glabel setup working. Since gjournal was now supposed to work as well I set this up once more. This was not so easy as I thought because cleaning the metadata on my previously journaled filesystems (but not working because of the bug) was a pain. With geom_journal.ko loaded at the boottime the system was not able to boot up - waiting infinitly for the nonexisting journal to show up spamming my screen with timeout messages. What a mess.... Finally I got the module disabled in the bootloader (I guess I'll never ever compile this directly into the kernel if it can cause my system not to come up again) Now I have two partitions in a journaled state. What I did was: gjournal load gjournal label da0p1 mirror/gm0s1h tunefs -J enable -n disable da0p1.journal gjournal label mirror/gm0s1f mirror/gm0s1g tunefs -J enable -n disable mirror/gm0s1f.journal Then I rebooted into single user mode again to label the filesystems. Then I did: glabel label swap mirror/gm0s1b tunefs -L root mirror/gm0s1a tunefs -L var mirror/gm0s1d tunefs -L tmp mirror/gm0s1e tunefs -L usr mirror/gm0s1f.journal tunefs -L files da0p1.journal /dev/ufs and /dev/label contained all the given label. Then I rebooted once more - again into the single user mode. Now ufs/files and ufs/usr is gone.... so glabel in conjunction with gjournal is broken.... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From amvandemore at gmail.com Fri Oct 23 16:13:52 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Fri Oct 23 16:13:59 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <20091023175544.893049ad.oliver@FreeBSD.org> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> <20091023175544.893049ad.oliver@FreeBSD.org> Message-ID: <6201873e0910230913p7dabb675tbb3d5737ab62fd74@mail.gmail.com> On Fri, Oct 23, 2009 at 10:55 AM, Oliver Lehmann wrote: > And one adition: > > I also have an external harddisk /dev/da1s1 which I labled with "backup" > with RC1. I unfortunally got a /dev/ufs/backup as well as > a /dev/ufs/backupd for the 4th partition of the 1st slide /dev/da1s1d. > > I wanted to fix this (label da1s1d as backup) and booted into the single > user mode, and typed "glabel destroy backup". The two backup+backupd > entries in /dev/ufs where gone. > I then rebooted once more into the single user mode and now I have backup > +backupd again. Something seems to be definitly broken here :( > > No - I have not mounted that filesystem at any time. > > -- > Oliver Lehmann > > man glabel: stop Turn off the given label by its name. This command does not touch on-disk metadata! destroy Same as stop. clear Clear metadata on the given devices. You want clear for changes to persist. -- Adam Vande More From oliver at FreeBSD.org Fri Oct 23 16:29:59 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Fri Oct 23 16:30:06 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <6201873e0910230913p7dabb675tbb3d5737ab62fd74@mail.gmail.com> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> <20091023175544.893049ad.oliver@FreeBSD.org> <6201873e0910230913p7dabb675tbb3d5737ab62fd74@mail.gmail.com> Message-ID: <20091023182957.4524d4dc.oliver@FreeBSD.org> Adam Vande More wrote: > You want clear for changes to persist. Yeah tried this too without much success - how should I proceed? root@nudel /root> ls -l /dev/ufs/backup* /dev/da1* crw-r----- 1 root operator 0, 98 Oct 23 18:26 /dev/da1 crw-r----- 1 root operator 0, 101 Oct 23 18:26 /dev/da1s1 crw-r----- 1 root operator 0, 108 Oct 23 18:26 /dev/da1s1d crw-r----- 1 root operator 0, 107 Oct 23 18:26 /dev/ufs/backup crw-r----- 1 root operator 0, 117 Oct 23 18:26 /dev/ufs/backupd root@nudel /root> glabel clear da1s1 Can't clear metadata on da1s1: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear da1s1d Can't clear metadata on da1s1d: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear da1 Can't clear metadata on da1: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear backup Can't clear metadata on backup: No such file or directory. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear backupd Can't clear metadata on backupd: No such file or directory. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear ufs/backupd Can't clear metadata on ufs/backupd: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear ufs/backup Can't clear metadata on ufs/backup: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel stop backup root@nudel /root> ls -l /dev/ufs/backup* /dev/da1* crw-r----- 1 root operator 0, 98 Oct 23 18:26 /dev/da1 crw-r----- 1 root operator 0, 139 Oct 23 18:28 /dev/da1s1 crw-r----- 1 root operator 0, 140 Oct 23 18:28 /dev/da1s1d root@nudel /root> glabel clear da1s1 Can't clear metadata on da1s1: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear da1 Can't clear metadata on da1: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear da1s1d Can't clear metadata on da1s1d: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear backup Can't clear metadata on backup: No such file or directory. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear backupd Can't clear metadata on backupd: No such file or directory. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear ufs/backupd Can't clear metadata on ufs/backupd: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> glabel clear ufs/backup Can't clear metadata on ufs/backup: Invalid argument. glabel: Not fully done. Exit 1 root@nudel /root> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From amvandemore at gmail.com Fri Oct 23 16:59:49 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Fri Oct 23 17:01:24 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <20091023182957.4524d4dc.oliver@FreeBSD.org> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> <20091023175544.893049ad.oliver@FreeBSD.org> <6201873e0910230913p7dabb675tbb3d5737ab62fd74@mail.gmail.com> <20091023182957.4524d4dc.oliver@FreeBSD.org> Message-ID: <6201873e0910230959i7f411744pcd1ae911ed0e9930@mail.gmail.com> On Fri, Oct 23, 2009 at 11:29 AM, Oliver Lehmann wrote: > Adam Vande More wrote: > > > You want clear for changes to persist. > > Yeah tried this too without much success - how should I proceed? > > root@nudel /root> ls -l /dev/ufs/backup* /dev/da1* > crw-r----- 1 root operator 0, 98 Oct 23 18:26 /dev/da1 > crw-r----- 1 root operator 0, 101 Oct 23 18:26 /dev/da1s1 > crw-r----- 1 root operator 0, 108 Oct 23 18:26 /dev/da1s1d > crw-r----- 1 root operator 0, 107 Oct 23 18:26 /dev/ufs/backup > crw-r----- 1 root operator 0, 117 Oct 23 18:26 /dev/ufs/backupd > root@nudel /root> glabel clear da1s1 > Can't clear metadata on da1s1: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear da1s1d > Can't clear metadata on da1s1d: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear da1 > Can't clear metadata on da1: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear backup > Can't clear metadata on backup: No such file or directory. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear backupd > Can't clear metadata on backupd: No such file or directory. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear ufs/backupd > Can't clear metadata on ufs/backupd: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear ufs/backup > Can't clear metadata on ufs/backup: Invalid argument. > glabel: Not fully done. > Exit 1 > > > root@nudel /root> glabel stop backup > > > root@nudel /root> ls -l /dev/ufs/backup* /dev/da1* > crw-r----- 1 root operator 0, 98 Oct 23 18:26 /dev/da1 > crw-r----- 1 root operator 0, 139 Oct 23 18:28 /dev/da1s1 > crw-r----- 1 root operator 0, 140 Oct 23 18:28 /dev/da1s1d > root@nudel /root> glabel clear da1s1 > Can't clear metadata on da1s1: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear da1 > Can't clear metadata on da1: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear da1s1d > Can't clear metadata on da1s1d: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear backup > Can't clear metadata on backup: No such file or directory. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear backupd > Can't clear metadata on backupd: No such file or directory. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear ufs/backupd > Can't clear metadata on ufs/backupd: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> glabel clear ufs/backup > Can't clear metadata on ufs/backup: Invalid argument. > glabel: Not fully done. > Exit 1 > root@nudel /root> > > sysctl kern.geom.debugflags=17 -- Adam Vande More From oliver at FreeBSD.org Fri Oct 23 17:11:31 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Fri Oct 23 17:11:38 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <6201873e0910230959i7f411744pcd1ae911ed0e9930@mail.gmail.com> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> <20091023175544.893049ad.oliver@FreeBSD.org> <6201873e0910230913p7dabb675tbb3d5737ab62fd74@mail.gmail.com> <20091023182957.4524d4dc.oliver@FreeBSD.org> <6201873e0910230959i7f411744pcd1ae911ed0e9930@mail.gmail.com> Message-ID: <20091023191128.1c45041c.oliver@FreeBSD.org> Hi Adam, Adam Vande More wrote: > sysctl kern.geom.debugflags=17 I also tried this in the meantime. The behaviour is still the same. I also attached the disk to a FreeBSD 7.2 system - same problem: root@kartoffel olivleh1> glabel status Name Status Components ufsid/49f8856ee7867c4f N/A da0s1 ufs/backup N/A da0s1 root@kartoffel olivleh1> sysctl kern.geom.debugflags=17 kern.geom.debugflags: 0 -> 17 root@kartoffel olivleh1> glabel stop backup root@kartoffel olivleh1> glabel status Name Status Components ufsid/49f8856ee7867c4f N/A da0s1 root@kartoffel olivleh1> glabel clear -v da0s1 Can't clear metadata on da0s1: Invalid argument. glabel: Not fully done. Exit 1 root@kartoffel olivleh1> glabel status Name Status Components ufsid/49f8856ee7867c4f N/A da0s1 ufs/backup N/A da0s1 root@kartoffel olivleh1> You see? while trying to clear the data, the label is back.... -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From jbozza at mindsites.com Fri Oct 23 18:47:02 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Fri Oct 23 18:47:10 2009 Subject: Possible scheduler (SCHED_ULE) bug? Message-ID: I believe I found a problem with the ULE scheduler - At least the fact that there is a problem, but I'm not sure where to go from here. The system locks all processes, but doesn't panic, so I have no output to give. I was able to duplicate this on three different machines and solved it by switching to the scheduler to 4BSD. Here's the environment: FreeBSD 7.2 i386, installed from bootonly ISO, Custom install, minimal, no other changes other than setting timezone, changing root password, and turning on sshd (allowing root and password connection). Running portsnap (fetch, then extract) to get latest ports tree. >From ports, make installs of lang/php5 and www/lighttpd, using defaults for all ports installed. Modified lighttpd.conf for PHP (attached diff), created a short script called uploadfile.php (attached). File was installed at /usr/local/www/data/uploadfile.php Start lighttpd (lighttpd_enable="YES" in rc.conf, /usr/local/etc/rc.d/lighttpd start), connect and run script. As long as I upload a file less than 64K, everything works fine. If I try to upload something larger than 64K, system no longer responds. Console prompt at login will allow me to enter username/password, but nothing happens after that. Console prompt logged in will allow me to type a single line, but if I press enter, nothing after that. No errors get written anywhere - console, logs, etc. I'm at a loss of what to do next. Can anyone give me ideas of what else I can do? -------------- next part -------------- --- lighttpd.conf.sample 2009-10-23 09:37:50.000000000 -0500 +++ lighttpd.conf 2009-10-23 10:02:00.000000000 -0500 @@ -20,7 +20,7 @@ # "mod_auth", # "mod_status", # "mod_setenv", -# "mod_fastcgi", + "mod_fastcgi", # "mod_proxy", # "mod_simple_vhost", # "mod_evhost", @@ -39,7 +39,7 @@ server.document-root = "/usr/local/www/data/" ## where to send error-messages to -server.errorlog = "/var/log/lighttpd.error.log" +server.errorlog = "/tmp/lighttpd.error.log" # files to check for if .../ is requested index-file.names = ( "index.php", "index.html", @@ -115,7 +115,7 @@ # server.tag = "lighttpd" #### accesslog module -accesslog.filename = "/var/log/lighttpd.access.log" +accesslog.filename = "/tmp/lighttpd.access.log" ## deny access the file-extensions # @@ -324,3 +324,20 @@ # Enable IPV6 and IPV4 together server.use-ipv6 = "enable" $SERVER["socket"] == "0.0.0.0:80" { } + + fastcgi.server = ( ".php" => (( + "bin-path" => "/usr/local/bin/php-cgi", + "socket" => "/tmp/hermes.php.socket", + "min-procs" => 1, + "max-procs" => 1, + "bin-environment" => ( + "PHP_FCGI_CHILDREN" => "4", + "PHP_FCGI_MAX_REQUESTS" => "50", + "PHPRC" => "/data/sites/support/conf/" + ), + "bin-copy-environment" => ( + "PATH", "SHELL", "USER", "TZ" + ), + "broken-scriptfilename" => "enable", + ))) + \ -------------- next part -------------- A non-text attachment was scrubbed... Name: uploadfile.php Type: application/octet-stream Size: 640 bytes Desc: uploadfile.php Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091023/6a230221/uploadfile.obj From sullrich at gmail.com Fri Oct 23 19:15:03 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Oct 23 19:15:11 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: On Fri, Oct 23, 2009 at 2:46 PM, Jaime Bozza wrote: > I believe I found a problem with the ULE scheduler - At least the fact that there is a problem, but I'm not sure where to go from here. ? The system locks all processes, but doesn't panic, so I have no output to give. > > I was able to duplicate this on three different machines and solved it by switching to the scheduler to 4BSD. > > Here's the environment: > > FreeBSD 7.2 i386, installed from bootonly ISO, Custom install, minimal, no other changes other than setting timezone, changing root password, and turning on sshd (allowing root and password connection). > > Running portsnap (fetch, then extract) to get latest ports tree. > > >From ports, make installs of lang/php5 and www/lighttpd, using defaults for all ports installed. > > Modified lighttpd.conf for PHP (attached diff), created a short script called uploadfile.php (attached). ?File was installed at /usr/local/www/data/uploadfile.php > > Start lighttpd (lighttpd_enable="YES" in rc.conf, /usr/local/etc/rc.d/lighttpd start), connect and run script. > > As long as I upload a file less than 64K, everything works fine. ?If I try to upload something larger than 64K, system no longer responds. ? Console prompt at login will allow me to enter username/password, but nothing happens after that. ?Console prompt logged in will allow me to type a single line, but if I press enter, nothing after that. > > No errors get written anywhere - console, logs, etc. > > I'm at a loss of what to do next. ?Can anyone give me ideas of what else I can do? Try adding this or changing these items in lighttpd.conf: ## FreeBSD! server.event-handler = "freebsd-kqueue" server.network-backend = "writev" Scott From heliocentric at gmail.com Fri Oct 23 20:51:18 2009 From: heliocentric at gmail.com (Dylan Cochran) Date: Fri Oct 23 20:51:26 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: On 10/23/09, Jaime Bozza wrote: > I believe I found a problem with the ULE scheduler - At least the fact that > there is a problem, but I'm not sure where to go from here. The system > locks all processes, but doesn't panic, so I have no output to give. > > I was able to duplicate this on three different machines and solved it by > switching to the scheduler to 4BSD. > > Here's the environment: > > FreeBSD 7.2 i386, installed from bootonly ISO, Custom install, minimal, no > other changes other than setting timezone, changing root password, and > turning on sshd (allowing root and password connection). > > Running portsnap (fetch, then extract) to get latest ports tree. > > >From ports, make installs of lang/php5 and www/lighttpd, using defaults for > all ports installed. > > Modified lighttpd.conf for PHP (attached diff), created a short script > called uploadfile.php (attached). File was installed at > /usr/local/www/data/uploadfile.php > > Start lighttpd (lighttpd_enable="YES" in rc.conf, > /usr/local/etc/rc.d/lighttpd start), connect and run script. > > As long as I upload a file less than 64K, everything works fine. If I try > to upload something larger than 64K, system no longer responds. Console > prompt at login will allow me to enter username/password, but nothing > happens after that. Console prompt logged in will allow me to type a single > line, but if I press enter, nothing after that. > > No errors get written anywhere - console, logs, etc. > > I'm at a loss of what to do next. Can anyone give me ideas of what else I > can do? Superficially, this seams identical to a deadlock I reported for 7.1-RC1. Would you mind compiling a kernel with these options: options DDB options KDB options SW_WATCHDOG options DEBUG_VFS_LOCKS then add the following to /etc/rc.conf: watchdogd_enable="YES" watchdogd_flags="-e 'ls -al /etc'" This should force a panic when the lockup happens again, which will drop to a debugger. Please check the backtrace, and tell me if the call stack is the same as this one (between the --- interrupt, and --- syscall sections): KDB: stack backtrace: db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c Xtimerint() at Xtimerint+0x1f --- interrupt, eip = 0xc07ff29d, esp = 0xe66e0b48, ebp = 0xe66e0c34 --- kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at do_sendfile+0xb1 sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 syscall(e66e0d38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = 0xbfbfc7cc, ebp = 0xbfbfe848 --- KDB: enter: watchdog timeout You can type 'reboot' to reboot the machine (in my case, panic would not work, so a useful dump wasn't in the cards) From jbozza at mindsites.com Fri Oct 23 20:52:29 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Fri Oct 23 20:52:36 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: > Try adding this or changing these items in lighttpd.conf: > > ## FreeBSD! > server.event-handler = "freebsd-kqueue" > server.network-backend = "writev" Scott, Lighttpd was already using freebsd-kqueue, but I added the writev network-backend and the problem went away. With this additional information I was able to track down kern/138999, which seems to be the exact issue I'm having. The additional information I have (over the PR) is that: 1) Files over 64K cause the problem, not just larger files 2) switching over to SCHED_4BSD eliminates the problem - system no longer locks. 3) 7.2 amd64 doesn't have the problem - Tested a similar configuration and was not able to duplicate on amd64 at all. I'm CC'ing the original submitter of the PR to give him an update to see if he had any additional luck. Jaime From kostikbel at gmail.com Fri Oct 23 21:21:11 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Oct 23 21:21:18 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: <20091023212104.GH2160@deviant.kiev.zoral.com.ua> On Fri, Oct 23, 2009 at 04:28:59PM -0400, Dylan Cochran wrote: > On 10/23/09, Jaime Bozza wrote: > > I believe I found a problem with the ULE scheduler - At least the fact that > > there is a problem, but I'm not sure where to go from here. The system > > locks all processes, but doesn't panic, so I have no output to give. > > > > I was able to duplicate this on three different machines and solved it by > > switching to the scheduler to 4BSD. > > > > Here's the environment: > > > > FreeBSD 7.2 i386, installed from bootonly ISO, Custom install, minimal, no > > other changes other than setting timezone, changing root password, and > > turning on sshd (allowing root and password connection). > > > > Running portsnap (fetch, then extract) to get latest ports tree. > > > > >From ports, make installs of lang/php5 and www/lighttpd, using defaults for > > all ports installed. > > > > Modified lighttpd.conf for PHP (attached diff), created a short script > > called uploadfile.php (attached). File was installed at > > /usr/local/www/data/uploadfile.php > > > > Start lighttpd (lighttpd_enable="YES" in rc.conf, > > /usr/local/etc/rc.d/lighttpd start), connect and run script. > > > > As long as I upload a file less than 64K, everything works fine. If I try > > to upload something larger than 64K, system no longer responds. Console > > prompt at login will allow me to enter username/password, but nothing > > happens after that. Console prompt logged in will allow me to type a single > > line, but if I press enter, nothing after that. > > > > No errors get written anywhere - console, logs, etc. > > > > I'm at a loss of what to do next. Can anyone give me ideas of what else I > > can do? > > Superficially, this seams identical to a deadlock I reported for > 7.1-RC1. Would you mind compiling a kernel with these options: > > options DDB > options KDB > options SW_WATCHDOG > options DEBUG_VFS_LOCKS > > > then add the following to /etc/rc.conf: > > watchdogd_enable="YES" > watchdogd_flags="-e 'ls -al /etc'" > > This should force a panic when the lockup happens again, which will > drop to a debugger. > > Please check the backtrace, and tell me if the call stack is the same > as this one (between the --- interrupt, and --- syscall sections): > > KDB: stack backtrace: > db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 > hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 > lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c > Xtimerint() at Xtimerint+0x1f > --- interrupt, eip = 0xc07ff29d, esp = 0xe66e0b48, ebp = 0xe66e0c34 --- > kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d > do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at do_sendfile+0xb1 > sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 > syscall(e66e0d38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = > 0xbfbfc7cc, ebp = 0xbfbfe848 --- > KDB: enter: watchdog timeout Can you look up the source line for kern_sendfile+0x90d in your kernel ? Do kgdb kernel.debug, then execute "list *(kern_sendfile+0x90d)". -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091023/82bd0cf1/attachment.pgp From mav at FreeBSD.org Fri Oct 23 21:38:51 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Oct 23 21:39:04 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE073CF.40500@comcast.net> References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> Message-ID: <4AE22264.60909@FreeBSD.org> Steve Polyack wrote: > Alexander Motin wrote: >>> If your conditions permit, you can try to upgrade to recent HEAD to look >>> how will it go with newer code. I am periodically merging my work there >>> from Perforce. Also I am going to generate new test patch for HEAD, >>> which includes reworked PMP support, tomorrow. >> >> You can try this patch against today's HEAD: >> http://people.freebsd.org/~mav/cam-ata.20091022.patch >> > I tried the patch this morning against a fresh checkout of HEAD. > Immediately after boot only one device per PM was detected (I have two > hooked up at the moment, 5 drives on one, 1 on the other). However, > about two minutes later all of the drives showed up! I've just committed to HEAD new reset sequence for siis. Try please new HEAD with new patch and show me full results. Patch: http://people.freebsd.org/~mav/cam-ata.20091023.patch Thanks. -- Alexander Motin From jacob at whotookspaz.org Fri Oct 23 22:09:27 2009 From: jacob at whotookspaz.org (Jacob Myers) Date: Fri Oct 23 22:09:34 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: <4AE2232E.10406@whotookspaz.org> Jaime Bozza wrote: [snip] > The additional information I have (over the PR) is that: > 1) Files over 64K cause the problem, not just larger files I thought it was over 1 MB or so. But maybe I'm wrong. ISTR that I couldn't trigger it with some images of around 70K. > 2) switching over to SCHED_4BSD eliminates the problem - system no longer locks. I will have to test this. This is indeed interesting... > 3) 7.2 amd64 doesn't have the problem - Tested a similar configuration and was not able to duplicate on amd64 at all. I can replicate this problem on FreeBSD 7.2/amd64 reliably. -- Jacob Myers | Website: http://whotookspaz.org Network Admin, Wilcox Technologies | Public key: 186A424A Using FreeBSD since 2007 | Public shell: http://bit.ly/42iGCR Answer a fool according to his folly, lest he be wise in his own conceit -- Proverbs, 26:5 From areilly at bigpond.net.au Sat Oct 24 03:58:17 2009 From: areilly at bigpond.net.au (Andrew Reilly) Date: Sat Oct 24 03:58:29 2009 Subject: Some questions about da0 on USB2 (recent bad behaviour) Message-ID: <20091024022238.GA9296@duncan.reilly.home> Hi there, I have a system with a couple of Western Digital "MyBook" USB2 drives connected to it, and have started seeing some odd behaviour that I am not sure how to identify the cause of. Perhaps someone could offer a suggestion or two? The behaviour that I've noticed (and I can't remember any particular event precipitating this, but I do track 8-STABLE approximately weekly, so things do change from time to time...) is that the drive will just stop for a couple of minutes, and then continue what it was doing. For a while that's all I could see: no error messages at all. The last time I booted, I turned on verbose booting and now I see that these periods of inactivity result in streams of syslog messages like: Oct 24 12:48:55 duncan kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Oct 24 12:48:55 duncan kernel: (da0:umass-sim0:0:0:0): Retrying Command Oct 24 12:50:24 duncan kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Oct 24 12:50:24 duncan kernel: (da0:umass-sim0:0:0:0): Retrying Command The retry seems to be successful, because I'm not getting any hard error messages anywhere, and the disk activity does seem to proceed afterwards. The disk drive isn't making any bad/broken noises, either. That drive is, according to dmesg.boot: ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus1 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-0 device pass0: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) What is the likelihood that these pauses and command retries are a sign that this specific drive is in the process of dying, physically? If that were the case, are there any diagnostic tools that I could run against it to show, say, internal error logs? What is the significance of the "sim" part of the device designation umass-sim0? I've looked in all of the manual pages I can think of, but that clearly isn't enough. usbdevs -v says "no USB controllers found", which I thought a bit unuseful. I assume it is *supposed* to work, is there a trick? usbconfig shows my connected USB devices and hubs: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON At this rate the dump/restore backup that I'm running to get the data off it will take a little over a day to finish (according to dump), even though systat shows the drive doing about 8MB/s while it's working, which would allow the dump to finish in about eight hours. These modern, large drives are all very well, but they make doing any kind of system reconfiguration or backup really time consuming... Cheers, -- Andrew From areilly at bigpond.net.au Sat Oct 24 09:29:01 2009 From: areilly at bigpond.net.au (Andrew Reilly) Date: Sat Oct 24 09:29:09 2009 Subject: Some questions about da0 on USB2 (recent bad behaviour) In-Reply-To: <20091024022238.GA9296@duncan.reilly.home> References: <20091024022238.GA9296@duncan.reilly.home> Message-ID: <20091024092846.GA68657@duncan.reilly.home> Just a follow-up with some more information: I now doubt that the problem that I reported in the original message is the drive dying: I've just done some read tests (cat largefile >/dev/null) on the other USB2-attached drive (also a Western Digital MyBook, but this one is a USB2+Firewire one with 1TB, while the other one was just USB2 with 750G.) I'm seeing essentially the same behaviour on that drive, too. That is: it seems to work fine for some fraction of a minute (doesn't seem to be longer than a minute, anyway), and then stops completely for several minutes (processes reading or writing sit in "D" state in ps) and then starts again, after logging "Request completed with CAM_REQ_CMP_ERR\nRetrying Command". I reckon that the duty cycle of useful behaviour is is a bit less than a third. Any chance this is some new badness in the USB+umass stack? Anything that I can poke or prod to make it behave better? Any way that I can find out where it's going awry? I don't have kdb in my kernel, but everything not directly connected to these USB devices seem to be behaving themselves completely. Oh: stoppage on the two drives doesn't seem to be chronologically correllated. Cheers, -- Andrew From oliver at FreeBSD.org Sat Oct 24 09:48:44 2009 From: oliver at FreeBSD.org (Oliver Lehmann) Date: Sat Oct 24 09:48:52 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <20091023173611.1d44c7a4.oliver@FreeBSD.org> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> Message-ID: <20091024114842.a4b9846e.oliver@FreeBSD.org> Oliver Lehmann wrote: > tunefs -L usr mirror/gm0s1f.journal > tunefs -L files da0p1.journal > > /dev/ufs and /dev/label contained all the given label. Then I rebooted > once more - again into the single user mode. > > Now ufs/files and ufs/usr is gone.... so glabel in conjunction with > gjournal is broken.... This worked by the way in BETA3 - this was when I tested this setup before setting up the fileserver.... so this is a regression to me. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From jbozza at mindsites.com Sat Oct 24 14:36:53 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Sat Oct 24 14:37:00 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: <4AE2232E.10406@whotookspaz.org> References: <4AE2232E.10406@whotookspaz.org> Message-ID: > > The additional information I have (over the PR) is that: > > 1) Files over 64K cause the problem, not just larger files > I thought it was over 1 MB or so. But maybe I'm wrong. ISTR that I > couldn't trigger it with some images of around 70K. I discovered it originally with a 72K file. After some tests, I found a 63K file worked and a 65K file didn't. When I get back into the office, I can test the actual boundary (65535, 65536, 65537, etc), but 64K seems pretty logical. > > 2) switching over to SCHED_4BSD eliminates the problem - system no > longer locks. > I will have to test this. This is indeed interesting... > > > 3) 7.2 amd64 doesn't have the problem - Tested a similar > configuration and was not able to duplicate on amd64 at all. > I can replicate this problem on FreeBSD 7.2/amd64 reliably. I haven't tried larger files - Maybe the boundary is different on amd64? Doing some quick tests right now, I was able to upload a 100MB file without a problem, but this is an AMD64 system with SMP, plus the filesystem is all ZFS, so there are too many things different. I'll have to setup a system that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I can say I'm not having a problem there. Jaime From bf1783 at googlemail.com Sat Oct 24 19:39:03 2009 From: bf1783 at googlemail.com (b. f.) Date: Sat Oct 24 19:39:10 2009 Subject: Some questions about da0 on USB2 (recent bad behaviour) Message-ID: >That is: it seems to work fine for some fraction of a minute >(doesn't seem to be longer than a minute, anyway), and then >stops completely for several minutes (processes reading or >writing sit in "D" state in ps) and then starts again, after >logging "Request completed with CAM_REQ_CMP_ERR\nRetrying >Command". In the past week or so, Alexander Motin (mav@FreeBSD.org) and Andrew Thompson (thompsa@FreeBSD.org) have made a number of related changes to cam and usb in the P4 repository, and in 9-CURRENT. Some of these may address your problem. I'm not sure when they will be back-ported to 8.X. You may wish to try out the latest version of -CURRENT, to see if it solves your problem(s); or to contact them. b. From mav at FreeBSD.org Sun Oct 25 00:47:04 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Sun Oct 25 00:47:12 2009 Subject: MCP55 SATA solution to test Message-ID: <4AE3A001.8000205@FreeBSD.org> Hi. Thanks to one man who provided access to his machine, I seem to found how to fix device detection on nVidia MCP55 SATA controller on amd64 8.0. Looks like this controller need some time (very short) to enable BAR(5) memory access after PCI configuration register written. Probably some changes in PCI code exposed this issue. Also it explains why setting hw.pci.mcfg to 0 helps. Attached patch solves problem for that machine. Testers are welcome. -- Alexander Motin -------------- next part -------------- --- ata-nvidia.c.prev 2009-10-25 03:13:57.000000000 +0300 +++ ata-nvidia.c 2009-10-25 03:15:52.000000000 +0300 @@ -165,7 +165,8 @@ ata_nvidia_chipinit(device_t dev) /* enable control access */ pci_write_config(dev, 0x50, pci_read_config(dev, 0x50, 1) | 0x04,1); - + /* MCP55 seems to need some time to allow r_res2 read. */ + DELAY(10); if (ctlr->chip->cfg1 & NVQ) { /* clear interrupt status */ ATA_OUTL(ctlr->r_res2, offset, 0x00ff00ff); From =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= Sun Oct 25 02:07:18 2009 From: =?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?= (=?utf-8?b?4LmE4Lie4Lij4Lix4LiKIA==?=) Date: Sun Oct 25 02:07:25 2009 Subject: make release stop at cdrtools Message-ID: <20091025081422.20341pp8zbvuupgu@webmail.tint.or.th> hi sirs, apologized me for disturbing this list but ireally have problem s. i make my own release by follwoing document in releng articles. here is my command cd /usr/src/release time make CHROOTDIR=/kaitag/KAITAG BUILDNAME=7.2-RELEASE \ CVSROOT=/var/ftp/pub/ncvs RELEASETAG=RELENG_7_2_0_RELEASE \ EXTSRCDIR=/usr/src EXTPORTSDIR=/usr/ports \ DOC_LANG=en_US.ISO8859-1 NODOC=NO NOPORTS=NO \ MAKE_DVD=YES MAKE_ISOS=YES CDROM=YES RELEASEDISTFILES=/var/ftp/pub/distfiles \ release the build process goes well but then fetching for cdrtools.tbz begin and stop. in my machine i have installed cdrtools and there is also mkisofs file so i wonder why the script /usr/src/release/i386/mkisofsimages.sh still fetching for cdrtools. and here is my uname of my machine wmc# uname -a FreeBSD wmc.tint.or.th 7.2-RELEASE FreeBSD KAITAG #0: Wed Oct 21 14:36:40 ICT 2009 root@wmc.tint.or.th:/usr/obj/usr/src/sys/WMC i386 wmc# i set UNAME_r=7.2-RELEASE in /etc/make.conf though. many thanks in advance for any helps and hints. with best regards, psr -- ???? ?????????? ????? ????????? http://makham.blogspot.com ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From marco.broeder at gmx.eu Sun Oct 25 16:37:17 2009 From: marco.broeder at gmx.eu (Marco =?utf-8?q?Br=C3=B6der?=) Date: Sun Oct 25 16:37:54 2009 Subject: MCP55 SATA solution to test In-Reply-To: <4AE3A001.8000205@FreeBSD.org> References: <4AE3A001.8000205@FreeBSD.org> Message-ID: <200910251709.49850.marco.broeder@gmx.eu> On Sun October 25 2009 02:46:57 Alexander Motin wrote: > Hi. > > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. > > Attached patch solves problem for that machine. Testers are welcome. > Success! I tested your patch and everything is working fine with hw.pci.mcfg set to 1, now. Please commit it. Many thanks! -- Regards, Marco Br?der OpenPGP key fingerprint: 5615 106E 031A F3D3 64CC 0F9E 4DCE 6524 F595 082F From kris.weston at gmail.com Sun Oct 25 16:44:07 2009 From: kris.weston at gmail.com (Kris Weston) Date: Sun Oct 25 16:44:24 2009 Subject: i am desperate over some GPT tables In-Reply-To: <1256303940.2283.15.camel@balrog.2hip.net> References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> <1256303940.2283.15.camel@balrog.2hip.net> Message-ID: <72d267bc0910250944y298d9535x9eac8cf9ba7a9b27@mail.gmail.com> hi Robert appreciate you having a look at this, if you need any funny noises ever, give us a shout :) i really dont know what to do as i dont have a spare box to try out solaris on and solaris wont boot fully here... i did manage to export the drives from solaris first so all *should* be well... there are three disks in the set ad4,ad6,ad8 terrabyte each - they are supposed to be two mirrors but one disk went down should still work though - well was working in solaris... as i said before it at least could read the pools from freebsd before but something has happened now where it wont... i think 4+6 are a mirror... let me know if you can shed any light... out of interest - how do you look at these dumps ? and what are you looking for ? thanks Kris -- )) (( c[_] 2009/10/23 Robert Noland > On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: > > been looking for months now, trawled google no help, i just dont > understand. > > do you need a GPT table with zfs ? > > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to > import > > my zpool into it > > exported fine on solaris , its definitely the same version (v13) > > but when i import into zfs it says GPT tables corrupt ? > > why ? and what does this mean ? > > please help me. pleeeeease. > > Send me the fist 34 sectors of the disk and I will try to take a look. > > dd if= of=header.dmp bs=512 count=34 > > robert. > > > -- > > > > )) > > (( > > c[_] > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > -- > Robert Noland > FreeBSD > > -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad4.dmp Type: application/octet-stream Size: 17408 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/3f12260d/headerad4.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad6.dmp Type: application/octet-stream Size: 17408 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/3f12260d/headerad6.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad8.dmp Type: application/octet-stream Size: 17408 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/3f12260d/headerad8.obj From ronald-freebsd8 at klop.yi.org Sun Oct 25 19:54:53 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Sun Oct 25 19:55:06 2009 Subject: zfs receive gives: internal error: Argument list too long Message-ID: Hi, Making a backup to my external USB-disk now fails with the following output. [root@sjakie ~]# zfs send -vi tank/home@repl-20090919_195900 tank/home@repl-20090921_195900 > /bla.snapshot # ls -lh /bla* -rw-r--r-- 1 root wheel 547M Oct 25 20:44 /bla.snapshot [root@sjakie ~]# zfs receive -F extern/home < /bla.snapshot internal error: Argument list too long Abort trap: 6 (core dumped) # uname -a FreeBSD sjakie.klop.ws 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 21 00:57:07 CEST 2009 root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC amd64 I have two pools 'tank' and 'extern'. I send/recieve several volumes from tank to extern. zpool is version 13 and zfs is version 3 Searching the internet I found this link: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6573681 Is this a known bug for freebsd also? Can anybody help me in continuing my snapshotting process? (Except making a new fresh snapshot, which is my last option.) Ronald. From ronald-freebsd8 at klop.yi.org Sun Oct 25 19:58:39 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Sun Oct 25 19:58:56 2009 Subject: zfs receive gives: internal error: Argument list too long In-Reply-To: References: Message-ID: On Sun, 25 Oct 2009 20:54:48 +0100, Ronald Klop wrote: > Hi, > > Making a backup to my external USB-disk now fails with the following > output. > > [root@sjakie ~]# zfs send -vi tank/home@repl-20090919_195900 > tank/home@repl-20090921_195900 > /bla.snapshot > > # ls -lh /bla* > -rw-r--r-- 1 root wheel 547M Oct 25 20:44 /bla.snapshot > > [root@sjakie ~]# zfs receive -F extern/home < /bla.snapshot > internal error: Argument list too long > Abort trap: 6 (core dumped) > > # uname -a > FreeBSD sjakie.klop.ws 8.0-RC1 FreeBSD 8.0-RC1 #6: Wed Oct 21 00:57:07 > CEST 2009 root@sjakie.klop.ws:/usr/obj/usr/src/sys/GENERIC amd64 > > I have two pools 'tank' and 'extern'. I send/recieve several volumes > from tank to extern. > zpool is version 13 and zfs is version 3 > > Searching the internet I found this link: > http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6573681 I meant: http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6801979 > Is this a known bug for freebsd also? > Can anybody help me in continuing my snapshotting process? (Except > making a new fresh snapshot, which is my last option.) > > Ronald. From glen.j.barber at gmail.com Sun Oct 25 21:39:30 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Sun Oct 25 21:39:37 2009 Subject: [panic] Finally got a crash report Message-ID: <4ad871310910251439x781a462cq96c98cee1a4806f7@mail.gmail.com> Howdy, Since I got this laptop, I've been having some issues I could not track. Usually the system will completely lock up, no keyboard, mouse, etc, leaving me with no way to break to the debugger, forcing me to power off completely. Something changed recently, and although the machine locked up again, I was able to get a crash report[1]. The kernel config the crash report mentions is available as well[2]. I can usually trigger it with excessive disk IO, but this time I was editing a file in Vim. Any thoughts? [1] - http://freebsd.dev-urandom.com/ports/20091025.core.txt [2] - http://freebsd.dev-urandom.com/ports/PEGASUS -- Glen Barber From rnoland at FreeBSD.org Sun Oct 25 22:51:26 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sun Oct 25 22:51:34 2009 Subject: i am desperate over some GPT tables In-Reply-To: <72d267bc0910250944y298d9535x9eac8cf9ba7a9b27@mail.gmail.com> References: <72d267bc0910210511t4a54ce3dm1490fec593377a44@mail.gmail.com> <1256303940.2283.15.camel@balrog.2hip.net> <72d267bc0910250944y298d9535x9eac8cf9ba7a9b27@mail.gmail.com> Message-ID: <1256511077.2502.181.camel@balrog.2hip.net> On Sun, 2009-10-25 at 16:44 +0000, Kris Weston wrote: > hi Robert appreciate you having a look at this, > if you need any funny noises ever, give us a shout :) > i really dont know what to do as i dont have a spare box to try out solaris > on and solaris wont boot fully here... > i did manage to export the drives from solaris first so all *should* be > well... > there are three disks in the set ad4,ad6,ad8 > terrabyte each - they are supposed to be two mirrors but one disk went down > should still work though - well was working in solaris... > as i said before it at least could read the pools from freebsd before but > something has happened now where it wont... > > i think 4+6 are a mirror... > let me know if you can shed any light... > out of interest - how do you look at these dumps ? and what are you looking > for ? Ok, we have a couple of options.... What I have done so far is to hex edit your GPT headers, though technically they are valid. Sector 2 is the GPT header and normally the header length is recorded as 92 bytes. Yours claim that the header it 512 bytes or the entire sector. The crc32 value is calculated based on byte 0 - header size. Our GPT code is performing the crc comparison based on the 92 valid bytes in the header along with 512 - 92 bytes of random memory, so the header crc fails and GEOM refuses the header. We need to fix the GPT code to handle this correctly, so you can give me a little time to fix it correctly, or we can just fix your existing GPT headers to work with our code... Before: GEOM: md6: corrupt or invalid GPT detected. GEOM: md6: GPT rejected -- may not be recoverable. After: GEOM: md6: the secondary GPT table is corrupt or invalid. GEOM: md6: using the primary only -- recovery suggested. => 34 1953525101 md6 GPT (466T) 34 222 - free - (111K) 256 1953508495 1 !6a898cc3-1dd2-11b2-99a6-080020736631 (932G) 1953508751 16384 9 !6a945a3b-1dd2-11b2-99a6-080020736631 (8.0M) Hopefully I don't need to tell you proceed with caution here, but if you want to rewrite the headers, I've attached 6 files which contain the modified primary and secondary headers. The seek values below for the secondary header are calculated for your drive. Make sure that you use the correct header for the correct drive and pri/sec. dd if=headeradX-pri.dmp of=/dev/adX bs=512 seek=1 dd if=headeradX-sec.dmp of=/dev/adX bs=512 seek=1953525167 robert. > thanks > > Kris > -- > > )) > (( > c[_] > > > 2009/10/23 Robert Noland > > > On Wed, 2009-10-21 at 13:11 +0100, Kris Weston wrote: > > > been looking for months now, trawled google no help, i just dont > > understand. > > > do you need a GPT table with zfs ? > > > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to > > import > > > my zpool into it > > > exported fine on solaris , its definitely the same version (v13) > > > but when i import into zfs it says GPT tables corrupt ? > > > why ? and what does this mean ? > > > please help me. pleeeeease. > > > > Send me the fist 34 sectors of the disk and I will try to take a look. > > > > dd if= of=header.dmp bs=512 count=34 > > > > robert. > > > > > -- > > > > > > )) > > > (( > > > c[_] > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > > " > > -- > > Robert Noland > > FreeBSD > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad4-pri.dmp Type: application/octet-stream Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/8ea6dd9d/headerad4-pri.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad4-sec.dmp Type: application/octet-stream Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/8ea6dd9d/headerad4-sec.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad6-pri.dmp Type: application/octet-stream Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/8ea6dd9d/headerad6-pri.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad6-sec.dmp Type: application/octet-stream Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/8ea6dd9d/headerad6-sec.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad8-pri.dmp Type: application/octet-stream Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/8ea6dd9d/headerad8-pri.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: headerad8-sec.dmp Type: application/octet-stream Size: 512 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091025/8ea6dd9d/headerad8-sec.obj From petefrench at ticketswitch.com Mon Oct 26 11:20:13 2009 From: petefrench at ticketswitch.com (Pete French) Date: Mon Oct 26 11:20:20 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? Message-ID: just about to build a new ZFS based system and I was wondering what the recommended way to dedicate a whole disc to ZFS is these days. Should I just give it 'da1', 'da2' etc as I have done in the past, or is it better to use GPT to create a partition over the whole disc, which is marked as being for freebsd-zfs ? Not that I have had any problems with simply using bare drives, but the phrase 'dangerously dedicated' does keep nagging at me, hence considering the GPT route :-) cheers, -pete. From exemys at exemys.com Mon Oct 26 12:36:39 2009 From: exemys at exemys.com (Exemys) Date: Mon Oct 26 12:36:49 2009 Subject: Modbus Serial - Modbus TCP/IP Message-ID: This is a message in multipart MIME format. Your mail client should not be displaying this. Consider upgrading your mail client to view this message correctly. From arnaud.houdelette at tzim.net Mon Oct 26 13:10:33 2009 From: arnaud.houdelette at tzim.net (Arnaud Houdelette) Date: Mon Oct 26 13:10:41 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: <4AE2232E.10406@whotookspaz.org> Message-ID: <4AE59FBE.6060904@tzim.net> Jaime Bozza a ?crit : >>> The additional information I have (over the PR) is that: >>> 1) Files over 64K cause the problem, not just larger files >>> >> I thought it was over 1 MB or so. But maybe I'm wrong. ISTR that I >> couldn't trigger it with some images of around 70K. >> > > I discovered it originally with a 72K file. After some tests, I found a 63K file worked and a 65K file didn't. When I get back into the office, I can test the actual boundary (65535, 65536, 65537, etc), but 64K seems pretty logical. > > >>> 2) switching over to SCHED_4BSD eliminates the problem - system no >>> >> longer locks. >> I will have to test this. This is indeed interesting... >> >> >>> 3) 7.2 amd64 doesn't have the problem - Tested a similar >>> >> configuration and was not able to duplicate on amd64 at all. >> I can replicate this problem on FreeBSD 7.2/amd64 reliably. >> > > I haven't tried larger files - Maybe the boundary is different on amd64? Doing some quick tests right now, I was able to upload a 100MB file without a problem, but this is an AMD64 system with SMP, plus the filesystem is all ZFS, so there are too many things different. I'll have to setup a system that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I can say I'm not having a problem there. > > Jaime > I had the same issue using 7.1 amd64, with ZFS, no SMP. Not really sure what is the size boundary. I can't really test either, as the machine is remote. But I confirm that each tentative upload of certain relatively 'big' files (around 1MB) with wordpress hanged the system before I switched from sendfile to writev. I might do some test on amd64 7.2 with no SMP if it can be of any use ? Arnaud From jacob at whotookspaz.org Mon Oct 26 13:38:05 2009 From: jacob at whotookspaz.org (Jacob Myers) Date: Mon Oct 26 13:38:18 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: <4AE59FBE.6060904@tzim.net> References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> Message-ID: <4AE5A631.1030607@whotookspaz.org> Arnaud Houdelette wrote: > I had the same issue using 7.1 amd64, with ZFS, no SMP. > Not really sure what is the size boundary. I can't really test either, > as the machine is remote. > But I confirm that each tentative upload of certain relatively 'big' > files (around 1MB) with wordpress hanged the system before I switched > from sendfile to writev. > > I might do some test on amd64 7.2 with no SMP if it can be of any use ? > > Arnaud I can confirm it happens without SMP on 7.2 and amd64. If you can give it a try though, well, the more information the better. Any boundary information, even approximate (well, mostly testing if 64K is the boundary or if 1 MB or so is) would probably be good, too. -- Jacob Myers | Website: http://whotookspaz.org Network Admin, Wilcox Technologies | Public key: 186A424A Using FreeBSD since 2007 | Public shell: http://bit.ly/42iGCR Answer a fool according to his folly, lest he be wise in his own conceit -- Proverbs, 26:5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091026/1a86ac41/signature.pgp From dalroi at solfertje.student.utwente.nl Mon Oct 26 13:53:47 2009 From: dalroi at solfertje.student.utwente.nl (Alban Hertroys) Date: Mon Oct 26 13:53:54 2009 Subject: NULL-pointer reference in ulpt Message-ID: I didn't get any replies to my previous report, so I'm trying again. I frequently get a kernel-panic after printing something to my USB printer (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a NULL-pointer for xfer from ulpt_tick(). System is a 7.2-STABLE, last updated on Sep 15. I just did a make update, but there were no changes to ulpt.c. The core-summary is available from http://solfertje.student.utwente.nl/~dalroi/core.txt Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4ae5a9e512191499454227! From korvus at comcast.net Mon Oct 26 13:55:18 2009 From: korvus at comcast.net (Steve Polyack) Date: Mon Oct 26 13:55:26 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE099D8.5060103@FreeBSD.org> References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> Message-ID: <4AE5AA43.7030405@comcast.net> Alexander Motin wrote: > Steve Polyack wrote: > >> Alexander Motin wrote: >> >>> You can try this patch against today's HEAD: >>> http://people.freebsd.org/~mav/cam-ata.20091022.patch >>> >>> >> I tried the patch this morning against a fresh checkout of HEAD. >> Immediately after boot only one device per PM was detected (I have two >> hooked up at the moment, 5 drives on one, 1 on the other). However, >> about two minutes later all of the drives showed up! >> >> camcontrol also rescans the entire bus *very* quickly now, and discovers >> all changes (new/missing disks and port multipliers). >> >> Here's some verbose info from /var/log/messages immediately after boot: >> Oct 22 10:52:03 lovepod kernel: siisch0: Timeout on slot 27 >> Oct 22 10:52:03 lovepod kernel: siisch0: siis_timeout is 00000000 ss >> 08000000 rs 08000000 es 00000000 sts 801b2000 serr 00000000 >> Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms >> Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms >> Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset... >> Oct 22 10:52:03 lovepod kernel: siisch0: ready wait time=1ms >> Oct 22 10:52:03 lovepod kernel: siisch0: hardware reset ... >> Oct 22 10:52:03 lovepod kernel: siisch0: SATA connect timeout >> status=00000001 >> Oct 22 10:52:03 lovepod kernel: siisch0: SIIS reset done: phy reset >> found no device >> Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Command timed out >> Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): error 5 >> Oct 22 10:52:03 lovepod kernel: (aprobe0:siisch0:0:1:0): Retries Exhausted >> Oct 22 10:52:03 lovepod kernel: siisch0: DISCONNECT requested >> > > What was before that? Can you send me full verbose boot messages? > > Here's a full dmesg from today using the 10/22/2009 head and patch. It actually failed to detect all but one of 6 drives this time. I'm about to try today's head and patch. I'll let you know how it goes. -------------- next part -------------- Copyright (c) 1992-2009 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 9.0-CURRENT #2: Thu Oct 22 10:34:44 EDT 2009 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff809e7000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff809e7260. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133421704 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000093fff, 602112 bytes (147 pages) 0x0000000000a16000 - 0x00000000b60fffff, 3043926016 bytes (743146 pages) 0x00000000bf78e000 - 0x00000000bf78ffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x000000013ffeffff, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: <061909 APIC1420> INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 00000097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 00000097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 00000000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 00000097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 00000097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 00000097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 00000097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 00000097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 00000097) ACPI: DMAR 0xbf79e0c0 00120 (v1 AMI OEMDMAR 00000001 MSFT 00000097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 00000097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 00000097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 00000097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 00000097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x10000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010400 nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 ACPI timer: 1/2 1/2 1/1 1/0 1/0 1/2 1/0 1/0 1/1 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff iomem 0xfed40000-0xfed44fff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3403, revid=0x13 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x13 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x13 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x13 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3410, revid=0x13 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342e, revid=0x13 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x13 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x13 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x13 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3430, revid=0x13 domain=0, bus=0, slot=22, func=0 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacfc000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3431, revid=0x13 domain=0, bus=0, slot=22, func=1 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3432, revid=0x13 domain=0, bus=0, slot=22, func=2 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3433, revid=0x13 domain=0, bus=0, slot=22, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3429, revid=0x13 domain=0, bus=0, slot=22, func=4 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacec000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x342a, revid=0x13 domain=0, bus=0, slot=22, func=5 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x342b, revid=0x13 domain=0, bus=0, slot=22, func=6 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x342c, revid=0x13 domain=0, bus=0, slot=22, func=7 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacde000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacde000 found-> vendor=0x8086, dev=0x3a3e, revid=0x00 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfacd8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a4a, revid=0x00 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacdc000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacdc000 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a22, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xac00, size 2, enabled map[18]: type I/O Port, range 32, base 0xa880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa800, size 2, enabled map[20]: type I/O Port, range 32, base 0xa480, size 5, enabled map[24]: type Memory, range 32, base 0xfacd2000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfacd0000, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfad00000-0xfadfffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x12d8, dev=0xe111, revid=0x02 domain=0, bus=3, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: irq 16 at device 0.0 on pci3 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xfad00000-0xfadfffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1095, dev=0x3124, revid=0x01 domain=0, bus=4, slot=4, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x01df, statreg=0x02b0, cachelnsz=64 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfadfe000, size 7, enabled pcib4: requested memory range 0xfadfe000-0xfadfe07f: good pcib3: requested memory range 0xfadfe000-0xfadfe07f: good map[18]: type Memory, range 64, base 0xfadf0000, size 15, enabled pcib4: requested memory range 0xfadf0000-0xfadf7fff: good pcib3: requested memory range 0xfadf0000-0xfadf7fff: good map[20]: type I/O Port, range 32, base 0xcc00, size 4, enabled pcib4: requested I/O range 0xcc00-0xcc0f: in range pcib3: requested I/O range 0xcc00-0xcc0f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: slot 4 INTA is routed to irq 16 siis0: port 0xcc00-0xcc0f mem 0xfadfe000-0xfadfe07f,0xfadf0000-0xfadf7fff irq 16 at device 4.0 on pci4 siis0: Reserved 0x80 bytes for rid 0x10 type 3 at 0xfadfe000 siis0: Reserved 0x8000 bytes for rid 0x18 type 3 at 0xfadf0000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 16 vector 49 siis0: [MPSAFE] siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [MPSAFE] siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [MPSAFE] siisch1: [ITHREAD] siisch2: at channel 2 on siis0 siisch2: [MPSAFE] siisch2: [ITHREAD] siisch3: at channel 3 on siis0 siisch3: [MPSAFE] siisch3: [ITHREAD] pcib5: at device 9.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 16 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 16 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfacde000-0xfacde3ff irq 18 at device 26.7 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 16 vector 52 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib6: irq 17 at device 28.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0x0-0x0 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 pcib7: irq 17 at device 28.4 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xd000-0xdfff pcib7: memory decode 0xfae00000-0xfaefffff pcib7: no prefetched decode pci7: on pcib7 pci7: domain=0, physical bus=7 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfaee0000, size 17, enabled pcib7: requested memory range 0xfaee0000-0xfaefffff: good map[18]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib7: requested I/O range 0xdc00-0xdc1f: in range map[1c]: type Memory, range 32, base 0xfaedc000, size 14, enabled pcib7: requested memory range 0xfaedc000-0xfaedffff: good pcib7: matched entry for 7.0.INTA pcib7: slot 0 INTA hardwired to IRQ 16 em0: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci7 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfaee0000 em0: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfaedc000 em0: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 256 to local APIC 16 vector 53 msi: routing MSI-X IRQ 257 to local APIC 16 vector 54 msi: routing MSI-X IRQ 258 to local APIC 16 vector 55 em0: using IRQs 256-258 for MSI-X em0: Using MSIX interrupts em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: bpf attached em0: Ethernet address: 00:30:48:db:7d:9e pcib8: irq 16 at device 28.5 on pci0 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0xe000-0xefff pcib8: memory decode 0xfaf00000-0xfaffffff pcib8: no prefetched decode pci8: on pcib8 pci8: domain=0, physical bus=8 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfafe0000, size 17, enabled pcib8: requested memory range 0xfafe0000-0xfaffffff: good map[18]: type I/O Port, range 32, base 0xec00, size 5, enabled pcib8: requested I/O range 0xec00-0xec1f: in range map[1c]: type Memory, range 32, base 0xfafdc000, size 14, enabled pcib8: requested memory range 0xfafdc000-0xfafdffff: good pcib8: matched entry for 8.0.INTA pcib8: slot 0 INTA hardwired to IRQ 17 em1: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci8 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfafe0000 em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfafdc000 em1: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 259 to local APIC 16 vector 56 msi: routing MSI-X IRQ 260 to local APIC 16 vector 57 msi: routing MSI-X IRQ 261 to local APIC 16 vector 58 em1: using IRQs 259-261 for MSI-X em1: Using MSIX interrupts em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: bpf attached em1: Ethernet address: 00:30:48:db:7d:9f uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb480 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 16 vector 59 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x3f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb080 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfacdc000-0xfacdc3ff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib9: at device 30.0 on pci0 pcib9: domain 0 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0xfb000000-0xfbefffff pcib9: prefetched decode 0xf9000000-0xf9ffffff pcib9: Subtractively decoded bridge. pci9: on pcib9 pci9: domain=0, physical bus=9 found-> vendor=0x102b, dev=0x0532, revid=0x0a domain=0, bus=9, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=64 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=15 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf9000000, size 24, enabled pcib9: requested memory range 0xf9000000-0xf9ffffff: good map[14]: type Memory, range 32, base 0xfbefc000, size 14, enabled pcib9: requested memory range 0xfbefc000-0xfbefffff: good map[18]: type Memory, range 32, base 0xfb000000, size 23, enabled pcib9: requested memory range 0xfb000000-0xfb7fffff: good pcib9: matched entry for 9.1.INTA pcib9: slot 1 INTA hardwired to IRQ 18 vgapci0: mem 0xf9000000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff irq 18 at device 1.0 on pci9 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfacd2000-0xfacd27ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfacd2000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 262 to local APIC 16 vector 64 ahci0: using IRQ 262 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) Calling int 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting int 0x15 (ax=0x0000 bx=0xe712 cx=0x0000 dx=0x0000 es=0xf000 di=0x0000) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 16 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 16 vector 61 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 16 vector 62 uart1: [FILTER] uart1: fast interrupt cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 6E, should be 6B (20091013/tbutils-354) ACPI: SSDT 0xbf79e1e0 008F0 (v1 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf79ead0 004D5 (v1 PmRef P001Cst 00003001 INTL 20051117) est0: on cpu0 est0: Invalid id16 (set, cur) = (15, 16) est0: Invalid freq 2000, ignored. est0: Invalid id16 (set, cur) = (14, 16) est0: Invalid freq 1867, ignored. est0: Invalid id16 (set, cur) = (13, 16) est0: Invalid freq 1733, ignored. est0: Invalid id16 (set, cur) = (12, 16) est0: Invalid freq 1600, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (15, 16) est1: Invalid freq 2000, ignored. est1: Invalid id16 (set, cur) = (14, 16) est1: Invalid freq 1867, ignored. est1: Invalid id16 (set, cur) = (13, 16) est1: Invalid freq 1733, ignored. est1: Invalid id16 (set, cur) = (12, 16) est1: Invalid freq 1600, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (15, 16) est2: Invalid freq 2000, ignored. est2: Invalid id16 (set, cur) = (14, 16) est2: Invalid freq 1867, ignored. est2: Invalid id16 (set, cur) = (13, 16) est2: Invalid freq 1733, ignored. est2: Invalid id16 (set, cur) = (12, 16) est2: Invalid freq 1600, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (15, 16) est3: Invalid freq 2000, ignored. est3: Invalid id16 (set, cur) = (14, 16) est3: Invalid freq 1867, ignored. est3: Invalid id16 (set, cur) = (13, 16) est3: Invalid freq 1733, ignored. est3: Invalid id16 (set, cur) = (12, 16) est3: Invalid freq 1600, ignored. p4tcc3: on cpu3 acpi0: wakeup code va 0xffffff8077774000 pa 0x4000 isa_probe_children: disabling PnP devices ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 257519 -> 100000 procfs registered lapic: Divisor 2, Frequency 66669427 hz Timecounter "TSC" frequency 2133421704 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attachedsiisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch2: CONNECT requested siisch2: SIIS reset... siisch2: ready wait time=1ms siisch2: hardware reset ... siisch2: SATA connect time=0ms status=00000123 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 Waiting 15 seconds for SCSI devices to settle siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch1: SIIS reset... siisch1: ready wait time=1ms siisch1: hardware reset ... siisch1: SATA connect timeout status=00000000 siisch1: SIIS reset done: phy reset found no device siisch2: SIIS reset... siisch2: ready wait time=1ms siisch2: hardware reset ... siisch2: SATA connect time=0ms status=00000123 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 siisch3: SIIS reset... siisch3: ready wait time=1ms siisch3: hardware reset ... siisch3: SATA connect timeout status=00000000 siisch3: SIIS reset done: phy reset found no device ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect timeout status=00000000 ahcich0: AHCI reset done: phy reset found no device ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000123 ahcich1: ready wait time=4ms ahcich1: AHCI reset done: device found ahcich2: AHCI reset... ahcich2: hardware reset ... ahcich2: SATA connect timeout status=00000000 ahcich2: AHCI reset done: phy reset found no device ahcich3: AHCI reset... ahcich3: hardware reset ... ahcich3: SATA connect timeout status=00000000 ahcich3: AHCI reset done: phy reset found no device ahcich4: AHCI reset... ahcich4: hardware reset ... ahcich4: SATA connect timeout status=00000000 ahcich4: AHCI reset done: phy reset found no device ahcich5: AHCI reset... ahcich5: hardware reset ... ahcich5: SATA connect timeout status=00000000 ahcich5: AHCI reset done: phy reset found no device usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ipmi0: IPMI device rev. 1, firmware rev. 1.2, version 2.0 ipmi0: Number of channels 0 ipmi0: Attached watchdog ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ukbd0: on usbus1 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 (aprobe0:siisch0:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe2:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe5:ahcich1:0:0:0): SIGNATURE: 0000 pmp0 at siisch0 bus 0 scbus0 target 15 lun 0 pmp0: ATA/ATAPI-0 device pmp0: 300.000MB/s transfers PM ports: 5 PM RESET 0 PM RESET 1 PM RESET 2 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM RESET 3 PM RESET 4 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM reset done pmp1 at siisch2 bus 0 scbus2 target 15 lun 0 pmp1: ATA/ATAPI-0PM connect done devicePM status: 0 - 00000123 pmp1: 300.000MB/s transfersPM status: 1 - 00000123 PM status: 2 - 00000123 PM status: 3 - 00000123 PM ports: 5 PM status: 4 - 00000123 PM RESET 0 PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done ada0 at PM connect done GEOM: new disk ada0PM status: 0 - 00000123 ahcich1 bus 0 scbus5 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: Serial Number 9VM1RYE5 ada0: 300.000MB/s transfers ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled pass0 at siisch0 bus 0 scbus0 target 15 lun 0 pass0: ATA/ATAPI-0 device pass0: 30GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). 0.000MB/s transfersPM status: 1 - 00000000 PM status: 2 - 00000000 PM status: 3 - 00000000 PM status: 4 - 00000000 pass1 at siisch2 bus 0 scbus2 target 15 lun 0 pass1: ATA/ATAPI-0 device pass1: 300.000MB/s transfers pass2 at ahcich1 bus 0 scbus5 target 0 lun 0 pass2: ATA/ATAPI-8 SATA 2.x device pass2: Serial Number 9VM1RYE5 pass2: 300.000MB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x12000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x14000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x16000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 18 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 20 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 22 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 18 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 20 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 22 vector 49 msi: Assigning MSI-X IRQ 256 to local APIC 18 vector 50 msi: Assigning MSI-X IRQ 257 to local APIC 20 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 22 vector 50 msi: Assigning MSI-X IRQ 260 to local APIC 18 vector 51 msi: Assigning MSI-X IRQ 261 to local APIC 20 vector 51 msi: Assigning MSI IRQ 262 to local APIC 22 vector 51 (aprobe1:siisch2:0:0:0): SIGNATURE: 0000 pass3 at siisch2 bus 0 scbus2 target 0 lun 0 pass3: ATA/ATAPI-8 SATA 2.x device pass3: Serial Number 9VS2FGFN pass3: 300.000MB/s transfers ada1 at siisch2 bus 0 scbus2 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: Serial Number 9VS2FGFN ada1: 300.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled GEOM: new disk ada1 Trying to mount root from ufs:/dev/label/OS/rootfs ct_to_ts([2009-10-26 09:41:15]) = 1256550075.000000000 start_init: trying /sbin/init em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP siisch0: Timeout on slot 26 siisch0: siis_timeout is 00000000 ss 04000000 rs 04000000 es 00000000 sts 801a2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted siisch0: Timeout on slot 27 siisch0: siis_timeout is 00000000 ss 08000000 rs 08000000 es 00000000 sts 801b2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:1:0): Command timed out (aprobe0:siisch0:0:1:0): error 5 (aprobe0:siisch0:0:1:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch0: Timeout on slot 28 siisch0: siis_timeout is 00000000 ss 10000000 rs 10000000 es 00000000 sts 801c2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:2:0): Command timed out (aprobe0:siisch0:0:2:0): error 5 (aprobe0:siisch0:0:2:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch0: Timeout on slot 29 siisch0: siis_timeout is 00000000 ss 20000000 rs 20000000 es 00000000 sts 801d2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:3:0): Command timed out (aprobe0:siisch0:0:3:0): error 5 (aprobe0:siisch0:0:3:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch0: Timeout on slot 30 siisch0: siis_timeout is 00000000 ss 40000000 rs 40000000 es 00000000 sts 801e2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect timeout status=00000001 siisch0: SIIS reset done: phy reset found no device (aprobe0:siisch0:0:4:0): Command timed out (aprobe0:siisch0:0:4:0): error 5 (aprobe0:siisch0:0:4:0): Retries Exhausted siisch0: DISCONNECT requested siisch0: CONNECT requested siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 PMP freeze: 0 PMP freeze: 1 PMP freeze: 2 PMP freeze: 3 PMP freeze: 4 siisch0: Timeout on slot 0 siisch0: siis_timeout is 00000000 ss 00000001 rs 00000001 es 00000000 sts 80002000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (pmp0:siisch0:0:15:0): Command timed out (pmp0:siisch0:0:15:0): Retrying Command siisch0: Timeout on slot 1 siisch0: siis_timeout is 00000000 ss 00000002 rs 00000002 es 00000000 sts 80012000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: hardware reset ... siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (pmp0:siisch0:0:15:0): Command timed out (pmp0:siisch0:0:15:0): error 5 (pmp0:siisch0:0:15:0): Retries Exhausted PMP release: 0 PMP release: 1 PMP release: 2 PMP release: 3 PMP release: 4 From jbozza at mindsites.com Mon Oct 26 14:01:00 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Mon Oct 26 14:01:17 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: <4AE5A631.1030607@whotookspaz.org> References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> <4AE5A631.1030607@whotookspaz.org> Message-ID: From: Jacob Myers [mailto:jacob@whotookspaz.org] > Arnaud Houdelette wrote: > > I had the same issue using 7.1 amd64, with ZFS, no SMP. > > Not really sure what is the size boundary. I can't really test > either, > > as the machine is remote. > > But I confirm that each tentative upload of certain relatively 'big' > > files (around 1MB) with wordpress hanged the system before I switched > > from sendfile to writev. > > > > I might do some test on amd64 7.2 with no SMP if it can be of any use > ? > > > > Arnaud > > I can confirm it happens without SMP on 7.2 and amd64. If you can give > it a try though, well, the more information the better. Any boundary > information, even approximate (well, mostly testing if 64K is the > boundary or if 1 MB or so is) would probably be good, too. I haven't tested the specific boundaries yet, but I will do that shortly. I *was* able to get a crash dump on the i386 system - Will post the details shortly. My amd64 system is a test system with ZFS, so I couldn't get a crash dump. Trying to work around that. On both systems, I used a 72K file (73,688 bytes) to test. Both systems would "lock up", and then a few seconds later kdb would come up. It wasn't an immediate thing, at least not on the i386 system. I wasn't able to watch the amd64 system since it's too far away to time. Jaime From mav at FreeBSD.org Mon Oct 26 14:03:42 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Mon Oct 26 14:03:54 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE5AA43.7030405@comcast.net> References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> <4AE5AA43.7030405@comcast.net> Message-ID: <4AE5AC38.4050507@FreeBSD.org> Steve Polyack wrote: > I'm about to try today's head and patch. I'll let you know how it goes. Ok. Just to be sure it is not cabling issue (I have seen such), try also limit port speed to 1.5Gbps by adding to loader.conf: hint.siisch.0.sata_rev=1 hint.siisch.1.sata_rev=1 hint.siisch.2.sata_rev=1 hint.siisch.3.sata_rev=1 -- Alexander Motin From jbozza at mindsites.com Mon Oct 26 14:05:50 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Mon Oct 26 14:05:57 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: References: Message-ID: Sincerely, Jaime Bozza MindSites Group, LLC From: Dylan Cochran [mailto:heliocentric@gmail.com] > Superficially, this seams identical to a deadlock I reported for > 7.1-RC1. Would you mind compiling a kernel with these options: > > > KDB: stack backtrace: > db_trace_self_wrapper(c0b55b52,e66e0ae0,c07615e9,c0b50617,8ca93,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c0b50617,8ca93,0,c41a7690,2,...) at kdb_backtrace+0x29 > hardclock(0,c07ff29d,0,0,4,...) at hardclock+0x1f9 > lapic_handle_timer(e66e0b08) at lapic_handle_timer+0x9c > Xtimerint() at Xtimerint+0x1f > --- interrupt, eip = 0xc07ff29d, esp = 0xe66e0b48, ebp = 0xe66e0c34 --- > kern_sendfile(c41a7690,e66e0cfc,0,0,0,...) at kern_sendfile+0x90d > do_sendfile(e66e0d2c,c0aba265,c41a7690,e66e0cfc,20,...) at > do_sendfile+0xb1 > sendfile(c41a7690,e66e0cfc,20,16,e66e0d2c,...) at sendfile+0x13 > syscall(e66e0d38) at syscall+0x335 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (393, FreeBSD ELF32, sendfile), eip = 0x282cb0cb, esp = > 0xbfbfc7cc, ebp = 0xbfbfe848 --- > KDB: enter: watchdog timeout > > You can type 'reboot' to reboot the machine (in my case, panic would > not work, so a useful dump wasn't in the cards) Different offset on mine, but of course I'm using a different kernel. kern_sendfile+0x6ad do_sendfile+0xb1 sendfile+0x13 Luckily, I was able to get a panic, so I have all the files necessary to debug. Here's the backtrace: (kgdb) backtrace #0 doadump () at pcpu.h:196 #1 0xc07f2c57 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07f2f62 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0497e47 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:446 #4 0xc04985bc in db_command (last_cmdp=0xc0ca9154, cmd_table=0x0, dopager=1) at /usr/src/sys/ddb/db_command.c:413 #5 0xc04986ca in db_command_loop () at /usr/src/sys/ddb/db_command.c:466 #6 0xc049a17d in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:228 #7 0xc081fdf6 in kdb_trap (type=3, code=0, tf=0xc72e2a5c) at /usr/src/sys/kern/subr_kdb.c:524 #8 0xc0b01b9b in trap (frame=0xc72e2a5c) at /usr/src/sys/i386/i386/trap.c:692 #9 0xc0ae58fb in calltrap () at /usr/src/sys/i386/i386/exception.s:166 #10 0xc081ff7a in kdb_enter_why (why=0xc0b677b2 "watchdog", msg=0xc0b7ef1d "watchdog timeout") at cpufunc.h:60 #11 0xc07b0cad in hardclock (usermode=0, pc=3229966301) at /usr/src/sys/kern/kern_clock.c:640 #12 0xc0aedf1c in lapic_handle_timer (frame=0xc72e2afc) at /usr/src/sys/i386/i386/local_apic.c:785 #13 0xc0ae5edf in Xtimerint () at apic_vector.s:108 #14 0xc0855fdd in kern_sendfile (td=0xc771db40, uap=0xc72e2cfc, hdr_uio=0x0, trl_uio=0x0, compat=0) at atomic.h:160 #15 0xc0856d31 in do_sendfile (td=0xc771db40, uap=0xc72e2cfc, compat=0) at /usr/src/sys/kern/uipc_syscalls.c:1775 #16 0xc0856dd3 in sendfile (td=0xc771db40, uap=0xc72e2cfc) at /usr/src/sys/kern/uipc_syscalls.c:1746 #17 0xc0b01365 in syscall (frame=0xc72e2d38) at /usr/src/sys/i386/i386/trap.c:1094 #18 0xc0ae5960 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) This is all a bit new to me (debugging, etc), so let me know if you need anything else! Jaime From jbozza at mindsites.com Mon Oct 26 14:09:09 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Mon Oct 26 14:09:18 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: <20091023212104.GH2160@deviant.kiev.zoral.com.ua> References: <20091023212104.GH2160@deviant.kiev.zoral.com.ua> Message-ID: From: Kostik Belousov [mailto:kostikbel@gmail.com] > Can you look up the source line for kern_sendfile+0x90d in your > kernel ? Do kgdb kernel.debug, then execute "list *(kern_sendfile+0x90d)". In my case, it was kern_sendfile+0x6ad (rebuilt with RELENG_7 this weekend). Here's the output: (kgdb) list *(kern_sendfile+0x6ad) 0xc0855fdd is in kern_sendfile (atomic.h:160). 155 static __inline int 156 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) 157 { 158 u_char res; 159 160 __asm __volatile( 161 " " MPLOCKED " " 162 " cmpxchgl %2,%1 ; " 163 " sete %0 ; " 164 "1: " Not much to go on there. I posted a backtrace in a previous email, but the relevant sections (I think) are: #14 0xc0855fdd in kern_sendfile (td=0xc771db40, uap=0xc72e2cfc, hdr_uio=0x0, trl_uio=0x0, compat=0) at atomic.h:160 #15 0xc0856d31 in do_sendfile (td=0xc771db40, uap=0xc72e2cfc, compat=0) at /usr/src/sys/kern/uipc_syscalls.c:1775 #16 0xc0856dd3 in sendfile (td=0xc771db40, uap=0xc72e2cfc) at /usr/src/sys/kern/uipc_syscalls.c:1746 #17 0xc0b01365 in syscall (frame=0xc72e2d38) at /usr/src/sys/i386/i386/trap.c:1094 #18 0xc0ae5960 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:262 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) I'm still going to test the specific boundary, but if there's more information I can give, let me know! Jaime From caelian at gmail.com Mon Oct 26 14:18:38 2009 From: caelian at gmail.com (Pascal Hofstee) Date: Mon Oct 26 14:18:49 2009 Subject: MCP55 SATA solution to test In-Reply-To: <4AE3A001.8000205@FreeBSD.org> References: <4AE3A001.8000205@FreeBSD.org> Message-ID: 2009/10/25 Alexander Motin : > Hi. > > Thanks to one man who provided access to his machine, I seem to found > how to fix device detection on nVidia MCP55 SATA controller on amd64 > 8.0. Looks like this controller need some time (very short) to enable > BAR(5) memory access after PCI configuration register written. Probably > some changes in PCI code exposed this issue. Also it explains why > setting hw.pci.mcfg to 0 helps. > > Attached patch solves problem for that machine. Testers are welcome. Confirmed this also fixes the SATA detection on my MSI K9N Neo on 9.0-CURRENT. Please commit :) From korvus at comcast.net Mon Oct 26 14:24:04 2009 From: korvus at comcast.net (Steve Polyack) Date: Mon Oct 26 14:24:14 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE5AC38.4050507@FreeBSD.org> References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> <4AE5AA43.7030405@comcast.net> <4AE5AC38.4050507@FreeBSD.org> Message-ID: <4AE5B102.6000704@comcast.net> Alexander Motin wrote: > Steve Polyack wrote: > >> I'm about to try today's head and patch. I'll let you know how it goes. >> > > Ok. Just to be sure it is not cabling issue (I have seen such), try also > limit port speed to 1.5Gbps by adding to loader.conf: > hint.siisch.0.sata_rev=1 > hint.siisch.1.sata_rev=1 > hint.siisch.2.sata_rev=1 > hint.siisch.3.sata_rev=1 > > Here's a dmesg from todays head and your patch from this morning. It's still only sensing one disk over the two PMs. Forcing SATA1/1.5Gbps operation didn't change anything. -------------- next part -------------- Copyright (c) 1992-2009 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 9.0-CURRENT #4: Mon Oct 26 10:01:55 EDT 2009 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff809e7000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff809e7260. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2133419836 Hz CPU: Intel(R) Xeon(R) CPU E5506 @ 2.13GHz (2133.42-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4299161600 (4100 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000093fff, 602112 bytes (147 pages) 0x0000000000a16000 - 0x00000000b60fffff, 3043926016 bytes (743146 pages) 0x00000000bf78e000 - 0x00000000bf78ffff, 8192 bytes (2 pages) 0x0000000100000000 - 0x000000013ffeffff, 1073676288 bytes (262128 pages) avail memory = 4095377408 (3905 MB) ACPI APIC Table: <061909 APIC1420> INTR: Adding local APIC 18 as a target INTR: Adding local APIC 20 as a target INTR: Adding local APIC 22 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 16 cpu1 (AP): APIC ID: 18 cpu2 (AP): APIC ID: 20 cpu3 (AP): APIC ID: 22 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xfa710 00024 (v2 ACPIAM) ACPI: XSDT 0xbf790100 0008C (v1 NEC 20090619 MSFT 00000097) ACPI: FACP 0xbf790290 000F4 (v4 061909 FACP1420 20090619 MSFT 00000097) ACPI: DSDT 0xbf790670 05B8F (v2 10006 10006000 00000000 INTL 20051117) ACPI: FACS 0xbf79e000 00040 ACPI: APIC 0xbf790390 000D2 (v2 061909 APIC1420 20090619 MSFT 00000097) ACPI: MCFG 0xbf790470 0003C (v1 061909 OEMMCFG 20090619 MSFT 00000097) ACPI: SLIC 0xbf7904b0 00176 (v1 NEC 20090619 MSFT 00000097) ACPI: ERST 0xbf790630 00040 (v1 061909 WHEA1420 20090619 MSFT 00000097) ACPI: OEMB 0xbf79e040 0007B (v1 061909 OEMB1420 20090619 MSFT 00000097) ACPI: HPET 0xbf79a670 00038 (v1 061909 OEMHPET 20090619 MSFT 00000097) ACPI: DMAR 0xbf79e0c0 00120 (v1 AMI OEMDMAR 00000001 MSFT 00000097) ACPI: SSDT 0xbf79efb0 00363 (v1 DpgPmm CpuPm 00000012 INTL 20051117) ACPI: EINJ 0xbf79a6b0 00130 (v1 AMIER AMI_EINJ 20090619 MSFT 00000097) ACPI: BERT 0xbf79a840 00030 (v1 AMIER AMI_BERT 20090619 MSFT 00000097) ACPI: ERST 0xbf79a870 001B0 (v1 AMIER AMI_ERST 20090619 MSFT 00000097) ACPI: HEST 0xbf79aa20 000A8 (v1 AMIER AMI_HEST 20090619 MSFT 00000097) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x10000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010400 nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 16 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 ACPI timer: 1/1 1/0 1/0 1/2 0/459 1/2 1/0 1/0 1/0 1/0 -> 9 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 6 7 10 11 12 14 15 Validation 0 255 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 3 4 6 7 10 11 12 14 15 Validation 0 7 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 6 7 10 11 12 14 15 Validation 0 6 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff iomem 0xfed40000-0xfed44fff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x3403, revid=0x13 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3408, revid=0x13 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340a, revid=0x13 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x340e, revid=0x13 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x3410, revid=0x13 domain=0, bus=0, slot=9, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 2 messages, vector masks found-> vendor=0x8086, dev=0x342e, revid=0x13 domain=0, bus=0, slot=20, func=0 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3422, revid=0x13 domain=0, bus=0, slot=20, func=1 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3423, revid=0x13 domain=0, bus=0, slot=20, func=2 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3438, revid=0x13 domain=0, bus=0, slot=20, func=3 class=08-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3430, revid=0x13 domain=0, bus=0, slot=22, func=0 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacfc000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3431, revid=0x13 domain=0, bus=0, slot=22, func=1 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3432, revid=0x13 domain=0, bus=0, slot=22, func=2 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3433, revid=0x13 domain=0, bus=0, slot=22, func=3 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacf0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3429, revid=0x13 domain=0, bus=0, slot=22, func=4 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xfacec000, size 14, enabled pcib0: matched entry for 0.22.INTA pcib0: slot 22 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x342a, revid=0x13 domain=0, bus=0, slot=22, func=5 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface8000, size 14, enabled pcib0: matched entry for 0.22.INTB pcib0: slot 22 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x342b, revid=0x13 domain=0, bus=0, slot=22, func=6 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface4000, size 14, enabled pcib0: matched entry for 0.22.INTC pcib0: slot 22 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x342c, revid=0x13 domain=0, bus=0, slot=22, func=7 class=08-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 powerspec 3 supports D0 D3 current D0 MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xface0000, size 14, enabled pcib0: matched entry for 0.22.INTD pcib0: slot 22 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a37, revid=0x00 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xbc00, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a38, revid=0x00 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 map[20]: type I/O Port, range 32, base 0xb880, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=0x8086, dev=0x3a39, revid=0x00 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=14 map[20]: type I/O Port, range 32, base 0xb800, size 5, enabled pcib0: matched entry for 0.26.INTD pcib0: slot 26 INTD hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a3c, revid=0x00 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacde000, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacde000 found-> vendor=0x8086, dev=0x3a3e, revid=0x00 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfacd8000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x3a40, revid=0x00 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0104, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a48, revid=0x00 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x3a4a, revid=0x00 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x3a34, revid=0x00 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xb480, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x3a35, revid=0x00 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 map[20]: type I/O Port, range 32, base 0xb400, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a36, revid=0x00 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x3a3a, revid=0x00 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfacdc000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfacdc000 found-> vendor=0x8086, dev=0x244e, revid=0x90 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x1a (6500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a16, revid=0x00 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x3a22, revid=0x00 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=14 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled map[14]: type I/O Port, range 32, base 0xac00, size 2, enabled map[18]: type I/O Port, range 32, base 0xa880, size 3, enabled map[1c]: type I/O Port, range 32, base 0xa800, size 2, enabled map[20]: type I/O Port, range 32, base 0xa480, size 5, enabled map[24]: type Memory, range 32, base 0xfacd2000, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x3a30, revid=0x00 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=15 map[10]: type Memory, range 64, base 0xfacd0000, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 4 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfad00000-0xfadfffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x12d8, dev=0xe111, revid=0x02 domain=0, bus=3, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: irq 16 at device 0.0 on pci3 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xc000-0xcfff pcib4: memory decode 0xfad00000-0xfadfffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x1095, dev=0x3124, revid=0x01 domain=0, bus=4, slot=4, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x01df, statreg=0x02b0, cachelnsz=64 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfadfe000, size 7, enabled pcib4: requested memory range 0xfadfe000-0xfadfe07f: good pcib3: requested memory range 0xfadfe000-0xfadfe07f: good map[18]: type Memory, range 64, base 0xfadf0000, size 15, enabled pcib4: requested memory range 0xfadf0000-0xfadf7fff: good pcib3: requested memory range 0xfadf0000-0xfadf7fff: good map[20]: type I/O Port, range 32, base 0xcc00, size 4, enabled pcib4: requested I/O range 0xcc00-0xcc0f: in range pcib3: requested I/O range 0xcc00-0xcc0f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 pcib4: slot 4 INTA is routed to irq 16 siis0: port 0xcc00-0xcc0f mem 0xfadfe000-0xfadfe07f,0xfadf0000-0xfadf7fff irq 16 at device 4.0 on pci4 siis0: Reserved 0x80 bytes for rid 0x10 type 3 at 0xfadfe000 siis0: Reserved 0x8000 bytes for rid 0x18 type 3 at 0xfadf0000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 16 vector 49 siis0: [MPSAFE] siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [MPSAFE] siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [MPSAFE] siisch1: [ITHREAD] siisch2: at channel 2 on siis0 siisch2: [MPSAFE] siisch2: [ITHREAD] siisch3: at channel 3 on siis0 siisch3: [MPSAFE] siisch3: [ITHREAD] pcib5: at device 9.0 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=0, physical bus=5 pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attached) pci0: at device 22.5 (no driver attached) pci0: at device 22.6 (no driver attached) pci0: at device 22.7 (no driver attached) uhci0: port 0xbc00-0xbc1f irq 16 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xb880-0xb89f irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb880 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 16 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xb800-0xb81f irq 19 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 16 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfacde000-0xfacde3ff irq 18 at device 26.7 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 16 vector 52 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib6: irq 17 at device 28.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0x0-0x0 pcib6: no prefetched decode pci6: on pcib6 pci6: domain=0, physical bus=6 pcib7: irq 17 at device 28.4 on pci0 pcib7: domain 0 pcib7: secondary bus 7 pcib7: subordinate bus 7 pcib7: I/O decode 0xd000-0xdfff pcib7: memory decode 0xfae00000-0xfaefffff pcib7: no prefetched decode pci7: on pcib7 pci7: domain=0, physical bus=7 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfaee0000, size 17, enabled pcib7: requested memory range 0xfaee0000-0xfaefffff: good map[18]: type I/O Port, range 32, base 0xdc00, size 5, enabled pcib7: requested I/O range 0xdc00-0xdc1f: in range map[1c]: type Memory, range 32, base 0xfaedc000, size 14, enabled pcib7: requested memory range 0xfaedc000-0xfaedffff: good pcib7: matched entry for 7.0.INTA pcib7: slot 0 INTA hardwired to IRQ 16 em0: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci7 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfaee0000 em0: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfaedc000 em0: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 256 to local APIC 16 vector 53 msi: routing MSI-X IRQ 257 to local APIC 16 vector 54 msi: routing MSI-X IRQ 258 to local APIC 16 vector 55 em0: using IRQs 256-258 for MSI-X em0: Using MSIX interrupts em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: [MPSAFE] em0: [ITHREAD] em0: bpf attached em0: Ethernet address: 00:30:48:db:7d:9e pcib8: irq 16 at device 28.5 on pci0 pcib8: domain 0 pcib8: secondary bus 8 pcib8: subordinate bus 8 pcib8: I/O decode 0xe000-0xefff pcib8: memory decode 0xfaf00000-0xfaffffff pcib8: no prefetched decode pci8: on pcib8 pci8: domain=0, physical bus=8 found-> vendor=0x8086, dev=0x10d3, revid=0x00 domain=0, bus=8, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=64 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 5 messages in map 0x1c map[10]: type Memory, range 32, base 0xfafe0000, size 17, enabled pcib8: requested memory range 0xfafe0000-0xfaffffff: good map[18]: type I/O Port, range 32, base 0xec00, size 5, enabled pcib8: requested I/O range 0xec00-0xec1f: in range map[1c]: type Memory, range 32, base 0xfafdc000, size 14, enabled pcib8: requested memory range 0xfafdc000-0xfafdffff: good pcib8: matched entry for 8.0.INTA pcib8: slot 0 INTA hardwired to IRQ 17 em1: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 17 at device 0.0 on pci8 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfafe0000 em1: Reserved 0x4000 bytes for rid 0x1c type 3 at 0xfafdc000 em1: attempting to allocate 3 MSI-X vectors (5 supported) msi: routing MSI-X IRQ 259 to local APIC 16 vector 56 msi: routing MSI-X IRQ 260 to local APIC 16 vector 57 msi: routing MSI-X IRQ 261 to local APIC 16 vector 58 em1: using IRQs 259-261 for MSI-X em1: Using MSIX interrupts em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: [MPSAFE] em1: [ITHREAD] em1: bpf attached em1: Ethernet address: 00:30:48:db:7d:9f uhci3: port 0xb480-0xb49f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb480 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 16 vector 59 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x3f00 usbus4: on uhci3 uhci4: port 0xb400-0xb41f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xb080-0xb09f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb080 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfacdc000-0xfacdc3ff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib9: at device 30.0 on pci0 pcib9: domain 0 pcib9: secondary bus 9 pcib9: subordinate bus 9 pcib9: I/O decode 0xf000-0xfff pcib9: memory decode 0xfb000000-0xfbefffff pcib9: prefetched decode 0xf9000000-0xf9ffffff pcib9: Subtractively decoded bridge. pci9: on pcib9 pci9: domain=0, physical bus=9 found-> vendor=0x102b, dev=0x0532, revid=0x0a domain=0, bus=9, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=64 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=15 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xf9000000, size 24, enabled pcib9: requested memory range 0xf9000000-0xf9ffffff: good map[14]: type Memory, range 32, base 0xfbefc000, size 14, enabled pcib9: requested memory range 0xfbefc000-0xfbefffff: good map[18]: type Memory, range 32, base 0xfb000000, size 23, enabled pcib9: requested memory range 0xfb000000-0xfb7fffff: good pcib9: matched entry for 9.1.INTA pcib9: slot 1 INTA hardwired to IRQ 18 vgapci0: mem 0xf9000000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff irq 18 at device 1.0 on pci9 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfacd2000-0xfacd27ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfacd2000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 262 to local APIC 16 vector 64 ahci0: using IRQ 262 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahci0: Caps2: ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) Calling int 0x15 (ax=0xc000 bx=0x0000 cx=0x0000 dx=0x0000 es=0x0000 di=0x0000) Exiting int 0x15 (ax=0x0000 bx=0xe712 cx=0x0000 dx=0x0000 es=0xf000 di=0x0000) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 16 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 16 vector 61 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 16 vector 62 uart1: [FILTER] uart1: fast interrupt cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - 6E, should be 6B (20091013/tbutils-354) ACPI: SSDT 0xbf79e1e0 008F0 (v1 DpgPmm P001Ist 00000011 INTL 20051117) ACPI: SSDT 0xbf79ead0 004D5 (v1 PmRef P001Cst 00003001 INTL 20051117) est0: on cpu0 est0: Invalid id16 (set, cur) = (15, 16) est0: Invalid freq 2000, ignored. est0: Invalid id16 (set, cur) = (14, 16) est0: Invalid freq 1867, ignored. est0: Invalid id16 (set, cur) = (13, 16) est0: Invalid freq 1733, ignored. est0: Invalid id16 (set, cur) = (12, 16) est0: Invalid freq 1600, ignored. p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est1: Invalid id16 (set, cur) = (15, 16) est1: Invalid freq 2000, ignored. est1: Invalid id16 (set, cur) = (14, 16) est1: Invalid freq 1867, ignored. est1: Invalid id16 (set, cur) = (13, 16) est1: Invalid freq 1733, ignored. est1: Invalid id16 (set, cur) = (12, 16) est1: Invalid freq 1600, ignored. p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est2: Invalid id16 (set, cur) = (15, 16) est2: Invalid freq 2000, ignored. est2: Invalid id16 (set, cur) = (14, 16) est2: Invalid freq 1867, ignored. est2: Invalid id16 (set, cur) = (13, 16) est2: Invalid freq 1733, ignored. est2: Invalid id16 (set, cur) = (12, 16) est2: Invalid freq 1600, ignored. p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est3: Invalid id16 (set, cur) = (15, 16) est3: Invalid freq 2000, ignored. est3: Invalid id16 (set, cur) = (14, 16) est3: Invalid freq 1867, ignored. est3: Invalid id16 (set, cur) = (13, 16) est3: Invalid freq 1733, ignored. est3: Invalid id16 (set, cur) = (12, 16) est3: Invalid freq 1600, ignored. p4tcc3: on cpu3 acpi0: wakeup code va 0xffffff8077774000 pa 0x4000 isa_probe_children: disabling PnP devices ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 257519 -> 100000 procfs registered lapic: Divisor 2, Frequency 66669369 hz Timecounter "TSC" frequency 2133419836 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attachedsiisch0: CONNECT requested siisch0: SIIS reset... siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=00000113 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch2: CONNECT requested siisch2: SIIS reset... siisch2: device reset time=0ms siisch2: SATA connect time=0ms status=00000113 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 Waiting 15 seconds for SCSI devices to settle siisch0: SIIS reset... siisch0: device reset time=1ms siisch0: SATA connect time=0ms status=00000113 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 siisch1: SIIS reset... siisch1: device reset time=1ms siisch1: SATA connect timeout status=00000000 siisch1: SIIS reset done: phy reset found no device siisch2: SIIS reset... siisch2: device reset time=1ms siisch2: SATA connect time=0ms status=00000113 siisch2: ready wait time=0ms siisch2: SIIS reset done: devices=00000001 siisch3: SIIS reset... siisch3: device reset time=1ms siisch3: SATA connect timeout status=00000000 siisch3: SIIS reset done: phy reset found no device ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect timeout status=00000000 ahcich0: AHCI reset done: phy reset found no device ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000123 ahcich1: ready wait time=4ms ahcich1: AHCI reset done: device found ahcich2: AHCI reset... ahcich2: hardware reset ... ahcich2: SATA connect timeout status=00000000 ahcich2: AHCI reset done: phy reset found no device ahcich3: AHCI reset... ahcich3: hardware reset ... ahcich3: SATA connect timeout status=00000000 ahcich3: AHCI reset done: phy reset found no device ahcich4: AHCI reset... ahcich4: hardware reset ... ahcich4: SATA connect timeout status=00000000 ahcich4: AHCI reset done: phy reset found no device ahcich5: AHCI reset... ahcich5: hardware reset ... ahcich5: SATA connect timeout status=00000000 ahcich5: AHCI reset done: phy reset found no device usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ipmi0: IPMI device rev. 1, firmware rev. 1.2, version 2.0 ipmi0: Number of channels 0 ipmi0: Attached watchdog ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 ukbd0: on usbus1 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 (aprobe0:siisch0:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe2:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 (aprobe5:ahcich1:0:0:0): SIGNATURE: 0000 pmp0 at siisch0 bus 0 scbus0 target 15 lun 0 pmp0: ATA/ATAPI-0 device pmp0: 150.000MB/s transfers PM ports: 5 PM RESET 0 PM RESET 1 PM RESET 2 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM RESET 3 PM RESET 4 siisch0: SNTF 0x0000 siisch0: SNTF 0x0000 PM reset done pmp1 at siisch2 bus 0 scbus2 target 15 lun 0 pmp1: ATA/ATAPI-0 device pmp1: 150.000MB/s transfers PM ports: 5 PM RESET 0 PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done GEOM: new disk ada0 ada0 at ahcich1 bus 0 scbus5 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: Serial Number 9VM1RYE5 ada0: 300.000MB/s transfers ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled pass0 at siisch0 bus 0 scbus0 target 15 lun 0 pass0: ATA/ATAPI-0 device pass0: 150.000MB/s transfers PM connect done PM status: 0 - 00000123 PM status: 1 - 00000123 PM status: 2 - 00000123 PM status: 3 - 00000123 PM status: 4 - 00000123 pass1 at siisch2 bus 0 scbus2 target 15 lun 0 pass1: ATA/ATAPI-0 device pass1: 150.000MB/s transfers pass2 at ahcich1 bus 0 scbus5 target 0 lun 0PM connect done pass2: PM status: 0 - 00000123 ATA/ATAPI-8 SATA 2.x device pass2: Serial Number 9VM1RYE5 pass2: 300.000MB/s transfers ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x12000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x16000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x14000000 VER: 0x00060015 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 18 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 20 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 22 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 18 vector 49 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 20 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 22 vector 49 msi: Assigning MSI-X IRQ 256 to local APIC 18 vector 50 msi: Assigning MSI-X IRQ 257 to local APIC 20 vector 50 msi: Assigning MSI-X IRQ 258 to local APIC 22 vector 50 msi: Assigning MSI-X IRQ 260 to local APIC 18 vector 51 msi: Assigning MSI-X IRQ 261 to local APIC 20 vector 51 msi: Assigning MSI IRQ 262 to local APIC 22 vector 51 GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Trying to mount root from ufs:/dev/label/OS/rootfs ct_to_ts([2009-10-26 10:16:33]) = 1256552193.000000000 start_init: trying /sbin/init PM status: 1 - 00000000 PM status: 2 - 00000000 PM status: 3 - 00000000 PM status: 4 - 00000000 (aprobe1:siisch2:0:0:0): SIGNATURE: 0000 pass3 at siisch2 bus 0 scbus2 target 0 lun 0 pass3: ATA/ATAPI-8 SATA 2.x device pass3: Serial Number 9VS2FGFN pass3: 150.000MB/s transfers ada1 at siisch2 bus 0 scbus2 target 0 lun 0GEOM: new disk ada1 ada1: ATA/ATAPI-8 SATA 2.x device ada1: Serial Number 9VS2FGFN ada1: 150.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled em0: Link is up 1000 Mbps Full Duplex em0: link state changed to UP siisch0: Timeout on slot 26 siisch0: siis_timeout is 00000000 ss 04000000 rs 04000000 es 00000000 sts 801a2000 serr 00000000 siisch0: ready wait time=0ms siisch0: ready wait time=0ms siisch0: SIIS reset... siisch0: device reset time=1ms siisch0: SATA connect time=0ms status=00000113 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 PMP freeze: 1 PMP freeze: 2 PMP freeze: 3 PMP freeze: 4 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted PMP freeze: 0 PM ports: -1771503359 PM RESET 0 PM reset done PM connect done PMP release: 0 PMP release: 1 PMP release: 2 PMP release: 3 PMP release: 4 t_delta 15.fc765cbdba5b39c0 too short From korvus at comcast.net Mon Oct 26 14:48:26 2009 From: korvus at comcast.net (Steve Polyack) Date: Mon Oct 26 14:48:33 2009 Subject: FreeBSD and SATA Port Multipliers In-Reply-To: <4AE5B102.6000704@comcast.net> References: <4AE04F73.1050703@comcast.net> <4AE073CF.40500@comcast.net> <4AE099D8.5060103@FreeBSD.org> <4AE5AA43.7030405@comcast.net> <4AE5AC38.4050507@FreeBSD.org> <4AE5B102.6000704@comcast.net> Message-ID: <4AE5B6B8.2010509@comcast.net> Steve Polyack wrote: > Alexander Motin wrote: >> Steve Polyack wrote: >> >>> I'm about to try today's head and patch. I'll let you know how it >>> goes. >>> >> >> Ok. Just to be sure it is not cabling issue (I have seen such), try also >> limit port speed to 1.5Gbps by adding to loader.conf: >> hint.siisch.0.sata_rev=1 >> hint.siisch.1.sata_rev=1 >> hint.siisch.2.sata_rev=1 >> hint.siisch.3.sata_rev=1 >> >> > Here's a dmesg from todays head and your patch from this morning. > It's still only sensing one disk over the two PMs. Forcing > SATA1/1.5Gbps operation didn't change anything. > I should also note that if I do a 'camcontrol rescan', the first PM (with 5 physical drives attached, none detected) will vanish. Physically unplugging and reconnecting the device does the same. COMMAND=/sbin/camcontrol rescan all siisch0: Timeout on slot 29 siisch0: siis_timeout is 00000000 ss 20000000 rs 20000000 es 00000000 sts 801f2000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms siisch0: SIIS reset... siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (aprobe0:siisch0:0:15:0): Command timed out (aprobe0:siisch0:0:15:0): error 5 (aprobe0:siisch0:0:15:0): Retries Exhausted (pass0:siisch0:0:15:0): lost device (pass0:siisch0:0:15:0): removing device entry (pmp0:siisch0:0:15:0): lost device siisch0: Timeout on slot 30 siisch0: siis_timeout is 00000000 ss 40000000 rs 40000000 es 00000000 sts 801f0000 serr 00000000 siisch0: ready wait time=1ms siisch0: ready wait time=1ms (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command siisch0: SIIS reset... siisch0: ready wait time=1ms siisch0: device reset time=0ms siisch0: SATA connect time=0ms status=00000123 siisch0: ready wait time=0ms siisch0: SIIS reset done: devices=00000001 (aprobe0:siisch0:0:0:0): Command timed out (aprobe0:siisch0:0:0:0): error 5 (aprobe0:siisch0:0:0:0): Retries Exhausted (pmp0:siisch0:0:15:0): Request Requeued (pmp0:siisch0:0:15:0): Retrying Command (aprobe0:siisch2:0:15:0): SIGNATURE: 9669 PM Product ID: 37261095 PM Revision: 00001706 PMP freeze: 0 PM ports: 5 PM RESET 0 skipping PM RESET 1 PM RESET 2 PM RESET 3 PM RESET 4 PM reset done PM connect done PM status: 0 - 00000123 PM status: 1 - 00000000 PM status: 2 - 00000000 PM status: 3 - 00000000 PM status: 4 - 00000000 PMP release: 0 From Johan at double-l.nl Mon Oct 26 14:49:40 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Mon Oct 26 14:49:47 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> >> Hello all >> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 >> server. >> It fails to detect the Broadcom network interface. >> >> >> >> Pciconf -lv gives me the following. >> >> none3@pci0:4:0:0: class=0x020000 card=0x705d10c chip=0x165b14e4 >> rev=0x10 >> hdr=0x00 >> >> vendor = 'Broadcom Corporation' >> class = network >> >> Subclass = Ethernet >> >> >> >> Is there something I can do, other than install an other network card? >I think you can just patch the bge(4) driver to add support for your >adapter. >It looks like a BCM5723 from the PCI ID. Support for it was just added in >9.0 as part of change 197832, but I suspect it might not need all the other >patches from that change. Try this diff: >Index: if_bgereg.h >=================================================================== >--- if_bgereg.h (revision 197831) >+++ if_bgereg.h (revision 197832) >@@ -2101,6 +2123,7 @@ > #define BCOM_DEVICEID_BCM5720 0x1658 > #define BCOM_DEVICEID_BCM5721 0x1659 > #define BCOM_DEVICEID_BCM5722 0x165A >+#define BCOM_DEVICEID_BCM5723 0x165B > #define BCOM_DEVICEID_BCM5750 0x1676 > #define BCOM_DEVICEID_BCM5750M 0x167C > #define BCOM_DEVICEID_BCM5751 0x1677 >Index: if_bge.c >=================================================================== >--- if_bge.c (revision 197831) >+++ if_bge.c (revision 197832) >@@ -170,6 +170,7 @@ > { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, >+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, Like I said in my first answer, the device is detected with these lines. Only if I enable the device it can not boot. If I boot with the inserted em0 interface and the change in the rc.conf file the em0 into bge0 and do a /etc/netstart, the systems hangs, only a power cycle can reclaim the server. I have installed FreeBSD 9.0Current on the machine and here it works fine I saw a commit from Bjoern A. Zeeb which describe the hang, but do not know if this can be reverted back to 8.x before the release. svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb regards, and thank you for your time. cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) Johan Hendriks No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 From rnoland at FreeBSD.org Mon Oct 26 15:39:04 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Oct 26 15:39:10 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: Message-ID: <1256571535.2502.221.camel@balrog.2hip.net> On Mon, 2009-10-26 at 11:19 +0000, Pete French wrote: > just about to build a new ZFS based system and I was wondering > what the recommended way to dedicate a whole disc to ZFS is > these days. Should I just give it 'da1', 'da2' etc as I have > done in the past, or is it better to use GPT to create a > partition over the whole disc, which is marked as > being for freebsd-zfs ? > > Not that I have had any problems with simply using bare > drives, but the phrase 'dangerously dedicated' does keep > nagging at me, hence considering the GPT route :-) Others may have different opinions, but if your drives are dedicated to zfs and you don't intend to try and boot from them, I see no reason not to continue giving the whole disk to zfs. robert. > cheers, > > -pete. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From stas at deglitch.com Mon Oct 26 15:41:08 2009 From: stas at deglitch.com (Stanislav Sedov) Date: Mon Oct 26 15:41:20 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> <57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> Message-ID: <20091026184101.11830c6b.stas@deglitch.com> On Mon, 26 Oct 2009 15:49:37 +0100 "Johan Hendriks" mentioned: > I saw a commit from Bjoern A. Zeeb which describe the hang, but do not > know if this can be reverted back to 8.x before the release. > > svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb > > regards, and thank you for your time. > cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) > I believe bz's patch should fix it for you. You can either apply it by hand, or disable ASF mode by putting the following into /boot/loader.conf: hw.bge.allow_asf=0 The latter will be off by default in 8.0, but this change was not done by the point when RC1 was branched. It should be disabled by default in RC2 though, when it will be ready. -- Stanislav Sedov ST4096-RIPE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091026/1bd3a6de/attachment.pgp From jhb at freebsd.org Mon Oct 26 15:45:21 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Oct 26 15:45:50 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local> <200910230812.31166.jhb@freebsd.org> <57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> Message-ID: <200910261008.42292.jhb@freebsd.org> On Friday 23 October 2009 11:17:33 am Johan Hendriks wrote: > > On Thursday 22 October 2009 11:07:23 am Johan Hendriks wrote: > >> Hello all > >> I just installed FreeBSD 8.0RC1 AMD64 on my new HP Proliant ML150 G6 > >> server. > >> It fails to detect the Broadcom network interface. > >> > >> > >> > >> Pciconf -lv gives me the following. > >> > >> none3@pci0:4:0:0: class=0x020000 card=0x705d10c > chip=0x165b14e4 > >> rev=0x10 > >> hdr=0x00 > >> > >> vendor = 'Broadcom Corporation' > >> class = network > >> > >> Subclass = Ethernet > >> > >> > >> > >> Is there something I can do, other than install an other network > card? > > >I think you can just patch the bge(4) driver to add support for your > >adapter. > >It looks like a BCM5723 from the PCI ID. Support for it was just added > in > >9.0 as part of change 197832, but I suspect it might not need all the > other > >patches from that change. Try this diff: > > >Index: if_bgereg.h > >=================================================================== > >--- if_bgereg.h (revision 197831) > >+++ if_bgereg.h (revision 197832) > >@@ -2101,6 +2123,7 @@ > > #define BCOM_DEVICEID_BCM5720 0x1658 > > #define BCOM_DEVICEID_BCM5721 0x1659 > > #define BCOM_DEVICEID_BCM5722 0x165A > >+#define BCOM_DEVICEID_BCM5723 0x165B > > #define BCOM_DEVICEID_BCM5750 0x1676 > > #define BCOM_DEVICEID_BCM5750M 0x167C > > #define BCOM_DEVICEID_BCM5751 0x1677 > >Index: if_bge.c > >=================================================================== > >--- if_bge.c (revision 197831) > >+++ if_bge.c (revision 197832) > >@@ -170,6 +170,7 @@ > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5720 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5721 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5722 }, > >+ { BCOM_VENDORID, BCOM_DEVICEID_BCM5723 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750 }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5750M }, > > { BCOM_VENDORID, BCOM_DEVICEID_BCM5751 }, > > > Ok done that, and the card is found, only the server is not very stable > right now. > It does not continue the boot. > It stops at setting the hostname > > Setting hostname: server01.mydomain.local > > And it stays there. Can you tell what it is doing (with Ctrl-T, or perhaps including ddb and breaking into ddb and using 'ps')? -- John Baldwin From jbozza at mindsites.com Mon Oct 26 15:52:41 2009 From: jbozza at mindsites.com (Jaime Bozza) Date: Mon Oct 26 15:53:01 2009 Subject: Possible scheduler (SCHED_ULE) bug? In-Reply-To: <4AE59FBE.6060904@tzim.net> References: <4AE2232E.10406@whotookspaz.org> <4AE59FBE.6060904@tzim.net> Message-ID: From: Arnaud Houdelette [mailto:arnaud.houdelette@tzim.net] > I haven't tried larger files - Maybe the boundary is different on amd64? Doing some quick tests > right now, I was able to upload a 100MB file without a problem, but this is an AMD64 system with SMP, > plus the filesystem is all ZFS, so there are too many things different. I'll have to setup a system > that closely mirrors the rest of my tests (UFS, ULE, no SMP, etc) before I can say I'm not having a > problem there. > > > > Jaime > > > I had the same issue using 7.1 amd64, with ZFS, no SMP. > Not really sure what is the size boundary. I can't really test either, > as the machine is remote. > But I confirm that each tentative upload of certain relatively 'big' > files (around 1MB) with wordpress hanged the system before I switched > from sendfile to writev. > > I might do some test on amd64 7.2 with no SMP if it can be of any use ? > > Arnaud I was able to duplicate the problem on 7.2-STABLE amd64 no SMP - Problem didn't seem to happen with SMP on. While I wasn't able to get a crash dump, the crash looked similar. Jaime From Johan at double-l.nl Mon Oct 26 16:02:35 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Mon Oct 26 16:02:42 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local><200910230812.31166.jhb@freebsd.org><57200BF94E69E54880C9BB1AF714BBCBA570E2@w2003s01.double-l.local> <20091026184101.11830c6b.stas@deglitch.com> Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570E6@w2003s01.double-l.local> >> I saw a commit from Bjoern A. Zeeb which describe the hang, but do not >> know if this can be reverted back to 8.x before the release. >> >> svn commit: r198049 - head/sys/dev/bge Bjoern A. Zeeb >> >> regards, and thank you for your time. >> cc'ed stas@ and bz@ ( hope they do not mind, if so I am sorry) >> >I believe bz's patch should fix it for you. You can either apply it >by hand, or disable ASF mode by putting the following into >/boot/loader.conf: >hw.bge.allow_asf=0 >The latter will be off by default in 8.0, but this change was not done by >the point when RC1 was branched. It should be disabled by default in RC2 >though, when it will be ready. On my system sysctl -a | grep hw.bge.allow_asf gives me the value 0 hw.bge.allow_asf: 0 So it is off, I did try the patch from bz but it still hangs. Maybe I did not apply it the right way, because I did it by hand. can you provide me a patch file? Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 From Johan at double-l.nl Mon Oct 26 16:16:18 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Mon Oct 26 16:16:26 2009 Subject: Broadcom on HP Proliant ML150G6 not detected by 8.0RC1 AMD64 References: <57200BF94E69E54880C9BB1AF714BBCBA570C7@w2003s01.double-l.local><200910230812.31166.jhb@freebsd.org><57200BF94E69E54880C9BB1AF714BBCBA570DA@w2003s01.double-l.local> <200910261008.42292.jhb@freebsd.org> Message-ID: <57200BF94E69E54880C9BB1AF714BBCBA570E7@w2003s01.double-l.local> >> >> Ok done that, and the card is found, only the server is not very stable >> right now. >> It does not continue the boot. >> It stops at setting the hostname >> >> Setting hostname: server01.mydomain.local >> >> And it stays there. >Can you tell what it is doing (with Ctrl-T, or perhaps including ddb and >breaking into ddb and using 'ps')? I can not do anything. If I boot with a em0 interface, he finds the bge0 interface, but when I activate the driver by changing ifconfig_em0 to ifconfig_bge0 in /etc/rc.conf, and do a /etc/netstart I get the following. devd already running? (pid=703) Setting hostuuid: b032ac21-056a-de11-9e59-19c320fc2231 Setting hosted: 0xe51c1df3 This is it, can not switch consoles, can not use keyboard at all, CAPS is not working anymore. and the health led in front of the server turns from green to flashing red. Regards, Johan No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.32/2459 - Release Date: 10/25/09 19:57:00 From brian at brianwhalen.net Mon Oct 26 16:56:35 2009 From: brian at brianwhalen.net (Brian Whalen) Date: Mon Oct 26 16:56:41 2009 Subject: 8.0-RC2 Message-ID: <4AE5D0F8.5030806@brianwhalen.net> I just got this via csup, guess we are getting close, excellent. Brian From ronald-freebsd8 at klop.yi.org Mon Oct 26 20:15:07 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Mon Oct 26 20:15:20 2009 Subject: NULL-pointer reference in ulpt In-Reply-To: References: Message-ID: On Mon, 26 Oct 2009 14:51:23 +0100, Alban Hertroys wrote: > I didn't get any replies to my previous report, so I'm trying again. I > frequently get a kernel-panic after printing something to my USB printer > (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a > NULL-pointer for xfer from ulpt_tick(). > > System is a 7.2-STABLE, last updated on Sep 15. I just did a make > update, but there were no changes to ulpt.c. > > The core-summary is available from > http://solfertje.student.utwente.nl/~dalroi/core.txt > > Alban Hertroys Can you try this in 8.0? The USB stack is very different there (and much better in a lot of ways). Ronald. From lehmann at ans-netz.de Mon Oct 26 21:04:25 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Mon Oct 26 21:04:33 2009 Subject: 8.0: glabel on a gjournaled FS is broken In-Reply-To: <20091023173611.1d44c7a4.oliver@FreeBSD.org> References: <20091023173611.1d44c7a4.oliver@FreeBSD.org> Message-ID: <20091026220419.0b41ef6e.lehmann@ans-netz.de> Oliver Lehmann wrote: [glabel with gjournaled device not working] So should I create a PR for that since none responded to that topic? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From areilly at bigpond.net.au Mon Oct 26 21:04:48 2009 From: areilly at bigpond.net.au (Andrew Reilly) Date: Mon Oct 26 21:05:01 2009 Subject: Some questions about da0 on USB2 (recent bad behaviour) In-Reply-To: References: Message-ID: <20091026210445.GA66088@duncan.reilly.home> On Sat, Oct 24, 2009 at 07:07:00PM +0000, b. f. wrote: > >That is: it seems to work fine for some fraction of a minute > >(doesn't seem to be longer than a minute, anyway), and then > >stops completely for several minutes (processes reading or > >writing sit in "D" state in ps) and then starts again, after > >logging "Request completed with CAM_REQ_CMP_ERR\nRetrying > >Command". > > In the past week or so, Alexander Motin (mav@FreeBSD.org) and Andrew > Thompson (thompsa@FreeBSD.org) have made a number of related changes > to cam and usb in the P4 repository, and in 9-CURRENT. Some of these > may address your problem. I'm not sure when they will be back-ported > to 8.X. You may wish to try out the latest version of -CURRENT, to > see if it solves your problem(s); or to contact them. I've done this, and it seems to have worked. It seems possible that the bulk throughput (measured by systat while doing a cat /backup/bigfile >/dev/null) might even have increased a bit, but maybe not. The big improvement is that the transfer isn't pausing any more. No more CAM_REQ_CMP_ERR messages. Thanks b. f. for the suggestion, and thanks Alexander and Andrew for the fixes! I haven't run -current for, probably, ten years, and the occasional messages about lock-order-reversals worry me a bit, but don't seem to be doing any harm. Should I report them? In a PR? Please count this message as a vote for MFC'ing those cam and usb changes to 8-STABLE. Cheers, -- Andrew From bf1783 at googlemail.com Mon Oct 26 21:28:07 2009 From: bf1783 at googlemail.com (b. f.) Date: Mon Oct 26 21:28:15 2009 Subject: Some questions about da0 on USB2 (recent bad behaviour) In-Reply-To: <20091026210445.GA66088@duncan.reilly.home> References: <20091026210445.GA66088@duncan.reilly.home> Message-ID: On 10/26/09, Andrew Reilly wrote: > On Sat, Oct 24, 2009 at 07:07:00PM +0000, b. f. wrote: ... > > I haven't run -current for, probably, ten years, and the > occasional messages about lock-order-reversals worry me a bit, > but don't seem to be doing any harm. Should I report them? In > a PR? > Some of them are known, and are either harmless or a false positive. If you get an LOR, you can check to see if a similar LOR has already been noted on Bjoern Zeeb's page: http://sources.zabbadoz.net/freebsd/lor.html If it hasn't, send him an email with the LOR, and the circumstances under which it arose, as described on that page. Don't forget that there is a lot of debugging code enabled by default under -CURRENT (which at this point is still pretty close to 8-STABLE, and will be until after the release of 8.0, so it ought to be fairly stable). If you feel confident about the safety of using -CURRENT, and want to get the best performance, disable the debugging code as described in /usr/src/UPDATING. > Please count this message as a vote for MFC'ing those cam and > usb changes to 8-STABLE. > I'm guessing that these changes will make it into 8.0, or at least 8-STABLE, fairly soon; but mav@, thompsa@, and re@ will know more. b. From matthew.fleming at isilon.com Mon Oct 26 21:56:12 2009 From: matthew.fleming at isilon.com (Matthew Fleming) Date: Mon Oct 26 21:56:19 2009 Subject: uart(4) on stable/7 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> I am interested in using uart(4) instead of sio(4) on stable/7, to ease our eventual transition to stable/8 or CURRENT. I added device uart and changed up /boot/device.hints (there were no entries in /etc/ttys that mentioned sio), and I get something that boots and has messages on the console, up to the login prompt. There's no login prompt, though. I can ssh to my box, echo to /dev/console appears on the console; messages on reboot appear on the console, just not the login prompt. Does anyone know what else I may be missing to use uart(4)? Also, we have some boot scripts locally that will try to set machdep.conspeed based on hardware type; uart(4) doesn't seem to expose a sysctl by that name. How does the uart driver for stable/7 deal with differing console speeds? The hints in /boot/device.hints, obtained by s/sio/uart: hint.uart.0.at="isa" hint.uart.0.port="0x3F8" hint.uart.0.flags="0x90" hint.uart.0.irq="4" hint.uart.1.at="isa" hint.uart.1.port="0x2F8" hint.uart.1.irq="3" hint.uart.2.at="isa" hint.uart.2.disabled="1" hint.uart.2.port="0x3E8" hint.uart.2.irq="5" hint.uart.3.at="isa" hint.uart.3.disabled="1" hint.uart.3.port="0x2E8" hint.uart.3.irq="9" Thanks, matthew From thompsa at FreeBSD.org Mon Oct 26 22:01:41 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Oct 26 22:02:15 2009 Subject: uart(4) on stable/7 In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> References: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> Message-ID: <20091026220135.GA16914@citylink.fud.org.nz> On Mon, Oct 26, 2009 at 02:57:42PM -0700, Matthew Fleming wrote: > I am interested in using uart(4) instead of sio(4) on stable/7, to ease > our eventual transition to stable/8 or CURRENT. I added device uart and > changed up /boot/device.hints (there were no entries in /etc/ttys that > mentioned sio) ... It doesnt mention sio but you do need to change ttyd* to ttyu*, which are the sio and uart tty devices respectively. Andrew From matheus at eternamente.info Tue Oct 27 00:33:26 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Tue Oct 27 00:33:32 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <1256571535.2502.221.camel@balrog.2hip.net> References: <1256571535.2502.221.camel@balrog.2hip.net> Message-ID: <712807c9d3c501520c438cd84a0981eb.squirrel@lamneth> On Mon, October 26, 2009 13:38, Robert Noland wrote: > On Mon, 2009-10-26 at 11:19 +0000, Pete French wrote: >> just about to build a new ZFS based system and I was wondering >> what the recommended way to dedicate a whole disc to ZFS is >> these days. Should I just give it 'da1', 'da2' etc as I have >> done in the past, or is it better to use GPT to create a >> partition over the whole disc, which is marked as >> being for freebsd-zfs ? >> >> Not that I have had any problems with simply using bare >> drives, but the phrase 'dangerously dedicated' does keep >> nagging at me, hence considering the GPT route :-) > > Others may have different opinions, but if your drives are dedicated to > zfs and you don't intend to try and boot from them, I see no reason not > to continue giving the whole disk to zfs. hear somewhere (current@ or stable@) that this may give hard time in case of disk replacement. I may not find exact the same size and trouble may com from this. never tried though. please correct me if I'm wrong. matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From xcllnt at mac.com Tue Oct 27 01:56:21 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Oct 27 01:56:27 2009 Subject: uart(4) on stable/7 In-Reply-To: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> References: <06D5F9F6F655AD4C92E28B662F7F853E032DF8FA@seaxch09.desktop.isilon.com> Message-ID: On Oct 26, 2009, at 2:57 PM, Matthew Fleming wrote: > I can ssh to my box, echo to /dev/console appears on the console; > messages on reboot appear on the console, just not the login prompt. > Does anyone know what else I may be missing to use uart(4)? As Andrew pointed put, you need to update /etc/ttys as well. > Also, we have some boot scripts locally that will try to set > machdep.conspeed based on hardware type; uart(4) doesn't seem to > expose > a sysctl by that name. How does the uart driver for stable/7 deal > with > differing console speeds? uart(4) has 2 approaches for this: 1) you don't specify a speed -- in this case uart(4) will simply re-use the speed that hardware is programmed for. 2) You do specify a speed - uart(4) will reprogram the the console speed based on the hw.uart.console tunable. Note that for compatibility with sio(4) hints can be used as well. Use hint.uart.0.baud=9600 to set the console speed to 9600 baud. There's no compiled-in console speed. The compiled-in default (in a way) is to use the speed the hardware is programmed for. -- Marcel Moolenaar xcllnt@mac.com From doconnor at gsoft.com.au Tue Oct 27 06:17:05 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Oct 27 06:17:13 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: Message-ID: <200910271646.55227.doconnor@gsoft.com.au> On Mon, 26 Oct 2009, Pete French wrote: > just about to build a new ZFS based system and I was wondering > what the recommended way to dedicate a whole disc to ZFS is > these days. Should I just give it 'da1', 'da2' etc as I have > done in the past, or is it better to use GPT to create a > partition over the whole disc, which is marked as > being for freebsd-zfs ? > > Not that I have had any problems with simply using bare > drives, but the phrase 'dangerously dedicated' does keep > nagging at me, hence considering the GPT route :-) I put GPT's on mine and reserved a few Gb on each so I could swap/dump on them (4Gb on each - overkill but kept them all the same size). Unfortunately it appears ZFS doesn't search for GPT partitions so if you have them and swap the drives around you need to fix it up manually. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091027/4b660375/attachment.pgp From fbsdlist at src.cx Tue Oct 27 06:59:09 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Tue Oct 27 06:59:16 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200910271646.55227.doconnor@gsoft.com.au> References: <200910271646.55227.doconnor@gsoft.com.au> Message-ID: > Unfortunately it appears ZFS doesn't search for GPT partitions so if you > have them and swap the drives around you need to fix it up manually. When I used raw disk or GPT partitions, if disk order was changed the pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all that had to be done is export/import the pool. After the pool has been re-imported it was back to ONLINE. Now I'm using GPT labels (gpart -l) specifically because that avoids issues with disk order or driver change. The pool I've built from GPT labels has survived several migrations between different controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX (ahci) and multiple drive permutations without any manual intervention at all. All that was done on 8-RC1/amd64. I have also successfully imported the pool on OpenSolaris and back again on FreeBSD. --Artem From artis.caune at gmail.com Tue Oct 27 07:00:28 2009 From: artis.caune at gmail.com (Artis Caune) Date: Tue Oct 27 07:00:36 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200910271646.55227.doconnor@gsoft.com.au> References: <200910271646.55227.doconnor@gsoft.com.au> Message-ID: <9e20d71e0910270000oc9bbe80n6e13d28325742a45@mail.gmail.com> 2009/10/27 Daniel O'Connor : > Unfortunately it appears ZFS doesn't search for GPT partitions so if you > have them and swap the drives around you need to fix it up manually. Every GPT partition have unique /dev/gptid/, you can find it out with: glabel status and instead of using e.x.: zpool create tank mirror ad4p3 ad6p3 you can use: zpool create tank mirror gptid/0f32d2e6-c227-11de-8d6c-001708386b68 gptid/bc78a46e-c227-11de-8d6c-001708386b68 and you can swap disk without worries -- Artis Caune Everything should be made as simple as possible, but not simpler. From notification at bankofamerica.com Tue Oct 27 07:15:24 2009 From: notification at bankofamerica.com (Bank of America) Date: Tue Oct 27 07:15:31 2009 Subject: Security Notification Message-ID: <20091026235131.40575B4B43A1DF67@bankofamerica.com> Dear Bank of America Customer, freebsd-stable@freebsd.org As part of our security measures, we regularly screen activity in the Bank of America system. We recently contacted you after noticing an issue on your account. We requested information from you for the following reason: We recently received a report of unauthorized credit card use associated with this account. As a precaution, we have limited access to your Bank of America account in order to protect against future unauthorized transactions. Case ID Number: BOA-531-472-560 This is a reminder to restore your account as soon as possible. Please download the form attached to this email and open it in a web browser. Once opened, you will be provided with steps to restore your account access. We appreciate your understanding as we work to ensure account safety. In accordance with Bank of America's Customer Agreement, your account access will remain limited until the issue has been resolved. Unfortunately, if access to your account remains limited for an extended period of time, it may result in further limitations or eventual account closure. We encourage you to restore your Bank of America account as soon as possible to help avoid this. We thank you for your prompt attention to this matter. Please understand that this is a security measure intended to help protect you and your account. We apologize for any inconvenience. Sincerely, Bank of America Security Center -------------- next part -------------- A non-text attachment was scrubbed... Name: Restore_your_Online_Banking_account.html Type: application/octet-stream Size: 3786 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091027/ab5c9304/Restore_your_Online_Banking_account.obj From hausen at punkt.de Tue Oct 27 08:03:23 2009 From: hausen at punkt.de (Patrick M. Hausen) Date: Tue Oct 27 08:03:31 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <9e20d71e0910270000oc9bbe80n6e13d28325742a45@mail.gmail.com> References: <200910271646.55227.doconnor@gsoft.com.au> <9e20d71e0910270000oc9bbe80n6e13d28325742a45@mail.gmail.com> Message-ID: <20091027080317.GA50389@hugo10.ka.punkt.de> Hello, On Tue, Oct 27, 2009 at 09:00:27AM +0200, Artis Caune wrote: > 2009/10/27 Daniel O'Connor : > > Unfortunately it appears ZFS doesn't search for GPT partitions so if you > > have them and swap the drives around you need to fix it up manually. > > Every GPT partition have unique /dev/gptid/, you can find it out with: > glabel status > > and instead of using e.x.: > zpool create tank mirror ad4p3 ad6p3 > you can use: > zpool create tank mirror > gptid/0f32d2e6-c227-11de-8d6c-001708386b68 > gptid/bc78a46e-c227-11de-8d6c-001708386b68 > > and you can swap disk without worries Nice. Is there any reason to prefer GPT labels over glabel on the raw disk like so? NAME STATE READ WRITE CKSUM zfs ONLINE 0 0 0 raidz2 ONLINE 0 0 0 label/disk100 ONLINE 0 0 0 label/disk101 ONLINE 0 0 0 label/disk102 ONLINE 0 0 0 label/disk103 ONLINE 0 0 0 label/disk104 ONLINE 0 0 0 label/disk105 ONLINE 0 0 0 Could GPT labelled disks be read on a Solaris host without further modification? Thanks, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From doconnor at gsoft.com.au Tue Oct 27 08:32:26 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Oct 27 08:32:34 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: References: <200910271646.55227.doconnor@gsoft.com.au> Message-ID: <200910271902.19618.doconnor@gsoft.com.au> On Tue, 27 Oct 2009, Artem Belevich wrote: > > Unfortunately it appears ZFS doesn't search for GPT partitions so > > if you have them and swap the drives around you need to fix it up > > manually. > > When I used raw disk or GPT partitions, if disk order was changed the > pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all > that had to be done is export/import the pool. After the pool has > been re-imported it was back to ONLINE. Hmm OK, I thought it supposedly DTRT for raw disks but apparently not. > Now I'm using GPT labels (gpart -l) specifically because that avoids > issues with disk order or driver change. The pool I've built from GPT > labels has survived several migrations between different > controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX > (ahci) and multiple drive permutations without any manual > intervention at all. All that was done on 8-RC1/amd64. > I have also successfully imported the pool on OpenSolaris and back > again on FreeBSD. Damn, if I'd realised I'd have done that :) Do you know if it's possible to change? Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091027/4507dfe3/attachment.pgp From alexs at ulgsm.ru Tue Oct 27 08:42:53 2009 From: alexs at ulgsm.ru (alexs@ulgsm.ru) Date: Tue Oct 27 08:43:01 2009 Subject: openldap unstable on freebsd Message-ID: <20091027082516.GA88892@mail.ulgsm.ru> Good day. Last 2 years (maybe when began using bdb backend), we get slapd crash on read load. System on low load work with monit monitoring and fails 1-3 in month. When load up crashes frequency up too. Tuning helped but not much. load about 20-30 queryes/sec in peak. and crashes every hour. Problem watched on Freebsd7,7.1,7.2 i386, amd64 and openldap2.3,2.4 (bdb,hdb backends) in any combinations. I tested openldap 2.4 on debian lenny, its work under my load without tuning (once was crashed whole linux :), but not slapd). Mybe some freebsd tuning needed? Some debug: ber_scanf fmt ({m) ber: ber_dump: buf=0x8037161b0 ptr=0x803716248 end=0x803716274 len=44 0000: 30 84 00 00 00 26 04 16 31 2e 32 2e 38 34 30 2e 0....&..1.2.840. 0010: 31 31 33 35 35 36 2e 31 2e 34 2e 33 31 39 04 0c 113556.1.4.319.. 0020: 30 84 00 00 00 06 02 02 03 e8 04 00 0........... ber_scanf fmt (m) ber: ber_dump: buf=0x8037161b0 ptr=0x803716266 end=0x803716274 len=14 0000: 00 0c 30 84 00 00 00 06 02 02 03 e8 04 00 ..0........... => get_ctrls: oid="1.2.840.113556.1.4.319" (noncritical) ber_scanf fmt ({im}) ber: ber_dump: buf=0x803831000 ptr=0x803831000 end=0x80383100c len=12 0000: 30 84 00 00 00 06 02 02 03 e8 04 00 0........... <= get_ctrls: n=1 rc=0 err="" attrs: cn userPassword memberUid uniqueMember gidNumber conn=105 op=1 SRCH base="ou=staff,dc=ulgsm,dc=ru" scope=1 deref=0 filter="(&(objectClass=posixGroup))" conn=105 op=1 SRCH attr=cn userPassword memberUid uniqueMember gidNumber slap_global_control: unavailable control: 1.2.840.113556.1.4.319 ==> limits_get: conn=105 op=1 dn="cn=bind,ou=staff,dc=ulgsm,dc=ru" => hdb_search bdb_dn2entry("ou=staff,dc=ulgsm,dc=ru") search_candidates: base="ou=staff,dc=ulgsm,dc=ru" (0x00000002) scope=1 => hdb_dn2idl("ou=staff,dc=ulgsm,dc=ru") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read zsh: segmentation fault /usr/local/libexec/slapd -d -1 -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru ???. +7 951 0985685, ??. 368 From ob at e-Gitt.NET Tue Oct 27 08:56:50 2009 From: ob at e-Gitt.NET (Oliver Brandmueller) Date: Tue Oct 27 08:56:58 2009 Subject: openldap unstable on freebsd In-Reply-To: <20091027082516.GA88892@mail.ulgsm.ru> References: <20091027082516.GA88892@mail.ulgsm.ru> Message-ID: <20091027085647.GT95002@e-Gitt.NET> Hi, On Tue, Oct 27, 2009 at 11:25:16AM +0300, alexs@ulgsm.ru wrote: > Last 2 years (maybe when began using bdb backend), we get slapd crash on > read load. > System on low load work with monit monitoring and fails 1-3 in month. > When load up crashes frequency up too. > > Tuning helped but not much. > > load about 20-30 queryes/sec in peak. > and crashes every hour. > > Problem watched on Freebsd7,7.1,7.2 i386, amd64 and openldap2.3,2.4 > (bdb,hdb backends) in any combinations. > > I tested openldap 2.4 on debian lenny, its work under my load without > tuning (once was crashed whole linux :), but not slapd). > > Mybe some freebsd tuning needed? We have slapd running on several servers with read loads of between 50 and 200 requests per second and it runs rock stable. What comes tomind, did your server crash at some point? Have you tried to either do a db_recover on the database files (while slapd is not running of course) or slapcat/slapadd to rebuild the BDB from scratch? I get the feeling your BDB is somehow damaged. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | From jakub_lach at mailplus.pl Tue Oct 27 14:32:11 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Tue Oct 27 14:32:19 2009 Subject: No sound after update to RC2 from RC1. Message-ID: <26078773.post@talk.nabble.com> Hello. I've lost sound. Dmesg content: hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] Starting default moused . mixer: unknown device: mic (or ogain) hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) pcm0: at cad 0 nid 1 on hdac0 It was previously working with such device.hints: hint.hdac.0.cad0.nid22.config="as=1" hint.hdac.0.cad0.nid26.config="as=1 seq=1" hint.hdac.0.cad0.nid24.config="as=2" hint.hdac.0.cad0.nid29.config="as=2 seq=1" + sysctl.conf dev.pcm.0.play.vchans=0 dev.pcm.0.bitperfect=1 -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26078773.html Sent from the freebsd-stable mailing list archive at Nabble.com. From jfarmer at goldsword.com Tue Oct 27 15:09:56 2009 From: jfarmer at goldsword.com (jfarmer@goldsword.com) Date: Tue Oct 27 15:11:34 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <200910271902.19618.doconnor@gsoft.com.au> References: <200910271646.55227.doconnor@gsoft.com.au> <200910271902.19618.doconnor@gsoft.com.au> Message-ID: <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> Quoting Daniel O'Connor : > On Tue, 27 Oct 2009, Artem Belevich wrote: >> > Unfortunately it appears ZFS doesn't search for GPT partitions so >> > if you have them and swap the drives around you need to fix it up >> > manually. >> >> When I used raw disk or GPT partitions, if disk order was changed the >> pool would come up in 'DEGRADED' or UNAVAILABLE state. Even then all >> that had to be done is export/import the pool. After the pool has >> been re-imported it was back to ONLINE. > > Hmm OK, I thought it supposedly DTRT for raw disks but apparently not. > >> Now I'm using GPT labels (gpart -l) specifically because that avoids >> issues with disk order or driver change. The pool I've built from GPT >> labels has survived several migrations between different >> controllers/drivers adX (ata) -> daX (SATA disks on mpt) -> adaX >> (ahci) and multiple drive permutations without any manual >> intervention at all. All that was done on 8-RC1/amd64. >> I have also successfully imported the pool on OpenSolaris and back >> again on FreeBSD. > > Damn, if I'd realised I'd have done that :) > > Do you know if it's possible to change? > Check the archives for stable@ and fs@. I believe that there was a thread not that long ago detailing exactly how to do that. IIRC, while it took a bit of work, it wasn't difficult. John ----------------------------------------------------------------- J. T. Farmer GoldSword Systems, Knoxville TN Coach & Instructor Consulting, Knoxville Academy of the Blade Software Development, Maryville Fencing Club Project Management From O.Seibert at cs.ru.nl Tue Oct 27 16:52:26 2009 From: O.Seibert at cs.ru.nl (Olaf Seibert) Date: Tue Oct 27 16:52:33 2009 Subject: 8.0-RC1 NFS client timeout issue Message-ID: <20091027164159.GU841@twoquid.cs.ru.nl> I see an annoying behaviour with NFS over TCP. It happens both with nfs and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is some Linux or perhaps Solaris, I'm not entirely sure. After trying to find something in packet traces, I think I have found something. The scenario seems to be as follows. Sorry for the width of the lines. No. Time Source Destination Protocol Info 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 The server decides, for whatever reason, to terminate the connection and sends a FIN. 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 Client acknowledges this, 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 but tries to sneak in another call anyway. [A] 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 Server ACKs but doesn't send anything else... [B] Time passes... 2312 3675.366081 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [FIN, ACK] Seq=238569 Ack=230406 Win=8192 Len=0 TSV=87175425 TSER=12431760 Client finally decides after 300 secs to close the connection too 2313 3675.366149 xxx.xxx.31.43 xxx.xxx.16.142 TCP 904 > nfs [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=5 TSV=87175425 TSER=0 and to re-open a new one. 2314 3675.366318 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238570 Win=49232 Len=0 TSV=12461749 TSER=87175425 2315 3675.366446 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 904 [SYN, ACK] Seq=0 Ack=1 Win=49232 Len=0 TSV=12461749 TSER=87175425 MSS=1460 WS=0 2316 3675.366483 xxx.xxx.31.43 xxx.xxx.16.142 TCP 904 > nfs [ACK] Seq=1 Ack=1 Win=66592 Len=0 TSV=87175425 TSER=12461749 2317 3675.366506 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2319), FH:0x008002a2 2318 3675.366660 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 904 [ACK] Seq=1 Ack=141 Win=49092 Len=0 TSV=12461749 TSER=87175425 2319 3675.367356 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2317) 2320 3675.367425 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 GETATTR Call (Reply In 2322), FH:0x170cb16a 2321 3675.367644 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 904 [ACK] Seq=125 Ack=277 Win=49232 Len=0 TSV=12461749 TSER=87175426 2322 3675.367730 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2320) Directory mode:2755 uid:4100 gid:4100 2323 3675.367759 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2325), FH:0x170cb16a Point [A] seems somwehat worrisome to me: Though technically the connection is closed in one direction only, the intention of the server seems clear, and it would be better to be careful and make a new connection right away. [B] would be a bug of the server in my opinion. If it ACKs a call, it should send a reply. And if it can't, it shouldn't. Please Cc me on replies, I am not subscribed to this list. -Olaf. -- From kometen at gmail.com Tue Oct 27 17:22:43 2009 From: kometen at gmail.com (Claus Guttesen) Date: Tue Oct 27 17:22:54 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. I used nfs with tcp on a 7.2-client without problems on a solaris nfs-server. When I upgraded to RC1 I had 'server not responding - alive again' messages so I swithced to udp which works flawlessly. I haven't had time to investigate it though. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare twitter.com/kometen From doconnor at gsoft.com.au Wed Oct 28 00:42:12 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Wed Oct 28 00:42:22 2009 Subject: whats best pracfive for ZFS on a whole disc these days ? In-Reply-To: <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> References: <200910271902.19618.doconnor@gsoft.com.au> <20091027104316.dsp7kikkoogo80gw@www.goldsword.com> Message-ID: <200910281112.06300.doconnor@gsoft.com.au> On Wed, 28 Oct 2009, jfarmer@goldsword.com wrote: > Check the archives for stable@ and fs@. ?I believe that there was a ? > thread not that long ago detailing exactly how to do that. ?IIRC, ? > while it took a bit of work, it wasn't difficult. Hmm do you have any idea what the subject was? I'm having trouble finding it :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091028/88e9bf5d/attachment.pgp From dclark at engr.scu.edu Wed Oct 28 01:16:37 2009 From: dclark at engr.scu.edu (Dorr H. Clark) Date: Wed Oct 28 01:16:58 2009 Subject: ptrace problem 6.x/7.x - can someone explain this? In-Reply-To: Message-ID: We believe ptrace has a problem in 6.3; we have not tried other releases. The same code, however, exists in 7.1. The bug was first encountered in gdb... (gdb) det Detaching from program: /usr/local/bin/emacs, process 66217 (gdb) att 66224 Attaching to program: /usr/local/bin/emacs, process 66224 Error accessing memory address 0x281ba5a4: Device busy. (gdb) det Detaching from program: /usr/local/bin/emacs, process 66224 ptrace: Device busy. (gdb) quit <--- target process 66224 dies here To isolate this problem, a wrote a simple minded test program was written that just attached and detached. This test program found even the very first detach fails with EBUSY (see test source below): $ ./test1 -p 66217 -c 1 -d 10 pid 66217 count 1 delay 10 Start of pass 0 Calling PT_ATTACH pid 66217 addr 0x0 sig 0 Calling PT_DETACH pid 66217 addr 0xffffffff sig 0 Call 0 to PT_DETACH returned -1, errno 16 Once again, the target process died when the ptracing test program exitted, as would be expected if a detach had failed. The failure return was coming from the following test in kern_ptrace() in sys_process.c /* not currently stopped */ if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 || p->p_suspcount != p->p_numthreads || (p->p_flag & P_WAITED) == 0) { error = EBUSY; goto fail; } This is applied to all operations except PT_TRACE_ME, PT_ATTACH, and some instances of PT_CLEAR_STEP. P_WAITED is generally not true. In particular, it's not set automatically when a process is PT_ATTACHed. It is cleared by PT_DETACH and again when ptrace sends a signal (PT_CONTINUE, PT_DETACH.) _But_ it's set in only two places, and they aren't in ptrace code. 2 sys/kern/kern_exit.c kern_wait 773 p->p_flag |= P_WAITED; 3 compat/svr4/svr4_misc.c svr4_sys_waitsys 1351 q->p_flag |= P_WAITED; The relevant one is the first one, primarily. Here's the code: mtx_lock_spin(&sched_lock); if ((p->p_flag & P_STOPPED_SIG) && (p->p_suspcount == p->p_numthreads) && (p->p_flag & P_WAITED) == 0 && (p->p_flag & P_TRACED || options & WUNTRACED)) { mtx_unlock_spin(&sched_lock); p->p_flag |= P_WAITED; sx_xunlock(&proctree_lock); td->td_retval[0] = p->p_pid; if (status) *status = W_STOPCODE(p->p_xstat); PROC_UNLOCK(p); return (0); } mtx_unlock_spin(&sched_lock); So it's only set on processes which are already traced. But it's not set until someone calls wait4() on them - or the equivalent sysV compatability routine. Gdb doesn't always wait4() for processes immediately opon tracing them, and the ptrace man page does not imply this is needed. Moreover, it's not clear why it should matter. The process needs to be stopped in order for it to make sense to do most of the things ptrace does. But - why should it need to be waited for? And what kind of sense does this make to someone writing a debugging tool, where the natural logic seems to be: - attach to process - look at some stuff - stick in some kind of breakpoint or similar and start it going again (or 'step' it) - wait for it to stop - look at and modify stuff - detach, or set it moving again By way of experiment, the test for P_WAITED was removed. Gdb no longer had problems, and no new issues with gdb were encountered (although this was just interactive, no "gdb coverage test" was attempted). The test program also stopped having issues. /* not currently stopped */ if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 || p->p_suspcount != p->p_numthreads { error = EBUSY; goto fail; } So does anyone know whether it's safe to simply remove that test? Thanks, Arlie Stephens Engineer Dorr H. Clark Advisor Graduate School of Engineering Santa Clara University, Santa Clara, CA --------------------------------------------------------------------- Test program here --------------------------------------------------------------------- /* * experiment with ptrace, try to see which is broken - gdb or ptrace */ #include #include #include #include #include #include void usage(void) { printf("Simple program to play with ptrace\n"); printf("Usage: test1 -p -c -d \n"); printf("Specify -n for no explicit detach\n"); printf("Will attach and detach repeatedly from target process\n"); exit(1); } int main(int argc, char *argv[]) { pid_t pid = -1; int count = 2; int delay = 5; int nodetach = 0; int opt; int ret; int i; while((opt = getopt(argc, argv, ":p:c:d:n")) != -1) { switch(opt) { case 'c': if (sscanf(optarg, "%d", &count) != 1) { printf("Count should be numeric\n"); usage(); } break; case 'd': if (sscanf(optarg, "%d", &delay) != 1) { printf("Delay should be numeric\n"); usage(); } break; case 'n': nodetach = 1; break; case 'p': if (sscanf(optarg, "%d", &pid) != 1) { printf("Pid should be numeric\n"); usage(); } break; default: printf("Illegal option -%c\n", opt); usage(); break; } } printf("pid %d count %d delay %d\n", pid, count, delay); if (pid == -1) { printf("Pid must be specified\n"); usage(); } if (count <= 0) { printf("Count must be positive\n"); usage(); } if (delay < 0) { printf("Delay must not be negative\n"); usage(); } for (i = 0; i < count; i++) { printf("Start of pass %d\n", i); errno = 0; printf("Calling PT_ATTACH pid %d addr 0x%lx sig %d\n", pid, (unsigned long)(caddr_t)NULL, 0); ret = ptrace(PT_ATTACH, pid, NULL, 0); if (ret != 0) { printf("Call %d to PT_ATTACH returned %d, errno %d\n", i, ret, errno); } sleep(delay); if (!nodetach) { errno = 0; printf("Calling PT_DETACH pid %d addr 0x%lx sig %d\n", pid, (unsigned long)(caddr_t)-1, 0); ret = ptrace(PT_DETACH, pid, (caddr_t)-1, 0); if (ret != 0) { printf("Call %d to PT_DETACH returned %d, " "errno %d\n", i, ret, errno); } } sleep(delay); } return 0; } From marcus at blazingdot.com Wed Oct 28 02:14:11 2009 From: marcus at blazingdot.com (Marcus Reid) Date: Wed Oct 28 02:14:17 2009 Subject: New devices appear in all devfs mounts Message-ID: <20091028014730.GA40196@blazingdot.com> Hi, I have devfs mounted in a chroot jail, with just the basic device nodes visible: fstab: /dev/null /usr/data/home/scp/dev devfs rw 0 0 rc.conf: devfs_set_rulesets="/usr/data/home/scp/dev=devfsrules_hide_all /usr/data/home/scp/dev=devfsrules_unhide_basic" When a new device is created, such as when adding a new scsi device or having enough concurrent logins to instantiate new ttys, the new devices appear in both /dev and /usr/data/home/scp/dev, which is not the intent for the stripped-down chrooted dev dir. Is there a way to work around this? Thanks, Marcus From alexs at ulgsm.ru Wed Oct 28 05:52:18 2009 From: alexs at ulgsm.ru (alexs@ulgsm.ru) Date: Wed Oct 28 05:52:25 2009 Subject: openldap unstable on freebsd In-Reply-To: <20091027085647.GT95002@e-Gitt.NET> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> Message-ID: <20091028055210.GA72197@mail.ulgsm.ru> * Oliver Brandmueller [2009-10-27 09:56:48 +0100]: > Hi, > > On Tue, Oct 27, 2009 at 11:25:16AM +0300, alexs@ulgsm.ru wrote: > > Last 2 years (maybe when began using bdb backend), we get slapd crash on > > read load. > > System on low load work with monit monitoring and fails 1-3 in month. > > When load up crashes frequency up too. > > > > Tuning helped but not much. > > > > load about 20-30 queryes/sec in peak. > > and crashes every hour. > > > > Problem watched on Freebsd7,7.1,7.2 i386, amd64 and openldap2.3,2.4 > > (bdb,hdb backends) in any combinations. > > > > I tested openldap 2.4 on debian lenny, its work under my load without > > tuning (once was crashed whole linux :), but not slapd). > > > > Mybe some freebsd tuning needed? > > We have slapd running on several servers with read loads of between 50 > and 200 requests per second and it runs rock stable. > > What comes tomind, did your server crash at some point? Have you tried > to either do a db_recover on the database files (while slapd is not > running of course) or slapcat/slapadd to rebuild the BDB from scratch? I > get the feeling your BDB is somehow damaged. I reinstall opneldap, remove all tunung, make slapadd < backup.ldif and get about 50 failures at the night. :( > > - Oliver > > -- > | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | > | Ich bin das Internet. Sowahr ich Gott helfe. | > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From mav at FreeBSD.org Wed Oct 28 08:25:59 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 28 08:26:05 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <1256667780.00177464.1256654401@10.7.7.3> References: <1256667780.00177464.1256654401@10.7.7.3> Message-ID: <4AE80012.803@FreeBSD.org> Jakub Lach wrote: > I've lost sound. Dmesg content: > > hdac0: HDA Driver Revision: 20090624_0136 > hdac0: [ITHREAD] > > Starting default moused > . > mixer: > unknown device: mic > (or ogain) > > hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) > pcm0: at cad 0 nid 1 on hdac0 > > It was previously working with such device.hints: > > hint.hdac.0.cad0.nid22.config="as=1" > hint.hdac.0.cad0.nid26.config="as=1 seq=1" > hint.hdac.0.cad0.nid24.config="as=2" > hint.hdac.0.cad0.nid29.config="as=2 seq=1" > > + sysctl.conf > > dev.pcm.0.play.vchans=0 > dev.pcm.0.bitperfect=1 There was no any changes in snd_hda for last two month in RELENG_8 branch. Show me full verbose boot messages and `cat /dev/sndstat`. -- Alexander Motin From alexs at ulgsm.ru Wed Oct 28 10:13:05 2009 From: alexs at ulgsm.ru (=?utf-8?B?0JrQu9GO0YfQvdC40LrQvtCyINCQLtChLg==?=) Date: Wed Oct 28 10:13:13 2009 Subject: openldap unstable on freebsd In-Reply-To: References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> <20091028055210.GA72197@mail.ulgsm.ru> Message-ID: <20091028101258.GA33200@mail.ulgsm.ru> * Dewayne Geraghty [2009-10-28 19:02:58 +1100]: > Alexs, Would you please provide the output to the following two questions: > /usr/local/libexec/slapd -V ~]>/usr/local/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.19 (Oct 28 2009 09:02:40) $ root@bazar:/usr/wrkdir/usr/ports/net/openldap24-server/work/openldap-2.4.19/servers/slapd > ldd /usr/local/libexec/slapd ~]>ldd /usr/local/libexec/slapd /usr/local/libexec/slapd: libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) libdb-4.7.so.0 => /usr/local/lib/libdb-4.7.so.0 (0x800a97000) libssl.so.5 => /usr/lib/libssl.so.5 (0x800cf7000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e41000) libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010d3000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011e1000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012e3000) libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013fc000) libthr.so.3 => /lib/libthr.so.3 (0x801505000) libc.so.7 => /lib/libc.so.7 (0x80161d000) > It will be helpful to indicate what libraries that you are linking to; and what > version are you using. Currently openldap is 2.4.19. Please note that the > FreeBSD-stable list will be helpful to you if there are operating system > issues. I don't think that you've established an operating system problem with > the information provided. You have asked a good question which would trigger > responses if other people were experiencing the same problem. > > Similar to earlier replies, LDAP has been reliable on my 7.2Stable, and I'm > tracking 3 days behind cvs. My production machines with openldap, run on > average for 600 days without any crashes or reboots; which is what you should > expect. Maybe its my mistake in freebsd and openldap configuration. I cant find it long time. Today I tried on netbsd, (there are openldap 2.4.16 in pkgsrc), work perfect! So it work on linux and netbsd, soon i`ll try on solaris. > > From your description of your problem, you might need to contact the Openldap > mailing list; but you'll need more detail. > Kind regards, Dewayne. Yes. But thea are strong moderated. I think its my english why moderator rejected me. -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From O.Seibert at cs.ru.nl Wed Oct 28 10:14:06 2009 From: O.Seibert at cs.ru.nl (Olaf Seibert) Date: Wed Oct 28 10:14:15 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: References: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: <20091028101404.GV841@twoquid.cs.ru.nl> On Tue 27 Oct 2009 at 18:01:11 +0100, Claus Guttesen wrote: > I used nfs with tcp on a 7.2-client without problems on a solaris > nfs-server. When I upgraded to RC1 I had 'server not responding - > alive again' messages so I swithced to udp which works flawlessly. I > haven't had time to investigate it though. Sounds like the same as my problem. I have switched to UDP and so far, with light useage, I have seen no problem. (It would appear with light useage only, anyway). I have looked at some source, but not being an expert on the terrirory, I haven't seen anything obvious yet. > Claus -Olaf. -- From a.huth at tmr.net Wed Oct 28 11:29:56 2009 From: a.huth at tmr.net (Alex Huth) Date: Wed Oct 28 11:30:02 2009 Subject: Next stable version Message-ID: <20091028110214.GB13028@borusse.borussiapark> Hi! Is there any timeline when 8.0 becomes stable to use it in production? Thx Alex Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. ? unknow From db at danielbond.org Wed Oct 28 11:40:35 2009 From: db at danielbond.org (Daniel Bond) Date: Wed Oct 28 11:40:42 2009 Subject: Next stable version In-Reply-To: <20091028110214.GB13028@borusse.borussiapark> References: <20091028110214.GB13028@borusse.borussiapark> Message-ID: Hi, according to the schedule, 8.0-RELEASE is a bit delayed. This is quite usual, but epecially for 8.0 there have been a lot of last minute fixes. The main schedule is here: http://www.freebsd.org/releng/index.html#schedule which links to more updated and detailed information in the wiki: http://wiki.freebsd.org/8.0TODO If the schedule is still accurate, looks like release building will start in about a week. Personally, I often wait untill the X.1 or X.2 release before upgrading systems allready in production, unless I need a new feature, but I advise testing the BETA's and RC's prior to release, so you can report bugs/issues to be fixed prior to the RELEASE. Best regards, Daniel Bond. On Oct 28, 2009, at 12:02 PM, Alex Huth wrote: > Hi! > > Is there any timeline when 8.0 becomes stable to use it in production? > > Thx > > Alex > > Never be afraid to try something new. > Remember, amateurs built the ark. > Professionals built the Titanic. ? unknow > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091028/cacbd45d/PGP.pgp From a.huth at tmr.net Wed Oct 28 12:24:35 2009 From: a.huth at tmr.net (Alex Huth) Date: Wed Oct 28 12:24:42 2009 Subject: Next stable version In-Reply-To: References: <20091028110214.GB13028@borusse.borussiapark> Message-ID: <20091028122418.GB15578@borusse.borussiapark> * Daniel Bond schrieb: > Hi, > > Personally, I often wait untill the X.1 or X.2 release before upgrading > systems allready in production, unless I need a new feature, but I > advise testing the BETA's and RC's prior to release, so you can report > bugs/issues to be fixed prior to the RELEASE. > We actual have 6.4 on our production server. I don't want to upgrade, because i need a different layout. I need the feature to use several IP in a jail. That's why i am waiting for 8.0. But i have the possibillity to build it on a secondary testing system, which will be later the productive system. Never be afraid to try something new. Remember, amateurs built the ark. Professionals built the Titanic. ? unknow From bsam at ipt.ru Wed Oct 28 12:31:17 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Oct 28 12:31:24 2009 Subject: Next stable version In-Reply-To: (Daniel Bond's message of "Wed\, 28 Oct 2009 12\:40\:28 +0100") References: <20091028110214.GB13028@borusse.borussiapark> Message-ID: <77838974@serv3.int.kfs.ru> Daniel Bond writes: > If the schedule is still accurate, looks like release building will > start in about a week. AFAIC RC2 will be out really soon. But due to many fixes it should be stabilized and RC3 will take place before release is done. -- WBR, bsam From db at danielbond.org Wed Oct 28 12:40:56 2009 From: db at danielbond.org (Daniel Bond) Date: Wed Oct 28 12:41:03 2009 Subject: Next stable version In-Reply-To: <20091028122418.GB15578@borusse.borussiapark> References: <20091028110214.GB13028@borusse.borussiapark> <20091028122418.GB15578@borusse.borussiapark> Message-ID: On Oct 28, 2009, at 1:24 PM, Alex Huth wrote: > We actual have 6.4 on our production server. I don't want to > upgrade, because > i need a different layout. I need the feature to use several IP in a > jail. > That's why i am waiting for 8.0. But i have the possibillity to > build it on a > secondary testing system, which will be later the productive system. You could optionally use 7.2-RELEASE also, which was the first release to support for multiple IP4/6 in jail. Best regards, Daniel Bond. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091028/c78acf93/PGP.pgp From 000.fbsd at quip.cz Wed Oct 28 12:54:46 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Oct 28 12:54:54 2009 Subject: Next stable version In-Reply-To: <20091028122418.GB15578@borusse.borussiapark> References: <20091028110214.GB13028@borusse.borussiapark> <20091028122418.GB15578@borusse.borussiapark> Message-ID: <4AE83F10.3060707@quip.cz> Alex Huth wrote: > * Daniel Bond schrieb: > >>Hi, >> >>Personally, I often wait untill the X.1 or X.2 release before upgrading >>systems allready in production, unless I need a new feature, but I >>advise testing the BETA's and RC's prior to release, so you can report >>bugs/issues to be fixed prior to the RELEASE. >> > > We actual have 6.4 on our production server. I don't want to upgrade, because > i need a different layout. I need the feature to use several IP in a jail. > That's why i am waiting for 8.0. But i have the possibillity to build it on a > secondary testing system, which will be later the productive system. If you only need jails with several IPs, IPv6 or noIPs, you can go for 7-STABLE. The multi-IP was committed right after the 7.2-RELEASE and I an running it for half a year without any problems + cpuset ability. Miroslav Lachman From db at danielbond.org Wed Oct 28 12:57:58 2009 From: db at danielbond.org (Daniel Bond) Date: Wed Oct 28 12:58:13 2009 Subject: Next stable version In-Reply-To: <4AE83F10.3060707@quip.cz> References: <20091028110214.GB13028@borusse.borussiapark> <20091028122418.GB15578@borusse.borussiapark> <4AE83F10.3060707@quip.cz> Message-ID: <1C39034B-E48E-4017-A688-9247B70ED758@danielbond.org> On Oct 28, 2009, at 1:54 PM, Miroslav Lachman wrote: > > If you only need jails with several IPs, IPv6 or noIPs, you can go > for 7-STABLE. The multi-IP was committed right after the 7.2-RELEASE > and I an running it for half a year without any problems + cpuset > ability. It should be included in 7.2-RELEASE, according to announcements and the manual page. - Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 203 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091028/6d010da1/PGP.pgp From darcsis at gmail.com Wed Oct 28 13:20:39 2009 From: darcsis at gmail.com (Denise H. G.) Date: Wed Oct 28 13:20:46 2009 Subject: Next stable version In-Reply-To: <77838974@serv3.int.kfs.ru> (Boris Samorodov's message of "Wed, 28 Oct 2009 14:50:09 +0300") References: <20091028110214.GB13028@borusse.borussiapark> <77838974@serv3.int.kfs.ru> Message-ID: <86639zissq.fsf@pluton.xbsd.name> >>>>> "Boris" == Boris Samorodov writes: Boris> Daniel Bond writes: >> If the schedule is still accurate, looks like release building >> will start in about a week. Boris> AFAIC RC2 will be out really soon. But due to many fixes it Boris> should be stabilized and RC3 will take place before release Boris> is done. I've been followying -STABLE and now it is already RC2 as of today. You can give it a csup and take a look. Boris> -- WBR, bsam _______________________________________________ Boris> freebsd-stable@freebsd.org mailing list Boris> http://lists.freebsd.org/mailman/listinfo/freebsd-stable To Boris> unsubscribe, send any mail to Boris> "freebsd-stable-unsubscribe@freebsd.org" -- (dhg) darcsis AT gmail dot COM From kensmith at buffalo.edu Wed Oct 28 14:45:21 2009 From: kensmith at buffalo.edu (Ken Smith) Date: Wed Oct 28 14:45:34 2009 Subject: 8.0-RC2 Available Message-ID: <1256741116.13258.61.camel@bauer.cse.buffalo.edu> The second of the Release Candidates for the FreeBSD 8.0 release cycle is now available. At this point we feel most of what has been discovered during public testing that is feasible to fix as part of the release process has been addressed. So the current plan is to have 8.0-RC3 in about two weeks. Details about the current target schedule along with much more detail about the current status of the release is available here: http://wiki.freebsd.org/8.0TODO If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is "about to become a stable branch" but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, or 8.0-RC1 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC2: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC2-amd64-bootonly.iso) = d8b4a402dd510446d7bec239cb2a5add MD5 (8.0-RC2-amd64-disc1.iso) = 74ae55d888589d759339d736db4e4e15 MD5 (8.0-RC2-amd64-dvd1.iso) = c1772eb971b9c451ebbdd9e82b09b7b7 MD5 (8.0-RC2-amd64-livefs.iso) = ef34d58bc1c6c47acb69d8a772de364a MD5 (8.0-RC2-amd64-memstick.img) = 295815f1b358706a8f39f09f3240dde2 MD5 (8.0-RC2-i386-bootonly.iso) = 2d9e62645603a2d284c787f3505060fa MD5 (8.0-RC2-i386-disc1.iso) = 8883ed3b408b67a265d82467d0659ced MD5 (8.0-RC2-i386-dvd1.iso) = 484792f88bae31fca2846bc2a78d8e95 MD5 (8.0-RC2-i386-livefs.iso) = 7053f9ea329d4751c3361112d33b3caa MD5 (8.0-RC2-i386-memstick.img) = b6a703e47e184e2eef63defd60f11abe MD5 (8.0-RC2-ia64-bootonly.iso) = 803d1d48e4a7c52f028cdd9335f63e95 MD5 (8.0-RC2-ia64-disc1.iso) = eb0a6aea681ae605f1a291e17e92342c MD5 (8.0-RC2-ia64-disc2.iso) = 67471992168e3c93095dae45ae0be773 MD5 (8.0-RC2-ia64-disc3.iso) = 6a076b1abda6ff843b8e8745d8068906 MD5 (8.0-RC2-ia64-dvd1.iso) = caf585b43277c22d6b5da1725764eccb MD5 (8.0-RC2-ia64-livefs.iso) = 7c2251519fd99236af1d6bbda2606c3f MD5 (8.0-RC2-pc98-bootonly.iso) = 37bbc89727b0927b8075573133d0fb9f MD5 (8.0-RC2-pc98-disc1.iso) = 0d1f6a48ebcbac485df40f8825d54863 MD5 (8.0-RC2-pc98-livefs.iso) = 018d7f8d716e2a7a53f3263a4debef4d MD5 (8.0-RC2-powerpc-bootonly.iso) = b481aa9d1b66060ae21f427e4aa2a529 MD5 (8.0-RC2-powerpc-disc1.iso) = 0cc7590fe4a0933d54d0deecf9112129 MD5 (8.0-RC2-powerpc-disc2.iso) = e7a89d93be2bc8a69b54558c9d424c5c MD5 (8.0-RC2-powerpc-disc3.iso) = c549a90991122421dcb631d78ab8f312 MD5 (8.0-RC2-sparc64-bootonly.iso) = 3033c3b3c92eec90ad21b772b4ccd970 MD5 (8.0-RC2-sparc64-disc1.iso) = e4b3470481eb94baa2df115b85a23002 MD5 (8.0-RC2-sparc64-dvd1.iso) = a6571c2735c52dc8e5f83384e827c1ff SHA256 (8.0-RC2-amd64-bootonly.iso) = 0c72b0248a689df99b3aa76b7ed148b7bd74a9de2577950231120ac4403bdb4c SHA256 (8.0-RC2-amd64-disc1.iso) = a20b72acf3990f6b4a71941c576d5dc395260a98287bdfe4455cbf15555015e0 SHA256 (8.0-RC2-amd64-dvd1.iso) = f29f6a65d08190d946d38412cc199b7ad3d001ccd05e66b396cdb1339f45b3fd SHA256 (8.0-RC2-amd64-livefs.iso) = 59f3feb88ea35e8ec075b59ff1eeac8df36df219a375058966eab2b4deb1350a SHA256 (8.0-RC2-amd64-memstick.img) = 60a91e82223169fabf445b227f75cdc3495045a764285a0e7023bdf20478931a SHA256 (8.0-RC2-i386-bootonly.iso) = b160f47b2b7baa69acca8c5e5d45dccb8fa3582ade676f69b44638c956f92f38 SHA256 (8.0-RC2-i386-disc1.iso) = c7edabc1fe1429f396978b4699b41fff9e4a17574dfa2658499a6f9f2bd91a1d SHA256 (8.0-RC2-i386-dvd1.iso) = 34ae54a05ad5c0ac4a2d208edec95c218b0bf4e0a2458c97317f2cbebe4ce93b SHA256 (8.0-RC2-i386-livefs.iso) = e58b2b922ee1ee8fb56eeac36fe5e8eb35d7c9d7824535d770a7066faaafa8a4 SHA256 (8.0-RC2-i386-memstick.img) = aed885993e742a6c5ec17b4339ffab17449219e588d2e80457a0b7137d333f52 SHA256 (8.0-RC2-ia64-bootonly.iso) = 16967168e7eb1ea95d2aac1334d5046b307d06318613de329fc68fa65670e703 SHA256 (8.0-RC2-ia64-disc1.iso) = 6134adc5f124e397a5783a4d9ff8c94a3b942a06e2682e489ff484c8a87ea8d3 SHA256 (8.0-RC2-ia64-disc2.iso) = a4b471b71da9d4a047d6dbbdd2029ec2ec3ac6e7ebf96d993ded7917b0b8649b SHA256 (8.0-RC2-ia64-disc3.iso) = 4e44fb8dd42bab1775318ba6608656739533dfb60bccd5800877e1d693dd67a6 SHA256 (8.0-RC2-ia64-dvd1.iso) = db586139a60465d125ab89adcf28283528d0d62dd5ee6ef5dba6e90b0761107b SHA256 (8.0-RC2-ia64-livefs.iso) = 0a2d497a400166e4ea4a4191a92bb5d37959bedc53b2dea04b35c0cd0681ee66 SHA256 (8.0-RC2-pc98-bootonly.iso) = 62f4af328fbb3660b49b4ca75158731de457781b41f6f1fd15f8cb58c8e2769d SHA256 (8.0-RC2-pc98-disc1.iso) = 5551baa1205ad356c87ccc7685241d463dd8a26bde366fd8bdb4bde44188bf72 SHA256 (8.0-RC2-pc98-livefs.iso) = 2f195b71d73eaf4a76ac00522431e674f5a9b8272bb002c90c2c6d2a5491c4f5 SHA256 (8.0-RC2-powerpc-bootonly.iso) = d268f4cebd71bfbe7a6532270097b4934f49da518a51754429448ef30bf57db0 SHA256 (8.0-RC2-powerpc-disc1.iso) = b847889e72d5134b7ac6bf06244e7c919639d7d80a0001f6cfea5fc0c4c2847d SHA256 (8.0-RC2-powerpc-disc2.iso) = 2fe8a8f97821d2695b0f795eda62422433eae23dc1e6f5b7c38983e6c2431b25 SHA256 (8.0-RC2-powerpc-disc3.iso) = 24ccace776b897705ad10115287c9819bc3301aedaa4afd253addbc038178f0a SHA256 (8.0-RC2-sparc64-bootonly.iso) = ce24a908fce56afa6a7a29687d9fcc63ffe724d59014851344349702a1df5fd2 SHA256 (8.0-RC2-sparc64-disc1.iso) = d4b3974421b52ed89699422d9160396758249ddd8f82fa12a0339cbf023cf32e SHA256 (8.0-RC2-sparc64-dvd1.iso) = 999f52fe73d32be3008eb5b289882d50eee35f469e4bb122268dfacd2f1508f0 SHA256 (8.0-RC2-sparc64-livefs.iso) = 7e22429d82bce3c3b7e927a380c6ce136ce30811653fec94f369eef496810725 -- Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091028/4d092c27/attachment.pgp From jakub_lach at mailplus.pl Wed Oct 28 19:05:57 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Wed Oct 28 19:06:22 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <4AE80012.803@FreeBSD.org> References: <26078773.post@talk.nabble.com> <4AE80012.803@FreeBSD.org> Message-ID: <26100325.post@talk.nabble.com> Alexander Motin-3 wrote: > > Jakub Lach wrote: >> I've lost sound. Dmesg content: >> >> hdac0: HDA Driver Revision: 20090624_0136 >> hdac0: [ITHREAD] >> >> Starting default moused >> . >> mixer: >> unknown device: mic >> (or ogain) >> >> hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) >> pcm0: at cad 0 nid 1 on >> hdac0 >> >> It was previously working with such device.hints: >> >> hint.hdac.0.cad0.nid22.config="as=1" >> hint.hdac.0.cad0.nid26.config="as=1 seq=1" >> hint.hdac.0.cad0.nid24.config="as=2" >> hint.hdac.0.cad0.nid29.config="as=2 seq=1" >> >> + sysctl.conf >> >> dev.pcm.0.play.vchans=0 >> dev.pcm.0.bitperfect=1 > > There was no any changes in snd_hda for last two month in RELENG_8 > branch. Show me full verbose boot messages and `cat /dev/sndstat`. > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Yes, I tried tracing related changes to no avail, furthermore I didn't change anything related in my configuration. Dmesg gives some insight: hdac0: Tracing association 1 (2) hdac0: Unable to trace pin 24 to ADC 20, undo traces hdac0: Pin 24 traced to ADC 21 hdac0: Unable to trace pin 29 to ADC 21, undo traces hdac0: Association 1 (2) trace failed Full dmesg + sndstat http://senduit.com/8fdabe -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26100325.html Sent from the freebsd-stable mailing list archive at Nabble.com. From rmacklem at uoguelph.ca Wed Oct 28 20:31:25 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Wed Oct 28 20:31:32 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091027164159.GU841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: First off, I know that cross posting is evil, but I wanted to try and make sure developers saw it. On Tue, 27 Oct 2009, Olaf Seibert wrote: > I see an annoying behaviour with NFS over TCP. It happens both with nfs > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > some Linux or perhaps Solaris, I'm not entirely sure. > > After trying to find something in packet traces, I think I have found > something. > > The scenario seems to be as follows. Sorry for the width of the lines. > > > No. Time Source Destination Protocol Info > 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w > 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT > 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin > 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 > 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 > 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) > 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w > 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT > 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 > 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 > 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 > 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 > > The server decides, for whatever reason, to terminate the > connection and sends a FIN. > > 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 > > Client acknowledges this, > > 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 > > but tries to sneak in another call anyway. [A] > Probably not the best behaviour, but I think it is technically allowed by TCP. (My TCP is very rusty, but I think the socket should be in TCPS_CLOSE_WAIT at this point and the BSD code will have called socantrcvmore(), but not socantsndmore().) > 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 > > Server ACKs but doesn't send anything else... [B] > > Time passes... > This is where it seems interesting. It looks to me like the socket upcall for receiving the FIN would have happened before this point, setting the ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't check for this. (It does check for it happening during and after the sosend(), but not before it, from what I can see.) > > [B] would be a bug of the server in my opinion. If it ACKs a call, it > should send a reply. And if it can't, it shouldn't. > I'll leave this one for the TCP wizzards. I'm not sure what the correct behaviour is when data is received on a connection. (I think it is waiting for a FIN from the client side at this point.) If you could try the following patch and see if it helps, that would be appreciated, rick ps: I'll try to reproduce the situation here, but I'm not sure if I can. --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 +++ rpc/clnt_vc.c 2009-10-28 15:49:57.000000000 -0400 @@ -413,6 +413,19 @@ cr->cr_xid = xid; mtx_lock(&ct->ct_lock); + /* + * Check to see if the other end has already started to close down + * the connection. If it happens after this point, it will be + * detected below, when cr->cr_error is checked. + */ + if (ct->ct_error.re_status == RPC_CANTRECV) { + if (errp != &ct->ct_error) { + errp->re_errno = ct->ct_error.re_errno; + errp->re_status = RPC_CANTRECV; + } + stat = RPC_CANTRECV; + goto out; + } TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); mtx_unlock(&ct->ct_lock); From rea-fbsd at codelabs.ru Thu Oct 29 07:03:32 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Oct 29 07:03:45 2009 Subject: ptrace problem 6.x/7.x - can someone explain this? In-Reply-To: References: Message-ID: Dorr, good day. Tue, Oct 27, 2009 at 05:32:34PM -0700, Dorr H. Clark wrote: > We believe ptrace has a problem in 6.3; we have not tried other > releases. The same code, however, exists in 7.1. And in HEAD too. > The bug was first encountered in gdb... > > (gdb) det > Detaching from program: /usr/local/bin/emacs, process 66217 > (gdb) att 66224 > Attaching to program: /usr/local/bin/emacs, process 66224 > Error accessing memory address 0x281ba5a4: Device busy. > (gdb) det > Detaching from program: /usr/local/bin/emacs, process 66224 > ptrace: Device busy. > (gdb) quit <--- target process 66224 dies here > > To isolate this problem, a wrote a simple minded test program was > written that just attached and detached. This test program found > even the very first detach fails with EBUSY (see test source below): > > $ ./test1 -p 66217 -c 1 -d 10 > pid 66217 count 1 delay 10 > Start of pass 0 > Calling PT_ATTACH pid 66217 addr 0x0 sig 0 > Calling PT_DETACH pid 66217 addr 0xffffffff sig 0 > Call 0 to PT_DETACH returned -1, errno 16 > > Once again, the target process died when the ptracing test program > exitted, as would be expected if a detach had failed. > > The failure return was coming from the following test in kern_ptrace() > in sys_process.c > > /* not currently stopped */ > if ((p->p_flag & (P_STOPPED_SIG | P_STOPPED_TRACE)) == 0 || > p->p_suspcount != p->p_numthreads || > (p->p_flag & P_WAITED) == 0) { > error = EBUSY; > goto fail; > } Yes, the ptraced process should have been waited for, even after the PT_ATTACH call. This is somewhat documented in ptrace(2), ----- ----- but I agree that the wording is a bit sloppy. I'll try to produce slightly modified explanation in the manual page and will post the patch here and as the PR. I had modified your example to visually display the results of each wait() call that is made after ptrace() invocation. Here we go: ----- $ ./test -p 45901 pid 45901 count 2 delay 5 Start of pass 0 Calling PT_ATTACH pid 45901 addr 0x0 sig 0 Attached wait() yield 0x117f: stopped by signal 17; <-- after PT_ATTACH wait() yield 0x57f: stopped by signal 5; <-- after PT_STEP Calling PT_DETACH pid 45901 addr 0xffffffffffffffff sig 0 Detached. ----- As you see, the process is stopped just after the PT_ATTACH with the signal 17, SIGSTOP. PT_STEP follows with the delivery of the SIGTRAP. Both of these signals should be processed by the parent's wait(). And PT_DETACH works, apart from one thing: on my 8.0 PT_DETACH leads to the segfault of the traced program. I hadn't yet tried it on the other versions, so may be there is some bug in the code of test.c, or some bug in the ptrace() implementation -- can't say for sure. If anyone knows why the program segfaults -- please, speak up. The modified source of the test.s is attached. > This is applied to all operations except PT_TRACE_ME, PT_ATTACH, and > some instances of PT_CLEAR_STEP. > > P_WAITED is generally not true. In particular, it's not set > automatically when a process is PT_ATTACHed. It is cleared by > PT_DETACH and again when ptrace sends a signal (PT_CONTINUE, > PT_DETACH.) _But_ it's set in only two places, and they aren't in > ptrace code. > > 2 sys/kern/kern_exit.c kern_wait 773 p->p_flag |= P_WAITED; > 3 compat/svr4/svr4_misc.c svr4_sys_waitsys 1351 q->p_flag |= P_WAITED; > > The relevant one is the first one, primarily. Here's the code: > > mtx_lock_spin(&sched_lock); > if ((p->p_flag & P_STOPPED_SIG) && > (p->p_suspcount == p->p_numthreads) && > (p->p_flag & P_WAITED) == 0 && > (p->p_flag & P_TRACED || options & WUNTRACED)) { > mtx_unlock_spin(&sched_lock); > p->p_flag |= P_WAITED; > sx_xunlock(&proctree_lock); > td->td_retval[0] = p->p_pid; > if (status) > *status = W_STOPCODE(p->p_xstat); > PROC_UNLOCK(p); > return (0); > } > mtx_unlock_spin(&sched_lock); > > So it's only set on processes which are already traced. But it's not > set until someone calls wait4() on them - or the equivalent sysV > compatability routine. > > Gdb doesn't always wait4() for processes immediately opon tracing > them, and the ptrace man page does not imply this is needed. Hmm, there is at least one thread on the simular matter, http://sourceware.org/ml/gdb/2008-12/msg00041.html and people are saying that wait() still should be present. > Moreover, it's not clear why it should matter. The process > needs to be stopped in order for it to make sense to do most > of the things ptrace does. But - why should it need to be waited for? To see if it was really stopped, I presume. > And what kind of sense does this make to someone writing a debugging > tool, where the natural logic seems to be: > - attach to process - wait for the process' attachment by doing wait(). > - look at some stuff > - stick in some kind of breakpoint or similar and start it going again > (or 'step' it) > - wait for it to stop > - look at and modify stuff > - detach, or set it moving again > > By way of experiment, the test for P_WAITED was removed. Gdb no longer had > problems, and no new issues with gdb were encountered (although this > was just interactive, no "gdb coverage test" was attempted). By the way, I can't reproduce gdb faults with the 8.0 sources. Will try 7.x, but I think that I have no 6.x handy. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From alexs at ulgsm.ru Thu Oct 29 12:31:12 2009 From: alexs at ulgsm.ru (alexs@ulgsm.ru) Date: Thu Oct 29 12:31:41 2009 Subject: openldap unstable on freebsd In-Reply-To: <9345792F61634092B5DA5990B7529999@HS> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> <20091028055210.GA72197@mail.ulgsm.ru> <20091028101258.GA33200@mail.ulgsm.ru> <9345792F61634092B5DA5990B7529999@HS> Message-ID: <20091029123105.GA74611@mail.ulgsm.ru> * Dewayne Geraghty [2009-10-29 10:39:22 +1100]: > Alexs, > Thank-you. You seem to be using a default setup from ports. > > If you are using the same configuration files for slapd.conf and > /var/openldap-data/DB_CONFIG files on the three operating systems, and FreeBSD > isn't working, I'm struggling to think of any load induced problems that it > might be from the information provided. > > Rather than asking you a lot of questions, I think you need to rule out that > disks can handle the load, that bdb is able to service the queries, and that > the tools creating the ldap queries are using the same assumptions that the > ldap server is using, etc. I think it unlikely, but I couldn't rule out a bad > ldap query as a source of the problem. I tryed put database on RAM drive (created by mdconfig -t malloc), fails anyway. All configs in defaults, inly indexes and some acls added. > Review the "man slapd.conf" and determine the loglevel that you think > appropriate, I'd suggest 2047 as a good start. > /usr/local/libexec/slapd -d 2047 -4 -h ldapi://%2fvar%2frun%2fopenldap%2fldapi/ > ldap://alexs-ldap-server/ For geting crashes (for this mail only, real crashes needs to wait) I am use small script via nss_ldap. ~]>cat test.sh #!/bin/sh while true do id test > /dev/null done With 3 running scripts get fault in 30 seconds http://pastebin.org/49205 http://pastebin.org/49211 http://pastebin.org/49213 So crashes in different places. I think need some another debuging. I tried truss slapd process, but there different places too. > > Good luck, Dewayne. -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From alexs at ulgsm.ru Thu Oct 29 13:28:05 2009 From: alexs at ulgsm.ru (alexs@ulgsm.ru) Date: Thu Oct 29 13:28:12 2009 Subject: openldap unstable on freebsd In-Reply-To: <20091029123105.GA74611@mail.ulgsm.ru> References: <20091027082516.GA88892@mail.ulgsm.ru> <20091027085647.GT95002@e-Gitt.NET> <20091028055210.GA72197@mail.ulgsm.ru> <20091028101258.GA33200@mail.ulgsm.ru> <9345792F61634092B5DA5990B7529999@HS> <20091029123105.GA74611@mail.ulgsm.ru> Message-ID: <20091029132800.GA71226@mail.ulgsm.ru> * alexs@ulgsm.ru [2009-10-29 15:31:05 +0300]: > * Dewayne Geraghty [2009-10-29 10:39:22 +1100]: > > > Alexs, > > Thank-you. You seem to be using a default setup from ports. > > > > If you are using the same configuration files for slapd.conf and > > /var/openldap-data/DB_CONFIG files on the three operating systems, and FreeBSD > > isn't working, I'm struggling to think of any load induced problems that it > > might be from the information provided. Tested now on freebsd 8.0rc2 i386, slapd crashed after 10sec on stress load. -- Email: alexs@ulgsm.ru Email/Jabber: alexs@ulgsm.ru From O.Seibert at cs.ru.nl Thu Oct 29 13:52:42 2009 From: O.Seibert at cs.ru.nl (Olaf Seibert) Date: Thu Oct 29 13:52:52 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: References: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: <20091029135239.GX841@twoquid.cs.ru.nl> On Wed 28 Oct 2009 at 16:38:27 -0400, Rick Macklem wrote: > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) After writing, I realised that it is indeed perfectly allowed for the client to send data. But since the server already sent its FIN, it can't send anything more, not even an error message. So with that in mind, the client shouldn't send anything any more either. > If you could try the following patch and see if it helps, that would be > appreciated, rick Thanks, it looks like it should do the trick. I can't try it before monday, though. -Olaf. -- From tinderbox at freebsd.org Thu Oct 29 16:45:49 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Oct 29 16:46:01 2009 Subject: [releng_7 tinderbox] failure on powerpc/powerpc Message-ID: <20091029164546.1ACDC1B5060@freebsd-stable.sentex.ca> TB --- 2009-10-29 15:47:29 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-10-29 15:47:29 - starting RELENG_7 tinderbox run for powerpc/powerpc TB --- 2009-10-29 15:47:29 - cleaning the object tree TB --- 2009-10-29 15:48:02 - cvsupping the source tree TB --- 2009-10-29 15:48:02 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/powerpc/powerpc/supfile TB --- 2009-10-29 15:48:12 - building world TB --- 2009-10-29 15:48:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-29 15:48:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-29 15:48:12 - TARGET=powerpc TB --- 2009-10-29 15:48:12 - TARGET_ARCH=powerpc TB --- 2009-10-29 15:48:12 - TZ=UTC TB --- 2009-10-29 15:48:12 - __MAKE_CONF=/dev/null TB --- 2009-10-29 15:48:12 - cd /src TB --- 2009-10-29 15:48:12 - /usr/bin/make -B buildworld >>> World build started on Thu Oct 29 15:48:14 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/share/man/man9/BUF_LOCKINIT.9 > BUF_LOCKINIT.9.gz gzip -cn /src/share/man/man9/BUF_REFCNT.9 > BUF_REFCNT.9.gz gzip -cn /src/share/man/man9/BUF_TIMELOCK.9 > BUF_TIMELOCK.9.gz gzip -cn /src/share/man/man9/BUF_UNLOCK.9 > BUF_UNLOCK.9.gz gzip -cn /src/share/man/man9/bus_activate_resource.9 > bus_activate_resource.9.gz gzip -cn /src/share/man/man9/BUS_ADD_CHILD.9 > BUS_ADD_CHILD.9.gz gzip -cn /src/share/man/man9/bus_alloc_resource.9 > bus_alloc_resource.9.gz make: don't know how to make BUS_BIND_INTR.9. Stop *** Error code 2 Stop in /src/share/man. *** Error code 1 Stop in /src/share. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-29 16:45:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-29 16:45:45 - ERROR: failed to build world TB --- 2009-10-29 16:45:45 - 2966.82 user 298.38 system 3496.86 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-powerpc-powerpc.full From mav at FreeBSD.org Thu Oct 29 21:29:05 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Oct 29 21:29:23 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <1256768585.00177895.1256757002@10.7.7.3> References: <1256667780.00177464.1256654401@10.7.7.3> <1256728986.00177694.1256718601@10.7.7.3> <1256768585.00177895.1256757002@10.7.7.3> Message-ID: <4AEA091B.30304@FreeBSD.org> Jakub Lach wrote: > Yes, I tried tracing related changes to no avail, furthermore I didn't > change > anything related in my configuration. > > Dmesg gives some insight: > > hdac0: Tracing association 1 (2) > hdac0: Unable to trace pin 24 to ADC 20, undo traces > hdac0: Pin 24 traced to ADC 21 > hdac0: Unable to trace pin 29 to ADC 21, undo traces > hdac0: Association 1 (2) trace failed > > Full dmesg + sndstat > > http://senduit.com/8fdabe It tells that file has expired. -- Alexander Motin From areilly at bigpond.net.au Thu Oct 29 22:02:19 2009 From: areilly at bigpond.net.au (Andrew Reilly) Date: Thu Oct 29 22:02:26 2009 Subject: amd64/139859: commit references a PR In-Reply-To: <200910291550.n9TFo5wc035999@freefall.freebsd.org> References: <200910291550.n9TFo5wc035999@freefall.freebsd.org> Message-ID: <20091029220214.GA48360@duncan.reilly.home> On Thu, Oct 29, 2009 at 03:50:05PM +0000, dfilter service wrote: > Modified: releng/8.0/UPDATING > ============================================================================== > --- releng/8.0/UPDATING Thu Oct 29 15:39:30 2009 (r198605) > +++ releng/8.0/UPDATING Thu Oct 29 15:42:50 2009 (r198606) > @@ -566,6 +566,15 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 8. > userland (libpmc(3)) and the kernel module (hwpmc(4)) in > sync. > > +20081009: > + atapci kernel module now includes only generic PCI ATA > + driver. AHCI driver moved to ataahci kernel module. That probably wants to say 20091029? Cheers, -- Andrew From jakub_lach at mailplus.pl Thu Oct 29 23:05:34 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Thu Oct 29 23:05:42 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <4AEA091B.30304@FreeBSD.org> References: <26078773.post@talk.nabble.com> <4AEA091B.30304@FreeBSD.org> Message-ID: <26122214.post@talk.nabble.com> mav-3 wrote: > > Jakub Lach wrote: >> Yes, I tried tracing related changes to no avail, furthermore I didn't >> change >> anything related in my configuration. >> >> Dmesg gives some insight: >> >> hdac0: Tracing association 1 (2) >> hdac0: Unable to trace pin 24 to ADC 20, undo traces >> hdac0: Pin 24 traced to ADC 21 >> hdac0: Unable to trace pin 29 to ADC 21, undo traces >> hdac0: Association 1 (2) trace failed >> >> Full dmesg + sndstat >> >> http://senduit.com/8fdabe > > It tells that file has expired. > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > You mean that my device.hints file is no longer valid? What triggered it? -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26122214.html Sent from the freebsd-stable mailing list archive at Nabble.com. From cpghost at cordula.ws Thu Oct 29 23:47:11 2009 From: cpghost at cordula.ws (cpghost) Date: Thu Oct 29 23:47:18 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <26122214.post@talk.nabble.com> References: <26078773.post@talk.nabble.com> <4AEA091B.30304@FreeBSD.org> <26122214.post@talk.nabble.com> Message-ID: <20091029232917.GC1599@phenom.cordula.ws> On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: > mav-3 wrote: > > > > Jakub Lach wrote: > >> Yes, I tried tracing related changes to no avail, furthermore I didn't > >> change > >> anything related in my configuration. > >> > >> Dmesg gives some insight: > >> > >> hdac0: Tracing association 1 (2) > >> hdac0: Unable to trace pin 24 to ADC 20, undo traces > >> hdac0: Pin 24 traced to ADC 21 > >> hdac0: Unable to trace pin 29 to ADC 21, undo traces > >> hdac0: Association 1 (2) trace failed > >> > >> Full dmesg + sndstat > >> > >> http://senduit.com/8fdabe > > > > It tells that file has expired. > > > > -- > > Alexander Motin > > You mean that my device.hints file is no longer valid? > What triggered it? He meant, the hosting provider senduit.com has expired your dmesg + sndstat: File has expired The file you are trying to download has expired and is no longer available. Without dmesg + sndstat output, noone can debug your problem. > -best regards, > Jakub Lach Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From npapke at acm.org Fri Oct 30 05:24:23 2009 From: npapke at acm.org (Norbert Papke) Date: Fri Oct 30 05:24:30 2009 Subject: 7.2 Stable Crash - possibly related to if_re Message-ID: <200910292156.19845.npapke@acm.org> This occurred shortly after "scp"ing from a VirtualBox VM to the host. The file transfer got stuck. The "re" interface stopped working. Shortly afterwards, the host crashed. The "re" interface was used by the host, the guest was using a different NIC in bridged mode. FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 18:36:57 PDT 2009 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction pointer = 0x8:0xffffffff80d476ee stack pointer = 0x10:0xffffff8000078ae0 frame pointer = 0x10:0xffffff8000078b40 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 18 (swi5: +) Physical memory: 8177 MB (kgdb) bt #0 doadump () at pcpu.h:195 #1 0xffffffff801d5faf in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516 #2 0xffffffff801d64b9 in db_command (last_cmdp=0xffffffff80b46ac8, cmd_table=0x0, dopager=1) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413 #3 0xffffffff801d66bb in db_command_loop () at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466 #4 0xffffffff801d8197 in db_trap (type=Variable "type" is not available. ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228 #5 0xffffffff8054ab45 in kdb_trap (type=12, code=0, tf=0xffffff8000078a30) at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 #6 0xffffffff807fcdd3 in trap_fatal (frame=0xffffff8000078a30, eva=Variable "eva" is not available. ) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772 #7 0xffffffff807fd185 in trap_pfault (frame=0xffffff8000078a30, usermode=0) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693 #8 0xffffffff807fd9bd in trap (frame=0xffffff8000078a30) at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464 #9 0xffffffff807e710e in calltrap () at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. ) at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 #12 0xffffffff80554d46 in taskqueue_run (queue=0xffffff000192f300) at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282 #13 0xffffffff804fbc1d in ithread_loop (arg=0xffffff00019433a0) at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126 #14 0xffffffff804f83c4 in fork_exit (callout=0xffffffff804fbaa5 , arg=0xffffff00019433a0, frame=0xffffff8000078c80) at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811 #15 0xffffffff807e74ee in fork_trampoline () at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554 From dmesg: re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:30:48:b0:6a:1f -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From bruce at cran.org.uk Fri Oct 30 06:05:48 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Fri Oct 30 06:05:55 2009 Subject: amd64/139859: commit references a PR In-Reply-To: <20091029220214.GA48360@duncan.reilly.home> References: <200910291550.n9TFo5wc035999@freefall.freebsd.org> <20091029220214.GA48360@duncan.reilly.home> Message-ID: <20091030060513.0000503b@unknown> On Fri, 30 Oct 2009 09:02:14 +1100 Andrew Reilly wrote: > On Thu, Oct 29, 2009 at 03:50:05PM +0000, dfilter service wrote: > > Modified: releng/8.0/UPDATING > > ============================================================================== > > --- releng/8.0/UPDATING Thu Oct 29 15:39:30 2009 > > (r198605) +++ releng/8.0/UPDATING Thu Oct 29 15:42:50 > > 2009 (r198606) @@ -566,6 +566,15 @@ NOTE TO PEOPLE WHO THINK > > THAT FreeBSD 8. userland (libpmc(3)) and the kernel module > > (hwpmc(4)) in sync. > > > > +20081009: > > + atapci kernel module now includes only generic PCI ATA > > + driver. AHCI driver moved to ataahci kernel module. > > That probably wants to say 20091029? The work was done in October last year (see http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/chipsets/ata-acard.c) but wasn't documented until now. -- Bruce Cran From jakub_lach at mailplus.pl Fri Oct 30 07:49:17 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Fri Oct 30 07:49:33 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <20091029232917.GC1599@phenom.cordula.ws> References: <26078773.post@talk.nabble.com> <4AEA091B.30304@FreeBSD.org> <26122214.post@talk.nabble.com> <20091029232917.GC1599@phenom.cordula.ws> Message-ID: <26126133.post@talk.nabble.com> cpghost wrote: > > On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: >> mav-3 wrote: >> > >> > Jakub Lach wrote: >> >> Yes, I tried tracing related changes to no avail, furthermore I didn't >> >> change >> >> anything related in my configuration. >> >> >> >> Dmesg gives some insight: >> >> >> >> hdac0: Tracing association 1 (2) >> >> hdac0: Unable to trace pin 24 to ADC 20, undo traces >> >> hdac0: Pin 24 traced to ADC 21 >> >> hdac0: Unable to trace pin 29 to ADC 21, undo traces >> >> hdac0: Association 1 (2) trace failed >> >> >> >> Full dmesg + sndstat >> >> >> >> http://senduit.com/8fdabe >> > >> > It tells that file has expired. >> > >> > -- >> > Alexander Motin >> >> You mean that my device.hints file is no longer valid? >> What triggered it? > > He meant, the hosting provider senduit.com has expired your > dmesg + sndstat: > > File has expired > The file you are trying to download has expired and is no longer > available. > > Without dmesg + sndstat output, noone can debug your problem. > >> -best regards, >> Jakub Lach > > Regards, > -cpghost. > > -- > Cordula's Web. http://www.cordula.ws/ > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > I'm really sorry. http://senduit.com/55d199 -best regards, Jakub Lach -- View this message in context: http://old.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26126133.html Sent from the freebsd-stable mailing list archive at Nabble.com. From tinderbox at freebsd.org Fri Oct 30 08:48:32 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Oct 30 08:48:43 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 Message-ID: <20091030084829.525521B5060@freebsd-stable.sentex.ca> TB --- 2009-10-30 07:41:34 - tinderbox 2.6 running on freebsd-stable.sentex.ca TB --- 2009-10-30 07:41:34 - starting RELENG_7 tinderbox run for i386/pc98 TB --- 2009-10-30 07:41:34 - cleaning the object tree TB --- 2009-10-30 07:42:00 - cvsupping the source tree TB --- 2009-10-30 07:42:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile TB --- 2009-10-30 07:42:12 - building world TB --- 2009-10-30 07:42:12 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-30 07:42:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-30 07:42:12 - TARGET=pc98 TB --- 2009-10-30 07:42:12 - TARGET_ARCH=i386 TB --- 2009-10-30 07:42:12 - TZ=UTC TB --- 2009-10-30 07:42:12 - __MAKE_CONF=/dev/null TB --- 2009-10-30 07:42:12 - cd /src TB --- 2009-10-30 07:42:12 - /usr/bin/make -B buildworld >>> World build started on Fri Oct 30 07:42:13 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Oct 30 08:46:35 UTC 2009 TB --- 2009-10-30 08:46:35 - generating LINT kernel config TB --- 2009-10-30 08:46:35 - cd /src/sys/pc98/conf TB --- 2009-10-30 08:46:35 - /usr/bin/make -B LINT TB --- 2009-10-30 08:46:36 - building LINT kernel TB --- 2009-10-30 08:46:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-10-30 08:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-10-30 08:46:36 - TARGET=pc98 TB --- 2009-10-30 08:46:36 - TARGET_ARCH=i386 TB --- 2009-10-30 08:46:36 - TZ=UTC TB --- 2009-10-30 08:46:36 - __MAKE_CONF=/dev/null TB --- 2009-10-30 08:46:36 - cd /src TB --- 2009-10-30 08:46:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Oct 30 08:46:36 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand ing /src/sys/i386/i386/mp_machdep.c:76:25: error: machine/mca.h: No such file or directory /src/sys/i386/i386/trap.c:93:25: error: machine/mca.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-10-30 08:48:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-10-30 08:48:29 - ERROR: failed to build lint kernel TB --- 2009-10-30 08:48:29 - 3300.35 user 359.48 system 4014.80 real http://tinderbox.freebsd.org/tinderbox-releng_7-RELENG_7-i386-pc98.full From pluknet at gmail.com Fri Oct 30 09:12:45 2009 From: pluknet at gmail.com (pluknet) Date: Fri Oct 30 09:12:53 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 In-Reply-To: <20091030084829.525521B5060@freebsd-stable.sentex.ca> References: <20091030084829.525521B5060@freebsd-stable.sentex.ca> Message-ID: 2009/10/30 FreeBSD Tinderbox : > TB --- 2009-10-30 07:41:34 - tinderbox 2.6 running on freebsd-stable.sentex.ca > TB --- 2009-10-30 07:41:34 - starting RELENG_7 tinderbox run for i386/pc98 > TB --- 2009-10-30 07:41:34 - cleaning the object tree > TB --- 2009-10-30 07:42:00 - cvsupping the source tree > TB --- 2009-10-30 07:42:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile > TB --- 2009-10-30 07:42:12 - building world > TB --- 2009-10-30 07:42:12 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-10-30 07:42:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-30 07:42:12 - TARGET=pc98 > TB --- 2009-10-30 07:42:12 - TARGET_ARCH=i386 > TB --- 2009-10-30 07:42:12 - TZ=UTC > TB --- 2009-10-30 07:42:12 - __MAKE_CONF=/dev/null > TB --- 2009-10-30 07:42:12 - cd /src > TB --- 2009-10-30 07:42:12 - /usr/bin/make -B buildworld >>>> World build started on Fri Oct 30 07:42:13 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> World build completed on Fri Oct 30 08:46:35 UTC 2009 > TB --- 2009-10-30 08:46:35 - generating LINT kernel config > TB --- 2009-10-30 08:46:35 - cd /src/sys/pc98/conf > TB --- 2009-10-30 08:46:35 - /usr/bin/make -B LINT > TB --- 2009-10-30 08:46:36 - building LINT kernel > TB --- 2009-10-30 08:46:36 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-10-30 08:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-10-30 08:46:36 - TARGET=pc98 > TB --- 2009-10-30 08:46:36 - TARGET_ARCH=i386 > TB --- 2009-10-30 08:46:36 - TZ=UTC > TB --- 2009-10-30 08:46:36 - __MAKE_CONF=/dev/null > TB --- 2009-10-30 08:46:36 - cd /src > TB --- 2009-10-30 08:46:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>>> Kernel build for LINT started on Fri Oct 30 08:46:36 UTC 2009 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies > [...] > awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h > awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h > awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h > rm -f .newdep > /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | ?MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing ?-std=c99 ?-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes ?-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ?-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc ?-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 ?-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand > ?ing > /src/sys/i386/i386/mp_machdep.c:76:25: error: machine/mca.h: No such file or directory > /src/sys/i386/i386/trap.c:93:25: error: machine/mca.h: No such file or directory > mkdep: compile failed MFC r192106 ? -- wbr, pluknet From mav at FreeBSD.org Fri Oct 30 12:52:23 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Oct 30 12:52:31 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <1256901782.00178420.1256889004@10.7.7.3> References: <1256667780.00177464.1256654401@10.7.7.3> <1256865780.00178296.1256852401@10.7.7.3> <1256869384.00178335.1256857801@10.7.7.3> <1256872982.00178351.1256860203@10.7.7.3> <1256901782.00178420.1256889004@10.7.7.3> Message-ID: <4AEAE181.1050304@FreeBSD.org> Jakub Lach wrote: > cpghost wrote: >> On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: >>> mav-3 wrote: >>>> Jakub Lach wrote: >>>>> Yes, I tried tracing related changes to no avail, furthermore I didn't >>>>> change >>>>> anything related in my configuration. >>>>> >>>>> Dmesg gives some insight: >>>>> >>>>> hdac0: Tracing association 1 (2) >>>>> hdac0: Unable to trace pin 24 to ADC 20, undo traces >>>>> hdac0: Pin 24 traced to ADC 21 >>>>> hdac0: Unable to trace pin 29 to ADC 21, undo traces >>>>> hdac0: Association 1 (2) trace failed >>>>> >>>>> Full dmesg + sndstat >>>>> > http://senduit.com/55d199 I don't know how it could work before, as looks like this codec unable to pass both mics to the same ADC. Also you seems not configured audio redirection. I would propose you such configuration with redirection: hint.hdac.0.cad0.nid22.config="as=1 seq=15" hint.hdac.0.cad0.nid24.config="as=3" hint.hdac.0.cad0.nid26.config="as=1" hint.hdac.0.cad0.nid29.config="as=2" or such with two separate pcm devices: hint.hdac.0.cad0.nid22.config="as=3" hint.hdac.0.cad0.nid24.config="as=4" hint.hdac.0.cad0.nid26.config="as=1" hint.hdac.0.cad0.nid29.config="as=2" -- Alexander Motin From jakub_lach at mailplus.pl Fri Oct 30 16:01:00 2009 From: jakub_lach at mailplus.pl (Jakub Lach) Date: Fri Oct 30 16:01:07 2009 Subject: No sound after update to RC2 from RC1. In-Reply-To: <4AEAE181.1050304@FreeBSD.org> References: <26078773.post@talk.nabble.com> <4AEAE181.1050304@FreeBSD.org> Message-ID: <26132631.post@talk.nabble.com> mav-3 wrote: > > Jakub Lach wrote: >> cpghost wrote: >>> On Thu, Oct 29, 2009 at 04:05:33PM -0700, Jakub Lach wrote: >>>> mav-3 wrote: >>>>> Jakub Lach wrote: >>>>>> Yes, I tried tracing related changes to no avail, furthermore I >>>>>> didn't >>>>>> change >>>>>> anything related in my configuration. >>>>>> >>>>>> Dmesg gives some insight: >>>>>> >>>>>> hdac0: Tracing association 1 (2) >>>>>> hdac0: Unable to trace pin 24 to ADC 20, undo traces >>>>>> hdac0: Pin 24 traced to ADC 21 >>>>>> hdac0: Unable to trace pin 29 to ADC 21, undo traces >>>>>> hdac0: Association 1 (2) trace failed >>>>>> >>>>>> Full dmesg + sndstat >>>>>> >> http://senduit.com/55d199 > > I don't know how it could work before, as looks like this codec unable > to pass both mics to the same ADC. Also you seems not configured audio > redirection. > > I would propose you such configuration with redirection: > > hint.hdac.0.cad0.nid22.config="as=1 seq=15" > hint.hdac.0.cad0.nid24.config="as=3" > hint.hdac.0.cad0.nid26.config="as=1" > hint.hdac.0.cad0.nid29.config="as=2" > > or such with two separate pcm devices: > > hint.hdac.0.cad0.nid22.config="as=3" > hint.hdac.0.cad0.nid24.config="as=4" > hint.hdac.0.cad0.nid26.config="as=1" > hint.hdac.0.cad0.nid29.config="as=2" > > -- > Alexander Motin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Thank you for your kind support. Still no sound. http://senduit.com/d3a51b http://senduit.com/873ec6 I admit that I didn't study with required diligence device.hints hda configuration, however I copied one which worked for L. Windschuh, and he uses very similar laptop. -best regards, Jakub Lach -- View this message in context: http://old.nabble.com/No-sound-after-update-to-RC2-from-RC1.-tp26078773p26132631.html Sent from the freebsd-stable mailing list archive at Nabble.com. From hausen at punkt.de Fri Oct 30 16:01:19 2009 From: hausen at punkt.de (Patrick M. Hausen) Date: Fri Oct 30 16:01:25 2009 Subject: boot0cfg and gmirror again Message-ID: <20091030160115.GB81189@hugo10.ka.punkt.de> Hi, all, Our hosting servers use a NanoBSD disk layout for rapid updates and - if necessary - fallback to the former working version of the system. I just tested the update from RELENG_6_3 to RELENG_7_2, because I was concerned about the one-way upgrade of the on disk data for gmirror. That part went great. We are, however, still struggling to autmatically switch the active partititon after dd'ing an update to the inactive one: new_server# uname -a FreeBSD new_server 7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4 #0: Fri Oct 30 14:49:14 CET 2009 root@nanobsd.ka.punkt.de:/var/home/nanobsd/obj/rx100s5-hosting/usr/src/sys/GENERIC amd64 new_server# gmirror status Name Status Components mirror/m0 COMPLETE ad4 ad6 new_server# fdisk /dev/mirror/m0 ******* Working on device /dev/mirror/m0 ******* parameters extracted from in-core disklabel are: cylinders=30401 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=30401 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16065, size 16418430 (8016 Meg), flag 0 beg: cyl 1/ head 0/ sector 1; end: cyl 1022/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 16434495, size 16418430 (8016 Meg), flag 80 (active) beg: cyl 1023/ head 0/ sector 1; end: cyl 1020/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 32852925, size 455539140 (222431 Meg), flag 0 beg: cyl 1021/ head 0/ sector 1; end: cyl 704/ head 254/ sector 63 The data for partition 4 is: new_server# mount /dev/mirror/m0s2a on / (ufs, local, read-only) devfs on /dev (devfs, local) /dev/mirror/m0s3a on /etc (ufs, local) /dev/mirror/m0s3d on /var (ufs, local, soft-updates) That's the status of the system, now let's try to activate partition 1: new_server# sysctl kern.geom.debugflags=0x10 kern.geom.debugflags: 0 -> 16 new_server# boot0cfg -v -s1 /dev/mirror/m0 boot0cfg: /dev/mirror/m0: Geom not found: "m0" boot0cfg: /dev/mirror/m0: ioctl DIOCSMBR: Operation not permitted Now, what? This was discussed here, already, and I got the impression that a solution was to be in RELENG_7: http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044487.html Tanks for any insight. Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: J?rgen Egeling AG Mannheim 108285 From pyunyh at gmail.com Fri Oct 30 16:54:51 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Oct 30 16:55:04 2009 Subject: 7.2 Stable Crash - possibly related to if_re In-Reply-To: <200910292156.19845.npapke@acm.org> References: <200910292156.19845.npapke@acm.org> Message-ID: <20091030165451.GA17243@michelle.cdnetworks.com> On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > This occurred shortly after "scp"ing from a VirtualBox VM to the host. The > file transfer got stuck. The "re" interface stopped working. Shortly > afterwards, the host crashed. The "re" interface was used by the host, the > guest was using a different NIC in bridged mode. > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > 18:36:57 PDT 2009 > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 It looks like a NULL pointer dereference, possibly mbuf related one. > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff80d476ee > stack pointer = 0x10:0xffffff8000078ae0 > frame pointer = 0x10:0xffffff8000078b40 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 18 (swi5: +) > Physical memory: 8177 MB > > > (kgdb) bt > #0 doadump () at pcpu.h:195 > #1 0xffffffff801d5faf in db_fncall (dummy1=Variable "dummy1" is not > available. > ) at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:516 > #2 0xffffffff801d64b9 in db_command (last_cmdp=0xffffffff80b46ac8, > cmd_table=0x0, dopager=1) > at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:413 > #3 0xffffffff801d66bb in db_command_loop () > at /usr/public/freebsd/sources/stable/sys/ddb/db_command.c:466 > #4 0xffffffff801d8197 in db_trap (type=Variable "type" is not available. > ) at /usr/public/freebsd/sources/stable/sys/ddb/db_main.c:228 > #5 0xffffffff8054ab45 in kdb_trap (type=12, code=0, tf=0xffffff8000078a30) > at /usr/public/freebsd/sources/stable/sys/kern/subr_kdb.c:524 > #6 0xffffffff807fcdd3 in trap_fatal (frame=0xffffff8000078a30, > eva=Variable "eva" is not available. > ) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:772 > #7 0xffffffff807fd185 in trap_pfault (frame=0xffffff8000078a30, usermode=0) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:693 > #8 0xffffffff807fd9bd in trap (frame=0xffffff8000078a30) > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/trap.c:464 > #9 0xffffffff807e710e in calltrap () > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko Hmm, I think there is a missing information here. Not sure where it dereferenced a NULL pointer in re_rxeof(). Because that this is the first report for NULL pointer dereference in Rx handler I need more information how to reproduce it with minimal configuration. Can you also reproduce the issues without virtual box? By chance, did you stop the re0 interface with ifconfig when you noticed the file transfer got stuck? > #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. > ) > > at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 > #12 0xffffffff80554d46 in taskqueue_run (queue=0xffffff000192f300) > at /usr/public/freebsd/sources/stable/sys/kern/subr_taskqueue.c:282 > #13 0xffffffff804fbc1d in ithread_loop (arg=0xffffff00019433a0) > at /usr/public/freebsd/sources/stable/sys/kern/kern_intr.c:1126 > #14 0xffffffff804f83c4 in fork_exit (callout=0xffffffff804fbaa5 > , arg=0xffffff00019433a0, > frame=0xffffff8000078c80) > at /usr/public/freebsd/sources/stable/sys/kern/kern_fork.c:811 > #15 0xffffffff807e74ee in fork_trampoline () > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:554 > From tiago.s.araujo at gmail.com Fri Oct 30 18:39:56 2009 From: tiago.s.araujo at gmail.com (Tiago Araujo) Date: Fri Oct 30 18:40:03 2009 Subject: Adding Me for Maillist (Freebsd) Please Message-ID: <4aeb2bec.e701be0a.771c.ffffa8bd@mx.google.com> Dear, Please.... Add for me in mail list! Att, Tiago Araujo Manage Administrator From jhb at freebsd.org Fri Oct 30 19:26:17 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 30 19:26:24 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 In-Reply-To: References: <20091030084829.525521B5060@freebsd-stable.sentex.ca> Message-ID: <200910301507.29875.jhb@freebsd.org> On Friday 30 October 2009 5:12:43 am pluknet wrote: > 2009/10/30 FreeBSD Tinderbox : > > TB --- 2009-10-30 07:41:34 - tinderbox 2.6 running on freebsd-stable.sentex.ca > > TB --- 2009-10-30 07:41:34 - starting RELENG_7 tinderbox run for i386/pc98 > > TB --- 2009-10-30 07:41:34 - cleaning the object tree > > TB --- 2009-10-30 07:42:00 - cvsupping the source tree > > TB --- 2009-10-30 07:42:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile > > TB --- 2009-10-30 07:42:12 - building world > > TB --- 2009-10-30 07:42:12 - MAKEOBJDIRPREFIX=/obj > > TB --- 2009-10-30 07:42:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2009-10-30 07:42:12 - TARGET=pc98 > > TB --- 2009-10-30 07:42:12 - TARGET_ARCH=i386 > > TB --- 2009-10-30 07:42:12 - TZ=UTC > > TB --- 2009-10-30 07:42:12 - __MAKE_CONF=/dev/null > > TB --- 2009-10-30 07:42:12 - cd /src > > TB --- 2009-10-30 07:42:12 - /usr/bin/make -B buildworld > >>>> World build started on Fri Oct 30 07:42:13 UTC 2009 > >>>> Rebuilding the temporary build tree > >>>> stage 1.1: legacy release compatibility shims > >>>> stage 1.2: bootstrap tools > >>>> stage 2.1: cleaning up the object tree > >>>> stage 2.2: rebuilding the object tree > >>>> stage 2.3: build tools > >>>> stage 3: cross tools > >>>> stage 4.1: building includes > >>>> stage 4.2: building libraries > >>>> stage 4.3: make dependencies > >>>> stage 4.4: building everything > >>>> World build completed on Fri Oct 30 08:46:35 UTC 2009 > > TB --- 2009-10-30 08:46:35 - generating LINT kernel config > > TB --- 2009-10-30 08:46:35 - cd /src/sys/pc98/conf > > TB --- 2009-10-30 08:46:35 - /usr/bin/make -B LINT > > TB --- 2009-10-30 08:46:36 - building LINT kernel > > TB --- 2009-10-30 08:46:36 - MAKEOBJDIRPREFIX=/obj > > TB --- 2009-10-30 08:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2009-10-30 08:46:36 - TARGET=pc98 > > TB --- 2009-10-30 08:46:36 - TARGET_ARCH=i386 > > TB --- 2009-10-30 08:46:36 - TZ=UTC > > TB --- 2009-10-30 08:46:36 - __MAKE_CONF=/dev/null > > TB --- 2009-10-30 08:46:36 - cd /src > > TB --- 2009-10-30 08:46:36 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>>> Kernel build for LINT started on Fri Oct 30 08:46:36 UTC 2009 > >>>> stage 1: configuring the kernel > >>>> stage 2.1: cleaning up the object tree > >>>> stage 2.2: rebuilding the object tree > >>>> stage 2.3: build tools > >>>> stage 3.1: making dependencies > > [...] > > awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h > > awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h > > awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h > > rm -f .newdep > > /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | ?MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing ?-std=c99 ?-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes ?-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ?-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc ?-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 ?-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand > > ?ing > > /src/sys/i386/i386/mp_machdep.c:76:25: error: machine/mca.h: No such file or directory > > /src/sys/i386/i386/trap.c:93:25: error: machine/mca.h: No such file or directory > > mkdep: compile failed > > MFC r192106 ? Doh, yes. Will fix it in a bit. -- John Baldwin From jhb at freebsd.org Fri Oct 30 19:26:17 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 30 19:26:36 2009 Subject: [releng_7 tinderbox] failure on i386/pc98 In-Reply-To: References: <20091030084829.525521B5060@freebsd-stable.sentex.ca> Message-ID: <200910301507.29875.jhb@freebsd.org> On Friday 30 October 2009 5:12:43 am pluknet wrote: > 2009/10/30 FreeBSD Tinderbox : > > TB --- 2009-10-30 07:41:34 - tinderbox 2.6 running on freebsd-stable.sentex.ca > > TB --- 2009-10-30 07:41:34 - starting RELENG_7 tinderbox run for i386/pc98 > > TB --- 2009-10-30 07:41:34 - cleaning the object tree > > TB --- 2009-10-30 07:42:00 - cvsupping the source tree > > TB --- 2009-10-30 07:42:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_7/i386/pc98/supfile > > TB --- 2009-10-30 07:42:12 - building world > > TB --- 2009-10-30 07:42:12 - MAKEOBJDIRPREFIX=/obj > > TB --- 2009-10-30 07:42:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2009-10-30 07:42:12 - TARGET=pc98 > > TB --- 2009-10-30 07:42:12 - TARGET_ARCH=i386 > > TB --- 2009-10-30 07:42:12 - TZ=UTC > > TB --- 2009-10-30 07:42:12 - __MAKE_CONF=/dev/null > > TB --- 2009-10-30 07:42:12 - cd /src > > TB --- 2009-10-30 07:42:12 - /usr/bin/make -B buildworld > >>>> World build started on Fri Oct 30 07:42:13 UTC 2009 > >>>> Rebuilding the temporary build tree > >>>> stage 1.1: legacy release compatibility shims > >>>> stage 1.2: bootstrap tools > >>>> stage 2.1: cleaning up the object tree > >>>> stage 2.2: rebuilding the object tree > >>>> stage 2.3: build tools > >>>> stage 3: cross tools > >>>> stage 4.1: building includes > >>>> stage 4.2: building libraries > >>>> stage 4.3: make dependencies > >>>> stage 4.4: building everything > >>>> World build completed on Fri Oct 30 08:46:35 UTC 2009 > > TB --- 2009-10-30 08:46:35 - generating LINT kernel config > > TB --- 2009-10-30 08:46:35 - cd /src/sys/pc98/conf > > TB --- 2009-10-30 08:46:35 - /usr/bin/make -B LINT > > TB --- 2009-10-30 08:46:36 - building LINT kernel > > TB --- 2009-10-30 08:46:36 - MAKEOBJDIRPREFIX=/obj > > TB --- 2009-10-30 08:46:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > > TB --- 2009-10-30 08:46:36 - TARGET=pc98 > > TB --- 2009-10-30 08:46:36 - TARGET_ARCH=i386 > > TB --- 2009-10-30 08:46:36 - TZ=UTC > > TB --- 2009-10-30 08:46:36 - __MAKE_CONF=/dev/null > > TB --- 2009-10-30 08:46:36 - cd /src > > TB --- 2009-10-30 08:46:36 - /usr/bin/make -B buildkernel KERNCONF=LINT > >>>> Kernel build for LINT started on Fri Oct 30 08:46:36 UTC 2009 > >>>> stage 1: configuring the kernel > >>>> stage 2.1: cleaning up the object tree > >>>> stage 2.2: rebuilding the object tree > >>>> stage 2.3: build tools > >>>> stage 3.1: making dependencies > > [...] > > awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h > > awk -f /src/sys/tools/makeobjops.awk /src/sys/pci/agp_if.m -h > > awk -f /src/sys/tools/makeobjops.awk /src/sys/pc98/pc98/canbus_if.m -h > > rm -f .newdep > > /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | ?MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing ?-std=c99 ?-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes ?-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual ?-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc ?-I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 ?-mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand > > ?ing > > /src/sys/i386/i386/mp_machdep.c:76:25: error: machine/mca.h: No such file or directory > > /src/sys/i386/i386/trap.c:93:25: error: machine/mca.h: No such file or directory > > mkdep: compile failed > > MFC r192106 ? Doh, yes. Will fix it in a bit. -- John Baldwin From rmacklem at uoguelph.ca Fri Oct 30 20:09:02 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Oct 30 20:09:09 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: <20091029135239.GX841@twoquid.cs.ru.nl> References: <20091027164159.GU841@twoquid.cs.ru.nl> <20091029135239.GX841@twoquid.cs.ru.nl> Message-ID: On Thu, 29 Oct 2009, Olaf Seibert wrote: > > After writing, I realised that it is indeed perfectly allowed for the > client to send data. But since the server already sent its FIN, it can't > send anything more, not even an error message. So with that in mind, the > client shouldn't send anything any more either. > Here is what I am seeing without and with the patch. The client is a pretty recent FreeBSD-CURRENT (nfsv4-test) and the server Solaris10 (nfsv4-solaris). I don't get the 5 minute reconnect delay without the patch. I think the reason is that the resets (Rst's) "inspire" the FreeBSD-CURRENT TCP to do the new connection. (I don't remember seeing any RSTs in your tcpdump?) I deleted a few irrelevant lines (packets not between nfsv4-test and nfsv4-solaris), which is why the packet #s aren't contiguous. (and appologies for the long lines) Hopefully someone with TCP expertise will know if the RSTs are done correctly and whether or not your server should be generating them. After the patch things look fine to me. Hopefully your (and others) testing will go ok. Snoop trace without the patch (what FreeBSD-CURRENT will do now): 2 209.18617 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=699 S=2049 Fin Ack=1066292217 Seq=1580479914 Len=0 Win=49232 Options= 3 209.18645 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Ack=1580479915 Seq=1066292217 Len=0 Win=16588 Options= 4 209.18656 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Rst Ack=1580479915 Seq=1066292217 Len=0 Win=0 5 209.18662 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=699 Rst Ack=1580479915 Seq=1066292217 Len=0 Win=0 7 528.97250 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 8 528.97261 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=699 S=2049 Rst Seq=1580479915 Len=0 Win=0 9 528.97311 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Syn Seq=3293207355 Len=0 Win=65535 Options= 10 528.97329 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=818 S=2049 Syn Ack=3293207356 Seq=1757551152 Len=0 Win=49232 Options= 11 528.97354 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Ack=1757551153 Seq=3293207356 Len=0 Win=8326 Options= 12 528.97375 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 13 528.97382 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Rst Ack=1757551153 Seq=3293207356 Len=0 Win=0 14 528.97439 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=818 S=2049 Ack=3293207488 Seq=1757551153 Len=0 Win=49100 Options= 15 528.97524 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 16 529.07565 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=818 Ack=1757551325 Seq=3293207488 Len=0 Win=16588 Options= and what happens after the patch is applied: 6 1.35481 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 7 1.35516 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 8 1.45564 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Ack=2612339569 Seq=837212133 Len=0 Win=16588 Options= 9 361.34400 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=651 S=2049 Fin Ack=837212133 Seq=2612339569 Len=0 Win=49232 Options= 10 361.34434 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Ack=2612339570 Seq=837212133 Len=0 Win=16588 Options= 11 361.34441 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Rst Ack=2612339570 Seq=837212133 Len=0 Win=0 12 361.34447 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=651 Rst Ack=2612339570 Seq=837212133 Len=0 Win=0 14 501.80966 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Syn Seq=1926848102 Len=0 Win=65535 Options= 15 501.80979 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=881 S=2049 Syn Ack=1926848103 Seq=2754679721 Len=0 Win=49232 Options= 16 501.81006 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Ack=2754679722 Seq=1926848103 Len=0 Win=8326 Options= 17 501.81024 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 18 501.81089 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=881 S=2049 Ack=1926848235 Seq=2754679722 Len=0 Win=49100 Options= 19 501.81169 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 20 501.91218 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=881 Ack=2754679894 Seq=1926848235 Len=0 Win=16588 Options= Anyone with TCP expertise have opinions on these? rick From jhell at DataIX.net Fri Oct 30 20:35:54 2009 From: jhell at DataIX.net (jhell) Date: Fri Oct 30 20:36:01 2009 Subject: Adding Me for Maillist (Freebsd) Please In-Reply-To: <4aeb2bec.e701be0a.771c.ffffa8bd@mx.google.com> References: <4aeb2bec.e701be0a.771c.ffffa8bd@mx.google.com> Message-ID: On Fri, 30 Oct 2009 14:09, tiago.s.araujo@ wrote: > Dear, > > > > Please.... Add for me in mail list! > > > > Att, > > Tiago Araujo > > Manage Administrator > > > > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > All the info you need is right here: http://lists.freebsd.org/ -- Fri Oct 30 16:35:10 2009 -0500 jhell From meme at yahoo-inc.com Fri Oct 30 21:40:56 2009 From: meme at yahoo-inc.com (meme@yahoo-inc.com) Date: Fri Oct 30 21:41:02 2009 Subject: =?utf-8?q?Voc=C3=AA_foi_convidado_para_usar_o_Meme?= Message-ID: <20091030214055.EF806106568D@hub.freebsd.org> Ol?, freebsd-stable@freebsd.org! Template Para Todos te convidou para usar o Meme. Ele ? o seu espa?o para compartilhar com o mundo tudo o que voc? encontrar de interessante. O Meme ainda est? em desenvolvimento e adorar?amos a sua colabora??o para constru?-lo junto com a gente. Use o endere?o abaixo para receber seu convite: http://meme.yahoo.com/invited/ Depois de se inscrever, confira o meme de Template Para Todos: http://meme.yahoo.com/templateparatodos/ Nos vemos l?, Meme, do Yahoo! http://meme.yahoo.com From npapke at acm.org Sat Oct 31 01:23:52 2009 From: npapke at acm.org (Norbert Papke) Date: Sat Oct 31 01:23:59 2009 Subject: 7.2 Stable Crash - possibly related to if_re In-Reply-To: <20091030165451.GA17243@michelle.cdnetworks.com> References: <200910292156.19845.npapke@acm.org> <20091030165451.GA17243@michelle.cdnetworks.com> Message-ID: <200910301823.51274.npapke@acm.org> On October 30, 2009, Pyun YongHyeon wrote: > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > This occurred shortly after "scp"ing from a VirtualBox VM to the host. > > The file transfer got stuck. The "re" interface stopped working. > > Shortly afterwards, the host crashed. The "re" interface was used by the > > host, the guest was using a different NIC in bridged mode. > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > > 18:36:57 PDT 2009 > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0x18 > > It looks like a NULL pointer dereference, possibly mbuf related > one. > > > fault code = supervisor write data, page not present > > instruction pointer = 0x8:0xffffffff80d476ee > > stack pointer = 0x10:0xffffff8000078ae0 > > frame pointer = 0x10:0xffffff8000078b40 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 18 (swi5: +) > > Physical memory: 8177 MB > > > > > > #9 0xffffffff807e710e in calltrap () > > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko > > Hmm, I think there is a missing information here. Not sure where it > dereferenced a NULL pointer in re_rxeof(). >> #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. >> ) >> at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 I am not sure how much I trust frame 10. The instruction at "0xffffffff80d476ee" is the one after the "retq" from re_rxeof(). Frame 11 seems OK to me. The "struct rl_softc*", in particular, looks plausible but I don't know enough to say for sure. > Because that this is the > first report for NULL pointer dereference in Rx handler I need more > information how to reproduce it with minimal configuration. Can you > also reproduce the issues without virtual box? I am trying but no luck so far. > By chance, did you stop the re0 interface with ifconfig when you > noticed the file transfer got stuck? It is possible. I had it happen twice. The first time I definitely tried to "down" re. I cannot recall what I did the second time. The crash dump is from the second time. Thanks very much for the response. I'll try to come up with a better test case. If I succeed, I will report back. Cheers, -- Norbert Papke. npapke@acm.org http://saveournet.ca Protecting your Internet's level playing field From danny at cs.huji.ac.il Sat Oct 31 09:16:35 2009 From: danny at cs.huji.ac.il (Daniel Braniss) Date: Sat Oct 31 09:16:48 2009 Subject: 8.0-RC1 NFS client timeout issue In-Reply-To: References: <20091027164159.GU841@twoquid.cs.ru.nl> Message-ID: > > First off, I know that cross posting is evil, but I wanted to try > and make sure developers saw it. > > On Tue, 27 Oct 2009, Olaf Seibert wrote: > > > I see an annoying behaviour with NFS over TCP. It happens both with nfs > > and newnfs. This is with FreeBSD/amd64 8.0-RC1 as client. The server is > > some Linux or perhaps Solaris, I'm not entirely sure. > > > > After trying to find something in packet traces, I think I have found > > something. > > > > The scenario seems to be as follows. Sorry for the width of the lines. > > > > > > No. Time Source Destination Protocol Info > > 2296 2992.216855 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2297), DH:0x3819da36/w > > 2297 2992.217107 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2296) Error:NFS3ERR_NOENT > > 2298 2992.217141 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2299), DH:0x170cb16a/bin > > 2299 2992.217334 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2298), FH:0x61b8eb12 > > 2300 2992.217361 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call (Reply In 2301), FH:0x61b8eb12 > > 2301 2992.217582 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 ACCESS Reply (Call In 2300) > > 2302 2992.217605 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 LOOKUP Call (Reply In 2303), DH:0x61b8eb12/w > > 2303 2992.217860 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 LOOKUP Reply (Call In 2302) Error:NFS3ERR_NOENT > > 2304 2992.318770 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238293 Ack=230289 Win=8192 Len=0 TSV=86492342 TSER=12393434 > > 2306 3011.537520 xxx.xxx.16.142 xxx.xxx.31.43 NFS V3 GETATTR Reply (Call In 2305) Directory mode:2755 uid:4100 gid:4100 > > 2307 3011.637744 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230405 Win=8192 Len=0 TSV=86511662 TSER=12395366 > > 2308 3371.534980 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [FIN, ACK] Seq=230405 Ack=238429 Win=49232 Len=0 TSV=12431366 TSER=86511662 > > > > The server decides, for whatever reason, to terminate the > > connection and sends a FIN. > > > > 2309 3371.535018 xxx.xxx.31.43 xxx.xxx.16.142 TCP 934 > nfs [ACK] Seq=238429 Ack=230406 Win=8192 Len=0 TSV=86871578 TSER=12431366 > > > > Client acknowledges this, > > > > 2310 3375.379693 xxx.xxx.31.43 xxx.xxx.16.142 NFS V3 ACCESS Call, FH:0x008002a2 > > > > but tries to sneak in another call anyway. [A] > > > Probably not the best behaviour, but I think it is technically allowed by > TCP. (My TCP is very rusty, but I think the socket should be in > TCPS_CLOSE_WAIT at this point and the BSD code will have called > socantrcvmore(), but not socantsndmore().) > > > 2311 3375.474788 xxx.xxx.16.142 xxx.xxx.31.43 TCP nfs > 934 [ACK] Seq=230406 Ack=238569 Win=49232 Len=0 TSV=12431760 TSER=86875423 > > > > Server ACKs but doesn't send anything else... [B] > > > > Time passes... > > > This is where it seems interesting. It looks to me like the socket upcall > for receiving the FIN would have happened before this point, setting the > ct_error.re_status to RPC_CANTRECV, but the code in clnt_vc_call() doesn't > check for this. (It does check for it happening during and after the > sosend(), but not before it, from what I can see.) > > > > > [B] would be a bug of the server in my opinion. If it ACKs a call, it > > should send a reply. And if it can't, it shouldn't. > > > I'll leave this one for the TCP wizzards. I'm not sure what the > correct behaviour is when data is received on a connection. (I think > it is waiting for a FIN from the client side at this point.) > > If you could try the following patch and see if it helps, that would be > appreciated, rick > ps: I'll try to reproduce the situation here, but I'm not sure if I can. > --- rpc/clnt_vc.c.sav 2009-10-28 15:44:20.000000000 -0400 > +++ rpc/clnt_vc.c 2009-10-28 15:49:57.000000000 -0400 > @@ -413,6 +413,19 @@ > > cr->cr_xid = xid; > mtx_lock(&ct->ct_lock); > + /* > + * Check to see if the other end has already started to close down > + * the connection. If it happens after this point, it will be > + * detected below, when cr->cr_error is checked. > + */ > + if (ct->ct_error.re_status == RPC_CANTRECV) { > + if (errp != &ct->ct_error) { > + errp->re_errno = ct->ct_error.re_errno; > + errp->re_status = RPC_CANTRECV; > + } > + stat = RPC_CANTRECV; > + goto out; > + } > TAILQ_INSERT_TAIL(&ct->ct_pending, cr, cr_link); > mtx_unlock(&ct->ct_lock); Did a make buildworld -j8, using as server netapp, freebsd, and all seems ok. danny From dimitry at andric.com Sat Oct 31 13:14:37 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Oct 31 13:14:44 2009 Subject: Console has no name? Message-ID: <4AEC3823.9000204@andric.com> Hi, Somewhere between r198312 and r198702 I started getting this message during boot, on a machine using serial console: WARNING: console at 0xc093cea0 has no name This is just before the copyright banner of the kernel. Does anybody have an idea what might cause this, before I start digging? :) The machine has /boot.config with just "-P", and no console-related entries in /boot/loader.conf. From dimitry at andric.com Sat Oct 31 14:54:10 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Oct 31 14:54:18 2009 Subject: Console has no name? In-Reply-To: <4AEC3823.9000204@andric.com> References: <4AEC3823.9000204@andric.com> Message-ID: <4AEC4F81.7010404@andric.com> On 2009-10-31 14:14, Dimitry Andric wrote: > Somewhere between r198312 and r198702 I started getting this message > during boot, on a machine using serial console: > > WARNING: console at 0xc093cea0 has no name Okay, this seems to be caused by r198655, which is an MFC of r197570, where experimental support for USB serial console was added. However, the consdev::cn_name field is never initialized in usb_serial.c, whereas this does happen in other console drivers. There doesn't seem to be a consensus whether this field needs to be initialized in the _cnprobe() or _cninit() functions: I count 9 instances of initialization in the former, and 3 in the latter. Is there a preferred way? Since _cnprobe seems more popular, I propose the following fix: Index: sys/dev/usb/serial/usb_serial.c =================================================================== --- sys/dev/usb/serial/usb_serial.c (revision 198702) +++ sys/dev/usb/serial/usb_serial.c (working copy) @@ -1301,6 +1301,7 @@ static void ucom_cnprobe(struct consdev *cp) { cp->cn_pri = CN_NORMAL; + strlcpy(cp->cn_name, "ucom", sizeof cp->cn_name); } static void From ivoras at gmail.com Sat Oct 31 15:30:23 2009 From: ivoras at gmail.com (Ivan Voras) Date: Sat Oct 31 15:30:37 2009 Subject: hostapd "deauthenticated due to local deauth request" Message-ID: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> I'm trying to setup an AP with a run0 interface on latest 8-STABLE but apparently 802.11 association fails: Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: associated Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deauthenticated due to local deauth request Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deassociated Oct 31 16:21:35 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: associated Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deauthenticated due to local deauth request Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE 802.11: deassociated etc. Apparently the client never comes to the phase to receive DHCP address. The client in this case is WinXP and the setup did work with 7-STABLE, though with a bug in the rum driver which caused regular kernel panics on the AP. The devices are configured like this: rum0: flags=8843 metric 0 mtu 2290 ether 00:1c:f0:9d:08:b3 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running wlan0: flags=8943 metric 0 mtu 1500 ether 00:1c:f0:9d:08:b3 inet6 fe80::21c:f0ff:fe9d:8b3%wlan0 prefixlen 64 scopeid 0x6 inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: running ssid Cosmos channel 1 (2412 Mhz 11g) bssid 00:1c:f0:9d:08:b3 country US authmode WPA privacy MIXED deftxkey 3 TKIP 2:128-bit TKIP 3:128-bit txpower 0 scanvalid 60 protmode CTS dtimperiod 1 -dfs hostapd.conf contains: interface=wlan0 debug=3 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=Cosmos wpa=1 wpa_passphrase=something wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP Any ideas? From hselasky at c2i.net Sat Oct 31 16:02:21 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 31 16:02:29 2009 Subject: Console has no name? In-Reply-To: <4AEC5F14.2030905@andric.com> References: <4AEC3823.9000204@andric.com> <200910311656.29159.hselasky@c2i.net> <4AEC5F14.2030905@andric.com> Message-ID: <200910311703.31362.hselasky@c2i.net> Hi, Your patch has been committed to USB P4: http://p4web.freebsd.org/chv.cgi?CH=170003 Thanks for reporting! --HPS From hselasky at c2i.net Sat Oct 31 16:42:25 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Oct 31 16:42:32 2009 Subject: Console has no name? In-Reply-To: <4AEC4F81.7010404@andric.com> References: <4AEC3823.9000204@andric.com> <4AEC4F81.7010404@andric.com> Message-ID: <200910311643.36862.hselasky@c2i.net> On Saturday 31 October 2009 15:53:53 Dimitry Andric wrote: > On 2009-10-31 14:14, Dimitry Andric wrote: > > Somewhere between r198312 and r198702 I started getting this message > > during boot, on a machine using serial console: > > > > WARNING: console at 0xc093cea0 has no name > > Okay, this seems to be caused by r198655, which is an MFC of r197570, > where experimental support for USB serial console was added. > > However, the consdev::cn_name field is never initialized in > usb_serial.c, whereas this does happen in other console drivers. > > There doesn't seem to be a consensus whether this field needs to be > initialized in the _cnprobe() or _cninit() functions: I count 9 instances > of initialization in the former, and 3 in the latter. Is there a > preferred way? > > Since _cnprobe seems more popular, I propose the following fix: > > Index: sys/dev/usb/serial/usb_serial.c > =================================================================== > --- sys/dev/usb/serial/usb_serial.c (revision 198702) > +++ sys/dev/usb/serial/usb_serial.c (working copy) > @@ -1301,6 +1301,7 @@ static void > ucom_cnprobe(struct consdev *cp) > { > cp->cn_pri = CN_NORMAL; > + strlcpy(cp->cn_name, "ucom", sizeof cp->cn_name); > } > > static void Patch looks fine by me. --HPS From onemda at gmail.com Sat Oct 31 16:46:47 2009 From: onemda at gmail.com (Paul B Mahol) Date: Sat Oct 31 16:46:55 2009 Subject: hostapd "deauthenticated due to local deauth request" In-Reply-To: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> References: <9bbcef730910310830s43237918g1489beb1fe9fae9a@mail.gmail.com> Message-ID: <3a142e750910310916labe85e5ke804386a834c49c8@mail.gmail.com> On 10/31/09, Ivan Voras wrote: > I'm trying to setup an AP with a run0 interface on latest 8-STABLE but > apparently 802.11 association fails: > > Oct 31 16:21:30 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: associated > Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deauthenticated due to local deauth request > Oct 31 16:21:33 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deassociated > Oct 31 16:21:35 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: associated > Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deauthenticated due to local deauth request > Oct 31 16:21:38 ursaminor hostapd: wlan0: STA 00:22:69:07:30:9e IEEE > 802.11: deassociated > > etc. Apparently the client never comes to the phase to receive DHCP address. > > The client in this case is WinXP and the setup did work with 7-STABLE, > though with a bug in the rum driver which caused regular kernel panics > on the AP. > I tried same one with rum(4) as AP and ndis(4) as client on same machine(some version of 8.0 - CURRENT). ndis client (configured via wpa_supplicant) would keep auth and deauth all the time. I came to conclusion that rum is broken. But I think I remmember that bwi(4) (as a client) did not have such problem ... (I will test again to see) From oliver.pntr at gmail.com Sat Oct 31 18:54:23 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Sat Oct 31 18:54:31 2009 Subject: CVE-2009-0689 Message-ID: <6101e8c40910311154j16125ffawd4d4f34e5ba50706@mail.gmail.com> Hello list! I have a small question from CVE-2009-0689[1]: The commit r197059 fixed this bug or not? On security lists its marked as high priority and find it at juni. some info: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0689 [2] http://securityreason.com/achievement_securityalert/63 [3] http://seclists.org/fulldisclosure/2009/Oct/357 From pyunyh at gmail.com Sat Oct 31 21:21:05 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Oct 31 21:21:12 2009 Subject: 7.2 Stable Crash - possibly related to if_re In-Reply-To: <200910301823.51274.npapke@acm.org> References: <200910292156.19845.npapke@acm.org> <20091030165451.GA17243@michelle.cdnetworks.com> <200910301823.51274.npapke@acm.org> Message-ID: <20091031212107.GC17243@michelle.cdnetworks.com> On Fri, Oct 30, 2009 at 06:23:51PM -0700, Norbert Papke wrote: > On October 30, 2009, Pyun YongHyeon wrote: > > On Thu, Oct 29, 2009 at 09:56:19PM -0700, Norbert Papke wrote: > > > This occurred shortly after "scp"ing from a VirtualBox VM to the host. > > > The file transfer got stuck. The "re" interface stopped working. > > > Shortly afterwards, the host crashed. The "re" interface was used by the > > > host, the guest was using a different NIC in bridged mode. > > > > > > > > > FreeBSD proven.lan 7.2-STABLE FreeBSD 7.2-STABLE #5 r198666: Thu Oct 29 > > > 18:36:57 PDT 2009 > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid = 0; apic id = 00 > > > fault virtual address = 0x18 > > > > It looks like a NULL pointer dereference, possibly mbuf related > > one. > > > > > fault code = supervisor write data, page not present > > > instruction pointer = 0x8:0xffffffff80d476ee > > > stack pointer = 0x10:0xffffff8000078ae0 > > > frame pointer = 0x10:0xffffff8000078b40 > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags = interrupt enabled, resume, IOPL = 0 > > > current process = 18 (swi5: +) > > > Physical memory: 8177 MB > > > > > > > > > > #9 0xffffffff807e710e in calltrap () > > > at /usr/public/freebsd/sources/stable/sys/amd64/amd64/exception.S:218 > > > #10 0xffffffff80d476ee in re_rxeof () from /boot/kernel/if_re.ko > > > > Hmm, I think there is a missing information here. Not sure where it > > dereferenced a NULL pointer in re_rxeof(). > > >> #11 0xffffffff80d4a481 in re_int_task (arg=Variable "arg" is not available. > >> ) > >> > at /usr/public/freebsd/sources/stable/sys/modules/re/../../dev/re/if_re.c:2191 > > I am not sure how much I trust frame 10. The instruction > at "0xffffffff80d476ee" is the one after the "retq" from re_rxeof(). Frame > 11 seems OK to me. The "struct rl_softc*", in particular, looks plausible > but I don't know enough to say for sure. > > > Because that this is the > > first report for NULL pointer dereference in Rx handler I need more > > information how to reproduce it with minimal configuration. Can you > > also reproduce the issues without virtual box? > > I am trying but no luck so far. > > > By chance, did you stop the re0 interface with ifconfig when you > > noticed the file transfer got stuck? > > It is possible. I had it happen twice. The first time I definitely tried > to "down" re. I cannot recall what I did the second time. The crash dump is > from the second time. > Ok, then would you try attached patch? -------------- next part -------------- A non-text attachment was scrubbed... Name: re.rxeof.patch Type: text/x-diff Size: 469 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091031/00d3e348/re.rxeof.bin