From cperciva at freebsd.org Wed Apr 1 00:17:38 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Wed Apr 1 00:17:51 2009 Subject: HEADS UP: FreeBSD 7.0 EoL coming soon Message-ID: <49D31510.7050908@freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Everyone, On April 30th, FreeBSD 7.0 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of FreeBSD 7.0 are strongly encouraged to upgrade to FreeBSD 7.1 before that date. Note that the End of Life date for FreeBSD 7.0 was originally announced as being February 28, but was delayed by two months in accordance with Security Team policy in order to allow a 3 month window between the release of FreeBSD 7.1 and the End of Life of FreeBSD 7.0 to allow time for systems to be upgraded. 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_0 |7.0-RELEASE |Normal |February 27, 2008|April 30, 2009 | ~ |-----------+------------+--------+-----------------+-----------------| ~ |RELENG_7_1 |7.1-RELEASE |Extended|January 4, 2009 |January 31, 2011 | ~ +---------------------------------------------------------------------+ When FreeBSD 7.2-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.9 (FreeBSD) iEYEARECAAYFAknTFQ8ACgkQFdaIBMps37ILwACggF8T2Yb4SSMqzviMDcHB74w4 5oQAoJ7oToAdSFT8eJlAWwWwldz8M4I2 =Er3j -----END PGP SIGNATURE----- From 000.fbsd at quip.cz Wed Apr 1 03:03:29 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Apr 1 03:03:36 2009 Subject: Upgrading from 7.0 to 7.1 In-Reply-To: <49D0E4E7.3050001@connection.ca> References: <49D0E4E7.3050001@connection.ca> Message-ID: <49D33790.6050805@quip.cz> James Wu wrote: > Hi all, > > I'm brand new to the list so forgive me if this has been answered. I > tried searching the archives and tried googling and didn't come up with > any results. > > I've been wanting to play with setfib multi-routing tables in 7.1, > however, we have a bunch of 7.0 machines. I thought I'd take a test > machine and upgrade it to 7.1. Everything went smoothly at first. I > compiled a custom 7.1 kernel and installed it just fine. Afterwards, I > ran: > > freebsd-update fetch > freebsd-update install > to upgrade to the latest 7.0 > > then: > freebsd-update upgrade -r 7.1-RELEASE > freebsd-update install -r 7.1-RELEASE > freebsd-update fetch > to upgrade to 7.1 Did you just these 3 commands? You must use freebsd-update install twice. First time for kernel upgrade, then reboot and then freebsd-update install again to install new userland. Do you have other binaries in /usr/sbin, /usr/bin, /bin /sbin upgraded? (ls -al shows newer date + time) > now when I do a > uname -a, > I get FreeBSD 7.1-RELEASE-p3 which looks right to me uname -a is derived from kernel, so it is possible that you have 7.1 kernel with 7.0 userland. > The problem I'm running into though is that the setfib binary doesn't > seem to been added during the upgrade as I don't see it anywhere. I took > a fresh install of 7.1 and do see it /usr/sbin/, but it's not there for > the upgraded version of 7.1. > I guess at this point, I would like to do a reinstall of the sbin folder > if it is possible or somehow get a clean copy of the /usr/sbin/ folder > into my upgraded machine. Any hints on how to do that? Miroslav Lachman From danny at cs.huji.ac.il Wed Apr 1 03:12:24 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Apr 1 03:12:32 2009 Subject: Intel Integrated Raid (iir) relevance In-Reply-To: <49D2CBB1.3070802@delphij.net> References: <49D2CBB1.3070802@delphij.net> Message-ID: Hi Xin LI, > (It would be probably good idea to redirect this discussion to -stable@, > redirected) > ok by me. > Hi, Danny, > > Danny Braniss wrote: > > It's no longer working (for me) under 7.2, and so far > > I am not getting any feedback, so since it seems that > > this particular hardware has reached EOL, I was wondering > > if, > > a) it's true, > > b) drop it, and replace it. > > c) should time be spent in getting it to work again. > > I'm not very sure about your problem with iir(4). A diff against > RELENG_7_1 does not reveal any change on the driver itself. Are you > sure that 7.1-R can have the device working? > it's definitly broken for me, it broke sometime after rev 189591. but the main questions are still unanswered. The problem I'm facing, together with the amr, is on hosts that are being de-comissioned, and though I'll be sad turning them to scrap, they did serve us well. thanks, danny From mav at FreeBSD.org Wed Apr 1 12:14:31 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Apr 1 12:14:37 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: References: <49D29097.9040701@FreeBSD.org> Message-ID: <49D3BD14.9070505@FreeBSD.org> Dmitry Morozovsky wrote: > On Wed, 1 Apr 2009, Alexander Motin wrote: > AM> Dmitry Morozovsky wrote: > AM> > Hi there colleagues, > AM> > > AM> > atapci3: port > AM> > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem > AM> > 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 > AM> > > AM> > > AM> > atacontrol detach ata7 > AM> > - insert ATA disk (ad14) > AM> > atacontrol attach ata7 > AM> > > AM> > pinics with Fatal trap 12: page fault while in kernel mode > AM> > AM> Any kernel verbose messages before it? > > Nope. Just > > ata7: [ITHREAD]^M > ^M > ^M > Fatal trap 12: page fault while in kernel mode^M > > and approx 15 seconds of wait between ata channel detection and the panic. Are you sure that you have verbose messages enabled during boot or via sysctl? It looks a bit too quiet. RELENG_7 branch ATA maintenance is a bit difficult for me now due to big differences from the HEAD. It makes me wish to sync them as there is still too much time before 7.x EOL. May be I will do it after the 7.2 release process finished. Now is probably not the best time to do it. -- Alexander Motin From lists at reiteration.net Wed Apr 1 20:12:45 2009 From: lists at reiteration.net (John) Date: Wed Apr 1 20:12:53 2009 Subject: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE) In-Reply-To: <20090331185409.GA2086@dchagin.static.corbina.ru> References: <49CAA7AB.8030506@reiteration.net> <20090328191143.GA1989@dchagin.static.corbina.ru> <20090330080532.GB26132@weongyo.cdnetworks.kr> <20090330165334.GA2831@dchagin.static.corbina.ru> <20090331034229.GJ26132@weongyo.cdnetworks.kr> <20090331070325.GA2479@dchagin.static.corbina.ru> <20090331073608.GA43918@weongyo.cdnetworks.kr> <20090331185409.GA2086@dchagin.static.corbina.ru> Message-ID: <20090402031530.1366612nkllms79u@webmail-srv2.servage.net> Quoting Chagin Dmitry : >> > >> > dchagin# ifconfig malo0 scan >> > ifconfig: unable to get scan results >> > >> > In the evening I will more in detail look... anyway, many thanks :) >> >> FWIW the following commands would be useful for CURRENT: >> >> # ifconfig wlan0 create wlandev malo0 >> # ifconfig wlan0 ssid up >> >> Please see malo(4) for details. Thanks for testing :-) >> > > yes, it works. thnx! Mine is now working too ;) thanks! -- John From weongyo.jeong at gmail.com Wed Apr 1 22:35:22 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Wed Apr 1 22:35:30 2009 Subject: malo causes sig 12 error and panic on Freebsd 7.2-PRERELEASE (7-STABLE) In-Reply-To: <20090402031530.1366612nkllms79u@webmail-srv2.servage.net> References: <49CAA7AB.8030506@reiteration.net> <20090328191143.GA1989@dchagin.static.corbina.ru> <20090330080532.GB26132@weongyo.cdnetworks.kr> <20090330165334.GA2831@dchagin.static.corbina.ru> <20090331034229.GJ26132@weongyo.cdnetworks.kr> <20090331070325.GA2479@dchagin.static.corbina.ru> <20090331073608.GA43918@weongyo.cdnetworks.kr> <20090331185409.GA2086@dchagin.static.corbina.ru> <20090402031530.1366612nkllms79u@webmail-srv2.servage.net> Message-ID: <20090402053517.GD44973@weongyo.cdnetworks.kr> On Thu, Apr 02, 2009 at 03:15:30AM +0000, John wrote: > Quoting Chagin Dmitry : > > >>> > >>> dchagin# ifconfig malo0 scan > >>> ifconfig: unable to get scan results > >>> > >>> In the evening I will more in detail look... anyway, many thanks :) > >> > >>FWIW the following commands would be useful for CURRENT: > >> > >> # ifconfig wlan0 create wlandev malo0 > >> # ifconfig wlan0 ssid up > >> > >>Please see malo(4) for details. Thanks for testing :-) > >> > > > >yes, it works. thnx! > > Mine is now working too ;) Thank you for testing. :-) regards, Weongyo Jeong From vas at mpeks.tomsk.su Wed Apr 1 22:44:02 2009 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Wed Apr 1 22:44:10 2009 Subject: Failure to make world for RELENG_6_4 Message-ID: <20090402044358.GA34249@admin.sibptus.tomsk.ru> Colleagues, I have recently submitted 2 PRs misc/133264 misc/133066 regarding the failure to compile the security branch RELENG_6_4. Could you please look at them and try to reproduce the problems? http://www.freebsd.org/cgi/query-pr.cgi?pr=133264 http://www.freebsd.org/cgi/query-pr.cgi?pr=133066 -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From marck at rinet.ru Thu Apr 2 00:58:14 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Apr 2 00:58:25 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: <49D3BD14.9070505@FreeBSD.org> References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> Message-ID: On Wed, 1 Apr 2009, Alexander Motin wrote: AM> > AM> > AM> > atapci3: port AM> > AM> > AM> > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem AM> > AM> > 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 AM> > AM> > AM> > AM> > atacontrol detach ata7 AM> > AM> > - insert ATA disk (ad14) AM> > AM> > atacontrol attach ata7 AM> > AM> > AM> > pinics with Fatal trap 12: page fault while in kernel mode AM> > AM> AM> Any kernel verbose messages before it? AM> > AM> > Nope. Just AM> > AM> > ata7: [ITHREAD]^M AM> > ^M AM> > ^M AM> > Fatal trap 12: page fault while in kernel mode^M AM> > AM> > and approx 15 seconds of wait between ata channel detection and the panic. AM> AM> Are you sure that you have verbose messages enabled during boot or via AM> sysctl? It looks a bit too quiet. Ah, you're right, on this server I turned off boot_verbose. Will recheck. AM> RELENG_7 branch ATA maintenance is a bit difficult for me now due to big AM> differences from the HEAD. It makes me wish to sync them as there is still AM> too much time before 7.x EOL. May be I will do it after the 7.2 release AM> process finished. Now is probably not the best time to do it. Fully understood. The only thing I wish to add is that RELENG_7 ata is much more picky in reinitializations (e.g., disk swaps) than RELENG_6. Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From marck at rinet.ru Thu Apr 2 06:17:44 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Apr 2 06:17:51 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> Message-ID: On Thu, 2 Apr 2009, Dmitry Morozovsky wrote: DM> AM> > AM> > AM> > atapci3: port DM> AM> > AM> > DM> AM> > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem DM> AM> > AM> > 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 DM> AM> > AM> > AM> > AM> > atacontrol detach ata7 DM> AM> > AM> > - insert ATA disk (ad14) DM> AM> > AM> > atacontrol attach ata7 DM> AM> > AM> > AM> > pinics with Fatal trap 12: page fault while in kernel mode DM> AM> > AM> AM> Any kernel verbose messages before it? got it: ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7: [MPSAFE]^M ata7: [ITHREAD]^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M GEOM_LABEL: Label ufs/moose09 removed.^M [-- MARK -- Thu Apr 2 17:00:00 2009] GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M GEOM_LABEL: Label ufs/moose09 removed.^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7: ata7: [MPSAFE]^M CONNECT requested^M ata7: [ITHREAD]^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad: ad14 already exists; skipping it^M ad: ad14 already exists; skipping it^M ^M ^M Fatal trap 12: page fault while in kernel mode^M -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From mav at FreeBSD.org Thu Apr 2 06:36:30 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Apr 2 06:36:38 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> Message-ID: <49D4BF5C.4010509@FreeBSD.org> Dmitry Morozovsky wrote: > On Thu, 2 Apr 2009, Dmitry Morozovsky wrote: > > DM> AM> > AM> > AM> > atapci3: port > DM> AM> > AM> > > DM> AM> > 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem > DM> AM> > AM> > 0xefcb3000-0xefcb3fff irq 23 at device 5.2 on pci0 > DM> AM> > AM> > AM> > AM> > atacontrol detach ata7 > DM> AM> > AM> > - insert ATA disk (ad14) > DM> AM> > AM> > atacontrol attach ata7 > DM> AM> > AM> > AM> > pinics with Fatal trap 12: page fault while in kernel mode > DM> AM> > AM> AM> Any kernel verbose messages before it? > > got it: > > ata7: SATA connect time=0ms^M > ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M > ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M > ata7: [MPSAFE]^M > ata7: [ITHREAD]^M > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > ad14: 715404MB at ata7-master SATA300^M > ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth > queue^M > GEOM: new disk ad14^M > GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M > GEOM_LABEL: Label ufs/moose09 removed.^M > [-- MARK -- Thu Apr 2 17:00:00 2009] > GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M > GEOM_LABEL: Label ufs/moose09 removed.^M > ata7: SATA connect time=0ms^M > ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x01 lsb=0x00 msb=0x00^M > ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M > ata7: ata7: [MPSAFE]^M > CONNECT requested^M > ata7: [ITHREAD]^M > ata7: CONNECTED^M > ata7: SATA connect time=0ms^M > ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M > ata7: DISCONNECT requested^M > ata7: CONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: DISCONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: CONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: DISCONNECT requested^M > ata7: CONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: DISCONNECT requested^M > ata7: CONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: DISCONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: CONNECT requested^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M > ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M This looks like race between PATA reset sequence and SATA hot plug events. For AHCI it is handled by masking interrupts during reset. How it is expected to be done here, I am not sure. You can just disable hot plug by commenting respective part of of ata_sata_phy_check_events() function. > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > ad: ad14 already exists; skipping it^M > ad: ad14 already exists; skipping it^M > ^M > ^M > Fatal trap 12: page fault while in kernel mode^M It looks alike to crash I have already fixed on CURRENT: http://svn.freebsd.org/changeset/base/188464 -- Alexander Motin From marck at rinet.ru Thu Apr 2 10:14:46 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Apr 2 10:14:54 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: <49D4BF5C.4010509@FreeBSD.org> References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> <49D4BF5C.4010509@FreeBSD.org> Message-ID: On Thu, 2 Apr 2009, Alexander Motin wrote: AM> > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM> > ad: ad14 already exists; skipping it^M AM> > ad: ad14 already exists; skipping it^M AM> > ^M AM> > ^M AM> > Fatal trap 12: page fault while in kernel mode^M AM> AM> It looks alike to crash I have already fixed on CURRENT: AM> http://svn.freebsd.org/changeset/base/188464 Seems to be. Would you please ask re@ for MFC approval? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From mav at FreeBSD.org Thu Apr 2 10:31:39 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Apr 2 10:31:45 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> <49D4BF5C.4010509@FreeBSD.org> Message-ID: <49D4F679.5040703@FreeBSD.org> Dmitry Morozovsky wrote: > On Thu, 2 Apr 2009, Alexander Motin wrote: > > AM> > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M > AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > AM> > ad: ad14 already exists; skipping it^M > AM> > ad: ad14 already exists; skipping it^M > AM> > ^M > AM> > ^M > AM> > Fatal trap 12: page fault while in kernel mode^M > AM> > AM> It looks alike to crash I have already fixed on CURRENT: > AM> http://svn.freebsd.org/changeset/base/188464 > > Seems to be. Would you please ask re@ for MFC approval? This is not actually a fix for original problem, but it may help to avoid system crash. Can you confirm that it helps you, as I haven't tested it on STABLE yet, I am doing it now. If it helps, I will ask re@. -- Alexander Motin From marck at rinet.ru Thu Apr 2 11:14:10 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Apr 2 11:14:20 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: <49D4F679.5040703@FreeBSD.org> References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> <49D4BF5C.4010509@FreeBSD.org> <49D4F679.5040703@FreeBSD.org> Message-ID: On Thu, 2 Apr 2009, Alexander Motin wrote: AM> Dmitry Morozovsky wrote: AM> > On Thu, 2 Apr 2009, Alexander Motin wrote: AM> > AM> > AM> > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M AM> > AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM> > AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M AM> > AM> > ad: ad14 already exists; skipping it^M AM> > AM> > ad: ad14 already exists; skipping it^M AM> > AM> > ^M AM> > AM> > ^M AM> > AM> > Fatal trap 12: page fault while in kernel mode^M AM> > AM> AM> It looks alike to crash I have already fixed on CURRENT: AM> > AM> http://svn.freebsd.org/changeset/base/188464 AM> > AM> > Seems to be. Would you please ask re@ for MFC approval? AM> AM> This is not actually a fix for original problem, but it may help to avoid AM> system crash. Can you confirm that it helps you, as I haven't tested it on AM> STABLE yet, I am doing it now. If it helps, I will ask re@. Well, partially. Machine survived a dozed of detach-remove-insert-attach cycles (which it definitly could not before). However, it it still paniced on hot-remove-insert (could not dump): ata7: DISCONNECT requested^M ata7: DISCONNECTED^M GEOM_LABEL: Label ufs/moose09 removed.^M ata7: CONNECT requested^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=80 ostat1=00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M [a bunch of it] ata7: DISCONNECT requested^M ata7: ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: DISCONNECT requested^M ata7: CONNECT requested^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x80 err=0x00 lsb=0x00 msb=0x00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M ata7: DISCONNECTED^M ata7: CONNECTED^M ata7: SATA connect time=0ms^M ata7: reset tp1 mask=01 ostat0=50 ostat1=00^M ata7: stat0=0x50 err=0x01 lsb=0x00 msb=0x00^M ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M ad14: 715404MB at ata7-master SATA300^M ad14: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth queue^M GEOM: new disk ad14^M GEOM_LABEL: Label for provider ad14a is ufs/moose09.^M ^M ^M Fatal trap 12: page fault while in kernel mode^M cpuid = 0; apic id = 00^M fault virtual address = 0x4^M fault code = supervisor read, page not present^M instruction pointer = 0x20:0xc04e058b^M stack pointer = 0x28:0xfa320be8^M frame pointer = 0x28:0xfa320c8c^M code segment = base 0x0, limit 0xfffff, type 0x1b^M = DPL 0, pres 1, def32 1, gran 1^M processor eflags = interrupt enabled, resume, IOPL = 0^M current process = 2 (g_event)^M trap number = 12^M Some other hot reinserts finished successfully. Well, at least now it is significally better that before, if one does not forget to detach ata channel before reinserting the device. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From marck at rinet.ru Thu Apr 2 11:26:32 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Apr 2 11:26:39 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> <49D4BF5C.4010509@FreeBSD.org> <49D4F679.5040703@FreeBSD.org> Message-ID: On Thu, 2 Apr 2009, Dmitry Morozovsky wrote: DM> Some other hot reinserts finished successfully. Well, a couple minutes later after hot-reinsert machine paniced again (but now it seems related to ZFS): Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0836964 stack pointer = 0x28:0xfa466bd4 frame pointer = 0x28:0xfa466be4 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 = 35 (arc_reclaim_thread) trap number = 12 panic: page fault cpuid = 1 Uptime: 11m8s Physical memory: 2039 MB Dumping 300 MB: 285 269 253 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc06cfce3 in trap_fatal (frame=0xfa466b94, eva=40) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc06cff40 in trap_pfault (frame=0xfa466b94, usermode=0, eva=40) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc06d08e6 in trap (frame=0xfa466b94) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc06b5b5b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0836964 in avl_destroy_nodes (tree=0xc9a2d540, cookie=0xfa466bf4) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:933 #8 0xc088b873 in mze_destroy (zap=Variable "zap" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:175 #9 0xc088bbf3 in zap_evict (db=0xcca1cdac, vzap=0xc9a2d500) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:472 #10 0xc084c818 in dbuf_evict_user (db=0xcca1cdac) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:224 #11 0xc084d655 in dbuf_clear (db=0xcca1cdac) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1281 #12 0xc084d762 in dbuf_evict (db=0xcca1cdac) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:237 #13 0xc084db76 in dbuf_do_evict (private=0xc90d5cbc) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1458 #14 0xc0847517 in arc_do_user_evicts () at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1321 #15 0xc084a584 in arc_reclaim_thread (dummy=0x0) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:1551 #16 0xc050d877 in fork_exit (callout=0xc084a380 , arg=0x0, frame=0xfa466d38) at /usr/src/sys/kern/kern_fork.c:810 #17 0xc06b5bd0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From marck at rinet.ru Thu Apr 2 13:32:36 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Apr 2 13:32:44 2009 Subject: RELENG_7/i386: ZFS constant panic on file system writes Message-ID: Pawel, could you please help me a bit with *very* unpleasant situation: one of my servers with very large ZFS reboots on most write requests to one (largest, which effectively prohibits recreating) ZFS file system with panic: avl_find() succeeded inside avl_add() (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0836a20 in avl_add (tree=Variable "tree" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 #4 0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, fatreader=1, zapp=0xfc6907f8) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 #5 0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc "daily.20080701.gz", integer_size=8, num_integers=1, buf=0xfc69083c) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 #6 0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, name=0xfc6908bc "daily.20080701.gz", zpp=0xfc690874, flag=Variable "flag" is not available. ) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 #7 0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc "daily.20080701.gz", vpp=0xfc690b5c) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 #8 0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 #9 0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at vnode_if.c:153 #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at vnode_if.c:99 #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088
, pathseg=UIO_USERSPACE, sbp=0xfc690c18) at /usr/src/sys/kern/vfs_syscalls.c:2184 #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at /usr/src/sys/kern/vfs_syscalls.c:2167 #16 0xc06d0288 in syscall (frame=0xfc690d38) at /usr/src/sys/i386/i386/trap.c:1090 #17 0xc06b5bc0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #18 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ 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 artem_kim at inbox.ru Thu Apr 2 15:59:36 2009 From: artem_kim at inbox.ru (Artem Kim) Date: Thu Apr 2 15:59:43 2009 Subject: 7.2-PRERELEASE X-server hang in "drmwtq" Message-ID: <200904030223.27059.artem_kim@inbox.ru> Hi. In last time, I have a problem with stability on my system: 7.2-PRERELEASE Thu Apr 2 20:20:31 MSD 2009 amd64 (UP); ati 9800-XT From time to time the x-server go in "drmwtq" state if the AIGLX is enabled. This usually happens when creating a new window. If I setup hw.dri.0.debug to "1", I get a lot of messages: [drm: pid1469: drm_ioctl] pid = 1469, cmd = 0x80046457, nr = 0x57, dev 0xffffff0001306800, auth = 1 [drm: pid1469: drm_ioctl] returning -1 I can see a recurring message in in ktrace: 1469 Xorg PSIG SIGALRM caught handler = 0x4dca90 mask = 0x0 code = 0x0 1469 Xorg CALL sigreturn (0x7fffffffe5b0) 1469 Xorg RET sigreturn JUSTRETURN 1469 Xorg CALL ioctl (0xa, 0x80046457, 0x8156e807c) 1469 Xorg RET ioctl RESTART The problems started after vblank rework in the STABLE. The first time I got a panic when i try to restart or shutdown x-server, but the problem with panic was solved (for me ;)) quickly. I am ready to provide any additional information. Many thanks for your work. From kensmith at cse.Buffalo.EDU Thu Apr 2 21:43:28 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Thu Apr 2 21:43:36 2009 Subject: FreeBSD 7.2-BETA1 Available Message-ID: <1238733801.82195.25.camel@neo.cse.buffalo.edu> The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now available. Testing of two recent changes to the system would be particularly valuable. The bce(4) network driver was updated a few days ago. And some significant work was done on the threading libraries a short time ago that is known to fix several major issues but testing to see if it introduced any regressions would be appreciated. The target schedule for the release is available here: http://www.freebsd.org/releases/7.2R/schedule.html So far we're just one day off target (BETA1 builds started Tuesday). The ISO images and FTP install trees are available on the FreeBSD Mirror sites. Using the primary site as an example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.2/ where ${arch} is one of amd64 i386, ia64, pc98, powerpc, or sparc64. Checksums for the ISO images are at the bottom of this message. The amd64 and i386 sets include a *preliminary* set of packages. If you would like to do a source-based update to 7.2-BETA1 from an already installed machine you can update your tree to RELENG_7 using normal cvsup/csup methods. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE or 7.1-RELEASE can upgrade as follows: # freebsd-update upgrade -r 7.2-BETA1 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. # 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, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.2-BETA1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x. NOTE: Due to a recently uncovered bug, FreeBSD Update may fail while downloading updates. If this occurs, please use the mirror update1.freebsd.org, by running freebsd-update with the "-s update1.freebsd.org" flag added; this mirror should be immune to this bug. Checksums: MD5 (7.2-BETA1-amd64-bootonly.iso) = 112490bebd43f407bb8ef8bae2d0cc05 MD5 (7.2-BETA1-amd64-disc1.iso) = 742fd7ed423f77761ae6112a81931716 MD5 (7.2-BETA1-amd64-disc2.iso) = c733ea160e94b4e355c8da7dd54e4135 MD5 (7.2-BETA1-amd64-disc3.iso) = 0111313462034b4bca982e81d61ea17d MD5 (7.2-BETA1-amd64-docs.iso) = 03b601464047aa483d2706577cfb3a74 MD5 (7.2-BETA1-amd64-dvd1.iso) = bd08de1b3bf525f7bd597d7f99b9a0fd MD5 (7.2-BETA1-amd64-livefs.iso) = 9ed0331a0d612ea4e98c80b1447a45c6 MD5 (7.2-BETA1-i386-bootonly.iso) = 2ba4d30be7a95ff9ca91e3d4ef8a35f6 MD5 (7.2-BETA1-i386-disc1.iso) = 6933fd6b9f7ee500397c0c54aa831408 MD5 (7.2-BETA1-i386-disc2.iso) = bfc682aaec7f9df8919da31987c9d8fb MD5 (7.2-BETA1-i386-disc3.iso) = 600030debe096c10b348c726462f9ce1 MD5 (7.2-BETA1-i386-docs.iso) = 04faa50ba321cf2b402c8a99828f58e2 MD5 (7.2-BETA1-i386-dvd1.iso) = 6603b9ca9c09b8c1c92613441bb154ad MD5 (7.2-BETA1-i386-livefs.iso) = cda0a13ba0453e1d885c0c613f34c758 MD5 (7.2-BETA1-ia64-bootonly.iso) = b20eba8d3113ab8882c5c47e1a3df2d2 MD5 (7.2-BETA1-ia64-disc1.iso) = c208adb4539d9f0c9ee17133289e3601 MD5 (7.2-BETA1-ia64-disc2.iso) = eee4987b3686609658fdaccc5960070e MD5 (7.2-BETA1-ia64-disc3.iso) = e7bb48a107e73955ece1a5c156060c34 MD5 (7.2-BETA1-ia64-docs.iso) = edc30334bb334f6adc53142af214a532 MD5 (7.2-BETA1-ia64-livefs.iso) = f6e54bb4cd582d20be8c8896b56d10b9 MD5 (7.2-BETA1-powerpc-bootonly.iso) = eadb2fa7cd289300f65e1bc246ec41bb MD5 (7.2-BETA1-powerpc-disc1.iso) = 463352649f74208e3421c2bdda400e47 MD5 (7.2-BETA1-powerpc-disc2.iso) = 2ec54888eae7931e4ca869fd151856c2 MD5 (7.2-BETA1-powerpc-disc3.iso) = a657ec95fef82c98af1a111d74181dff MD5 (7.2-BETA1-powerpc-docs.iso) = 4061d9d75aa86de96f0682695dd8040b MD5 (7.2-BETA1-sparc64-bootonly.iso) = 93469eab2b36d3f3f1115f603252487d MD5 (7.2-BETA1-sparc64-disc1.iso) = d517489f2048896cd8295f862bcfb6f2 MD5 (7.2-BETA1-sparc64-docs.iso) = e750843e3bb2c91aa31a8fdada2a062f SHA256 (7.2-BETA1-amd64-bootonly.iso) = 88d4d5042a309ab3ccd701250919f81ec80d79c8b3854413919bc6070e456083 SHA256 (7.2-BETA1-amd64-disc1.iso) = 62f6eada40404630e0a98a5e9005a88053675285b4c5f40e7c8535d13f148805 SHA256 (7.2-BETA1-amd64-disc2.iso) = 40c6ad096eb02be1a3ce1dad4ace04e56557258ebb853969120819e8a81ca8aa SHA256 (7.2-BETA1-amd64-disc3.iso) = c3430a4e47d4a4428d5d4719b1ec8907b4a7b36d9c663c41ef02e9795a5ba9cb SHA256 (7.2-BETA1-amd64-docs.iso) = 24dcf4707734439e1fc2c206cba12b951987314208706476386bf5d83fc65699 SHA256 (7.2-BETA1-amd64-dvd1.iso) = 1133fbb4d65afc242c44ea10dba13071d8254d9afb03e9b47668a40197233258 SHA256 (7.2-BETA1-amd64-livefs.iso) = 29d7de7cf139c6b9f1be459f0d7cc50767563d433db6a3eafda880dbfb8059c5 SHA256 (7.2-BETA1-i386-bootonly.iso) = b4d11881cb2209c0d2adab4b4e880ba978b19e38de2b9e78b263341194b6be8b SHA256 (7.2-BETA1-i386-disc1.iso) = 71375c06038a1e18ad769d6585a91449739aafc1e84fdce5d30d84992f6aaf99 SHA256 (7.2-BETA1-i386-disc2.iso) = 75c18bafcf7aae2fb805bd0457ee2bcf51649579e13357102af6dbec72bff450 SHA256 (7.2-BETA1-i386-disc3.iso) = 58e1feb8f84c80e884abec1a509575a96d346d6fd3eea505b61df4b90f0c4c93 SHA256 (7.2-BETA1-i386-docs.iso) = 6bded95d0dfa3dcb252364e4fdde757046bdcb30b6efd0b4d6d130dfec118762 SHA256 (7.2-BETA1-i386-dvd1.iso) = 14ad7e6f0b63fea970733786f2b7705771d06fe1ba980a02c45cf7357b263577 SHA256 (7.2-BETA1-i386-livefs.iso) = cbab873d5bd28ed59cc154bf92d7497546b9d1fb286391cf9e5b7de6fb9a0bb0 SHA256 (7.2-BETA1-ia64-bootonly.iso) = 7d102500543faaab90a5a5d30bec5f493cd4574785a7e33a8aaad2bf6bddd878 SHA256 (7.2-BETA1-ia64-disc1.iso) = 5d6ffec1a0da1b4d65e87ae658e12873ab7b979b77f83ff9090701234a2cce29 SHA256 (7.2-BETA1-ia64-disc2.iso) = 59914cc7514296ee116953bf9eb153e9be795c06e3b63eca52b2f7e89b9d2bbe SHA256 (7.2-BETA1-ia64-disc3.iso) = cd97b56a4a504f25dc3529ca403df9bb28e5cb066efb2820aeeff0421a9e23b4 SHA256 (7.2-BETA1-ia64-docs.iso) = 611ea6c453d4ee9e91bad7f491d53e994c4dabce487250af26e4a0d957abf2ca SHA256 (7.2-BETA1-ia64-livefs.iso) = 128751bcd2eaee9f723efc1cee20f19484e6d328bc0a6e2ade21b458f795058a SHA256 (7.2-BETA1-powerpc-bootonly.iso) = d6851b9b1503e69bdb2b585b9ed3f52f8c8ccf3c8067d37af7ac789149044e5c SHA256 (7.2-BETA1-powerpc-disc1.iso) = b51cf856031a7903d987d25c0a1dac7e4b40db948342f5e654a27b8194422032 SHA256 (7.2-BETA1-powerpc-disc2.iso) = b7a8d8ffa6a3b6e95f3dcdbb6fb4044755e595687c33112c91d9f8dd5e4df826 SHA256 (7.2-BETA1-powerpc-disc3.iso) = 4b6180318ea8874faf5b661b8de9ac1b1d310cc84a759e454530611ad525eb05 SHA256 (7.2-BETA1-powerpc-docs.iso) = 9df4fe36d4f020f2f0af1605f237b7fb454150477560f1cd9a92bb9aed30f2de SHA256 (7.2-BETA1-sparc64-bootonly.iso) = 348fcd9ca7f990247e84b964972be26441815e870676ccd10b1db9959b6a9a3d SHA256 (7.2-BETA1-sparc64-disc1.iso) = 72f4460eadd5509a0524bdd978fe6e4d348a9b8dc81c8ee66fa03945113c72e3 SHA256 (7.2-BETA1-sparc64-docs.iso) = dcf798bf11e792d2441a071cab96c81abf826dee18f31e21d9a4fa89c5f9e2f1 -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090403/0a1b0dba/attachment.pgp From rnoland at FreeBSD.org Thu Apr 2 22:17:51 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Apr 2 22:17:58 2009 Subject: 7.2-PRERELEASE X-server hang in "drmwtq" In-Reply-To: <200904030223.27059.artem_kim@inbox.ru> References: <200904030223.27059.artem_kim@inbox.ru> Message-ID: <1238735828.65025.5.camel@balrog.2hip.net> On Fri, 2009-04-03 at 02:23 +0400, Artem Kim wrote: > Hi. > > In last time, I have a problem with stability > on my system: > > 7.2-PRERELEASE Thu Apr 2 20:20:31 MSD 2009 amd64 (UP); ati 9800-XT > > From time to time the x-server go in "drmwtq" state if the AIGLX is enabled. > This usually happens when creating a new window. > > If I setup hw.dri.0.debug to "1", I get a lot of > messages: > > [drm: pid1469: drm_ioctl] pid = 1469, cmd = 0x80046457, nr = 0x57, dev > 0xffffff0001306800, auth = 1 > [drm: pid1469: drm_ioctl] returning -1 > > I can see a recurring message in in ktrace: > > 1469 Xorg PSIG SIGALRM caught handler = 0x4dca90 mask = 0x0 code = 0x0 > 1469 Xorg CALL sigreturn (0x7fffffffe5b0) > 1469 Xorg RET sigreturn JUSTRETURN > 1469 Xorg CALL ioctl (0xa, 0x80046457, 0x8156e807c) > 1469 Xorg RET ioctl RESTART > > The problems started after vblank rework in the STABLE. > The first time I got a panic when i try to restart or shutdown x-server, > but the problem with panic was solved (for me ;)) quickly. > > I am ready to provide any additional information. > > Many thanks for your work. Ok, I haven't really seen a problem on ati. Intel is a nightmare... I think that I have it all sorted out now, but in order to deal with some of this, I am having to rework all of the drivers. robert. > _______________________________________________ > freebsd-x11@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-x11 > To unsubscribe, send any mail to "freebsd-x11-unsubscribe@freebsd.org" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090403/d6cad1e3/attachment.pgp From kamikaze at bsdforen.de Fri Apr 3 02:43:29 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Fri Apr 3 02:43:36 2009 Subject: powerd broken In-Reply-To: <49CF9C19.3020509@FreeBSD.org> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> Message-ID: <49D5DA33.4010800@bsdforen.de> Alexander Motin wrote: > Dominic Fandrey wrote: >> I can rule out drm0 as the cause, because uhci0 is the only common >> presence in all occurrences of this problem. > > You have other examples? If you mean "irq16: hdac0 uhci+" string, then > "+" there means "and some other devices", which in this case is probably > drm0. > > There were some drm related commits last time and there are also some > IRQ related problems were reported/patched in CURRENT recently. So I > would not ignore this possibility without additional testing. > Is there anything I can do, apart from turning off drm? This is really annoying (well, it eats a whole core while I'm compiling and it keeps the fans going, when the machine should be idle). Is there somehow I can generate useful information? Someone to send a kernel dump to? From marius at nuenneri.ch Fri Apr 3 02:53:10 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Apr 3 02:53:17 2009 Subject: RELENG_7/i386: ZFS constant panic on file system writes In-Reply-To: References: Message-ID: On Thu, Apr 2, 2009 at 22:32, Dmitry Morozovsky wrote: > Pawel, > > could you please help me a bit with *very* unpleasant situation: one of my > servers with very large ZFS reboots on most write requests to one (largest, > which effectively prohibits recreating) ZFS file system with > > panic: avl_find() succeeded inside avl_add() > > (kgdb) bt > #0 ?doadump () at pcpu.h:196 > #1 ?0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 ?0xc0533535 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 ?0xc0836a20 in avl_add (tree=Variable "tree" is not available. > ) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 > #4 ?0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, > fatreader=1, zapp=0xfc6907f8) > ? ?at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 > #5 ?0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc > "daily.20080701.gz", integer_size=8, num_integers=1, buf=0xfc69083c) > ? ?at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 > #6 ?0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, > name=0xfc6908bc "daily.20080701.gz", zpp=0xfc690874, flag=Variable "flag" is > not available. > ) > ? ?at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 > #7 ?0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc > "daily.20080701.gz", vpp=0xfc690b5c) > ? ?at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 > #8 ?0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) > ? ?at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 > #9 ?0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at > vnode_if.c:153 > #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 > #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at > vnode_if.c:99 > #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 > #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 > #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088
0xbfbfd088 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xfc690c18) > ? ?at /usr/src/sys/kern/vfs_syscalls.c:2184 > #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at > /usr/src/sys/kern/vfs_syscalls.c:2167 > #16 0xc06d0288 in syscall (frame=0xfc690d38) at > /usr/src/sys/i386/i386/trap.c:1090 > #17 0xc06b5bc0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #18 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ > > Thanks in advance. Hi Dmitry, I think the line numbers are misleading, see: http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c?v=FREEBSD7;im=bigexcerpts#L262 Could you build a kernel with -O1 or -O0 perhaps that will help. I have no other clue about your situation except maybe try 8-current? - Marius From mav at FreeBSD.org Fri Apr 3 03:07:18 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Apr 3 03:07:25 2009 Subject: powerd broken In-Reply-To: <49D5DA33.4010800@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> Message-ID: <49D5DFD4.5050209@FreeBSD.org> Dominic Fandrey wrote: > Alexander Motin wrote: >> Dominic Fandrey wrote: >>> I can rule out drm0 as the cause, because uhci0 is the only common >>> presence in all occurrences of this problem. >> You have other examples? If you mean "irq16: hdac0 uhci+" string, then >> "+" there means "and some other devices", which in this case is probably >> drm0. >> >> There were some drm related commits last time and there are also some >> IRQ related problems were reported/patched in CURRENT recently. So I >> would not ignore this possibility without additional testing. > > Is there anything I can do, apart from turning off drm? This is really > annoying (well, it eats a whole core while I'm compiling and it keeps > the fans going, when the machine should be idle). As first, try to disable DRI/DRM just to investigate the problem better. If it is related, try to ask Robert Noland , he is our DRI/DRM man. -- Alexander Motin From invite+24=yztyy at facebookmail.com Fri Apr 3 03:48:10 2009 From: invite+24=yztyy at facebookmail.com (Vahid Chitsazzadeh) Date: Fri Apr 3 03:48:17 2009 Subject: Check out my photos on Facebook Message-ID: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. ---------- hello! ---------- Thanks, Vahid To sign up for Facebook, follow the link below: http://www.facebook.com/p.php?i=1485341899&k=3VL2Z65234ZM5DLAYDVYU3&r stable@freebsd.org was invited to join Facebook by Vahid Chitsazzadeh. If you do not wish to receive this type of email from Facebook in the future, please click on the link below to unsubscribe. http://www.facebook.com/o.php?k=936fd1&u=1681869548&mid=3fe309G643f4aecG0G8 Facebook's offices are located at 156 University Ave., Palo Alto, CA 94301. From mav at FreeBSD.org Fri Apr 3 04:06:11 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Apr 3 04:06:19 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> <49D4BF5C.4010509@FreeBSD.org> <49D4F679.5040703@FreeBSD.org> Message-ID: <49D5EDA1.8060104@FreeBSD.org> Dmitry Morozovsky wrote: > On Thu, 2 Apr 2009, Alexander Motin wrote: > AM> Dmitry Morozovsky wrote: > AM> > On Thu, 2 Apr 2009, Alexander Motin wrote: > AM> > > AM> > AM> > ata7: reset tp2 stat0=50 stat1=00 devices=0x1^M > AM> > AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > AM> > AM> > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire^M > AM> > AM> > ad: ad14 already exists; skipping it^M > AM> > AM> > ad: ad14 already exists; skipping it^M > AM> > AM> > ^M > AM> > AM> > ^M > AM> > AM> > Fatal trap 12: page fault while in kernel mode^M > AM> > AM> AM> It looks alike to crash I have already fixed on CURRENT: > AM> > AM> http://svn.freebsd.org/changeset/base/188464 > AM> > > AM> > Seems to be. Would you please ask re@ for MFC approval? > AM> > AM> This is not actually a fix for original problem, but it may help to avoid > AM> system crash. Can you confirm that it helps you, as I haven't tested it on > AM> STABLE yet, I am doing it now. If it helps, I will ask re@. > > Well, partially. Machine survived a dozed of detach-remove-insert-attach > cycles (which it definitly could not before). Merged. > However, it it still paniced on hot-remove-insert (could not dump): > Some other hot reinserts finished successfully. It is probably an ATA code problem. I have reworked that part in HEAD. > Well, at least now it is significally better that before, if one does not > forget to detach ata channel before reinserting the device. -- Alexander Motin From kensmith at cse.Buffalo.EDU Fri Apr 3 05:59:35 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Fri Apr 3 05:59:42 2009 Subject: FreeBSD 7.2-BETA1 Available In-Reply-To: <1238733801.82195.25.camel@neo.cse.buffalo.edu> References: <1238733801.82195.25.camel@neo.cse.buffalo.edu> Message-ID: <1238763568.48371.11.camel@bauer.cse.buffalo.edu> On Fri, 2009-04-03 at 00:43 -0400, Ken Smith wrote: > The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now > available. Well, sort of. Sorry, it's been a couple months since I uploaded something bigger than 2Gb (the dvd images) and I forgot the mechanism that some mirrors use to sync with the master site chokes on files over 2Gb. So the mirrors that use that mechanism to sync won't have it for another couple of hours (I just gzip-ed the dvd images now). If the place you normally get it from doesn't have it at the point you want to download it I know ftp10.us.freebsd.org has got it. By tomorrow all the mirrors should have it. -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090403/e09264f4/attachment.pgp From marck at rinet.ru Fri Apr 3 06:19:45 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Fri Apr 3 06:19:52 2009 Subject: RELENG_7 ata panic on atacontrol attach In-Reply-To: <49D5EDA1.8060104@FreeBSD.org> References: <49D29097.9040701@FreeBSD.org> <49D3BD14.9070505@FreeBSD.org> <49D4BF5C.4010509@FreeBSD.org> <49D4F679.5040703@FreeBSD.org> <49D5EDA1.8060104@FreeBSD.org> Message-ID: On Fri, 3 Apr 2009, Alexander Motin wrote: AM> > AM> This is not actually a fix for original problem, but it may help to avoid AM> > AM> system crash. Can you confirm that it helps you, as I haven't tested it on AM> > AM> STABLE yet, I am doing it now. If it helps, I will ask re@. AM> > AM> > Well, partially. Machine survived a dozed of detach-remove-insert-attach AM> > cycles (which it definitly could not before). AM> AM> Merged. Thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From commercial at troisdnet.com Fri Apr 3 08:35:22 2009 From: commercial at troisdnet.com (troisdnet.com) Date: Fri Apr 3 08:35:30 2009 Subject: Le nettoyage de hottes discount Message-ID: <3E35DBF0-D421-4CE2-8B43-5DDBCE24263A@troisdnet.com> This is the text that will appear if the recipient cannot view HTML messages. Replace this with a plain text version of your message. From horst at sxemacs.org Fri Apr 3 08:59:18 2009 From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III) Date: Fri Apr 3 08:59:27 2009 Subject: Check out my photos on Facebook In-Reply-To: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> References: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> Message-ID: <1238759663.2433.10.camel@horst-tla> On Fri, 2009-04-03 at 03:32 -0700, Vahid Chitsazzadeh wrote: > I set up a Facebook profile where I can post my pictures, videos and events and I want to add you as a friend so you can see it. First, you need to join Facebook! Once you join, you can also create your own profile. On behalf of FreeBSD-STABLE, "not on your fucking life". :) -- Horst -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090403/a361c3e6/attachment.pgp From erratic at devel.ws Fri Apr 3 09:49:31 2009 From: erratic at devel.ws (Paige Thompson) Date: Fri Apr 3 09:49:49 2009 Subject: Check out my photos on Facebook In-Reply-To: <1238759663.2433.10.camel@horst-tla> References: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> <1238759663.2433.10.camel@horst-tla> Message-ID: <5061b39c0904030922m179163e7g7e1a20302a8002b9@mail.gmail.com> hehehe i got yelled at so much for facebook sending mail to mailing lists because theyre in my address book and I imported my address book to facebook. -Adele (sent from my gphone!) On Apr 3, 2009 9:00 AM, "Horst G?nther Burkhardt III" wrote: On Fri, 2009-04-03 at 03:32 -0700, Vahid Chitsazzadeh wrote: > I set up a Facebook profile where I c... On behalf of FreeBSD-STABLE, "not on your fucking life". :) -- Horst From rnoland at FreeBSD.org Fri Apr 3 10:00:50 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 3 10:00:59 2009 Subject: powerd broken In-Reply-To: <49D5DA33.4010800@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> Message-ID: <1238778004.65025.30.camel@balrog.2hip.net> On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: > Alexander Motin wrote: > > Dominic Fandrey wrote: > >> I can rule out drm0 as the cause, because uhci0 is the only common > >> presence in all occurrences of this problem. > > > > You have other examples? If you mean "irq16: hdac0 uhci+" string, then > > "+" there means "and some other devices", which in this case is probably > > drm0. > > > > There were some drm related commits last time and there are also some > > IRQ related problems were reported/patched in CURRENT recently. So I > > would not ignore this possibility without additional testing. > > > > Is there anything I can do, apart from turning off drm? This is really > annoying (well, it eats a whole core while I'm compiling and it keeps > the fans going, when the machine should be idle). > > Is there somehow I can generate useful information? Someone to send a > kernel dump to? Use a radeon? ;( I've been working on the Intel vblank / irq issues. Every time I commit something thinking that I have it resolved, it isn't. So I'm waiting on hardware to arrive that will let me test this all more thoroughly. I do have a patch that I think fixes most of the issues on Intel, but the ddx driver is still doing some silly things that cause issues in some cases. I *think* the only outstanding issue I have with Intel is if something is rendering (synced to vblank or not) when the display goes into dpms sleep, there isn't anything to block that app, so it renders as hard as it can even though it isn't being displayed. In reality, this probably isn't a huge issue, but running gears while the display is asleep keeps the cpu at 100%, which isn't ideal. Normal apps that aren't trying to draw as fast as they can, shouldn't cause an issue. The other issue with my current patches is that I had to change around a fair amount of infrastructure code to try and fix Intel's brain damage, so I have to finish fixing the rest of the drivers so they don't break. I have Intel and radeon fixed, I just have to hit the more obscure drivers. robert. > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090403/6bdc01e9/attachment.pgp From mike at sentex.net Fri Apr 3 11:01:15 2009 From: mike at sentex.net (Mike Tancsa) Date: Fri Apr 3 11:01:22 2009 Subject: FreeBSD 7.2-BETA1 Available In-Reply-To: <1238733801.82195.25.camel@neo.cse.buffalo.edu> References: <1238733801.82195.25.camel@neo.cse.buffalo.edu> Message-ID: <200904031800.n33I0Jdh028897@lava.sentex.ca> At 12:43 AM 4/3/2009, Ken Smith wrote: >The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now >available. Testing of two recent changes to the system would be Just tried out the i386 DVD and all worked great on a shiny new X58 MB from supermicro! And as a bonus, the watchdog actually works! However there are some acpi errors as well as Enhanced SpeedStep doesnt seem to work either. Note, the BIOS version is 1.0 (nothing else available) so it might be the issue. But even without the power saving, the server idles at around 100Watts!! And doing several cat /dev/urandom | md5 pushes it upto just 160W. i7# 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-BETA1 #0: Tue Mar 31 21:01:09 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2660.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100000 AMD Features2=0x1 Cores per package: 8 Logical CPUs per core: 2 real memory = 3212312576 (3063 MB) avail memory = 3137855488 (2992 MB) ACPI APIC Table: <030609 APIC0930> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 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, bff00000 (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 pcib1: at device 1.0 on pci0 pci1: on pcib1 em0: port 0xdc00-0xdc1f mem 0xfaee0000-0xfaefffff,0xfaedc000-0xfaedffff irq 16 at device 0.0 on pci1 em0: Using MSIX interrupts em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] em0: Ethernet address: 00:30:48:d7:c1:6e pcib2: at device 2.0 on pci0 pci2: on pcib2 em1: port 0xec00-0xec1f mem 0xfafe0000-0xfaffffff,0xfafdc000-0xfafdffff irq 16 at device 0.0 on pci2 em1: Using MSIX interrupts em1: [ITHREAD] em1: [ITHREAD] em1: [ITHREAD] em1: Ethernet address: 00:30:48:d7:c1:6f pcib3: at device 3.0 on pci0 pci3: on pcib3 pcib4: at device 7.0 on pci0 pci4: on pcib4 pcib5: at device 9.0 on pci0 pci5: on pcib5 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) 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 0xcc00-0xcc1f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc880-0xc89f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xc800-0xc81f irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfadde000-0xfadde3ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhci3: port 0xc480-0xc49f irq 23 at device 29.0 on pci0 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 0xc400-0xc41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xc080-0xc09f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfaddc000-0xfaddc3ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib6: at device 30.0 on pci0 pci6: on pcib6 vgapci0: mem 0xf9800000-0xf9ffffff,0xfbefc000-0xfbefffff,0xfb000000-0xfb7fffff irq 17 at device 4.0 on pci6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb48f,0xb400-0xb40f irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xb000-0xb007,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa48f,0xa400-0xa40f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] sio2: <16550A-compatible COM port> port 0x3e8-0x3ef irq 5 on acpi0 sio2: type 16550A sio2: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 8F, should be 8C [20070320] est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 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 14 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est3 attach returned 6 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est4 attach returned 6 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est5 attach returned 6 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est6 attach returned 6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est7 attach returned 6 p4tcc7: on cpu7 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [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 ad4: 76319MB at ata2-master SATA150 acd0: DVDROM at ata2-slave UDMA33 SMP: AP CPU #5 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted ichwd module loaded ichwd0: on isa0 ichwd0: Intel ICH10R watchdog timer (ICH10 or equivalent) ppc0: parallel port not found. From peter at simons-rock.edu Fri Apr 3 12:05:00 2009 From: peter at simons-rock.edu (Peter C. Lai) Date: Fri Apr 3 12:05:08 2009 Subject: Check out my photos on Facebook In-Reply-To: <5061b39c0904030922m179163e7g7e1a20302a8002b9@mail.gmail.com> References: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> <1238759663.2433.10.camel@horst-tla> <5061b39c0904030922m179163e7g7e1a20302a8002b9@mail.gmail.com> Message-ID: <20090403184159.GT13398@cesium.hyperfine.info> This is actually a Conficker signature I believe (a Conficker variant spoofs Facebook mails to socially engineer Facebook users to download itself). On 2009-04-03 09:22:46AM -0700, Paige Thompson wrote: > hehehe i got yelled at so much for facebook sending mail to mailing lists > because theyre in my address book and I imported my address book to > facebook. > > -Adele > (sent from my gphone!) > > On Apr 3, 2009 9:00 AM, "Horst G?nther Burkhardt III" > wrote: > > On Fri, 2009-04-03 at 03:32 -0700, Vahid Chitsazzadeh wrote: > I set up a > Facebook profile where I c... > On behalf of FreeBSD-STABLE, "not on your fucking life". > > :) > > -- Horst > _______________________________________________ > 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" -- =========================================================== Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =========================================================== From ianjhart at ntlworld.com Fri Apr 3 13:35:04 2009 From: ianjhart at ntlworld.com (ian j hart) Date: Fri Apr 3 13:35:11 2009 Subject: 7.1-R to RELENG_7 upgrade breaks re nic In-Reply-To: <152F64EF-EE07-4E98-B525-C5F9E1E8B5B7@stevenwills.com> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <152F64EF-EE07-4E98-B525-C5F9E1E8B5B7@stevenwills.com> Message-ID: <200904032134.09546.ianjhart@ntlworld.com> On Tuesday 31 March 2009 04:52:54 Steve Wills wrote: > Hi, > > On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: > > On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > >> Hi, > >> > >> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > >> booting, re0 works for only a short time, then gives "re0: PHY read > >> failed" over and over. Does anyone have a suggestion on how to debug? > > > > I need more information for your hardware revision. > > Would you show me dmesg output and revision number of if_re.c? > > For the record, and if anyone else is having this issue, SVN rev > 190587 fixes this. > > Thanks for taking care of it! > > Steve > > _______________________________________________ > 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 seems to fix it for me too. At least I've had no messages for the last hour (usually 6-10/hour). Good work, now let's get this in 7.2. -- ian j hart From subbsd at gmail.com Fri Apr 3 13:51:21 2009 From: subbsd at gmail.com (subbsd) Date: Fri Apr 3 13:51:28 2009 Subject: FreeBSD 7.2-BETA1 Available In-Reply-To: <200904031800.n33I0Jdh028897@lava.sentex.ca> References: <1238733801.82195.25.camel@neo.cse.buffalo.edu> <200904031800.n33I0Jdh028897@lava.sentex.ca> Message-ID: <200904040026.26304.subbsd@gmail.com> Hello maillist. Can somewhere see release notes for 7.2 now? Thanks! > At 12:43 AM 4/3/2009, Ken Smith wrote: > >The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now > >available. Testing of two recent changes to the system would be From ianjhart at ntlworld.com Fri Apr 3 13:56:23 2009 From: ianjhart at ntlworld.com (ian j hart) Date: Fri Apr 3 13:56:30 2009 Subject: 7.1-R to RELENG_7 upgrade breaks re nic In-Reply-To: <152F64EF-EE07-4E98-B525-C5F9E1E8B5B7@stevenwills.com> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <152F64EF-EE07-4E98-B525-C5F9E1E8B5B7@stevenwills.com> Message-ID: <200904032134.09546.ianjhart@ntlworld.com> On Tuesday 31 March 2009 04:52:54 Steve Wills wrote: > Hi, > > On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: > > On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > >> Hi, > >> > >> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > >> booting, re0 works for only a short time, then gives "re0: PHY read > >> failed" over and over. Does anyone have a suggestion on how to debug? > > > > I need more information for your hardware revision. > > Would you show me dmesg output and revision number of if_re.c? > > For the record, and if anyone else is having this issue, SVN rev > 190587 fixes this. > > Thanks for taking care of it! > > Steve > > _______________________________________________ > 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 seems to fix it for me too. At least I've had no messages for the last hour (usually 6-10/hour). Good work, now let's get this in 7.2. -- ian j hart From alexzhuk at mail.ru Fri Apr 3 18:46:58 2009 From: alexzhuk at mail.ru (Alex) Date: Fri Apr 3 18:47:05 2009 Subject: FreeBSD 7.0 and Samba 3.3.2 crash over ZFS share Message-ID: <49D69F45.6010209@mail.ru> Hi, I have small home file server running FreeBSD 7.0 and 4x500 GBytes ZFS volume. Currently I have Samba 3.0.34 from ports working fine. When I install latest Samba 3.3.2 from ports any access to shares residing on ZFS volume cause panic in samba. Access to UFS share is fine. Any body see same problem? Is it possible to fix? uname -a FreeBSD 7.0-RELEASE-p11 #25: Fri Mar 27 19:13:25 EDT 2009 root@storage:/usr/obj/usr/src/sys/VIAC7 i386 Thank you, Alex From LukeD at pobox.com Fri Apr 3 19:12:03 2009 From: LukeD at pobox.com (Luke Dean) Date: Fri Apr 3 19:12:12 2009 Subject: Radeon r6/7xx support merged to -STABLE In-Reply-To: <1237142952.1774.22.camel@balrog.2hip.net> References: <1237142952.1774.22.camel@balrog.2hip.net> Message-ID: On Sun, 15 Mar 2009, Robert Noland wrote: > I went ahead and merged the Radeon R6/7xx code to -STABLE a while ago. > > The current xorg drivers will not enable it by default on R600+ chips. > You will need to be using xf86-video-ati-6.12.0, > xf86-video-radeonhd-devel or possibly even better git master of either. > > You will need to add the following to the Device section of your > xorg.conf to enable it. If you are experiencing issues, commenting > these two options out, will prevent Xorg from auto-loading the kernel > module. > > Options "DRI" > Options "AccelMethod" "EXA" > > robert. I know it's been a few weeks, but thanks for this work! I'm using a Radeon HD 4350 and tracking -STABLE. Ever since the big xorg update, my system has been crippled. I like to use startx, restart X, and switch consoles with the function keys. The only driver I could find that didn't completely lock up the system when I did these things was the vesa driver, so I've been using it. Even now vesa throws "failed to set mtrr: Invalid argument" on startup and the screen gets corrupted when I change consoles with the function keys, but it doesn't freeze my system, so I've been using it. Today I finally got around to trying out the radeon changes listed above, and now my system is crippled no more! Plus I have graphics acceleration! Thanks! From andsux at gmail.com Fri Apr 3 19:25:49 2009 From: andsux at gmail.com (Andrei) Date: Fri Apr 3 19:26:22 2009 Subject: FreeBSD 7.0 and Samba 3.3.2 crash over ZFS share In-Reply-To: <49D69F45.6010209@mail.ru> References: <49D69F45.6010209@mail.ru> Message-ID: <7ca674500904031857p643dc3e3g30f853296474a3b9@mail.gmail.com> 2009/4/4 Alex > Hi, > I have small home file server running FreeBSD 7.0 and 4x500 GBytes ZFS > volume. Currently I have Samba 3.0.34 from ports working fine. When I > install latest Samba 3.3.2 from ports any access to shares residing on ZFS > volume cause panic in samba. Access to UFS share is fine. > Any body see same problem? > Is it possible to fix? > > uname -a > FreeBSD 7.0-RELEASE-p11 #25: Fri Mar 27 19:13:25 EDT 2009 root@storage:/usr/obj/usr/src/sys/VIAC7 > i386 > > Thank you, > Alex read this guide... http://wiki.freebsd.org/ZFSTuningGuide Upgrade to FreeBSD 7.2 this branch has some patches that improve ZFS, even that .. is not the same as the branch 8 ;) -- **** "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" From horst at sxemacs.org Fri Apr 3 21:31:12 2009 From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III) Date: Fri Apr 3 21:31:19 2009 Subject: Check out my photos on Facebook In-Reply-To: <20090403184159.GT13398@cesium.hyperfine.info> References: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> <1238759663.2433.10.camel@horst-tla> <5061b39c0904030922m179163e7g7e1a20302a8002b9@mail.gmail.com> <20090403184159.GT13398@cesium.hyperfine.info> Message-ID: <1238819471.2433.13.camel@horst-tla> On Fri, 2009-04-03 at 14:41 -0400, Peter C. Lai wrote: > This is actually a Conficker signature I believe (a Conficker variant > spoofs Facebook mails to socially engineer Facebook users to download > itself). I've been reading about Conficker. I honestly didn't think it affected FreeBSD So much for the virus having a classical infection vector :p So has the FreeBSD Security Team done anything about the clear menace of a Windows worm pwning people? ;-) -- Horst -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090404/ca40e555/attachment.pgp From mike at sentex.net Sat Apr 4 00:05:56 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Apr 4 00:06:03 2009 Subject: FreeBSD 7.2-BETA1 crash In-Reply-To: <1238733801.82195.25.camel@neo.cse.buffalo.edu> References: <1238733801.82195.25.camel@neo.cse.buffalo.edu> Message-ID: <200904040705.n3475Gwp033498@lava.sentex.ca> At 12:43 AM 4/3/2009, Ken Smith wrote: >The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now >available. Testing of two recent changes to the system would be >particularly valuable. The bce(4) network driver was updated a few days >ago. And some significant work was done on the threading libraries a >short time ago that is known to fix several major issues but testing to >see if it introduced any regressions would be appreciated. Not sure if its a fluke or not, but I had a crash on a recently upgraded box. March 22 was the previous kernel and csuping to today gave the following panic. panic: vm_page_insert: page already inserted 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"... Unread portion of the kernel message buffer: panic: vm_page_insert: page already inserted cpuid = 0 Uptime: 11h35m56s Physical memory: 2039 MB Dumping 179 MB: 164 148 132 116 100 84 68 52 36 20 4 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/k8temp.ko...done. Loaded symbols for /boot/kernel/k8temp.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:196 #1 0xc05e1207 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05e14d9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc076b4ba in vm_page_insert (m=0xc2a05490, object=0xc59e6200, pindex=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_page.c:642 #4 0xc076ba19 in vm_page_alloc (object=0xc59e6200, pindex=4176, req=64) at /usr/src/sys/vm/vm_page.c:1148 #5 0xc075bb57 in vm_fault (map=0xc5086938, vaddr=183959552, fault_type=2 '\002', fault_flags=Variable "fault_flags" is not available. ) at /usr/src/sys/vm/vm_fault.c:441 #6 0xc07bcdab in trap_pfault (frame=0xe7a08d38, usermode=1, eva=183959552) at /usr/src/sys/i386/i386/trap.c:829 #7 0xc07bd6f7 in trap (frame=0xe7a08d38) at /usr/src/sys/i386/i386/trap.c:397 #8 0xc07a1f4b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #9 0x280a58d0 in ?? () Previous frame inner to this frame (corrupt stack?) From pyunyh at gmail.com Sat Apr 4 02:04:37 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Apr 4 02:04:49 2009 Subject: 7.1-R to RELENG_7 upgrade breaks re nic In-Reply-To: <200904032134.09546.ianjhart@ntlworld.com> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <152F64EF-EE07-4E98-B525-C5F9E1E8B5B7@stevenwills.com> <200904032134.09546.ianjhart@ntlworld.com> Message-ID: <20090404090439.GA27478@michelle.cdnetworks.co.kr> On Fri, Apr 03, 2009 at 09:34:09PM +0100, ian j hart wrote: > On Tuesday 31 March 2009 04:52:54 Steve Wills wrote: > > Hi, > > > > On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: > > > On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > > >> Hi, > > >> > > >> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > > >> booting, re0 works for only a short time, then gives "re0: PHY read > > >> failed" over and over. Does anyone have a suggestion on how to debug? > > > > > > I need more information for your hardware revision. > > > Would you show me dmesg output and revision number of if_re.c? > > > > For the record, and if anyone else is having this issue, SVN rev > > 190587 fixes this. > > > > Thanks for taking care of it! > > > > Steve > > > > _______________________________________________ > > 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 seems to fix it for me too. At least I've had no messages for the last > hour (usually 6-10/hour). > > Good work, now let's get this in 7.2. > Already MFCed to RELENG_7. From pyunyh at gmail.com Sat Apr 4 02:04:37 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Apr 4 02:04:50 2009 Subject: 7.1-R to RELENG_7 upgrade breaks re nic In-Reply-To: <200904032134.09546.ianjhart@ntlworld.com> References: <20090226003842.GB63173@michelle.cdnetworks.co.kr> <152F64EF-EE07-4E98-B525-C5F9E1E8B5B7@stevenwills.com> <200904032134.09546.ianjhart@ntlworld.com> Message-ID: <20090404090439.GA27478@michelle.cdnetworks.co.kr> On Fri, Apr 03, 2009 at 09:34:09PM +0100, ian j hart wrote: > On Tuesday 31 March 2009 04:52:54 Steve Wills wrote: > > Hi, > > > > On Feb 25, 2009, at 7:38 PM, Pyun YongHyeon wrote: > > > On Tue, Feb 24, 2009 at 08:12:18PM -0500, Steve Wills wrote: > > >> Hi, > > >> > > >> I upgraded my 7.1-RELEASE system to RELENG_7 yesterday and after > > >> booting, re0 works for only a short time, then gives "re0: PHY read > > >> failed" over and over. Does anyone have a suggestion on how to debug? > > > > > > I need more information for your hardware revision. > > > Would you show me dmesg output and revision number of if_re.c? > > > > For the record, and if anyone else is having this issue, SVN rev > > 190587 fixes this. > > > > Thanks for taking care of it! > > > > Steve > > > > _______________________________________________ > > 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 seems to fix it for me too. At least I've had no messages for the last > hour (usually 6-10/hour). > > Good work, now let's get this in 7.2. > Already MFCed to RELENG_7. From kamikaze at bsdforen.de Sat Apr 4 03:31:54 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sat Apr 4 03:32:01 2009 Subject: powerd broken In-Reply-To: <1238778004.65025.30.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> Message-ID: <49D73715.6050700@bsdforen.de> Robert Noland wrote: > On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: >> Alexander Motin wrote: >>> Dominic Fandrey wrote: >>>> I can rule out drm0 as the cause, because uhci0 is the only common >>>> presence in all occurrences of this problem. >>> You have other examples? If you mean "irq16: hdac0 uhci+" string, then >>> "+" there means "and some other devices", which in this case is probably >>> drm0. >>> >>> There were some drm related commits last time and there are also some >>> IRQ related problems were reported/patched in CURRENT recently. So I >>> would not ignore this possibility without additional testing. >>> >> Is there anything I can do, apart from turning off drm? This is really >> annoying (well, it eats a whole core while I'm compiling and it keeps >> the fans going, when the machine should be idle). >> >> Is there somehow I can generate useful information? Someone to send a >> kernel dump to? > > Use a radeon? ;( Nay, I use an Intel GM965. > I've been working on the Intel vblank / irq issues. Every time I commit > something thinking that I have it resolved, it isn't. So I'm waiting on > hardware to arrive that will let me test this all more thoroughly. I do > have a patch that I think fixes most of the issues on Intel, but the ddx > driver is still doing some silly things that cause issues in some cases. > I *think* the only outstanding issue I have with Intel is if something > is rendering (synced to vblank or not) when the display goes into dpms > sleep, there isn't anything to block that app, so it renders as hard as > it can even though it isn't being displayed. In reality, this probably > isn't a huge issue, but running gears while the display is asleep keeps > the cpu at 100%, which isn't ideal. Normal apps that aren't trying to > draw as fast as they can, shouldn't cause an issue. > > The other issue with my current patches is that I had to change around a > fair amount of infrastructure code to try and fix Intel's brain damage, > so I have to finish fixing the rest of the drivers so they don't break. > I have Intel and radeon fixed, I just have to hit the more obscure > drivers. > > robert. So it appears all I've got to do is wait. Correct me if I'm wrong. Regards From ivoras at freebsd.org Sat Apr 4 08:36:49 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sat Apr 4 08:36:56 2009 Subject: FreeBSD 7.2-BETA1 crash In-Reply-To: <200904040705.n3475Gwp033498@lava.sentex.ca> References: <1238733801.82195.25.camel@neo.cse.buffalo.edu> <200904040705.n3475Gwp033498@lava.sentex.ca> Message-ID: Mike Tancsa wrote: > At 12:43 AM 4/3/2009, Ken Smith wrote: > >> The first of the test builds for the FreeBSD 7.2-RELEASE cycle is now >> available. Testing of two recent changes to the system would be >> particularly valuable. The bce(4) network driver was updated a few days >> ago. And some significant work was done on the threading libraries a >> short time ago that is known to fix several major issues but testing to >> see if it introduced any regressions would be appreciated. > > > Not sure if its a fluke or not, but I had a crash on a recently upgraded > box. March 22 was the previous kernel and csuping to today gave the > following panic. > > > panic: vm_page_insert: page already inserted I think Alan Cox once said he'd be interested in this particular panic, but I can't find it now. I can find only this: http://www.mail-archive.com/freebsd-stable@freebsd.org/msg102430.html so maybe memtest86 could be useful? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090404/9c9baa08/signature.pgp From rnoland at FreeBSD.org Sat Apr 4 09:45:02 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 4 09:45:09 2009 Subject: powerd broken In-Reply-To: <49D73715.6050700@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49D73715.6050700@bsdforen.de> Message-ID: <1238863450.65025.55.camel@balrog.2hip.net> On Sat, 2009-04-04 at 12:31 +0200, Dominic Fandrey wrote: > Robert Noland wrote: > > On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: > >> Alexander Motin wrote: > >>> Dominic Fandrey wrote: > >>>> I can rule out drm0 as the cause, because uhci0 is the only common > >>>> presence in all occurrences of this problem. > >>> You have other examples? If you mean "irq16: hdac0 uhci+" string, then > >>> "+" there means "and some other devices", which in this case is probably > >>> drm0. > >>> > >>> There were some drm related commits last time and there are also some > >>> IRQ related problems were reported/patched in CURRENT recently. So I > >>> would not ignore this possibility without additional testing. > >>> > >> Is there anything I can do, apart from turning off drm? This is really > >> annoying (well, it eats a whole core while I'm compiling and it keeps > >> the fans going, when the machine should be idle). > >> > >> Is there somehow I can generate useful information? Someone to send a > >> kernel dump to? > > > > Use a radeon? ;( > > Nay, I use an Intel GM965. > > > I've been working on the Intel vblank / irq issues. Every time I commit > > something thinking that I have it resolved, it isn't. So I'm waiting on > > hardware to arrive that will let me test this all more thoroughly. I do > > have a patch that I think fixes most of the issues on Intel, but the ddx > > driver is still doing some silly things that cause issues in some cases. > > I *think* the only outstanding issue I have with Intel is if something > > is rendering (synced to vblank or not) when the display goes into dpms > > sleep, there isn't anything to block that app, so it renders as hard as > > it can even though it isn't being displayed. In reality, this probably > > isn't a huge issue, but running gears while the display is asleep keeps > > the cpu at 100%, which isn't ideal. Normal apps that aren't trying to > > draw as fast as they can, shouldn't cause an issue. > > > > The other issue with my current patches is that I had to change around a > > fair amount of infrastructure code to try and fix Intel's brain damage, > > so I have to finish fixing the rest of the drivers so they don't break. > > I have Intel and radeon fixed, I just have to hit the more obscure > > drivers. > > > > robert. > > So it appears all I've got to do is wait. Correct me if I'm wrong. You can set the tuneable hw.drm.msi=0 for now and see if that helps. I haven't followed this whole thread, but the primary issue that people were having is that interrupts would not work after a vt switch with msi. So, it that isn't your issue, you may need to look elsewhere. robert. > Regards -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090404/ba78de28/attachment.pgp From npapke at acm.org Sat Apr 4 10:29:11 2009 From: npapke at acm.org (Norbert Papke) Date: Sat Apr 4 10:29:18 2009 Subject: powerd broken In-Reply-To: <1238778004.65025.30.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> Message-ID: <200904041001.12249.npapke@acm.org> Hi Robert, On April 3, 2009, Robert Noland wrote: > Use a radeon? ;( Is there any particular model of Radeon PCIe that you would recommend? Cheers, -- Norbert Papke. npapke@acm.org From rnoland at FreeBSD.org Sat Apr 4 11:19:27 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 4 11:19:33 2009 Subject: powerd broken In-Reply-To: <200904041001.12249.npapke@acm.org> References: <1238293386.00093672.1238281804@10.7.7.3> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <200904041001.12249.npapke@acm.org> Message-ID: <1238869120.65025.77.camel@balrog.2hip.net> On Sat, 2009-04-04 at 10:01 -0700, Norbert Papke wrote: > Hi Robert, > > On April 3, 2009, Robert Noland wrote: > > Use a radeon? ;( > > Is there any particular model of Radeon PCIe that you would recommend? Most all of them should work ok... You won't have 3d on r600+ just yet, but... I'm running on an x1650 right now. robert. > Cheers, > > -- Norbert Papke. > npapke@acm.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" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090404/a43a8332/attachment.pgp From mike at sentex.net Sat Apr 4 12:09:33 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Apr 4 12:09:41 2009 Subject: FreeBSD 7.2-BETA1 crash In-Reply-To: References: <1238733801.82195.25.camel@neo.cse.buffalo.edu> <200904040705.n3475Gwp033498@lava.sentex.ca> Message-ID: <200904041908.n34J8qvs037043@lava.sentex.ca> At 11:36 AM 4/4/2009, Ivan Voras wrote: > > > > panic: vm_page_insert: page already inserted > >I think Alan Cox once said he'd be interested in this particular panic, >but I can't find it now. I can find only this: >http://www.mail-archive.com/freebsd-stable@freebsd.org/msg102430.html so >maybe memtest86 could be useful? It could be hardware, but it was working just fine up until the latest csup. I did notice that the box didnt have swap configured correctly, so perhaps memory pressure ? vmstat -m Type InUse MemUse HighUse Requests Size(s) cdev -24 -2K - 0 sigio -1 0K - 0 filedesc 17045222 -16780K - 17112288 16,32,64,128,256,512,1024,2048,4096,8192,32768,65536,131072,262144,524288 kenv -63 -7K - 64 32 kqueue 455704619 -445802K - 456497152 16,32,64,128,512,2048,4096,8192,16384,65536,1048576,2097152,8388608 proc-args 120681083 -118865K - 121705424 16,32,64,128,256,512,1024,131072,262144,1048576,2097152,4194304,8388608 ithread -71 -4K - 0 CAM periph 167 0K - 176 16,32,64 CAM XPT 327 0K - 352 16,32,64,128 KTRACE -100 -11K - 0 linker 6264 -22K - 6368 32,64,256 lockf 1471380092 -1463034K - 1498134688 32,64,128,512,4096,8192,32768,65536,131072,262144,524288,1048576,2097152,4194 304,8388608,33554432,67108864,268435456 temp 174752484 -171192K - 175063904 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,524288,4194304 devbuf 12635 -3677K - 14352 16,32,128,256,512 module -238 -13K - 0 kbdmux -6 -7K - 0 mtx_pool -1 -3K - 0 subproc 273074567 -267642K - 273141760 16,32,64,128,256,512,2048,4096,8192,32768,65536,131072,262144,524288 proc -2 -7K - 0 session 887951 -882K - 902080 16,32,64,128,256,512,1024,2048,4096,16384,65536,131072 pgrp 889648 -884K - 903808 16,64,128,256,512,1024,2048,4096,16384,65536,131072 cred 109121950 -107031K - 109550080 32,128,256,512,1024,2048,8192,16384,65536,131072,262144,1048576,4194304 uidinfo 8947 -9K - 9248 16,32,64,128,256,512,1024,2048 plimit 1162784 -1143K - 1167360 16,32,64,128,512,2048,4096,32768 sysctltmp 229359 -237K - 244336 16,256,512,1024,2048,4096,8192,16384,32768,65536 sysctloid -512 -109K - 3216 16,128,256,2048 sysctl 75757 -77K - 80096 16,32,64,128,256,1024,2048,4096,8192,16384,32768 umtx 2422 -43K - 3136 16,32,64,128,512 p1003.1b -1 0K - 0 bus-sc 2874126 -2846K - 2876000 32,128,256,512,1024,2048,8192,16384 bus 1080919 -1100K - 1085472 16,512,8192,16384,32768 devstat -10 -19K - 0 eventhandler -72 -3K - 0 kobj 110392 -399K - 110592 32,64,256,512 CAM dev queue -1 0K - 0 CAM queue -3 0K - 0 rman 22933 -33K - 23488 16,32,64,128,512,1024,4096 CAM SIM -1 0K - 0 sbuf 466594 -455K - 467104 32,64,128,256,512,1024,2048,4096 ata_generic -1 0K - 0 ad_driver -1 0K - 0 stack 254 0K - 256 32 taskqueue -11 0K - 0 Unitno 17445077 -18171K - 18608096 16,64,128,256,512,1024,2048,4096,8192,32768,65536,131072,262144,524288,2097152,4194304,8388608 iov 349815148 -346318K - 354631424 16,32,256,1024,2048,8192,16384,65536,131072,262144,1048576,2097152,4194304,33554432 ioctlops 3982061 -3944K - 4039776 16,32,64,128,256,512,1024,2048,8192,16384,32768,65536,131072,524288 msg -4 -24K - 0 sem -4 -5K - 0 shm -1 -11K - 0 ttys 604117 -757K - 610048 16,32,128,256,1024,2048,4096,8192,16384,32768 ptys -1 0K - 0 mbuf_tag 1125553087 -1116619K - 1143419040 16,32,64,256,512,2048,4096,8192,16384,65536,524288,2097152,4194304,8388608,134217728 ata_dma -6 0K - 0 pcb 11447289 -11932K - 12210640 16,64,128,256,4096,8192,16384,32768,65536,131072,262144,1048576,2097152,4194304 soname 156656641 -157927K - 161711088 16,64,128,512,1024,2048,8192,16384,32768,65536,131072,262144,524288,1048576,2097152,4194304,8388608,16777216,33554432 biobuf 64797785 -63309K - 64829440 16,32,64,128,256,512,1024,4096,8192,16384,65536,131072,262144 vfscache -1 -511K - 0 cl_savebuf 249742 -247K - 254656 16,64,128,512,4096,8192,32768 export_host -6 0K - 0 vfs_hash -1 -255K - 0 vnodes -1 0K - 0 vnodemarker 9640526 -9432K - 9659392 16,64,128,256,1024,4096,8192,16384,32768,65536,131072 mount 12135 -16K - 12608 16,32,64,128,512,4096 BPF 6 -63K - 16 16 ether_multi 114 0K - 128 32 ifaddr -35 -9K - 0 ifnet -6 -4K - 0 clone 135 -27K - 144 32 arpcom -2 0K - 0 lo -1 0K - 0 ppbusdev -3 0K - 0 entropy -1024 -63K - 0 twe_commands 13052 -27K - 13312 16,64 routetbl 54297 -55K - 54592 16,64,128,1024,2048 in_multi -3 0K - 0 hostcache -1 -19K - 0 syncache -1 -71K - 0 nfss_daemon -17 -15K - 0 nfss_srvdesc 77666040 -76406K - 78241344 16,32,64,512,4096,8192,16384,32768,65536,131072,524288,8388608 nfss_srvsock 507 0K - 512 16,32 audit_evclass 405 -1K - 592 16,64,512 savedino 2131545 -2088K - 2139904 16,32,64,512,2048,4096,8192,16384,32768,65536 dirrem 6668468 -6721K - 6883584 16,32,64,256,512,2048,4096,8192,16384,32768,65536,131072,262144,524288,1048576 mkdir 1962610 -1977K - 2025920 32,64,128,1024,2048,8192,16384,32768,131072,262144,524288 diradd 13195087 -13090K - 13404544 16,64,256,2048,4096,65536,131072,262144,524288,1048576 freefile 5342211 -5385K - 5514592 16,32,64,256,512,1024,2048,4096,8192,16384,32768,65536,524288,1048576 freeblks 43922946 -43070K - 44095232 16,32,64,256,512,2048,4096,8192,16384,32768,65536,524288,1048576 freefrag 1327198 -1337K - 1370016 16,64,128,256,512,4096,8192,16384,131072,262144 allocindir 38490243 -38190K - 39101312 32,64,128,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288,8388608 indirdep 135668539 -132502K - 135683712 128,256,512,1024,2048,8192,16384,32768,65536 allocdirect 29260161 -28798K - 29490560 16,32,128,256,512,1024,2048,4096,8192,16384,32768,65536,131072,262144,524288,1048576 bmsafemap 4742130 -4703K - 4817408 16,32,64,256,512,1024,2048,4096,16384,32768,65536,524288 newblk 53012483 -52591K - 53853952 16,32,128,256,512,1024,2048,4096,16384,65536,131072,262144,524288,1048576,2097152,8388608 inodedep 39635459 -39278K - 39947648 16,32,64,256,4096,8192,65536,131072,262144,2097152 pagedep 8356755 -8353K - 8489408 16,32,64,512,8192,16384,32768,65536,131072,262144,524288,1048576 ufs_dirhash 215232921 -210622K - 215654224 16,32,64,128,256,512,4096,8192,16384,131072,262144,1048576,2097152 ufs_mount -18 -112K - 0 UMAHash 5365 -10K - 5376 16,32,64 DEVFS1 -91 -21K - 0 DEVFS3 -73 -24K - 128 16 DEVFS2 -89 0K - 0 vm_pgdata -1 -63K - 0 DEVFS_RULE -36 -7K - 0 atkbddev -2 0K - 0 DEVFS -11 0K - 16 16 pfs_nodes -20 -1K - 0 GEOM 1418331 -1398K - 1419600 16,32,128,256,512,1024,2048,4096,8192 io_apic -1 0K - 0 memdesc -1 -3K - 0 isadev -23 0K - 0 nexusdev -5 0K - 0 ar_driver 17914 -16K - 17920 32,64 acpica 18915084 -18761K - 19043600 16,64,128,256,512,1024,4096,16384,32768,65536,131072,262144,1048576 acpitask 62 0K - 64 32 acpidev -90 -1K - 0 acpisem -14 0K - 0 pci_link -64 -4K - 0 apmdev -1 0K - 0 From npapke at acm.org Sat Apr 4 12:24:49 2009 From: npapke at acm.org (Norbert Papke) Date: Sat Apr 4 12:24:56 2009 Subject: powerd broken In-Reply-To: <1238869120.65025.77.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <200904041001.12249.npapke@acm.org> <1238869120.65025.77.camel@balrog.2hip.net> Message-ID: <200904041224.47328.npapke@acm.org> On April 4, 2009, Robert Noland wrote: > On Sat, 2009-04-04 at 10:01 -0700, Norbert Papke wrote: > > Hi Robert, > > > > On April 3, 2009, Robert Noland wrote: > > > Use a radeon? ;( > > > > Is there any particular model of Radeon PCIe that you would recommend? > > Most all of them should work ok... You won't have 3d on r600+ just yet, > but... I'm running on an x1650 right now. After a quick check, everything available retail (locally) is r600 or newer. I'll keep an eye open for an older second hand card. Thanks for information and all your hard work. -- Norbert Papke. npapke@acm.org From rnoland at FreeBSD.org Sat Apr 4 12:29:14 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 4 12:29:21 2009 Subject: powerd broken In-Reply-To: <200904041224.47328.npapke@acm.org> References: <1238293386.00093672.1238281804@10.7.7.3> <200904041001.12249.npapke@acm.org> <1238869120.65025.77.camel@balrog.2hip.net> <200904041224.47328.npapke@acm.org> Message-ID: <1238873305.13321.1.camel@balrog.2hip.net> On Sat, 2009-04-04 at 12:24 -0700, Norbert Papke wrote: > On April 4, 2009, Robert Noland wrote: > > On Sat, 2009-04-04 at 10:01 -0700, Norbert Papke wrote: > > > Hi Robert, > > > > > > On April 3, 2009, Robert Noland wrote: > > > > Use a radeon? ;( > > > > > > Is there any particular model of Radeon PCIe that you would recommend? > > > > Most all of them should work ok... You won't have 3d on r600+ just yet, > > but... I'm running on an x1650 right now. > > After a quick check, everything available retail (locally) is r600 or newer. > I'll keep an eye open for an older second hand card. It is rumored that 3d support for the r6/7xx chips will be available soon(tm). For now, you get EXA and Xv acceleration. robert. > Thanks for information and all your hard work. > > -- Norbert Papke. > npapke@acm.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" -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090404/41e87e71/attachment.pgp From Martin.Blapp at t-systems.ch Sun Apr 5 09:28:33 2009 From: Martin.Blapp at t-systems.ch (Blapp, Martin) Date: Sun Apr 5 09:28:40 2009 Subject: FreeBSD 7.2-BETA1 tcp retransmit crash Message-ID: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> Hi all, Looks like the same problem as PR 129197 (FreeBSD 7 panic) http://www.freebsd.org/cgi/query-pr.cgi?pr=129197 OS: FreeBSD 7.2 BETA1 PF: Enabled SACK: net.inet.tcp.sack.enable: 1 Happens after some/many soabort calls ... I can reproduce it after 3-4 hours running time. Currently I'm testing a workaround but I guess the underlying problem should be fixed. -- Martin Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xc07c6cb0 stack pointer = 0x28:0xc2f9c97c frame pointer = 0x28:0xc2f9c984 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 = 25 (em0 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 4h12m47s Physical memory: 499 MB Dumping 104 MB: 89 73 57 41 25 9 Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmmemctl.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmxnet.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko Reading symbols from /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko...done. Loaded symbols for /usr/local/lib/vmware-tools/modules/drivers/vmhgfs.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/modules/accf_smtp.ko...done. Loaded symbols for /boot/modules/accf_smtp.ko #0 doadump () at pcpu.h:196 #1 0xc0772d87 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0773059 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0a5062c in trap_fatal (frame=0xc2f9c93c, eva=12) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0a508b0 in trap_pfault (frame=0xc2f9c93c, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0a5125c in trap (frame=0xc2f9c93c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0a3593b in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc07c6cb0 in sbsndptr (sb=0xc342ede4, off=112, len=113, moff=0xc2f9ca04) at /usr/src/sys/kern/uipc_sockbuf.c:939 #8 0xc089cd64 in tcp_output (tp=0xc43311d0) at /usr/src/sys/netinet/tcp_output.c:798 #9 0xc089974a in tcp_do_segment (m=0xc34a6600, th=0xc34c8024, so=0xc342ed00, tp=0xc43311d0, drop_hdrlen=52, tlen=0) at /usr/src/sys/netinet/tcp_input.c:1835 #10 0xc089b2ee in tcp_input (m=0xc34a6600, off0=20) at /usr/src/sys/netinet/tcp_input.c:846 #11 0xc08340a0 in ip_input (m=0xc34a6600) at /usr/src/sys/netinet/ip_input.c:664 #12 0xc081ae15 in netisr_dispatch (num=2, m=0xc34a6600) at /usr/src/sys/net/netisr.c:185 #13 0xc0810d81 in ether_demux (ifp=0xc31bb400, m=0xc34a6600) at /usr/src/sys/net/if_ethersubr.c:834 #14 0xc0811173 in ether_input (ifp=0xc31bb400, m=0xc34a6600) at /usr/src/sys/net/if_ethersubr.c:692 #15 0xc0561f2a in em_rxeof (adapter=0xc31bc000, count=99) at /usr/src/sys/dev/e1000/if_em.c:4539 #16 0xc0562a57 in em_handle_rxtx (context=0xc31bc000, pending=1) at /usr/src/sys/dev/e1000/if_em.c:1702 #17 0xc07a8015 in taskqueue_run (queue=0xc3181780) at /usr/src/sys/kern/subr_taskqueue.c:282 #18 0xc07a8228 in taskqueue_thread_loop (arg=0xc31c035c) at /usr/src/sys/kern/subr_taskqueue.c:401 #19 0xc074d839 in fork_exit (callout=0xc07a8160 , arg=0xc31c035c, frame=0xc2f9cd38) at /usr/src/sys/kern/kern_fork.c:810 #20 0xc0a359b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 (kgdb) frame 7 #7 0xc07c6cb0 in sbsndptr (sb=0xc342ede4, off=112, len=113, moff=0xc2f9ca04) at /usr/src/sys/kern/uipc_sockbuf.c:939 939 off > 0 && off >= m->m_len; (kgdb) list 934 *moff = off - sb->sb_sndptroff; 935 m = ret = sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; 936 937 /* Advance by len to be as close as possible for the next transmit. */ 938 for (off = off - sb->sb_sndptroff + len - 1; 939 off > 0 && off >= m->m_len; 940 m = m->m_next) { 941 sb->sb_sndptroff += m->m_len; 942 off -= m->m_len; 943 } (kgdb) p sb->sb_sndptr $1 = (struct mbuf *) 0x0 (kgdb) p sb->sb_mb $2 = (struct mbuf *) 0x0 Kein Wunder gibts da nen Crash ... (kgdb) p *sb $8 = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc0747700 , kl_unlock = 0xc07470e0 , kl_locked = 0xc07470c0 , kl_lockarg = 0xc342ee08}, si_flags = 0}, sb_mtx = {lock_object = {lo_name = 0xc0ad4ad8 "so_snd", lo_type = 0xc0ad4ad8 "so_snd", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3272403696, mtx_recurse = 0}, sb_sx = {lock_object = { lo_name = 0xc0ad4ae6 "so_snd_sx", lo_type = 0xc0ad4ae6 "so_snd_sx", lo_flags = 37421056, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, sb_state = 16, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 33580, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048} (kgdb) f 8 #8 0xc089cd64 in tcp_output (tp=0xc43311d0) at /usr/src/sys/netinet/tcp_output.c:798 798 mb = sbsndptr(&so->so_snd, off, len, &moff); p *so $9 = {so_count = 0, so_type = 1, so_options = 12, so_linger = 0, so_state = 24633, so_qstate = 2048, so_pcb = 0xc40e0708, so_proto = 0xc0b994a8, so_head = 0xc4056b60, so_incomp = {tqh_first = 0x0, tqh_last = 0x0}, so_comp = {tqh_first = 0x0, tqh_last = 0x0}, so_list = {tqe_next = 0x0, tqe_prev = 0xc445b02c}, so_qlen = 0, so_incqlen = 0, so_qlimit = 0, so_timeo = 0, so_error = 0, so_sigio = 0x0, so_oobmark = 0, so_aiojobq = { tqh_first = 0x0, tqh_last = 0xc342ed48}, so_rcv = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = {kl_list = { slh_first = 0x0}, kl_lock = 0xc0747700 , kl_unlock = 0xc07470e0 , kl_locked = 0xc07470c0 , kl_lockarg = 0xc342ed74}, si_flags = 0}, sb_mtx = {lock_object = {lo_name = 0xc0ad4adf "so_rcv", lo_type = 0xc0ad4adf "so_rcv", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, sb_sx = {lock_object = { lo_name = 0xc0ad4af0 "so_rcv_sx", lo_type = 0xc0ad4af0 "so_rcv_sx", lo_flags = 37421056, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, sb_state = 32, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 65700, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 1, sb_timeo = 0, sb_flags = 2048}, so_snd = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc0747700 , kl_unlock = 0xc07470e0 , kl_locked = 0xc07470c0 , kl_lockarg = 0xc342ee08}, si_flags = 0}, sb_mtx = {lock_object = {lo_name = 0xc0ad4ad8 "so_snd", lo_type = 0xc0ad4ad8 "so_snd", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3272403696, mtx_recurse = 0}, sb_sx = { lock_object = {lo_name = 0xc0ad4ae6 "so_snd_sx", lo_type = 0xc0ad4ae6 "so_snd_sx", lo_flags = 37421056, lo_witness_data = {lod_list = { stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, sb_state = 16, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 33580, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048}, so_upcall = 0, so_upcallarg = 0x5dc0, so_cred = 0xc4260900, so_label = 0x0, so_peerlabel = 0x0, so_gencnt = 118111, so_emuldata = 0x0, so_accf = 0x0, so_fibnum = 0} (kgdb) p so->so_snd $10 = {sb_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = {kl_list = {slh_first = 0x0}, kl_lock = 0xc0747700 , kl_unlock = 0xc07470e0 , kl_locked = 0xc07470c0 , kl_lockarg = 0xc342ee08}, si_flags = 0}, sb_mtx = {lock_object = {lo_name = 0xc0ad4ad8 "so_snd", lo_type = 0xc0ad4ad8 "so_snd", lo_flags = 16973824, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3272403696, mtx_recurse = 0}, sb_sx = {lock_object = { lo_name = 0xc0ad4ae6 "so_snd_sx", lo_type = 0xc0ad4ae6 "so_snd_sx", lo_flags = 37421056, lo_witness_data = {lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, sx_lock = 1, sx_recurse = 0}, sb_state = 16, sb_mb = 0x0, sb_mbtail = 0x0, sb_lastrecord = 0x0, sb_sndptr = 0x0, sb_sndptroff = 0, sb_cc = 0, sb_hiwat = 33580, sb_mbcnt = 0, sb_mcnt = 0, sb_ccnt = 0, sb_mbmax = 262144, sb_ctl = 0, sb_lowat = 2048, sb_timeo = 0, sb_flags = 2048} (kgdb) f 10 #10 0xc089b2ee in tcp_input (m=0xc34a6600, off0=20) at /usr/src/sys/netinet/tcp_input.c:846 846 tcp_do_segment(m, th, so, tp, drop_hdrlen, tlen); (kgdb) p m $13 = (struct mbuf *) 0xc34a6600 (kgdb) p *m $14 = {m_hdr = {mh_next = 0x0, mh_nextpkt = 0x0, mh_data = 0xc34c8010 "E", mh_len = 52, mh_flags = 3, mh_type = 1, pad = "\000"}, M_dat = {MH = { MH_pkthdr = {rcvif = 0xc31bb400, header = 0x0, len = 52, csum_flags = 3840, csum_data = 65535, tso_segsz = 0, ether_vtag = 0, tags = { slh_first = 0xc4c06b80}}, MH_dat = {MH_ext = {ext_buf = 0xc34c8000 "\005", ext_free = 0, ext_args = 0x0, ext_size = 2048, ref_cnt = 0xc34af9dc, ext_type = 6}, MH_databuf = "\000\200L?\000\000\000\000\000\000\000\000\000\b\000\000??J?\006\000\000\000e\224?\"\230\0058>\a?6\217F????????L?\tc\021?k???s\177?\211?y\214\020\rXr?&yPI\v^N\210??[\005???@?d/\003\215??\2205??RE$\003\020?f\035O0G??\216U\"?????\215`\002???\n\212?\207?r\036??j????HU\234\034???.?b?\031\220???Ae?\0333\207?z?? \025v?<\a?Z?\205W\214?\217\217p]\230?w>?s?"...}}, M_databuf = "\000?\033?\000\000\000\0004\000\000\000\000\017\000\000??\000\000\000\000\000\000\200k??\000\200L?\000\000\000\000\000\000\000\000\000\b\000\000??J?\006\000\000\000e\224?\"\230\0058>\a?6\217F????????L?\tc\021?k???s\177?\211?y\214\020\rXr?&yPI\v^N\210??[\005???@?d/\003\215??\2205??RE$\003\020?f\035O0G??\216U\"?????\215`\002???\n\212?\207?r\036??j????HU\234\034???.?b?\031\220???Ae?\0333\207?z?? \025v?<\a?Z?\205W"...}} From dougb at FreeBSD.org Sun Apr 5 09:37:51 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Apr 5 09:37:58 2009 Subject: Check out my photos on Facebook In-Reply-To: <1238759663.2433.10.camel@horst-tla> References: <18fb180c21bb7e10f6c7fd878ffde0a3@localhost.localdomain> <1238759663.2433.10.camel@horst-tla> Message-ID: <49D783AD.6090408@FreeBSD.org> Please don't respond to spam e-mail on FreeBSD mailing lists, it just creates more spam. I never saw the actual spam, my filter handled it, but I did see all these followups. Also, please don't use profanity on the FreeBSD mailing lists. Thanks, Doug -- This .signature sanitized for your protection From bzeeb-lists at lists.zabbadoz.net Sun Apr 5 09:59:05 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Apr 5 09:59:13 2009 Subject: FreeBSD 7.2-BETA1 tcp retransmit crash In-Reply-To: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> References: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> Message-ID: <20090405163705.U15361@maildrop.int.zabbadoz.net> On Sun, 5 Apr 2009, Blapp, Martin wrote: Hi Martin, > Looks like the same problem as PR 129197 (FreeBSD 7 panic) > > http://www.freebsd.org/cgi/query-pr.cgi?pr=129197 > > OS: FreeBSD 7.2 BETA1 > PF: Enabled > SACK: net.inet.tcp.sack.enable: 1 > > Happens after some/many soabort calls ... I can reproduce it > after 3-4 hours running time. Currently I'm testing a workaround > but I guess the underlying problem should be fixed. I had added a few assertions to HEAD last autumn to catch (possibly different) but still same panics that I haven't MFCed yet. I'll try to get the list of revisions together and get you a diff. With that I'd expect you to either hit a KASSERT or a pnic. -- Bjoern A. Zeeb The greatest risk is not taking one. From bzeeb-lists at lists.zabbadoz.net Sun Apr 5 11:30:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Apr 5 11:30:14 2009 Subject: FreeBSD 7.2-BETA1 tcp retransmit crash In-Reply-To: <20090405163705.U15361@maildrop.int.zabbadoz.net> References: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> <20090405163705.U15361@maildrop.int.zabbadoz.net> Message-ID: <20090405180621.F15361@maildrop.int.zabbadoz.net> On Sun, 5 Apr 2009, Bjoern A. Zeeb wrote: Hi, > On Sun, 5 Apr 2009, Blapp, Martin wrote: > > Hi Martin, > >> Looks like the same problem as PR 129197 (FreeBSD 7 panic) >> >> http://www.freebsd.org/cgi/query-pr.cgi?pr=129197 >> >> OS: FreeBSD 7.2 BETA1 >> PF: Enabled >> SACK: net.inet.tcp.sack.enable: 1 >> >> Happens after some/many soabort calls ... I can reproduce it >> after 3-4 hours running time. Currently I'm testing a workaround >> but I guess the underlying problem should be fixed. > > I had added a few assertions to HEAD last autumn to catch (possibly > different) but still same panics that I haven't MFCed yet. > > I'll try to get the list of revisions together and get you a diff. > With that I'd expect you to either hit a KASSERT or a pnic. Here's the patch of what I found was left un-MFCed: http://people.freebsd.org/~bz/20090405-mfc-r182841-r182842.diff According to your gdb output you are not getting to sbsndptr() with an invalid length so it's less likely to hit the KASSERT(). It would be interesting to see if at least the sbsndptr() patch works and gives you the panic. In that case I'd finally have a positive confirmation that those changes are right and MFC them;-) The ways I had found to hit this had been fixed a year ago and properly MFCed. This one sounds more like a race and other memory problem. What kind of patch are you testing? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From vas at mpeks.tomsk.su Sun Apr 5 19:04:49 2009 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Sun Apr 5 19:04:57 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <20090402044358.GA34249@admin.sibptus.tomsk.ru> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> Message-ID: <20090406020446.GD78037@admin.sibptus.tomsk.ru> Victor Sudakov wrote: > > I have recently submitted 2 PRs > misc/133066 This one was due to a dirty source tree. > misc/133264 This one however is not so simple. I have tried building world under VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building process crashed occasionally if more than 1 CPU is allocated to the virtual machine. The failures are due to various processes like sh, sed or cc1 dupming core on signal 11 during the build. The problem seems to be SMP related because enabling only 1 virtual CPU removes the problem. Of course it is also VMWare related. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From delphij at delphij.net Sun Apr 5 19:10:07 2009 From: delphij at delphij.net (Xin LI) Date: Sun Apr 5 19:10:15 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <20090406020446.GD78037@admin.sibptus.tomsk.ru> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> Message-ID: <49D96475.2070309@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Victor Sudakov wrote: >> misc/133264 > > This one however is not so simple. I have tried building world under > VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building > process crashed occasionally if more than 1 CPU is allocated to the > virtual machine. The failures are due to various processes like sh, > sed or cc1 dupming core on signal 11 during the build. > > The problem seems to be SMP related because enabling only 1 virtual > CPU removes the problem. Of course it is also VMWare related. - From what you have described, it's likely that there is some memory issue. The FreeBSD Virtual Memory system tends to use all physical memory and this could be a problem for faulty memory chips (i.e. it's more easy for FreeBSD to trigger problems). If you have access to the host system and possible, would you please try to install FreeBSD directly and see if the problem still occurs? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZZHUACgkQi+vbBBjt66DbrACfY0tbGQImQgm9PJJGbWDQPZLt FvIAoK+fWNP2eA37Zs6WpSaF0zG83vWg =7wMS -----END PGP SIGNATURE----- From delphij at delphij.net Sun Apr 5 19:50:58 2009 From: delphij at delphij.net (Xin LI) Date: Sun Apr 5 19:51:04 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <20090405223623.0fb6150b@kan.dnsalias.net> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090405223623.0fb6150b@kan.dnsalias.net> Message-ID: <49D96E01.8070107@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Kabaev wrote: > On Sun, 05 Apr 2009 19:09:57 -0700 > Xin LI wrote: >> - From what you have described, it's likely that there is some memory >> issue. The FreeBSD Virtual Memory system tends to use all physical >> memory and this could be a problem for faulty memory chips (i.e. it's >> more easy for FreeBSD to trigger problems). >> >> If you have access to the host system and possible, would you please >> try to install FreeBSD directly and see if the problem still occurs? >> >> Cheers, >> - -- >> Xin LI http://www.delphij.net/ >> FreeBSD - The Power to Serve! > JFYI, > > this seems to be the issue with combination of FreeBSD 6.x and VMWare > hypervisor when running with more than one virtual CPUs. I see it will > the full range of VMWare products, from Player to Fusion and > Workstation. FreeBSD 7 and up are working fine. I see, thanks for the pointer. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZbgAACgkQi+vbBBjt66D7fACgiiqUD6G0YobszxnDpQEvrdtM g80AoJPh1UDufIml6i66iWJw5EdH6uEH =rlCg -----END PGP SIGNATURE----- From kabaev at gmail.com Sun Apr 5 20:08:47 2009 From: kabaev at gmail.com (Alexander Kabaev) Date: Sun Apr 5 20:08:54 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <49D96475.2070309@delphij.net> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> Message-ID: <20090405223623.0fb6150b@kan.dnsalias.net> On Sun, 05 Apr 2009 19:09:57 -0700 Xin LI wrote: > > - From what you have described, it's likely that there is some memory > issue. The FreeBSD Virtual Memory system tends to use all physical > memory and this could be a problem for faulty memory chips (i.e. it's > more easy for FreeBSD to trigger problems). > > If you have access to the host system and possible, would you please > try to install FreeBSD directly and see if the problem still occurs? > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! JFYI, this seems to be the issue with combination of FreeBSD 6.x and VMWare hypervisor when running with more than one virtual CPUs. I see it will the full range of VMWare products, from Player to Fusion and Workstation. FreeBSD 7 and up are working fine. -- Alexander Kabaev From vas at mpeks.tomsk.su Sun Apr 5 21:39:48 2009 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Sun Apr 5 21:39:54 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <49D96475.2070309@delphij.net> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> Message-ID: <20090406043945.GA84052@admin.sibptus.tomsk.ru> Xin LI wrote: > >> misc/133264 > > > > This one however is not so simple. I have tried building world under > > VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building > > process crashed occasionally if more than 1 CPU is allocated to the > > virtual machine. The failures are due to various processes like sh, > > sed or cc1 dupming core on signal 11 during the build. > > > > The problem seems to be SMP related because enabling only 1 virtual > > CPU removes the problem. Of course it is also VMWare related. > > - From what you have described, it's likely that there is some memory > issue. The FreeBSD Virtual Memory system tends to use all physical > memory and this could be a problem for faulty memory chips (i.e. it's > more easy for FreeBSD to trigger problems). How is this connected with the number of virtual CPUs? When I give only 1 CPU to the virtual machine, the problem is gone. > > If you have access to the host system and possible, would you please try > to install FreeBSD directly and see if the problem still occurs? Sorry, I cannot do that. This host is already running several Windows servers and has been thoroughly tested before production use. I have however run Memtest-86 v3.2 in the virtual machine for 2 hours and it has found no errors. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From vas at mpeks.tomsk.su Sun Apr 5 21:40:14 2009 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Sun Apr 5 21:40:21 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <20090405223623.0fb6150b@kan.dnsalias.net> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090405223623.0fb6150b@kan.dnsalias.net> Message-ID: <20090406044011.GB84052@admin.sibptus.tomsk.ru> Alexander Kabaev wrote: > > this seems to be the issue with combination of FreeBSD 6.x and VMWare > hypervisor when running with more than one virtual CPUs. I see it will > the full range of VMWare products, from Player to Fusion and > Workstation. FreeBSD 7 and up are working fine. Is there a hypervisor which has no problems with FreeBSD? I have tried several. 1. Under Microsoft (former Connectix) VirtualPC, FreeBSD has timer problems ("microuptime went backwards"). 2. Under VirtualBox, some processes tend to hang with the obscure kernel mesage "sigreturn: eflags = 0x80286" (the VirtualBox bugtracker claims the issue is fixed, but it is not). 3. Under ESXi, you know. 4. What about Xen? Is it worth trying? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From delphij at delphij.net Sun Apr 5 21:54:33 2009 From: delphij at delphij.net (Xin LI) Date: Sun Apr 5 21:54:40 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <20090406043945.GA84052@admin.sibptus.tomsk.ru> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090406043945.GA84052@admin.sibptus.tomsk.ru> Message-ID: <49D98AFB.2050308@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Victor Sudakov wrote: > Xin LI wrote: >>>> misc/133264 >>> This one however is not so simple. I have tried building world under >>> VMWare ESXi 3.5.0 Update 3 (FreeBSD as a guest OS) and the building >>> process crashed occasionally if more than 1 CPU is allocated to the >>> virtual machine. The failures are due to various processes like sh, >>> sed or cc1 dupming core on signal 11 during the build. >>> >>> The problem seems to be SMP related because enabling only 1 virtual >>> CPU removes the problem. Of course it is also VMWare related. >> - From what you have described, it's likely that there is some memory >> issue. The FreeBSD Virtual Memory system tends to use all physical >> memory and this could be a problem for faulty memory chips (i.e. it's >> more easy for FreeBSD to trigger problems). > > How is this connected with the number of virtual CPUs? > When I give only 1 CPU to the virtual machine, the problem is gone. > >> If you have access to the host system and possible, would you please try >> to install FreeBSD directly and see if the problem still occurs? > > Sorry, I cannot do that. This host is already running several Windows > servers and has been thoroughly tested before production use. > > I have however run Memtest-86 v3.2 in the virtual machine for > 2 hours and it has found no errors. No, memtest is known to be weaker than a 'make world'. According to kan@, it looks like a bug in FreeBSD 6.x :( unfortunately. The good news is that the problem has been fixed in 7.x series. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknZivsACgkQi+vbBBjt66Ag+QCeKj/hsbvPLuiKa65iLsxWj5lt 0JEAnjWtwrGKX11P8h9W2ATmO13dwFT7 =ZVZj -----END PGP SIGNATURE----- From exemys at exemys.com Sun Apr 5 21:55:09 2009 From: exemys at exemys.com (Exemys) Date: Sun Apr 5 21:55:17 2009 Subject: Modbus I/O Module - Analog / Digital Message-ID: <4495e349640a1ba874f88a8169da227b@www.hostmailing.com> 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 eugen at kuzbass.ru Sun Apr 5 23:19:04 2009 From: eugen at kuzbass.ru (Eugene Grosbein) Date: Sun Apr 5 23:19:11 2009 Subject: repeatable 6.4-STABLE kernel panic: sleeping thread Message-ID: <200904060520.n365KZ1U000918@eg.svzserv.kuzbass.ru> >Submitter-Id: current-users >Originator: Eugene Grosbein >Organization: Svyaz Service >Confidential: no >Synopsis: repeatable 6.4-STABLE kernel panic: sleeping thread >Severity: critical >Priority: high >Category: kern >Class: sw-bug >Release: FreeBSD 6.4-STABLE i386 >Environment: System: FreeBSD eg.svzserv.kuzbass.ru 6.4-STABLE FreeBSD 6.4-STABLE #18: Mon Apr 6 12:56:06 KRAST 2009 eugen@eg.svzserv.kuzbass.ru:/usr/local/obj/usr/local/src/sys/EG i386 re(4) network driver >Description: 1 April I've updated my 6.4-STABLE (running 19 March 2009 sources before) to lastest RELENG_6 using standard source upgrade path and now it cannot boot - panices just after inetd start. It boots with kernel.old just fine. My kernel is monolithic and there are no kernel modules loaded other than acpi.ko. Here comes gdb backtrace: Script started on Mon Apr 6 12:07:44 2009 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"... Unread portion of the kernel message buffer: <118> mousechar_start <118>. <118>Starting inetd. Sleeping thread (tid 100084, pid 684) owns a non-sleepable lock sched_switch(c4e74600,0,1,4c477be9,b39fb614,...) at 0xc053ddcf = sched_switch+0x158 mi_switch(1,0) at 0xc0531483 = mi_switch+0x1d5 sleepq_switch(c07a7504,4,0,e752cb3c,c04ef432,...) at 0xc054e0f9 = sleepq_switch+0x93 sleepq_wait_sig(c07a7504,c07a74e0,c07429df,101,0,...) at 0xc054e280 = sleepq_wait_sig+0x21 cv_wait_sig(c07a7504,c07a74e0,e752cb78,8,e752cb58,...) at 0xc04ef432 = cv_wait_sig+0x15a kern_select(c4e74600,8,bfbfe8b0,0,0,...) at 0xc05549ae = kern_select+0x67d select(c4e74600,e752cd04,14,c4e74600,2817f000,...) at 0xc0554327 = select+0x63 syscall(3b,3b,3b,bfbfedc0,bfbfee40,...) at 0xc070822d = syscall+0x34f Xint0x80_syscall() at 0xc06f035f = Xint0x80_syscall+0x1f --- syscall (93, FreeBSD ELF32, select), eip = 0x2816af63, esp = 0xbfbfdb8c, ebp = 0xbfbfee78 --- panic: sleeping thread cpuid = 0 KDB: stack backtrace: kdb_backtrace(c075ab91,0,c07427ff,e35d1bd0,0,...) at 0xc05470aa = kdb_backtrace+0x2f panic(c07427ff,ffffffff,2ac,c4b15a80,e35d1be8,...) at 0xc0528e09 = panic+0x129 propagate_priority(c4b15a80,c4e74600,c05511d8,c4b15a80,e35d1c38,...) at 0xc0550c49 = propagate_priority+0x69 turnstile_wait(c07abfec,c4e74600,0,0,4,...) at 0xc05517b8 = turnstile_wait+0x34b _mtx_lock_sleep(c07abfec,c4b15a80,0,0,0,...) at 0xc051c240 = _mtx_lock_sleep+0x10d tcp_isn_tick(0,0,0,0,1ac3ffac,...) at 0xc0600b86 = tcp_isn_tick+0x4d softclock(0,e35d1cd4,6,363f5101,c4b15a80,...) at 0xc0538396 = softclock+0x2f6 ithread_execute_handlers(c4b14648,c4b63080,0,0,0,...) at 0xc050a353 = ithread_execute_handlers+0x162 ithread_loop(c4aee940,e35d1d38,0,0,0,...) at 0xc050a4ae = ithread_loop+0x64 fork_exit(c050a44a,c4aee940,e35d1d38) at 0xc0508d1e = fork_exit+0x7b fork_trampoline() at 0xc06f036c = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe35d1d6c, ebp = 0 --- Uptime: 6s Dumping 1023 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/modules/snd_hda.ko...done. Loaded symbols for /boot/modules/snd_hda.ko Reading symbols from /boot/modules/sound.ko...done. Loaded symbols for /boot/modules/sound.ko Reading symbols from /boot/modules/aio.ko...done. Loaded symbols for /boot/modules/aio.ko Reading symbols from /boot/modules/acpi.ko...done. Loaded symbols for /boot/modules/acpi.ko #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt full #0 doadump () at pcpu.h:165 No locals. #1 0xc0528ae9 in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:410 first_buf_printf = 1 #2 0xc0528ec8 in panic (fmt=0xc07427ff "sleeping thread") at /usr/local/src/sys/kern/kern_shutdown.c:566 td = (struct thread *) 0xc4b15a80 bootopt = 260 newpanic = 1 ap = 0xc4b15a80 "HF±Äà\215±Ä" buf = "sleeping thread", '\0' #3 0xc0550c49 in propagate_priority (td=0xc4e74600) at /usr/local/src/sys/kern/subr_turnstile.c:209 tc = (struct turnstile_chain *) 0xc4b15a80 ts = (struct turnstile *) 0xc4e73140 pri = 52 #4 0xc05517b8 in turnstile_wait (lock=0xc07abfec, owner=0x0, queue=0) at /usr/local/src/sys/kern/subr_turnstile.c:715 tc = (struct turnstile_chain *) 0xc07a6a38 ts = (struct turnstile *) 0xc4e73140 td = (struct thread *) 0xc4b15a80 td1 = (struct thread *) 0xc4b15a80 #5 0xc051c240 in _mtx_lock_sleep (m=0xc07abfec, tid=3299957376, opts=0, ---Type to continue, or q to quit--- file=0x0, line=0) at /usr/local/src/sys/kern/kern_mutex.c:579 owner = (volatile struct thread *) 0xc4e74600 v = 0 #6 0xc0600b86 in tcp_isn_tick (xtp=0x0) at /usr/local/src/sys/netinet/tcp_subr.c:1485 projected_offset = 0 #7 0xc0538396 in softclock (dummy=0x0) at /usr/local/src/sys/kern/kern_timeout.c:274 c_func = (void (*)(void *)) 0xc0600b39 c_arg = (void *) 0x0 c_mtx = (struct mtx *) 0x0 c_flags = 22 c = (struct callout *) 0x0 bucket = (struct callout_tailq *) 0xd8b21598 curticks = 5545 steps = 0 depth = 3 mpcalls = 1 mtxcalls = 0 gcalls = 2 #8 0xc050a353 in ithread_execute_handlers (p=0xc4b14648, ie=0xc4b63080) at /usr/local/src/sys/kern/kern_intr.c:682 ih = (struct intr_handler *) 0xc4b62880 ihn = (struct intr_handler *) 0xc4c4ea40 ---Type to continue, or q to quit--- #9 0xc050a4ae in ithread_loop (arg=0xc4aee940) at /usr/local/src/sys/kern/kern_intr.c:766 intr_event = (struct intr_thread *) 0xc4aee940 ie = (struct intr_event *) 0xc4b63080 td = (struct thread *) 0xc4b15a80 p = (struct proc *) 0xc4b14648 #10 0xc0508d1e in fork_exit (callout=0xc050a44a , arg=0x0, frame=0x0) at /usr/local/src/sys/kern/kern_fork.c:788 p = (struct proc *) 0xc4b14648 td = (struct thread *) 0x0 #11 0xc06f036c in fork_trampoline () at /usr/local/src/sys/i386/i386/exception.s:208 No locals. (kgdb) frame 6 #6 0xc0600b86 in tcp_isn_tick (xtp=0x0) at /usr/local/src/sys/netinet/tcp_subr.c:1485 1485 INP_INFO_WLOCK(&tcbinfo); (kgdb) l 1480 tcp_isn_tick(xtp) 1481 void *xtp; 1482 { 1483 u_int32_t projected_offset; 1484 1485 INP_INFO_WLOCK(&tcbinfo); 1486 projected_offset = isn_offset_old + ISN_BYTES_PER_SECOND / 100; 1487 1488 if (SEQ_GT(projected_offset, isn_offset)) 1489 isn_offset = projected_offset; (kgdb) quit Script done on Mon Apr 6 12:08:54 2009 I've investigated the case and found that there was only one commit to src/sys/netinet, that was ip_output.c,v 1.242.2.20 I've backed it out, rebuilt kernel and it does not panices anymore. >How-To-Repeat: Build and run RELENG_6 after 24 March 2009. >Fix: Unknown. Workaround is to backout this commit: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/ip_output.c.diff?r1=1.242.2.19;r2=1.242.2.20 Eugene Grosbein From Martin.Blapp at t-systems.ch Mon Apr 6 00:57:15 2009 From: Martin.Blapp at t-systems.ch (Blapp, Martin) Date: Mon Apr 6 00:57:23 2009 Subject: AW: FreeBSD 7.2-BETA1 tcp retransmit crash In-Reply-To: <20090405180621.F15361@maildrop.int.zabbadoz.net> References: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853900@TSS-EXCH01.t-systems.ch> <20090405163705.U15361@maildrop.int.zabbadoz.net>, <20090405180621.F15361@maildrop.int.zabbadoz.net> Message-ID: <509A7CA1EA3EA046B1A5BA2FCFDB3C8EC764853902@TSS-EXCH01.t-systems.ch> Hi, (kgdb) frame 7 #7 0xc07c6cb0 in sbsndptr (sb=0xc342ede4, off=112, len=113, moff=0xc2f9ca04) at /usr/src/sys/kern/uipc_sockbuf.c:939 This is also interesting. Is this an OffByOne somewhere ? As I said it's just a workaround, and for now it didn't crash anymore :-) I could modify this patch to see what happens exactly, dumpping the mbuf. The workaround I currently use is just skipping and dropping this mbuf: --- sys/kern/uipc_sockbuf.c.orig 2009-04-05 18:01:35.000000000 +0200 +++ sys/kern/uipc_sockbuf.c 2009-04-05 18:01:46.000000000 +0200 @@ -930,6 +930,13 @@ return (sb->sb_mb); } + /* + * Try to avoid some retransmit panics + */ + if (sb->sb_sndptr == NULL && sb->sb_mb == NULL) { + return (NULL); + } + /* Return closest mbuf in chain for current offset. */ *moff = off - sb->sb_sndptroff; m = ret = sb->sb_sndptr ? sb->sb_sndptr : sb->sb_mb; --- sys/netinet/tcp_output.c.orig 2009-04-05 18:01:29.000000000 +0200 +++ sys/netinet/tcp_output.c 2009-04-05 18:04:17.000000000 +0200 @@ -797,6 +797,17 @@ */ mb = sbsndptr(&so->so_snd, off, len, &moff); + + /* + * Avoid panics. Mask the error with ENETDOWN + */ + if (mb == NULL) { + SOCKBUF_UNLOCK(&so->so_snd); + (void) m_free(m); + error = ENETDOWN; + goto out; + } + if (len <= MHLEN - hdrlen - max_linkhdr) { m_copydata(mb, moff, (int)len, mtod(m, caddr_t) + hdrlen); From vas at mpeks.tomsk.su Mon Apr 6 06:44:35 2009 From: vas at mpeks.tomsk.su (Victor Sudakov) Date: Mon Apr 6 06:44:43 2009 Subject: Failure to make world for RELENG_6_4 In-Reply-To: <49D98AFB.2050308@delphij.net> References: <20090402044358.GA34249@admin.sibptus.tomsk.ru> <20090406020446.GD78037@admin.sibptus.tomsk.ru> <49D96475.2070309@delphij.net> <20090406043945.GA84052@admin.sibptus.tomsk.ru> <49D98AFB.2050308@delphij.net> Message-ID: <20090406134428.GA99411@admin.sibptus.tomsk.ru> Xin LI wrote: > > According to kan@, it looks like a bug in FreeBSD 6.x :( unfortunately. > The good news is that the problem has been fixed in 7.x series. Yes, I confirm that "make buildworld" works fine for RELENG_7_1 under VMWare ESXi with 2 virtual CPUs, even with -j4 or -j8. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From MondoBancoPosta at bancopostaonline.net Mon Apr 6 12:51:47 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 12:52:09 2009 Subject: Premio vi aspetta! Message-ID: <1239045563.43872.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltà. Per ricevere il bonus è necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltà » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From MondoBancoPosta at bancopostaonline.net Mon Apr 6 13:03:51 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 13:04:05 2009 Subject: Premio vi aspetta! Message-ID: <1239046624.96465.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltà. Per ricevere il bonus è necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltà » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From marck at rinet.ru Tue Apr 7 03:00:30 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Tue Apr 7 03:00:37 2009 Subject: RELENG_7/i386: ZFS constant panic on file system writes In-Reply-To: References: Message-ID: On Fri, 3 Apr 2009, Dmitry Morozovsky wrote: DM> Pawel, DM> DM> could you please help me a bit with *very* unpleasant situation: one of my DM> servers with very large ZFS reboots on most write requests to one (largest, DM> which effectively prohibits recreating) ZFS file system with DM> DM> panic: avl_find() succeeded inside avl_add() Is there a way I can clear the directory in question? Even the latest -current panics when I try to access the directory containing this file. DM> DM> (kgdb) bt DM> #0 doadump () at pcpu.h:196 DM> #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 DM> #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. DM> ) at /usr/src/sys/kern/kern_shutdown.c:574 DM> #3 0xc0836a20 in avl_add (tree=Variable "tree" is not available. DM> ) at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 DM> #4 0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, DM> fatreader=1, zapp=0xfc6907f8) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 DM> #5 0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc DM> "daily.20080701.gz", integer_size=8, num_integers=1, buf=0xfc69083c) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 DM> #6 0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, DM> name=0xfc6908bc "daily.20080701.gz", zpp=0xfc690874, flag=Variable "flag" is DM> not available. DM> ) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 DM> #7 0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc DM> "daily.20080701.gz", vpp=0xfc690b5c) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 DM> #8 0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 DM> #9 0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at DM> vnode_if.c:153 DM> #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 DM> #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at DM> vnode_if.c:99 DM> #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 DM> #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 DM> #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088
0xbfbfd088 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xfc690c18) DM> at /usr/src/sys/kern/vfs_syscalls.c:2184 DM> #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at DM> /usr/src/sys/kern/vfs_syscalls.c:2167 DM> #16 0xc06d0288 in syscall (frame=0xfc690d38) at DM> /usr/src/sys/i386/i386/trap.c:1090 DM> #17 0xc06b5bc0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 DM> #18 0x00000033 in ?? () DM> Previous frame inner to this frame (corrupt stack?) DM> DM> this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ DM> DM> Thanks in advance. DM> DM> -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From pjd at FreeBSD.org Tue Apr 7 03:39:47 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Apr 7 03:45:51 2009 Subject: RELENG_7/i386: ZFS constant panic on file system writes In-Reply-To: References: Message-ID: <20090407101324.GA1473@garage.freebsd.pl> On Tue, Apr 07, 2009 at 02:00:28PM +0400, Dmitry Morozovsky wrote: > On Fri, 3 Apr 2009, Dmitry Morozovsky wrote: > > DM> Pawel, > DM> > DM> could you please help me a bit with *very* unpleasant situation: one of my > DM> servers with very large ZFS reboots on most write requests to one (largest, > DM> which effectively prohibits recreating) ZFS file system with > DM> > DM> panic: avl_find() succeeded inside avl_add() > > Is there a way I can clear the directory in question? Even the latest -current > panics when I try to access the directory containing this file. Could you try running 'zpool scrub' on this pool? Nothing better comes to my mind, it looks like some kind of internal inconsistency and hopefully scrub will be able to find it. Could you also show 'zpool status' output? -- 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/20090407/e179dded/attachment.pgp From jhs at berklix.org Tue Apr 7 05:32:00 2009 From: jhs at berklix.org (Julian Stacey) Date: Tue Apr 7 05:32:10 2009 Subject: more automated fetch of ISO-IMAGES & ports Message-ID: <200904071121.n37BLhbY007253@fire.js.berklix.net> Hi stable@ people, Idea for a SOC or other development: Not all ftp sites carry betas (understandably), that raises an inefficiency of human & net resources also seen similarly on ports/ , eg: I tried to download 7.2-BETA to test, Not on local ftp://ftp2.de.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 ftp://ftp.de.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 Found manually on ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 but slow at 60 KB/s Faster @ 100K from USA ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 but I'd feel guilty loading main site & intercontinental band width. One could rustle up a ports/ entry to fetch ISO-IMAGES automatically from a list of nearest local national sites, using MASTER_SITE_BACKUP &/or MASTER_SITE_OVERRIDE, But does a pseudo port or tool exist already ? Choosing ftp site just by country is crude, (albeit better than global as once was), but if client is near national border, another country's adjacent city might be a nearer & faster server. Some servers for ports/ fetch are also incredibly slow, but fetch will hang in there trying, even if another site lower in the list might be nearer &/or faster. Perhaps some SOC student might like to develop some extension to fetch, or a new tool to intelligently save net bandwidth & human time (if not this year if SOC bids are in, then next) : Intelligently & automatically sniff fetch list to see where stuff is, measure the bandwidth, perhaps on a preliminary README, & automatically decide where to fetch from. & as 2nd stage, give up & try elsewhere if the server connection gets too bad. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From lars.eggert at nokia.com Tue Apr 7 05:55:31 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Tue Apr 7 05:55:39 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <200904071121.n37BLhbY007253@fire.js.berklix.net> References: <200904071121.n37BLhbY007253@fire.js.berklix.net> Message-ID: <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> On 2009-4-7, at 14:21, Julian Stacey wrote: > Perhaps some SOC student might like to develop some extension to > fetch, or a new tool to intelligently save net bandwidth & human > time (if not this year if SOC bids are in, then next) : > Intelligently & automatically sniff fetch list to see where > stuff is, measure the bandwidth, perhaps on a preliminary > README, & automatically decide where to fetch from. > & as 2nd stage, give up & try elsewhere if the server > connection gets too bad. Use BitTorrent for all file distribution, it does all that. Yes, I'm half serious. Lars From lars.eggert at nokia.com Tue Apr 7 06:02:14 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Tue Apr 7 06:02:21 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <49DB4E1F.3070407@bsd.ee> References: <200904071121.n37BLhbY007253@fire.js.berklix.net> <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> <49DB4E1F.3070407@bsd.ee> Message-ID: <59CB691F-EE4D-447E-B2F2-5E4967138FF5@nokia.com> On 2009-4-7, at 15:59, Andrei Kolu wrote: > What about this: > > # cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash > # fastest_cvsup -c us,ee,ru,eu,uk,de,no,se RTT != throughput, and not all files are available via cvsup Lars From jhs at berklix.org Tue Apr 7 06:20:06 2009 From: jhs at berklix.org (Julian Stacey) Date: Tue Apr 7 06:20:16 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: Your message "Tue, 07 Apr 2009 13:21:43 +0200." <200904071121.n37BLhbY007253@fire.js.berklix.net> Message-ID: <200904071233.n37CXHAH008723@fire.js.berklix.net> Hi stable@ people, Ref my: > Found manually on > ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > but slow at 60 KB/s > Faster @ 100K from USA > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > but I'd feel guilty loading main site & intercontinental band width. Erwin Lansing emailed me off list: > ... Are you sure you hit the US mirror? ftp.freebsd.org is a DNS round > robin between a US and a danish mirror, so my guess would be that > if you'd have hit the danish one, it would have been faster. ... Thanks Erwin, You're right, nslookup: Name: ftp.freebsd.org Address: 87.51.34.132 Address: 204.152.184.73 For me in Munich Germany the Danish mirror 87.51.34.132 ftp.beastie.tdk.net. is 10 times faster than USA. 204.152.184.73 freebsd.isc.org. But I wouldn't want to load Denmark needlessly either, so look forward to reading follow up I see starting re. bitorrent & fastest_cvsup etc. Thanks all ! Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From antik at bsd.ee Tue Apr 7 06:23:02 2009 From: antik at bsd.ee (Andrei Kolu) Date: Tue Apr 7 06:23:10 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> References: <200904071121.n37BLhbY007253@fire.js.berklix.net> <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> Message-ID: <49DB4E1F.3070407@bsd.ee> Lars Eggert wrote: > On 2009-4-7, at 14:21, Julian Stacey wrote: >> Perhaps some SOC student might like to develop some extension to >> fetch, or a new tool to intelligently save net bandwidth & human >> time (if not this year if SOC bids are in, then next) : >> Intelligently & automatically sniff fetch list to see where >> stuff is, measure the bandwidth, perhaps on a preliminary >> README, & automatically decide where to fetch from. >> & as 2nd stage, give up & try elsewhere if the server >> connection gets too bad. > > Use BitTorrent for all file distribution, it does all that. Yes, I'm > half serious. > > Lars What about this: # cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash # fastest_cvsup -c us,ee,ru,eu,uk,de,no,se From chris at arnold.se Tue Apr 7 07:43:00 2009 From: chris at arnold.se (Christopher Arnold) Date: Tue Apr 7 07:43:07 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <200904071121.n37BLhbY007253@fire.js.berklix.net> References: <200904071121.n37BLhbY007253@fire.js.berklix.net> Message-ID: On Tue, 7 Apr 2009, Julian Stacey wrote: > Some servers for ports/ fetch are also incredibly slow, but fetch will > hang in there trying, even if another site lower in the list might > be nearer &/or faster. > There is a tool called fastest_sites that uses round trip for the tcp hanshake wich is a little bit better than ping. I wrote about it here: http://www.arnold.se/chris/2008/11/how-to-speed-up-downloading-ports/ But the real solution is to do this the right waw. And we are a couple of people involved in making this happen. Notheing ready yet but be shure you will read all about it soon on a mailling list close to you... /Chris -- http://www.arnold.se/chris From smithi at nimnet.asn.au Tue Apr 7 07:45:48 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Tue Apr 7 07:45:57 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <200904071233.n37CXHAH008723@fire.js.berklix.net> References: <200904071233.n37CXHAH008723@fire.js.berklix.net> Message-ID: <20090408001501.Y14708@sola.nimnet.asn.au> On Tue, 7 Apr 2009, Julian Stacey wrote: > Hi stable@ people, > Ref my: > > Found manually on > > ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > > but slow at 60 KB/s > > Faster @ 100K from USA > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > > but I'd feel guilty loading main site & intercontinental band width. > > Erwin Lansing emailed me off list: > > ... Are you sure you hit the US mirror? ftp.freebsd.org is a DNS round > > robin between a US and a danish mirror, so my guess would be that > > if you'd have hit the danish one, it would have been faster. ... > > Thanks Erwin, You're right, nslookup: > Name: ftp.freebsd.org > Address: 87.51.34.132 > Address: 204.152.184.73 > For me in Munich Germany the Danish mirror > 87.51.34.132 ftp.beastie.tdk.net. > is 10 times faster than USA. > 204.152.184.73 freebsd.isc.org. > > But I wouldn't want to load Denmark needlessly either, so look > forward to reading follow up I see starting re. bitorrent & > fastest_cvsup etc. Thanks all ! http://www.mavetju.org/unix/freebsd-mirrors/ usually works for me .. doesn't show RTT or bandwidth directly, but Edwin might even share his secret recipe, offered enough $beer .. The 10 day score overview indeed shows .de mirrors improving yesterday from a not so hot score recently, and 7.2-BETA only on a few so far. cheers, Ian From oberman at es.net Tue Apr 7 07:55:19 2009 From: oberman at es.net (Kevin Oberman) Date: Tue Apr 7 07:55:26 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: Your message of "Tue, 07 Apr 2009 15:55:20 +0300." <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> Message-ID: <20090407145512.1EC781CC50@ptavv.es.net> > From: Lars Eggert > Date: Tue, 7 Apr 2009 15:55:20 +0300 > Sender: owner-freebsd-stable@freebsd.org > > On 2009-4-7, at 14:21, Julian Stacey wrote: > > Perhaps some SOC student might like to develop some extension to > > fetch, or a new tool to intelligently save net bandwidth & human > > time (if not this year if SOC bids are in, then next) : > > Intelligently & automatically sniff fetch list to see where > > stuff is, measure the bandwidth, perhaps on a preliminary > > README, & automatically decide where to fetch from. > > & as 2nd stage, give up & try elsewhere if the server > > connection gets too bad. > > Use BitTorrent for all file distribution, it does all that. Yes, I'm > half serious. Why only half? I have pulled FreeBSD ISOs via torrent and it was stunning to see the performance. The system I was loading it to had (at the time) only a fastE (100Mbps), but it loaded at a steady 90+ Mbps and spent a lot of time above 95M. Now that I am connected from that system at 1000M, I should see how it does. -- 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 lars.eggert at nokia.com Tue Apr 7 08:14:40 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Tue Apr 7 08:15:13 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <20090407145512.1EC781CC50@ptavv.es.net> References: <20090407145512.1EC781CC50@ptavv.es.net> Message-ID: <33AEED2F-800F-4DE2-AAA5-8A8E60736426@nokia.com> On 2009-4-7, at 17:55, Kevin Oberman wrote: >> Use BitTorrent for all file distribution, it does all that. Yes, I'm >> half serious. > > Why only half? I have pulled FreeBSD ISOs via torrent and it was > stunning to see the performance. Half, because getting a BitTorrent infrastructure in place for the ports distfiles wold take a bit of effort. Lars > > The system I was loading it to had (at the time) only a fastE > (100Mbps), > but it loaded at a steady 90+ Mbps and spent a lot of time above > 95M. Now that I am connected from that system at 1000M, I should see > how > it does. > -- > 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 m.e.sanliturk at gmail.com Tue Apr 7 08:42:51 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Tue Apr 7 08:42:57 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> References: <200904071121.n37BLhbY007253@fire.js.berklix.net> <24269939-A622-44A6-9F9C-F816E03BE31F@nokia.com> Message-ID: BitTorrent is NOT always a good solution . I tried it on an approximately 4.5 Giga Bytes iso which came out to be unusable because - direct download is taken minimum 12 hours with a 1024 kilo bits per second down load speed , in average 18 hours from Turkey . - BitTorrent download is reaching in average to 45 hours due to 256 kilo bits up loads where my PC is also used as a server for down loaders to share my downloaded parts . I am not escaping to help to other people but to find a 45 hours continuous time without destructive voltage fluctuations and nearly dedicate a PC so much time is difficult . On Tue, Apr 7, 2009 at 8:55 AM, Lars Eggert wrote: > On 2009-4-7, at 14:21, Julian Stacey wrote: > >> Perhaps some SOC student might like to develop some extension to >> fetch, or a new tool to intelligently save net bandwidth & human >> time (if not this year if SOC bids are in, then next) : >> Intelligently & automatically sniff fetch list to see where >> stuff is, measure the bandwidth, perhaps on a preliminary >> README, & automatically decide where to fetch from. >> & as 2nd stage, give up & try elsewhere if the server >> connection gets too bad. >> > > Use BitTorrent for all file distribution, it does all that. Yes, I'm half > serious. > > Lars From oberman at es.net Tue Apr 7 11:15:37 2009 From: oberman at es.net (Kevin Oberman) Date: Tue Apr 7 11:15:46 2009 Subject: more automated fetch of ISO-IMAGES & ports In-Reply-To: Your message of "Tue, 07 Apr 2009 11:13:25 EDT." Message-ID: <20090407181531.686721CC53@ptavv.es.net> > Date: Tue, 7 Apr 2009 11:13:25 -0400 > From: Mehmet Erol Sanliturk > Sender: owner-freebsd-stable@freebsd.org > > BitTorrent is NOT always a good solution . > > I tried it on an approximately 4.5 Giga Bytes iso which came out to be > unusable because > > - direct download is taken minimum 12 hours with a 1024 kilo bits per second > down load speed , > in average 18 hours from Turkey . > > - BitTorrent download is reaching in average to 45 hours due to 256 kilo > bits up loads where > my PC is also used as a server for down loaders to share my downloaded > parts . > > I am not escaping to help to other people but to find a 45 hours continuous > time without destructive voltage fluctuations and nearly dedicate a PC so > much time is difficult . No, bittorrent is should not replace conventional tranfers. It would be an additional way to distribute large data sets (like the DVD image). There are many cases, like this one, where it is not a good fit. That is true of most tools. Where it is a good fit, it works extremely well. -- 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 kamikaze at bsdforen.de Tue Apr 7 12:04:58 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Tue Apr 7 12:05:08 2009 Subject: powerd broken In-Reply-To: <1238863450.65025.55.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49D73715.6050700@bsdforen.de> <1238863450.65025.55.camel@balrog.2hip.net> Message-ID: <49DBA3D3.70407@bsdforen.de> Robert Noland wrote: > On Sat, 2009-04-04 at 12:31 +0200, Dominic Fandrey wrote: >> Robert Noland wrote: >>> On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: >>>> Alexander Motin wrote: >>>>> Dominic Fandrey wrote: >>>>>> I can rule out drm0 as the cause, because uhci0 is the only common >>>>>> presence in all occurrences of this problem. >>>>> You have other examples? If you mean "irq16: hdac0 uhci+" string, then >>>>> "+" there means "and some other devices", which in this case is probably >>>>> drm0. >>>>> >>>>> There were some drm related commits last time and there are also some >>>>> IRQ related problems were reported/patched in CURRENT recently. So I >>>>> would not ignore this possibility without additional testing. >>>>> >>>> Is there anything I can do, apart from turning off drm? This is really >>>> annoying (well, it eats a whole core while I'm compiling and it keeps >>>> the fans going, when the machine should be idle). >>>> >>>> Is there somehow I can generate useful information? Someone to send a >>>> kernel dump to? >>> Use a radeon? ;( >> Nay, I use an Intel GM965. >> >>> I've been working on the Intel vblank / irq issues. Every time I commit >>> something thinking that I have it resolved, it isn't. So I'm waiting on >>> hardware to arrive that will let me test this all more thoroughly. I do >>> have a patch that I think fixes most of the issues on Intel, but the ddx >>> driver is still doing some silly things that cause issues in some cases. >>> I *think* the only outstanding issue I have with Intel is if something >>> is rendering (synced to vblank or not) when the display goes into dpms >>> sleep, there isn't anything to block that app, so it renders as hard as >>> it can even though it isn't being displayed. In reality, this probably >>> isn't a huge issue, but running gears while the display is asleep keeps >>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying to >>> draw as fast as they can, shouldn't cause an issue. >>> >>> The other issue with my current patches is that I had to change around a >>> fair amount of infrastructure code to try and fix Intel's brain damage, >>> so I have to finish fixing the rest of the drivers so they don't break. >>> I have Intel and radeon fixed, I just have to hit the more obscure >>> drivers. >>> >>> robert. >> So it appears all I've got to do is wait. Correct me if I'm wrong. > > You can set the tuneable hw.drm.msi=0 for now and see if that helps. I > haven't followed this whole thread, but the primary issue that people > were having is that interrupts would not work after a vt switch with > msi. So, it that isn't your issue, you may need to look elsewhere. That doesn't make any difference. Turning hardware acceleration helps, though. However I cannot play Quake that way. From peter at pean.org Tue Apr 7 14:33:25 2009 From: peter at pean.org (=?ISO-8859-1?Q?Peter_Ankerst=E5l?=) Date: Tue Apr 7 14:33:42 2009 Subject: SMART for mpt raid. Message-ID: Hi, I have a mpt raid and want to run smart on the individual drives. But the examples in the config all seems linux-specific. Is there a way to get SMART-status for the drives in a mpt-raid? -- Peter Ankerst?l peter@pean.org http://www.pean.org/ From pluknet at gmail.com Tue Apr 7 15:36:21 2009 From: pluknet at gmail.com (pluknet) Date: Tue Apr 7 15:36:29 2009 Subject: hald/geom(?) lock up In-Reply-To: References: Message-ID: [redirected from -current] Seeing a similar locking issue on stable/7 as of April 5 now (I guess some pieces merged from -current caused that). 2009/2/10 pluknet : > Hi all. > > On recent -current after inserting a CD my system locks up in a few minutes. > Any commands I tried then lock on sysctl lock; i.e. ctrl+t returns: > load: 0.04 cmd: sudo 1008 [sysctl lock] 0.00u 0.00s 0% 312k > > FreeBSD 8.0-CURRENT #19: Tue Feb 10 00:24:21 UTC 2009 > > Captured ddb (partially transcribed as ddb capture does not return some data): > > db> show alllocks > > Process 924 (sshd) thread 0xc5d606c0 (100107) > exclusive sx so_rcv_sx ... uipc_sockbuf.c:148 > Process 890 (hald-addon-storage) thread 0xc5afd240 (100091) > exclusive sx GEOM topology ... geom_dev.c:171 > Process 880 (hald) thread 0xc5d60900 (100106) > exclusive sx sysctl lock ... kern_sysctl.c:1510 > Process 12 (intr) thread 0xc5663000 (100023) > exclusive sleep mutex Giant ... kbdmux.c:1044 > db> bt 890 > > Tracing pid 890 tid 100091 td 0xc5afd240 > sched_switch(c5afd240,0,104,18d,ae7e8399,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200 > sleepq_switch(c5afd240,0,c0805c50,26a,2,...) at sleepq_switch+0x15f > sleepq_timedwait(c089b424,0,c07f05e9,2,0,...) at sleepq_timedwait+0x6b > _sleep(c089b424,0,0,c07f05e9,1f4,...) at _sleep+0x329 > pause(c07f05e9,1f4,10,c5e170d0,c5986200,...) at pause+0x47 > acd_geom_access(c5986200,1,0,0,0,...) at acd_geom_access+0xeb > g_access(c5989340,1,0,0,2000,...) at g_access+0x20b > g_dev_open(c59a0500,1,2000,c5afd240,c052a7b4,...) at g_dev_open+0x104 > devfs_open(e7f1cacc,c5afd240,e7f1cba8,0,e7f1caf4,...) at devfs_open+0xe6 > VOP_OPEN_APV(c0847e80,e7f1cacc,c07fd022,c07fa9c9,c5decb84,...) at > VOP_OPEN_APV+0xa5 > vn_open_cred(e7f1cba8,e7f1cc5c,0,c5512900,c5de47a8,...) at vn_open_cred+0x429 > vn_open(e7f1cba8,e7f1cc5c,0,c5de47a8,3,...) at vn_open+0x33 > kern_openat(c5afd240,ffffff9c,bfbfe490,0,1,...) at kern_openat+0x110 > kern_open(c5afd240,bfbfe490,0,0,0,...) at kern_open+0x35 > open(c5afd240,e7f1ccf8,c,c0818fe7,c084b2d8,...) at open+0x30 > syscall(e7f1cd38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281c5fd3, esp = > 0xbfbfe19c, ebp = 0xbfbfe1c8 --- > db> bt 880 > > Tracing pid 880 tid 100106 td 0xc5d60900 > sched_switch(c5d60900,0,104,18d,dc8c7829,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,4c,...) at mi_switch+0x200 > sleepq_switch(c5d60900,0,c0805c50,26a,0,...) at sleepq_switch+0x15f > sleepq_timedwait(c5c8e200,4c,c07f97cd,0,0,...) at sleepq_timedwait+0x6b > _sleep(c5c8e200,0,4c,c07f97cd,3e8,...) at _sleep+0x329 > g_waitfor_event(c0542cb0,c59847e0,2,0,0,...) at g_waitfor_event+0x9c > sysctl_kern_geom_conftxt(c08493c0,0,0,e7f72ba4,e7f72ba4,...) at > sysctl_kern_geom_conftxt+0x58 > sysctl_root(e7f72ba4,0,c0802669,5e6,c5d60900,...) at sysctl_root+0x199 > userland_sysctl(c5d60900,e7f72c10,3,0,bfbfe9c4,...) at userland_sysctl+0x115 > __sysctl(c5d60900,e7f72cf8,18,c08087f9,c084c550,...) at __sysctl+0x94 > syscall(e7f72d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28350b3f, esp = > 0xbfbfe8bc, ebp = 0xbfbfe8e8 --- > db> c > > [thread pid 12 tid 100023 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> ps > > pid ppid pgrp uid state wmesg wchan cmd > 1113 932 1113 1001 S+ sysctl l 0xc089b464 ls > 1042 1 1042 0 Ss select 0xc5e3aaa4 sshd > 981 884 880 0 S select 0xc5c950a4 initial thread > 932 868 932 1001 S+ wait 0xc5af7a90 bash > 929 928 929 1001 Ss+ ttyin 0xc575e270 bash > 928 924 924 1001 S select 0xc5799624 sshd > 924 1 924 0 Ss sbwait 0xc5df7238 sshd > 890 884 880 0 S acdld 0xc089b424 initial thread > 884 880 880 0 S select 0xc5989de4 initial thread > 883 1 883 0 Ss (threaded) console-kit-daemon > 100111 S waitvt 0xc0896f84 console-kit-daemon > 100125 S waitvt 0xc0896fbc console-kit-daemon > 100124 S waitvt 0xc0896fb8 console-kit-daemon > 100123 S waitvt 0xc0896fb4 console-kit-daemon > 100122 S waitvt 0xc0896fb0 console-kit-daemon > 100121 S waitvt 0xc0896fac console-kit-daemon > 100120 S waitvt 0xc0896fa8 console-kit-daemon > 100119 S waitvt 0xc0896fa4 console-kit-daemon > 100118 S waitvt 0xc0896fa0 console-kit-daemon > db> bt 1113 > > Tracing pid 1113 tid 100126 td 0xc5d5f6c0 > sched_switch(c5d5f6c0,0,104,18d,6d4b9014,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200 > sleepq_switch(c5d5f6c0,0,c0805c50,247,c089b464,...) at sleepq_switch+0x15f > sleepq_wait(c089b464,0,c0802757,3,0,...) at sleepq_wait+0x63 > _sx_xlock_hard(c089b464,c5d5f6c0,0,c0802669,5e6,...) at _sx_xlock_hard+0x286 > _sx_xlock(c089b464,0,c0802669,5e6,c5d5f6c0,...) at _sx_xlock+0xc0 > userland_sysctl(c5d5f6c0,e7faec10,2,bfbfeacc,bfbfead0,...) at > userland_sysctl+0xf1 > __sysctl(c5d5f6c0,e7faecf8,18,c,c084c550,...) at __sysctl+0x94 > syscall(e7faed38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x2806147b, esp = > 0xbfbfea6c, ebp = 0xbfbfea98 --- > db> c > ^^^ I experienced a similar lockup when inserted a flash drive. Sorry, not too much info saved here: o exclusive sx lock @ kern_sysctl.c:1501 o exclusive sx GEOM topology @ g_part.c:1514 After a half hour or something like that the system went in its normal state. Then the system locked up again after I tried a dumb `mount /dev/cd1 /mnt`, ^T showed that mount locked at [cgticb] wait channel. db> show alllocks Process 66819 (mount) thread 0xc467c460 (100130) exclusive sx GEOM topology .. locked @ .. ffs_vfsops.c:633 Process 1479 (sshd) thread 0xc467caf0 (100127) Process 1156 (hald) thread 0xc4201d20 (100078) exclusive sx sysctl lock ... locked @ .. kern_sysctl.c:1501 Process 898 (hcsecd) thread 0xc4163af0 (100071) Process 15 (swi6: Giant taskq) thread 0xc3c95000 (100010) db> show lockedvnods Locked vnodes db> bt 66819 Tracing pid 66819 tid 100130 td 0xc467c460 sched_switch(c467c460,0,1,180,66eaa085,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,c467c460,...) at mi_switch+0x243 sleepq_switch(c467c460,0,c07bc615,243,4c,...) at sleepq_switch+0x182 sleepq_wait(c6f17b3c,0,c07b95b9,dc,0,...) at sleepq_wait+0x60 _sleep(c6f17b3c,0,4c,c079982f,0,...) at _sleep+0x399 cam_periph_getccb(c6f17b00,1,c0799bcf,e66ba82c,c055eb94,1) at cam_periph_getccb+0xcd cdgetccb(c5975800,e66ba844,c044368a,c082b4ec,0,...) at cdgetccb+0xd8 cdcheckmedia(c6f17b00,14c,c07a0e6c,b7,0,...) at cdcheckmedia+0x5d cdopen(c71ca200,4,c07b09ca,75,1,...) at cdopen+0xed g_disk_access(c6edc280,1,1,1,1,...) at g_disk_access+0x11d g_access(c4e7cbc0,1,1,1,c6ed9980,...) at g_access+0x229 g_vfs_open(c64088a0,e66baa30,c07c3923,1,c467c460,...) at g_vfs_open+0xae ffs_mount(c3ffab40,c467c460,c07c3c78,3f0,0,...) at ffs_mount+0x17a2 vfs_donmount(c467c460,0,c437a580,c437a580,804b907,...) at vfs_donmount+0x135d nmount(c467c460,e66bacfc,c,e66bad38,c08033b0,...) at nmount+0xab syscall(e66bad38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280dc6c7, esp = 0xbfbfdbcc, ebp = 0xbfbfe128 --- db> bt 1156 Tracing pid 1156 tid 100078 td 0xc4201d20 sched_switch(c4201d20,0,1,180,b08e54c,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,4c,...) at mi_switch+0x243 sleepq_switch(c4201d20,0,c07bc615,266,4c,...) at sleepq_switch+0x182 sleepq_timedwait(c6ede200,3e8,c07b0fa6,0,0,...) at sleepq_timedwait+0x68 _sleep(c6ede200,0,4c,c07b0fa6,3e8,...) at _sleep+0x375 g_waitfor_event(c0517400,c4b86d80,2,0,51f,...) at g_waitfor_event+0x9c sysctl_kern_geom_conftxt(c07ff820,0,0,e65f8ba4,e65f8ba4,...) at sysctl_kern_geom_conftxt+0x58 sysctl_root(e65f8ba4,0,c07b978b,5dd,c4201d20,...) at sysctl_root+0x1b5 userland_sysctl(c4201d20,e65f8c14,3,0,bfbfe9c4,...) at userland_sysctl+0x131 __sysctl(c4201d20,e65f8cfc,18,c07beafb,c0802330,...) at __sysctl+0x98 syscall(e65f8d38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28338763, esp = 0xbfbfe8bc, ebp = 0xbfbfe8e8 --- db> bt 898 Tracing pid 898 tid 100071 td 0xc4163af0 sched_switch(c4163af0,0,1,180,a2924776,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,c4160588,...) at mi_switch+0x243 sleepq_switch(c4160588,0,c07bc615,19e,c415e8dc,...) at sleepq_switch+0x182 sleepq_catch_signals(c055e864,c0847ec0,4,c07b782d,58,...) at sleepq_catch_signals+0x26d sleepq_wait_sig(c415e8dc,0,c07b95b9,dc,0,...) at sleepq_wait_sig+0x14 _sleep(c415e8dc,c415e894,158,c07c13a1,0) at _sleep+0x389 sbwait(c415e870,4,c07c1456,5b0,c415e894,...) at sbwait+0x76 soreceive_generic(c415e820,e65e2be8,e65e2bf4,0,0,...) at soreceive_generic+0x400 soreceive(c415e820,e65e2be8,e65e2bf4,0,0,...) at soreceive+0x38 kern_recvit(c4163af0,3,e65e2c60,0,0,...) at kern_recvit+0x153 recvit(bfbfee74,e65e2c64,4,bfbfec2e,200,bfbfee2e,22,e65e2c58,1,0,2817b878,0) at recvit+0x31 recvfrom(c4163af0,e65e2cfc,18,c07d2c3a,c08012f8,...) at recvfrom+0x76 syscall(e65e2d38) at syscall+0x2d3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x281233c7, esp = 0xbfbfebfc, ebp = 0xbfbfee88 --- db> capture off After some minutes the system console spammed with a number of calcru: runtime went backwards.... and one g_vfs_done():cd1[READ(offset=65536, length=8192)]error=5 continuing to stay in some lockup state. Then I tasted ddb again: db> show alllocks Process 898 (hcsecd) thread 0xc4163af0 (100071) Process 15 (swi6: Giant taskq) thread 0xc3c95000 (100010) Process 3 (g_event) thread 0xc3c50230 (100006) exclusive sx GEOM topology .. locked @ .. geom_event.c:185 db> bt 3 Tracing pid 3 tid 100006 td 0xc3c50230 sched_switch(c3c50230,0,1,180,ecfc9041,...) at sched_switch+0x253 mi_switch(1,0,c07bc615,1cb,c3c50230,...) at mi_switch+0x243 sleepq_switch(c3c50230,0,c07bc615,243,4c,...) at sleepq_switch+0x182 sleepq_wait(c3e11c28,0,c0799806,0,0,...) at sleepq_wait+0x60 _sleep(c3e11c28,0,4c,c0799806,0) at _sleep+0x399 cam_periph_ccbwait(c3e11c00,2,3,376,c0843730,...) at cam_periph_ccbwait+0x59 cam_periph_runccb(c3e11c00,c044df30,2,3,c3fc7b40,...) at cam_periph_runccb+0x78 cdrunccb(3,1,c0452e80,20,0,...) at cdrunccb+0x4b cdprevent(c587a650,c07efa40,c0452e80,20,c587a650,...) at cdprevent+0xaf cdcheckmedia(c6f17b00,14c,c07a0e6c,b7,0,...) at cdcheckmedia+0x170 cdopen(c71ca200,4,c07b09ca,75,0,...) at cdopen+0xed g_disk_access(c6edc280,1,0,0,0,...) at g_disk_access+0x11d g_access(c4a57d40,1,0,0,c6edc2d8,...) at g_access+0x229 g_part_taste(c07ffd00,c6edc280,0,20f,c7168b80,...) at g_part_taste+0xb1 g_new_provider_event(c6edc280,0,c07b0ed1,d2,0,...) at g_new_provider_event+0xa9 g_run_events(c0841800,0,4c,c07af7a5,64,...) at g_run_events+0x31e g_event_procbody(0,c3a88d38,c07b4f38,322,c3c8d570,...) at g_event_procbody+0x95 fork_exit(c0519660,0,c3a88d38) at fork_exit+0xc5 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc3a88d70, ebp = 0 --- db> capture off ^T showed now that mount waits in the [g_waitidle] channel. Then it locked down finally after about 30 minutes or so of wait in [g_waitidle]. I was able to ping / use ssh/nfs during that lock up (well, sometimes it refused to connect, I cannot say when definitely). -- wbr, pluknet From drosih at rpi.edu Tue Apr 7 15:54:25 2009 From: drosih at rpi.edu (Garance A Drosihn) Date: Tue Apr 7 15:54:32 2009 Subject: FreeBSD and iSCSI for disks. Message-ID: Some friends of mine are looking at the new "DroboPro", which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From josh.carroll at gmail.com Tue Apr 7 17:16:52 2009 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue Apr 7 17:17:01 2009 Subject: panic: lockmgr: locking against myself on 7.2-BEA1 (and gmirror dumpdev not working) Message-ID: <8cb6106e0904071651u79c5f8fdgf727c7118d9b6f73@mail.gmail.com> Hello. I have been able to reproduce this panic for a while now, and finally decided to build in debugging support for my kernel and obtain a proper panic, backtrace, etc as it's still happening with 7.2-BETA1 (FreeBSD pflog.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Tue Apr 7 16:03:17 EDT 2009 root@pflog.net:/usr/obj/usr/src/sys/PFLOG_DEBUG amd64). The way I've found to reproduce this panic is to mount /usr/obj as tmpfs and repeatedly build world - it generally happens within 30 minutes, but with debugging enabled it took a bit longer to cause it. Here's the fstab entry for /usr/obj: tmpfs /usr/obj tmpfs size=2147483648,rw 0 0 Here's the panic on the console when it happened: panic: lockmgr: locking against myself cpuid = 2 KDB: enter: panic [thread pid 61233 tid 100161 ] Stopped at kdb_enter_why+0x3d: movq $0,0x394136(%rip) db> Unfortunately, as mentioned in the subject, I am unable to get a savecore. After show alllocks and bt, I ran "call doadump", which appeared to work fine. However, after rebooting, there was no savecore in /var/crash and running savecore against /dev/mirror/gm1s1b states: # savecore /var/crash /dev/mirror/gm1s1b savecore: first and last dump headers disagree on /dev/mirror/gm1s1b savecore: unsaved dumps found but not saved If I use savecore -f, I get: # savecore -f /var/crash /dev/mirror/gm1s1b savecore: unable to force dump - bad magic savecore: no dumps found Which sounds to me like the swap slice's data was already clobbered. dumpdev appears to be set properly in rc.conf: dumpdev="/dev/mirror/gm1s1b" dumpdir="/var/crash" Here's the gm1 gmirror information, if that's pertinent: Geom name: gm1 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3971893092 Providers: 1. Name: mirror/gm1 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r5w5e6 Consumers: 1. Name: ad4 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 2996899963 2. Name: ad6 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 28724068 Here is a transcription of the output from show alllocks and then bt: show alllocks: Process 61346 (tsort) thread 0xffffff0008044000 (100084) exclusive sleep mutex vm page queue mutex r = 0 (0xffffffff80745e00) locked @ /usr/src/sys/vm/vm_object.c:684 exclusive sleep mutex vm page object (standard object) r = 0 (0xffffff00a5c34798) locked @ /usr/src/sys/vm/vm_object.c:460 exclusive sx user map r = 0 (0xffffff0006ccc0070) locked @ /usr/src/sys/vm/vm_map.c:2425 Process 61226 (sh) thread 0xffffff002ca1aa50 (100318) exclusive sx user map r = 0 (0xffffff002ca5b070) locked @ /usr/src/sys/vm/vm_map.c:3117 Process 61130 (tsort) thread 0xffffff002c710370 (100270) exclusive sx user map r = 0 (0xffffff0008049710) locked @ /usr/src/sys/vm/vm_map.c:3117 Process 89194 (sshd) thread 0xffffff002c4356e0 (100229) exclusive sx so_rcv_sx r = 0 (0xffffff000d8a6100) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 21453 (sshd) thread 0xffffff0018c336e0 (100307) exclusive sx so_rcv_sx r = 0 (0xffffff0008c113d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 11200 (pflogd) thread 0xffffff0005eb0000 (100057) exclusive sx so_rcv_sx r = 0 (0xffffff00080e36a0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 and bt: db> bt Tracing pid 61233 tid 100161 td 0xffffff00088c0a50 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x171 _lockmgr() at _lockmgr+0x861 VOP_LOCK1_AVP() at VOP_LOCK1_AVP+0x9b _vn_lock() at _vn_lock+0x8b vget() at vget+0x108 vm_object_reference() at vm_object_reference+0xbf kern_execve() at kern_execve+0x26a execve() at execve+0x38 syscall() at syscall+0x1d0 Xfast_syscall() at Xfast_syscall+0xab --- syscall (59, FreeBSD ELF64, execve), rip = 0x80091553c, rsp = 0x7fffffffdd28, rbp = 0x800b07b70 --- Hopefully this is enough information, as I don't have a dump obviously. If more information is needed, I'd prefer if I could fix the gmirror dumpdev issue first so I can have a coredump to use to get additional information without the tedious transcription from digital pictures! Please let me know if anything else is needed, or if there are ideas for how to fix the dumpdev issue for the gmirror. Thanks, Josh From josh.carroll at gmail.com Tue Apr 7 19:01:28 2009 From: josh.carroll at gmail.com (Josh Carroll) Date: Tue Apr 7 19:01:35 2009 Subject: panic: lockmgr: locking against myself on 7.2-BEA1 (and gmirror dumpdev not working) In-Reply-To: <8cb6106e0904071651u79c5f8fdgf727c7118d9b6f73@mail.gmail.com> References: <8cb6106e0904071651u79c5f8fdgf727c7118d9b6f73@mail.gmail.com> Message-ID: <8cb6106e0904071901l54f998bbt819c1530e2dfb7d0@mail.gmail.com> > Unfortunately, as mentioned in the subject, I am unable to get a > savecore. After show alllocks and bt, I ran "call doadump", which > appeared to work fine. However, after rebooting, there was no savecore > in /var/crash and running savecore against /dev/mirror/gm1s1b states: I was able to reproduce the panic and this time, I booted single user mode and I was able to manually call savecore to get /var/crash/vmcore.0 So if there is any additional kgdb output needed, just say the word and I can get it now. Curious why /etc/rc.d/savecore didn't work on a normal reboot after the dump, but that's probably a topic for a separate mail thread. Thanks, Josh From antik at bsd.ee Tue Apr 7 22:25:54 2009 From: antik at bsd.ee (Andrei Kolu) Date: Tue Apr 7 22:26:02 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <49DC3560.2060106@bsd.ee> Garance A Drosihn wrote: > Some friends of mine are looking at the new "DroboPro", which makes a > lot of disk space available via iSCSI (in addition to firewire 800), > and they were wondering how well iSCSI works with FreeBSD. I haven't > paid attention to iSCSI support. Is there anyone using it heavily > for disk-storage under FreeBSD? Has there been much changed for > iSCSI support in the 8.x branch, or is 7.x support working fine? > I have some experience with "net/istgt" port and it looks solid compared to OpenBSD implementation "net/iscsi-target". Of course your milage may wary. net/istgt This is an iSCSI target, it serves iSCSI protocol and provides SCSI devices to the initiator (client). WWW: http://shell.peach.ne.jp/aoyama/ From marck at rinet.ru Wed Apr 8 00:18:01 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Apr 8 00:18:08 2009 Subject: RELENG_7/i386: ZFS constant panic on file system writes In-Reply-To: <20090407101324.GA1473@garage.freebsd.pl> References: <20090407101324.GA1473@garage.freebsd.pl> Message-ID: On Tue, 7 Apr 2009, Pawel Jakub Dawidek wrote: PJD> > DM> could you please help me a bit with *very* unpleasant situation: one of my PJD> > DM> servers with very large ZFS reboots on most write requests to one (largest, PJD> > DM> which effectively prohibits recreating) ZFS file system with PJD> > DM> PJD> > DM> panic: avl_find() succeeded inside avl_add() PJD> > PJD> > Is there a way I can clear the directory in question? Even the latest -current PJD> > panics when I try to access the directory containing this file. PJD> PJD> Could you try running 'zpool scrub' on this pool? Nothing better comes PJD> to my mind, it looks like some kind of internal inconsistency and PJD> hopefully scrub will be able to find it. Could you also show 'zpool status' PJD> output? zpool status is showing everything ok: marck@moose:~> zpool status pool: m state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM m ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad4h ONLINE 0 0 0 ad6h ONLINE 0 0 0 ad8h ONLINE 0 0 0 ad10h ONLINE 0 0 0 ad12h ONLINE 0 0 0 errors: No known data errors will try scrub, thank you! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From xernet at hotmail.it Wed Apr 8 01:53:42 2009 From: xernet at hotmail.it (xer) Date: Wed Apr 8 01:53:50 2009 Subject: watchdog timeout In-Reply-To: <20090407120032.633E410656D5@hub.freebsd.org> References: <20090407120032.633E410656D5@hub.freebsd.org> Message-ID: Hello I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to 6.4-STABLE. This machine has two 3com nics (one is LAN other is WAN) and i see too much "watchdog timeout" on both cards. This on/off up/down on cards, affect the interrupt to clients that are downloading from apache web server, especially on large files. -------------------------------------------- xer:/root# dmesg xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP xl1: watchdog timeout xl1: link state changed to DOWN xl1: link state changed to UP --------------------------------------------- xer:/root# cat /var/run/dmesg.boot | grep xl xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:01:02:e0:04:1b xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xe880-0xe8ff mem 0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2 miibus1: on xl1 xlphy1: <3c905C 10/100 internal PHY> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:01:02:df:fe:ed --------------------------------------------- Another doubt would be my kernel config, maybe there is something wrong that i cannot see, i'll post at the end of this post, 'cause is too long. As you can see, the cards are 3c905C-TX model. Someone told me to change drivers, but i cannot understand this advice. I got same errors with same cards but with another mainboard, same problem, watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. I don't think that to change nic's pci slots, will solve the problem, i think that maybe change the nics would resolve the matter, but i cannot access to both FreeBSD phisically, cause the boxes are too far from me (about 3500 km). I'm asking you some advices, and i can i fix this problem. p.s. with both 5.4 or 5.5 old kernel, the nics was fine. Regards Xer ----------kernel config ----------- xer:/root# cat /usr/src/sys/i386/conf/ASUS # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.429.2.18 2008/07/28 02:20:29 yongari Exp $ # # custom kernel ASUS 01.15.2009 machine i386 cpu I686_CPU ident ASUS options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device ataraid # ATA RAID drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device plip # TCP/IP over parallel device ppi # Parallel port interface device # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 adapter Gigabit Ethernet Card device ixgb # Intel PRO/10GbE Ethernet Card device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nge # NatSemi DP83820 gigabit Ethernet device nve # nVidia nForce MCP on-board Ethernet Networking device pcn # AMD Am79C97x PCI 10/100(precedence over 'lnc') device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device ti # Alteon Networks Tigon I/II gigabit Ethernet device tl # Texas Instruments ThunderLAN device tx # SMC EtherPower II (83c170 ``EPIC'') device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device wb # Winbond W89C840F device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # ISA Ethernet NICs. pccard NICs included. device cs # Crystal Semiconductor CS89x0 NIC # 'device ed' requires 'device miibus' device ed # NE[12]000, SMC Ultra, 3c503, DS8390 cards device ex # Intel EtherExpress Pro/10 and Pro/10+ device ep # Etherlink III based cards device fe # Fujitsu MB8696x based cards device ie # EtherExpress 8/16, 3C507, StarLAN 10 etc. device lnc # NE2100, NE32-VL Lance Ethernet cards device sn # SMC's 9000 series of Ethernet chips device xe # Xircom pccard Ethernet # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # Firewall options IPFIREWALL # enable ipfirewall (required for dummynet) options IPFIREWALL_VERBOSE # enable firewall output logging to syslogd(8) options IPFIREWALL_VERBOSE_LIMIT=0 # limit firewall verbosity output options IPDIVERT # divert sockets options DUMMYNET # enable dummynet operation options HZ=1000 # set the timer granularity From lars.eggert at nokia.com Wed Apr 8 02:52:25 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Wed Apr 8 02:52:32 2009 Subject: bdes: fwrite error at 8 Message-ID: Hi, I'm doing encrypted nightly dumps over the network to an NFS file system, i.e., dump | bzip2 | bdes > nfs. Since about a week ago, I see occasional errors from bdes ("bdes: fwrite error at 8"). Anyone have a hunch what's going on here? I'm wondering if this is something that started when I upgraded to 7.2- PRERELEASE... Thanks, Lars Dumping /usr to /mnt/backup/fit.usr.3.20090408.dump.bz2.des DUMP: Date of this level 3 dump: Wed Apr 8 03:30:18 2009 DUMP: Date of last level 2 dump: Tue Apr 7 03:29:44 2009 DUMP: Dumping snapshot of /dev/mfid0s1f (/usr) to standard output DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 7237937 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: 13.89% done, finished in 0:31 at Wed Apr 8 04:09:30 2009 DUMP: 20.69% done, finished in 0:38 at Wed Apr 8 04:21:50 2009 DUMP: 25.17% done, finished in 0:44 at Wed Apr 8 04:33:06 2009 DUMP: 29.66% done, finished in 0:47 at Wed Apr 8 04:40:56 2009 DUMP: 34.16% done, finished in 0:48 at Wed Apr 8 04:46:41 2009 bdes: fwrite error at 8 DUMP: 38.56% done, finished in 0:47 at Wed Apr 8 04:51:17 2009 DUMP: 42.96% done, finished in 0:46 at Wed Apr 8 04:54:58 2009 DUMP: 47.47% done, finished in 0:44 at Wed Apr 8 04:57:45 2009 DUMP: 51.95% done, finished in 0:41 at Wed Apr 8 05:00:07 2009 DUMP: 56.44% done, finished in 0:38 at Wed Apr 8 05:02:05 2009 DUMP: 60.96% done, finished in 0:35 at Wed Apr 8 05:03:45 2009 DUMP: 65.47% done, finished in 0:31 at Wed Apr 8 05:05:10 2009 DUMP: 70.01% done, finished in 0:27 at Wed Apr 8 05:06:22 2009 DUMP: 74.51% done, finished in 0:23 at Wed Apr 8 05:07:28 2009 DUMP: 79.01% done, finished in 0:19 at Wed Apr 8 05:08:26 2009 DUMP: 83.86% done, finished in 0:15 at Wed Apr 8 05:08:55 2009 bdes: fwrite error at 8 DUMP: 91.89% done, finished in 0:07 at Wed Apr 8 05:06:01 2009 DUMP: DUMP: 7223390 tape blocks DUMP: finished in 5335 seconds, throughput 1353 KBytes/sec DUMP: level 3 dump on Wed Apr 8 03:30:18 2009 DUMP: DUMP IS DONE From ivoras at freebsd.org Wed Apr 8 04:37:01 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 8 04:37:08 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: Garance A Drosihn wrote: > Some friends of mine are looking at the new "DroboPro", which makes a > lot of disk space available via iSCSI (in addition to firewire 800), > and they were wondering how well iSCSI works with FreeBSD. I haven't > paid attention to iSCSI support. Is there anyone using it heavily > for disk-storage under FreeBSD? Has there been much changed for > iSCSI support in the 8.x branch, or is 7.x support working fine? I suppose you are interested in the "client" (initiator) side of iSCSI support. It hasn't changed much between 7.x and 8.x but there are apparently some announcements of a newer version: http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html I can't find any more information on it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090408/4f99c0b0/signature.pgp From ivoras at freebsd.org Wed Apr 8 05:30:52 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 8 05:30:59 2009 Subject: ZFSKnownProblems - needs revision? Message-ID: Hi, I've been pinged by two people already that it's possible that the problems listed at: http://wiki.freebsd.org/ZFSKnownProblems have been fixed in 7-STABLE, and that the page needs to be significantly revised to sound less scary. Since I unfortunately don't have any ZFS systems in production any more, I'd like to ask for experiences with ZFS from other people. Specifically: * Are the issues on the list still there? * Are there any new issues? * Is somebody running ZFS in production (non-trivial loads) with success? What architecture / RAM / load / applications used? * How is your memory load? (does it leave enough memory for other services) Please also note are you using the "new" ZFS port (in 8-CURRENT) or the "old" one (in 7-STABLE). If the progress has been great as has been suggested, then the page's text could be replaced with a note saying so and maybe even the file system promoted from "experimental"? Suggestion to the following page: http://wiki.freebsd.org/ZFSTuningGuide are also interesting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090408/01e92a53/signature.pgp From ivoras at freebsd.org Wed Apr 8 05:50:45 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 8 05:50:52 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: Ivan Voras wrote: > * Are the issues on the list still there? > * Are there any new issues? > * Is somebody running ZFS in production (non-trivial loads) with > success? What architecture / RAM / load / applications used? > * How is your memory load? (does it leave enough memory for other services) also: what configuration (RAIDZ, mirror, etc.?) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090408/b63f7c34/signature.pgp From danny at cs.huji.ac.il Wed Apr 8 05:54:28 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Wed Apr 8 05:54:37 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: > Garance A Drosihn wrote: > > Some friends of mine are looking at the new "DroboPro", which makes a > > lot of disk space available via iSCSI (in addition to firewire 800), > > and they were wondering how well iSCSI works with FreeBSD. I haven't > > paid attention to iSCSI support. Is there anyone using it heavily > > for disk-storage under FreeBSD? Has there been much changed for > > iSCSI support in the 8.x branch, or is 7.x support working fine? > > I suppose you are interested in the "client" (initiator) side of iSCSI > support. It hasn't changed much between 7.x and 8.x but there are > apparently some announcements of a newer version: > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html > > I can't find any more information on it. the latest is in: http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz cheers, danny From ivoras at freebsd.org Wed Apr 8 06:05:01 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 8 06:05:09 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: Danny Braniss wrote: >> Garance A Drosihn wrote: >>> Some friends of mine are looking at the new "DroboPro", which makes a >>> lot of disk space available via iSCSI (in addition to firewire 800), >>> and they were wondering how well iSCSI works with FreeBSD. I haven't >>> paid attention to iSCSI support. Is there anyone using it heavily >>> for disk-storage under FreeBSD? Has there been much changed for >>> iSCSI support in the 8.x branch, or is 7.x support working fine? >> I suppose you are interested in the "client" (initiator) side of iSCSI >> support. It hasn't changed much between 7.x and 8.x but there are >> apparently some announcements of a newer version: >> >> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html >> >> I can't find any more information on it. > > the latest is in: > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz Thanks! Is there anything in particular you'd like to get tested in the new version, any significant changes or improvements? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090408/f1ec440f/signature.pgp From rblayzor.bulk at inoc.net Wed Apr 8 07:12:39 2009 From: rblayzor.bulk at inoc.net (Robert Blayzor) Date: Wed Apr 8 07:12:45 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <2C0AE775-B15B-4B56-A915-6E126F25C8B0@inoc.net> On Apr 7, 2009, at 5:43 PM, Garance A Drosihn wrote: > Some friends of mine are looking at the new "DroboPro", which makes a > lot of disk space available via iSCSI (in addition to firewire 800), > and they were wondering how well iSCSI works with FreeBSD. I haven't > paid attention to iSCSI support. Is there anyone using it heavily > for disk-storage under FreeBSD? Has there been much changed for > iSCSI support in the 8.x branch, or is 7.x support working fine? If you're looking for "production ready" iSCSI initiator support in FreeBSD, do yourself a favor, save some time, and look into something else. Seriously, we went down this road just recently testing both FreeBSD 7.0/7.1 amd64 on various Dell servers with Intel (em) Gig-E NIC's and it was very easy to basically get the box to lock up solid and/or panic. Our targets were both Netapp and Equallogic iSCSI SAN's. We didn't have a lot of time to debug it, our setup was pretty simple.. yet when we tried to run various simulated real world load on it the boxes just caved. Even with jumbo frames enabled on the NIC's the performance was mediocre at best. Unfortunately due a time constraint we had to move the clients to CentOS 5.2/5.3 and things have been very good so far. I was hoping that FreeBSD's iSCSI support was a bit more solid, or at least hoping that the (isp) driver had support for the QLogic iSCSI HBA's... no luck. YMMV -- Robert Blayzor, BOFH INOC, LLC rblayzor@inoc.net http://www.inoc.net/~rblayzor/ From avg at icyb.net.ua Wed Apr 8 07:56:39 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 8 07:56:46 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <49DCBB21.6050102@icyb.net.ua> My account: amd64 stable/7 system 4GB RAM zero tuning 3-way mirrored zpool with individual dev size about 400G moderate load sufficient remaining RAM (still plenty) zero troubles (system age is 2 months) -- Andriy Gapon From dnelson at allantgroup.com Wed Apr 8 08:13:48 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Apr 8 08:13:54 2009 Subject: bdes: fwrite error at 8 In-Reply-To: References: Message-ID: <20090408144625.GA90152@dan.emsphone.com> In the last episode (Apr 08), Lars Eggert said: > I'm doing encrypted nightly dumps over the network to an NFS file system, > i.e., dump | bzip2 | bdes > nfs. > > Since about a week ago, I see occasional errors from bdes ("bdes: > fwrite error at 8"). Anyone have a hunch what's going on here? I'm > wondering if this is something that started when I upgraded to 7.2- > PRERELEASE... [..] > DUMP: 34.16% done, finished in 0:48 at Wed Apr 8 04:46:41 2009 > bdes: fwrite error at 8 > DUMP: 38.56% done, finished in 0:47 at Wed Apr 8 04:51:17 2009 Two bugs: if fwrite fails, there's no sense in continuing to encrypt, and it should print the error it got. Apply this patch and try again: Index: bdes.c =================================================================== RCS file: /home/ncvs/src/secure/usr.bin/bdes/bdes.c,v retrieving revision 1.9 diff -u -r1.9 bdes.c --- bdes.c 10 Feb 2005 14:47:06 -0000 1.9 +++ bdes.c 8 Apr 2009 14:32:43 -0000 @@ -112,7 +112,7 @@ #define READ(buf, n) fread(buf, sizeof(char), n, stdin) #define WRITE(buf,n) \ if (fwrite(buf, sizeof(char), n, stdout) != n) \ - warnx("fwrite error at %d", n); + err(1, "fwrite error at %d", n); /* * global variables and related macros After patching, the following test commands should print a single usefull error instead of a stream of useless ones. $ trap '' PIPE $ bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1 -- Dan Nelson dnelson@allantgroup.com From lars.eggert at nokia.com Wed Apr 8 08:23:00 2009 From: lars.eggert at nokia.com (Lars Eggert) Date: Wed Apr 8 08:23:07 2009 Subject: bdes: fwrite error at 8 In-Reply-To: <20090408144625.GA90152@dan.emsphone.com> References: <20090408144625.GA90152@dan.emsphone.com> Message-ID: <259CB8EE-6505-49A9-B886-F60BC84C2061@nokia.com> On 2009-4-8, at 17:46, Dan Nelson wrote: > bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1 # bdes -k asd < /boot/kernel/kernel | dd of=/dev/null count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000860 secs (595366 bytes/sec) bdes: fwrite error at 8: Broken pipe Lars From marck at rinet.ru Wed Apr 8 08:32:38 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Apr 8 08:32:48 2009 Subject: RELENG_7/i386: ZFS constant panic on file system writes In-Reply-To: References: <20090407101324.GA1473@garage.freebsd.pl> Message-ID: On Wed, 8 Apr 2009, Dmitry Morozovsky wrote: DM> PJD> > DM> could you please help me a bit with *very* unpleasant situation: one of my DM> PJD> > DM> servers with very large ZFS reboots on most write requests to one (largest, DM> PJD> > DM> which effectively prohibits recreating) ZFS file system with DM> PJD> > DM> DM> PJD> > DM> panic: avl_find() succeeded inside avl_add() DM> PJD> > DM> PJD> > Is there a way I can clear the directory in question? Even the latest -current DM> PJD> > panics when I try to access the directory containing this file. DM> PJD> DM> PJD> Could you try running 'zpool scrub' on this pool? Nothing better comes DM> PJD> to my mind, it looks like some kind of internal inconsistency and DM> PJD> hopefully scrub will be able to find it. Could you also show 'zpool status' DM> PJD> output? DM> DM> zpool status is showing everything ok: DM> DM> marck@moose:~> zpool status DM> pool: m DM> state: ONLINE DM> scrub: none requested DM> config: DM> DM> NAME STATE READ WRITE CKSUM DM> m ONLINE 0 0 0 DM> raidz1 ONLINE 0 0 0 DM> ad4h ONLINE 0 0 0 DM> ad6h ONLINE 0 0 0 DM> ad8h ONLINE 0 0 0 DM> ad10h ONLINE 0 0 0 DM> ad12h ONLINE 0 0 0 DM> DM> errors: No known data errors DM> DM> will try scrub, thank you! Unfortunately, it does not help: scrub: scrub completed with 0 errors on Wed Apr 8 19:04:51 2009 and then root@moose:~# ls -la /ar/nfstat/nfc/.bad/200807 total 9089 drwxr-xr-x 3 rscript wheel 4 Nov 5 21:01 ./ d--------- 3 root wheel 3 Apr 7 14:29 ../ drwxr-xr-x 2 rscript wheel 36 Apr 2 22:12 daily/ -rw-r--r-- 1 rscript wheel 9207828 Aug 1 2008 total.200807 root@moose:~# ls -la /ar/nfstat/nfc/.bad/200807/daily/ panic: avl_find() succeeded inside avl_add() cpuid = 2 [-- marck@localhost detached -- Wed Apr 8 19:28:13 2009] [-- marck@localhost attached -- Wed Apr 8 19:28:15 2009] [halt sent] KDB: enter: Line break on console [thread pid 153 tid 100152 ] Stopped at kdb_enter_why+0x3a: movl $0,kdb_why db> reboot cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 1 I can set up an account for you to serial console for this server, if it can help... -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From jonathan at kc8onw.net Wed Apr 8 08:58:14 2009 From: jonathan at kc8onw.net (Jonathan) Date: Wed Apr 8 08:58:21 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <49DCC982.6090809@kc8onw.net> Ivan Voras wrote: > Hi, > > I've been pinged by two people already that it's possible that the > problems listed at: > > http://wiki.freebsd.org/ZFSKnownProblems > > have been fixed in 7-STABLE, and that the page needs to be significantly > revised to sound less scary. Since I unfortunately don't have any ZFS > systems in production any more, I'd like to ask for experiences with ZFS > from other people. Specifically: > > * Are the issues on the list still there? 1. After tuning my i386 system was stable, I know of at least one other person who still has issues with kernel panics on i386 though. 2-5. I've never run into any of the other issues on my systems. > * Are there any new issues? Not that I've seen. > * Is somebody running ZFS in production (non-trivial loads) with > success? What architecture / RAM / load / applications used? > * How is your memory load? (does it leave enough memory for other services) Memory load is pretty heavy. IIUC memory used by ZFS is reported as Wired in top and a relatively lightly loaded system with 2GB of RAM has 1225MB wired here. > Please also note are you using the "new" ZFS port (in 8-CURRENT) or the > "old" one (in 7-STABLE). I'm using 7-Stable > If the progress has been great as has been suggested, then the page's > text could be replaced with a note saying so and maybe even the file > system promoted from "experimental"? I think a good chunk of the "experimental" tag is due to the lack of maintainers for ZFS. As far as I know PJD is still the only one that has thorough knowledge of ZFS on FreeBSD. At one point he stated he doesn't want to remove the experimental tag until there is at least one other person that knows the system well. I've not seen anything on this for a while though so my information could be out of date. Jonathan From cptsalek at gmail.com Wed Apr 8 09:18:32 2009 From: cptsalek at gmail.com (Christian Walther) Date: Wed Apr 8 09:18:40 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <14989d6e0904080918l78d6e52eja46d7dd258b1659a@mail.gmail.com> Hi, I used geli encrypted ZFS including Root on my IBM Thinkpad T31 with 1GB RAM on a 160GB HDD. (i386 7-STABLE) Swap on a dedicated slice. Some Z Filesystems used compression (/usr/ports, /usr/src, for example). I encountered several crashes, especially during heavy loads, such as compiling big ports. Tried some of the "workarounds" listed on the page, which decreased the performance to a level where watching HD videos wasn't possible anymore. On heavy load the system was unable to perform as expected, leading to side effects like a stuttering mouse. All this disappeared since I switched to classic UFS. My home server is a amd64 7-STABLE, 4GB RAM, 4x400GB HDD with geli encryption (AES 256). This works like a charm. So my take on ZFS is that it is a no go on i386, but a stable solution on amd64. Regards Christian Walther From mad at madpilot.net Wed Apr 8 09:25:27 2009 From: mad at madpilot.net (Guido Falsi) Date: Wed Apr 8 09:25:34 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <20090408160741.GC26242@megatron.madpilot.net> On Wed, Apr 08, 2009 at 02:50:33PM +0200, Ivan Voras wrote: > Ivan Voras wrote: > > > * Are the issues on the list still there? > > * Are there any new issues? > > * Is somebody running ZFS in production (non-trivial loads) with > > success? What architecture / RAM / load / applications used? > > * How is your memory load? (does it leave enough memory for other services) > > also: what configuration (RAIDZ, mirror, etc.?) I've been playing with 8.0 zfs on low end machines(laptops with 768MB-1GB RAM and just one disk device). I have successfully made them boot off of ZFS using gpt, this is not mentioned in ZFSOnRoot. I used the guide found here: http://blogs.freebsdish.org/lulf/category/freebsd/ Also still requires manually recompiling loader with ZFS support. Shouldn't this made trhe default in 8.0? I had a panic while doing a make clean in the openoffice port after compilation due to kmem exhaustion using the tuning suggested in the Tuning Guide; solved by using these: vm.kmem_size="384M" vm.kmem_size_max="384M" vfs.zfs.arc_max="40M" vfs.zfs.vdev.cache.size="5M" this is on an i386 laptop with 768 MB RAM, I should experiment a little with cache.size and arc_max too... On a 1GB RAM laptop(it's an EeePC labelled 904HA, has a 160GB disc) I'm using slughtly higher values with success for now, but I've installed this just a few days ago and have not made any tests. The last thing I noticed is the knownproblems wiki reports swapping on zfs' zvols is not working. I have not stress tested this to the limit, but my systems are successfully working with zvols as the only swapping device and actively swaping to it. What could be a good way to stress test his to the limit? hope these information helps someway. I'd like to test ZFS on some serious hardware with serious load, but I haven't had the chance at work for the time being. -- Guido Falsi From torfinn.ingolfsen at broadpark.no Wed Apr 8 10:00:22 2009 From: torfinn.ingolfsen at broadpark.no (Torfinn Ingolfsen) Date: Wed Apr 8 10:00:30 2009 Subject: uchcom and RELENG_7? Message-ID: <20090408190018.9f30845f.torfinn.ingolfsen@broadpark.no> Hi, Is there any reason why uchcom[1] hasn't been MFC'ed to RELENG_7 yet? I see discussion[2] about this subject as far back as around 7.0-release, but I can't find any uchcom.c files in my src, not even for latest RELENG_7. References: 1) http://www.freebsd.org/cgi/man.cgi?query=uchcom&apropos=0&sektion=0&manpath=FreeBSD+8-current&format=html 2) http://markmail.org/message/4w324qx4usmnd4ic#query:freebsd%20uchcom+page:1+mid:ecwpudhls4jqpr5s+state:results -- Regards, Torfinn Ingolfsen From fjwcash at gmail.com Wed Apr 8 10:19:57 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Wed Apr 8 10:20:04 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <200904080959.49201.fjwcash@gmail.com> On April 8, 2009 5:30 am Ivan Voras wrote: > Specifically: > * Are the issues on the list still there? > * Are there any new issues? > * Is somebody running ZFS in production (non-trivial loads) with > success? What architecture / RAM / load / applications used? > * How is your memory load? (does it leave enough memory for other > services) > > Please also note are you using the "new" ZFS port (in 8-CURRENT) or the > "old" one (in 7-STABLE). I'm running the following three setups with ZFS: Home file server generic P4 3.0 GHz system with 2 GB RAM 2 GB USB stick for / and /usr 3x 120 GB SATA HDs onboard Marvel gigabit NIC 32-bit FreeBSD 7.1-RELEASE pool has a single 3-way raidz1 vdev Work file server 1 & 2 5U chenbro case w/1350 Watt 4-way redundant PSU Tyan h2000M motherboard 2x dual-core Opteron 2200-series CPUs at 2.8 GHz 8 GB ECC DDR2-SDRAM 2x 2 GB CompactFlash using gmirror for / and /usr (server 1) 2x 2 GB USB sticks using gmirror for / and /usr (server 2) 3Ware 9550SXU PCI-X RAID controller 3Ware 9650SE PCIe RAID controller 24x 500 GB Western Digital SATA HDs 4-port Intel PRO/1000 gigabit NIC configured using lagg(4) 64-bit FreeBSD 7.1-RELEASE pool on each server has 3 8-way raidz2 vdevs On my home box, it took a little bit of tuning to get it stable. The hardest part was finding the right setting for vm.kmem_size_max and vfs.zfs.arc_max. After about of month of tweaking, twiddling, crashing, and rebooting, I hit upon 1G for kmem and 256M for zfs arc. Since then, it's been rock-solid. This box runs KDE 4.2.2, is used for watching movies, downloading, office work, and sharing files out via Samba and NFS to the rest of the house. On the work servers, it took about 6 weeks to get the right settings for loader.conf to make it stable. After much trial and error, we are using 1596M for kmem_size_max, and 512M for zfs_arc_max. These boxes do remote backups for ~90 Linux and FreeBSD boxes using rsync. The backup script runs parallel rsync processes for each remote site, doing sequential backups of each server at the site. We wait 250s before starting the next site backup. Takes just under 5 hours to do incremental backups for all 90 sites. We get (according to MRTG) a sustained 80 MBytes/sec read/write during the backups. It may be more, as we can't get the 64-bit disk counters to work, and have to poll the 32-bit counters every 60 secs. During the trial-and-error period, we did have a lot of livelocks, deadlocks, and kernel panics. Things have been very stable on both boxes for the past two months. We don't run into any out-of-memory issues. We use swap on ZVol for all the systems listed above. So far, that hasn't been an issue (knock wood). :) iSCSI support works nicely as well, using the net/iscsi-target port. Only done minor desktop-style testing using a Debian Linux initiator. Haven't had any issues sharing the ZFS filesystems via NFS either. We use a couple NFS shares for really old SCO boxes that refuse to install rsync. Even when the full backup run is going, and these boxes are copying files via NFS, we haven't hit any lockups. We run with vfs.zfs.prefetch_disable=1 and vfs.zfs.zil_disable=0 on all systems. We're really looking forward to FreeBSD 8 with the ZFS improvements. Especially the auto-tuning and much higher kmem_max. We'd like to be able to give ZFS 3-4 GB for the ARC. We've also heavily modified /etc/sysctl.conf and upped a bunch of the network-related sysctls. Doing so increased our SSH throughput from ~30 Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. So far, we've been very impressed with ZFS support on FreeBSD. Makes it really hard to use LVM on our Linux systems. :) -- Freddie fjwcash@gmail.com From andrew at rinet.ru Wed Apr 8 10:37:29 2009 From: andrew at rinet.ru (Andrew Kolchoogin) Date: Wed Apr 8 10:37:36 2009 Subject: ZFS Usage. In-Reply-To: References: Message-ID: <1239211272.3358.17.camel@akela.tsscom.ru> Dear colleagues, ? ??, 08/04/2009 ? 14:30 +0200, Ivan Voras ?????: I have "old port" (RELENG_7) ZFS in production on two servers. Both of them have Serial ATA HDDs with the following storage pool configuration: 1) mpt(4) SATA/SAS Controller with three drives as RAIDZ; 2) aac(4) SATA/SAS RAID Controller with six drives as two RAIDZs. Both servers in question are Intel Xeons with FreeBSD/amd64 installed on them, as such, tuning of kernel memory-related sysctls is unneccessary with recent RELENG_7. Servers have relatively complex workload: they contain two-to-six jails with PostFix/DrWeb/Amavis; MySQL Database (with very intensive workload as it is used as a backend for RADIUS server with quite intensive authorisation/accounting); Web Server (up to three on one of servers in question); Asterisk SoftPBX. Servers have NFS-shared home directories between jails via localhost. Conclusion: no problems detected past three months. ;) -- Cheers, Andrew. From marck at rinet.ru Wed Apr 8 11:09:11 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Apr 8 11:09:18 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: On Wed, 8 Apr 2009, Ivan Voras wrote: IV> > * Are the issues on the list still there? IV> > * Are there any new issues? IV> > * Is somebody running ZFS in production (non-trivial loads) with IV> > success? What architecture / RAM / load / applications used? IV> > * How is your memory load? (does it leave enough memory for other services) IV> IV> also: what configuration (RAIDZ, mirror, etc.?) Well, besides very strange data corruption problem I reported recently, I have no problems with ZFS (various combinations: my home workstation has mirror, notebook has ZFS on single disk, some machines with raidz, some with just disk on hardware RAID controllers (twa and arcmsr), both amd64 (mostly untuned, modulo kern.maxvnodes increase) and i386 (desktops; kmem_size/arc_max tuned, usually to 640m/192m) All of them are rather fresh RELENG_7. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From marck at rinet.ru Wed Apr 8 11:17:26 2009 From: marck at rinet.ru (Dmitry Morozovsky) Date: Wed Apr 8 11:17:33 2009 Subject: zpool history coredump Message-ID: Pawel, another one (though minor, I suppose) bug report: while playing with my poor pool, I tried to interact with it on -current, thus importing it with -f (without upgrading, of course). After reverting to RELENG_7, I found I no more can access history: root@moose:~# /usr/obj/usr/src/cddl/sbin/zpool/zpool history History for 'm': 2008-10-14.23:04:28 zpool create m raidz ad4h ad6h ad8h ad10h ad12h 2008-10-14.23:04:57 zfs set mountpoint=/mnt m 2008-10-14.23:05:27 zfs create m/usr 2008-10-14.23:05:29 zfs create m/usr/local 2008-10-14.23:05:32 zfs create m/usr/ports 2008-10-14.23:05:34 zfs create m/usr/src 2008-10-14.23:05:37 zfs create m/usr/obj 2008-10-14.23:05:48 zfs create m/usr/ports/distfiles 2008-10-14.23:05:53 zfs create m/home 2008-10-14.23:05:55 zfs create m/var 2008-10-14.23:05:58 zfs create m/ar 2008-10-14.23:20:13 zfs set mountpoint=legacy m 2008-10-14.23:20:27 zfs set mountpoint=/var m/var 2008-10-14.23:30:41 zpool import -f m 2008-10-14.23:57:57 zpool import -f m 2008-10-15.00:03:08 zpool import -f m 2008-10-15.00:03:47 zfs set atime=off m 2008-10-15.00:04:00 zfs set compression=gzip m/usr/ports 2008-10-15.00:04:15 zfs set compression=off m/usr/ports/distfiles 2008-10-15.00:13:30 zfs set compression=gzip m/home 2008-10-15.02:08:33 zfs create m/usr/compat 2008-12-11.14:22:22 zfs snapshot m/ar@20081211 2009-01-16.11:19:32 zfs destroy m/ar@20081211 2009-03-30.19:19:07 zpool clear m 2009-04-06.20:59:09 zpool replace m ad6h ad14h 2009-04-07.13:55:42 zpool import -f m Assertion failed: (*), function nvlist_lookup_string(records[i], ZPOOL_HIST_CMD, &cmdstr) == 0, file /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c, line 3338. Abort (core dumped) (gdb) bt #0 0x481dfff7 in kill () from /lib/libc.so.7 #1 0x481dff56 in raise () from /lib/libc.so.7 #2 0x481deb8a in abort () from /lib/libc.so.7 #3 0x481c6546 in __assert () from /lib/libc.so.7 #4 0x0804aca7 in get_history_one (zhp=0x4831a100, data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3337 #5 0x0805293f in pool_list_iter (zlp=0x4830e030, unavail=0, func=0x804ab30 , data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_iter.c:165 #6 0x08052bc6 in for_each_pool (argc=0, argv=0xbfbfecc8, unavail=B_FALSE, proplist=0x0, func=0x804ab30 , data=0xbfbfac40) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_iter.c:239 #7 0x0804a94a in zpool_do_history (argc=0, argv=0xbfbfecc4) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3365 #8 0x0804da4b in main (argc=2, argv=0xbfbfecc0) at /usr/src/cddl/sbin/zpool/../../../cddl/contrib/opensolaris/cmd/zpool/zpool_main.c:3570 -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From peter.esselius at gmail.com Wed Apr 8 11:24:54 2009 From: peter.esselius at gmail.com (Peter Esselius) Date: Wed Apr 8 11:25:01 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: <49DCBB21.6050102@icyb.net.ua> References: <49DCBB21.6050102@icyb.net.ua> Message-ID: My home fileserver: Started using zfs around 7.0-BETA2, oct-nov 07. The system is running 7-STABLE@amd64, updated once a month. 4GB RAM No kmem-tuning. 4x320gb, switched to 5x750 during the summer. No panics after switching from i386 to amd64. From piotr.smyrak at heron.pl Wed Apr 8 12:26:37 2009 From: piotr.smyrak at heron.pl (Piotr Smyrak) Date: Wed Apr 8 12:26:45 2009 Subject: no USB mice detected on GA-MA74GM-S2 Message-ID: <20090408190805.GA1368@smyrak.com> Hi, I recently upgraded my system to newer hardware with motherboard GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge) and AMD SB700 (south) where USB support is located. Everything would be fine except there is no USB mice detection by FreeBSD at all. And I am stuck with USB mise since the mobo has no PS/2 port. First I started with my old build of 6.2, then upgraded to 6.4 STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the issue. None of versions gave me USB mouse support. I have tried connecting 3 various mice. No luck. The only effect I can achieve after connecting a mouse, is a somewhat delayed message on console: "uhub0: device problem (TIMEOUT), disabling port 2" The same mice worked great before changing mobo, and still continue be detected and operational on my laptop (tp x23) running 6.0. I was also able to use a mouse with no problem within Ubuntu LiveCD. I have "device ums" compiled into the kernel. As well as devices uhci, ohci and ehci, ugen and usb, too. usbdevs gives no info on any mouse. Attaching a verbose dmesg from my currently installed 7.2 build. Any help is appreciated. -- dmesg output below -- 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-PRERELEASE #4: Sat Apr 4 20:24:14 CEST 2009 root@dsk:/usr/obj/usr/src/sys/SMYRU Preloaded elf kernel "/boot/kernel/kernel" at 0xc08b6000. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc08b6188. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc08b6234. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08b62e0. Calibrating clock(s) ... i8254 clock: 1193215 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2505346537 Hz CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 Data TLB: 32 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 2079195136 (1982 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x0000000079baffff, 2029563904 bytes (495499 pages) avail memory = 2029035520 (1935 MB) Table 'FACP' at 0x7bee3040 Table 'SSDT' at 0x7bee73c0 Table 'HPET' at 0x7bee7680 Table 'MCFG' at 0x7bee76c0 Table 'APIC' at 0x7bee7300 MADT: Found table at 0x7bee7300 MP Configuration Table version 1.4 found at 0xc00f0f00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: disabled MADT: Found CPU APIC ID 3 ACPI ID 3: disabled ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fb100 bios32: Entry = 0xfb7c0 (c00fb7c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb810 pnpbios: Found PnP BIOS data at 0xc00fc360 pnpbios: Entry = f0000:c390 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ACPI: RSDP @ 0x0xf7200/0x0014 (v 0 GBT ) ACPI: RSDT @ 0x0x7bee3000/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: FACP @ 0x0x7bee3040/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: DSDT @ 0x0x7bee30c0/0x4222 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x0100000C) ACPI: FACS @ 0x0x7bee0000/0x0040 ACPI: SSDT @ 0x0x7bee73c0/0x028A (v 1 PTLTD POWERNOW 0x00000001 LTP 0x00000001) ACPI: HPET @ 0x0x7bee7680/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x00000098) ACPI: MCFG @ 0x0x7bee76c0/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: APIC @ 0x0x7bee7300/0x0084 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 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 ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 2 MADT: Ignoring local NMI routed to ACPI CPU 3 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 kbd: new array size 4 kbd1 at kbdmux0 random: VESA: information block 56 45 53 41 00 03 b8 01 00 c0 01 00 00 00 44 00 00 01 00 01 37 0a ef 00 00 c0 81 00 00 c0 88 4c 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 51 mode(s) found VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc078c524 (1000044) VESA: ATI ATOMBIOS VESA: (C) 1988-2005, ATI Technologies Inc. RS740 01.00 mem: Pentium Pro MTRR support enabled null: io: npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4b7c000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a340 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=79111002) pcibios: BIOS version 3.00 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7bde0000 (3) failed ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x7911, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7912, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x63 (2970 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x7916, revid=0x00 domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x1002, dev=0x4390, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x9230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 2 messages map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfde00000-0xfdffffff pcib1: prefetched decode 0xf8000000-0xfbffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x796e, revid=0x00 domain=0, bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x20 (960 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 Prefetchable Memory, range 64, base 0xf8000000, size 26, enabled pcib1: requested memory range 0xf8000000-0xfbffffff: good map[18]: type Memory, range 64, base 0xfdff0000, size 16, enabled pcib1: requested memory range 0xfdff0000-0xfdffffff: good map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled pcib1: requested I/O range 0xee00-0xeeff: in range map[24]: type Memory, range 32, base 0xfde00000, size 20, enabled pcib1: requested memory range 0xfde00000-0xfdefffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 18 vgapci0: port 0xee00-0xeeff mem 0xf8000000-0xfbffffff,0xfdff0000-0xfdffffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on pci1 pcib2: at device 6.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xfda00000-0xfdafffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xde00, size 8, enabled pcib2: requested I/O range 0xde00-0xdeff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdaff000, size 12, enabled pcib2: requested memory range 0xfdaff000-0xfdafffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdae0000, size 16, enabled pcib2: requested memory range 0xfdae0000-0xfdaeffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 pci2: at device 0.0 (no driver attached) atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 ioapic0: routing intpin 22 (PCI IRQ 22) to vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: SATA connect time=0ms ata2: SIGNATURE: 00000101 ata2: ahci_reset devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: ahci_reset devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: SATA connect status=00000000 ata4: ahci_reset devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: SATA connect status=00000000 ata5: ahci_reset devices=0x0 ata5: [MPSAFE] ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 51 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] ehci0: Dropped interrupts workaround enabled usb2: EHCI version 1.0 usb2: companion controllers, 3 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: on usb2 uhub2: 6 ports with 6 removable, self powered ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci2 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 3 ports with 3 removable, self powered ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 3 ports with 3 removable, self powered ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] ehci1: Dropped interrupts workaround enabled usb5: EHCI version 1.0 usb5: companion controllers, 3 ports each: usb3 usb4 usb5: on ehci1 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 6 ports with 6 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=50 ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=ff stat1=00 devices=0x8 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 ata0: [MPSAFE] ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfdc00000-0xfdcfffff pcib3: prefetched decode 0xfdb00000-0xfdbfffff pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x1317, dev=0x0985, revid=0x11 domain=0, bus=3, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled pcib3: requested I/O range 0xce00-0xceff: in range map[14]: type Memory, range 32, base 0xfdcff000, size 10, enabled pcib3: requested memory range 0xfdcff000-0xfdcff3ff: good pcib3: matched entry for 3.6.INTA pcib3: slot 6 INTA hardwired to IRQ 20 dc0: port 0xce00-0xceff mem 0xfdcff000-0xfdcff3ff irq 20 at device 6.0 on pci3 dc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xce00 miibus0: on dc0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x000749, model 0x0001, rev. 1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:00:e8:12:73:a7 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 dc0: [MPSAFE] dc0: [ITHREAD] ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb6: OHCI version 1.0, legacy support usb6: SMM does not respond, resetting usb6: on ohci4 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 ata: ata0 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcd7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 ppbus0: [MPSAFE] ppbus0: [ITHREAD] lpt0: on ppbus0 lpt0: Interrupt-driven port ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] sio0 failed to probe at port 0x3f8 irq 4 on isa0 sio1 failed to probe at port 0x2f8 irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 130270 -> 100000 procfs registered lapic: Divisor 2, Frequency 100213866 hz Timecounter "TSC" frequency 2505346537 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA40 cable=40 wire acd0: setting PIO4 on IXP700 chip acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: setting UDMA33 on IXP700 chip acd0: CDRW drive at ata0 as slave acd0: read 4134KB/s (8958KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM 120mm data disc ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 305244MB at ata2-master SATA300 ad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): error 22 (probe0:ata0:0:1:0): Unretryable Error (probe0:ata0:0:1:0): Down reving Protocol Version from 2 to 0? acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:1:0): error 22 (probe0:ata0:0:1:0): Unretryable Error pass0 at ata0 bus 0 target 1 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 33.000MB/s transfers GEOM: new disk cd0 cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: cd present [294606 x 2048 byte records] SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 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 7 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 14 to local APIC 1 ioapic0: Assigning PCI IRQ 16 to local APIC 0 ioapic0: Assigning PCI IRQ 17 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 0 ioapic0: Assigning PCI IRQ 22 to local APIC 1 scsi_cd.c::ioctl cmd=4400648b error=25 Trying to mount root from ufs:/dev/ad4s2a start_init: trying /sbin/init Linux ELF exec handler installed fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 From rnoland at FreeBSD.org Wed Apr 8 13:49:00 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Wed Apr 8 13:49:09 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090408190805.GA1368@smyrak.com> References: <20090408190805.GA1368@smyrak.com> Message-ID: <1239223684.4491.12.camel@balrog.2hip.net> On Wed, 2009-04-08 at 21:08 +0200, Piotr Smyrak wrote: > Hi, > > I recently upgraded my system to newer hardware with motherboard > GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge) > and AMD SB700 (south) where USB support is located. Everything > would be fine except there is no USB mice detection by FreeBSD at > all. And I am stuck with USB mise since the mobo has no PS/2 port. > > First I started with my old build of 6.2, then upgraded to 6.4 > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > issue. None of versions gave me USB mouse support. I have tried > connecting 3 various mice. No luck. The only effect I can achieve > after connecting a mouse, is a somewhat delayed message on console: rebuild/reinstall devel/libpciaccess now that you have updated kernel. robert. > "uhub0: device problem (TIMEOUT), disabling port 2" > > The same mice worked great before changing mobo, and still continue > be detected and operational on my laptop (tp x23) running 6.0. I was > also able to use a mouse with no problem within Ubuntu LiveCD. > > I have "device ums" compiled into the kernel. As well as devices uhci, > ohci and ehci, ugen and usb, too. usbdevs gives no info on any mouse. > Attaching a verbose dmesg from my currently installed 7.2 build. > > Any help is appreciated. > > -- dmesg output below -- > > 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-PRERELEASE #4: Sat Apr 4 20:24:14 CEST 2009 > root@dsk:/usr/obj/usr/src/sys/SMYRU > Preloaded elf kernel "/boot/kernel/kernel" at 0xc08b6000. > Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc08b6188. > Preloaded elf module "/boot/kernel/miibus.ko" at 0xc08b6234. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc08b62e0. > Calibrating clock(s) ... i8254 clock: 1193215 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 2505346537 Hz > CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > TSC: P-state invariant > Cores per package: 2 > Data TLB: 32 entries, fully associative > Instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative > real memory = 2079195136 (1982 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000000c25000 - 0x0000000079baffff, 2029563904 bytes (495499 pages) > avail memory = 2029035520 (1935 MB) > Table 'FACP' at 0x7bee3040 > Table 'SSDT' at 0x7bee73c0 > Table 'HPET' at 0x7bee7680 > Table 'MCFG' at 0x7bee76c0 > Table 'APIC' at 0x7bee7300 > MADT: Found table at 0x7bee7300 > MP Configuration Table version 1.4 found at 0xc00f0f00 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 1 ACPI ID 1: enabled > SMP: Added CPU 1 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 2: disabled > MADT: Found CPU APIC ID 3 ACPI ID 3: disabled > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > bios32: Found BIOS32 Service Directory header at 0xc00fb100 > bios32: Entry = 0xfb7c0 (c00fb7c0) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0xb810 > pnpbios: Found PnP BIOS data at 0xc00fc360 > pnpbios: Entry = f0000:c390 Rev = 1.0 > Other BIOS signatures found: > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > ULE: setup cpu group 0 > ULE: setup cpu 0 > ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 > ULE: setup cpu group 1 > ULE: setup cpu 1 > ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 > ACPI: RSDP @ 0x0xf7200/0x0014 (v 0 GBT ) > ACPI: RSDT @ 0x0x7bee3000/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) > ACPI: FACP @ 0x0x7bee3040/0x0074 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) > ACPI: DSDT @ 0x0x7bee30c0/0x4222 (v 1 GBT GBTUACPI 0x00001000 MSFT 0x0100000C) > ACPI: FACS @ 0x0x7bee0000/0x0040 > ACPI: SSDT @ 0x0x7bee73c0/0x028A (v 1 PTLTD POWERNOW 0x00000001 LTP 0x00000001) > ACPI: HPET @ 0x0x7bee7680/0x0038 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x00000098) > ACPI: MCFG @ 0x0x7bee76c0/0x003C (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) > ACPI: APIC @ 0x0x7bee7300/0x0084 (v 1 GBT GBTUACPI 0x42302E31 GBTU 0x01010101) > MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 2 > 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 > ioapic0: intpin 9 polarity: low > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > MADT: Ignoring local NMI routed to ACPI CPU 2 > MADT: Ignoring local NMI routed to ACPI CPU 3 > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 > kbd: new array size 4 > kbd1 at kbdmux0 > random: > VESA: information block > 56 45 53 41 00 03 b8 01 00 c0 01 00 00 00 44 00 > 00 01 00 01 37 0a ef 00 00 c0 81 00 00 c0 88 4c > 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > VESA: 51 mode(s) found > VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc078c524 (1000044) > VESA: ATI ATOMBIOS > VESA: (C) 1988-2005, ATI Technologies Inc. RS740 01.00 > mem: > Pentium Pro MTRR support enabled > null: > io: > npx0: INT 16 interface > acpi0: on motherboard > ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xc4b7c000 pa 0x1000 > pci_open(1): mode 1 addr port (0x0cf8) is 0x8000a340 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=79111002) > pcibios: BIOS version 3.00 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, 7bde0000 (3) failed > ACPI timer: 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 1/2 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 255 N 0 3 4 5 6 7 10 11 > Validation 0 255 N 0 3 4 5 6 7 10 11 > After Disable 0 255 N 0 3 4 5 6 7 10 11 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x1002, dev=0x7911, revid=0x00 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1002, dev=0x7912, revid=0x00 > domain=0, bus=0, slot=1, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) > lattimer=0x63 (2970 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1002, dev=0x7916, revid=0x00 > domain=0, bus=0, slot=6, func=0 > class=06-04-00, hdrtype=0x01, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x1002, dev=0x4390, revid=0x00 > domain=0, bus=0, slot=17, func=0 > class=01-01-8f, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 4 messages, 64 bit > map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled > map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled > map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled > map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled > map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled > map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled > pcib0: matched entry for 0.17.INTA > pcib0: slot 17 INTA hardwired to IRQ 22 > found-> vendor=0x1002, dev=0x4397, revid=0x00 > domain=0, bus=0, slot=18, func=0 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=3 > map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled > pcib0: matched entry for 0.18.INTA > pcib0: slot 18 INTA hardwired to IRQ 16 > found-> vendor=0x1002, dev=0x4398, revid=0x00 > domain=0, bus=0, slot=18, func=1 > class=0c-03-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=3 > map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled > pcib0: matched entry for 0.18.INTA > pcib0: slot 18 INTA hardwired to IRQ 16 > found-> vendor=0x1002, dev=0x4396, revid=0x00 > domain=0, bus=0, slot=18, func=2 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled > pcib0: matched entry for 0.18.INTB > pcib0: slot 18 INTB hardwired to IRQ 17 > found-> vendor=0x1002, dev=0x4397, revid=0x00 > domain=0, bus=0, slot=19, func=0 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled > pcib0: matched entry for 0.19.INTA > pcib0: slot 19 INTA hardwired to IRQ 18 > found-> vendor=0x1002, dev=0x4398, revid=0x00 > domain=0, bus=0, slot=19, func=1 > class=0c-03-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled > pcib0: matched entry for 0.19.INTA > pcib0: slot 19 INTA hardwired to IRQ 18 > found-> vendor=0x1002, dev=0x4396, revid=0x00 > domain=0, bus=0, slot=19, func=2 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x02b0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled > pcib0: matched entry for 0.19.INTB > pcib0: slot 19 INTB hardwired to IRQ 19 > found-> vendor=0x1002, dev=0x4385, revid=0x3a > domain=0, bus=0, slot=20, func=0 > class=0c-05-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0403, statreg=0x9230, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1002, dev=0x439c, revid=0x00 > domain=0, bus=0, slot=20, func=1 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > MSI supports 2 messages > map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled > found-> vendor=0x1002, dev=0x4383, revid=0x00 > domain=0, bus=0, slot=20, func=2 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=3 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled > pcib0: matched entry for 0.20.INTA > pcib0: slot 20 INTA hardwired to IRQ 16 > found-> vendor=0x1002, dev=0x439d, revid=0x00 > domain=0, bus=0, slot=20, func=3 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1002, dev=0x4384, revid=0x00 > domain=0, bus=0, slot=20, func=4 > class=06-04-01, hdrtype=0x01, mfdev=1 > cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1002, dev=0x4399, revid=0x00 > domain=0, bus=0, slot=20, func=5 > class=0c-03-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=10 > map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled > pcib0: matched entry for 0.20.INTC > pcib0: slot 20 INTC hardwired to IRQ 18 > found-> vendor=0x1022, dev=0x1100, revid=0x00 > domain=0, bus=0, slot=24, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1101, revid=0x00 > domain=0, bus=0, slot=24, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1102, revid=0x00 > domain=0, bus=0, slot=24, func=2 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1103, revid=0x00 > domain=0, bus=0, slot=24, func=3 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > pcib1: at device 1.0 on pci0 > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: I/O decode 0xe000-0xefff > pcib1: memory decode 0xfde00000-0xfdffffff > pcib1: prefetched decode 0xf8000000-0xfbffffff > pci1: on pcib1 > pci1: domain=0, physical bus=1 > found-> vendor=0x1002, dev=0x796e, revid=0x00 > domain=0, bus=1, slot=5, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) > lattimer=0x20 (960 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 Prefetchable Memory, range 64, base 0xf8000000, size 26, enabled > pcib1: requested memory range 0xf8000000-0xfbffffff: good > map[18]: type Memory, range 64, base 0xfdff0000, size 16, enabled > pcib1: requested memory range 0xfdff0000-0xfdffffff: good > map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled > pcib1: requested I/O range 0xee00-0xeeff: in range > map[24]: type Memory, range 32, base 0xfde00000, size 20, enabled > pcib1: requested memory range 0xfde00000-0xfdefffff: good > pcib1: matched entry for 1.5.INTA > pcib1: slot 5 INTA hardwired to IRQ 18 > vgapci0: port 0xee00-0xeeff mem 0xf8000000-0xfbffffff,0xfdff0000-0xfdffffff,0xfde00000-0xfdefffff irq 18 at device 5.0 on pci1 > pcib2: at device 6.0 on pci0 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: I/O decode 0xd000-0xdfff > pcib2: memory decode 0xfdd00000-0xfddfffff > pcib2: prefetched decode 0xfda00000-0xfdafffff > pci2: on pcib2 > pci2: domain=0, physical bus=2 > found-> vendor=0x10ec, dev=0x8168, revid=0x02 > domain=0, bus=2, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 3 supports D0 D1 D2 D3 current D0 > MSI supports 2 messages, 64 bit > MSI-X supports 2 messages in map 0x20 > map[10]: type I/O Port, range 32, base 0xde00, size 8, enabled > pcib2: requested I/O range 0xde00-0xdeff: in range > map[18]: type Prefetchable Memory, range 64, base 0xfdaff000, size 12, enabled > pcib2: requested memory range 0xfdaff000-0xfdafffff: good > map[20]: type Prefetchable Memory, range 64, base 0xfdae0000, size 16, enabled > pcib2: requested memory range 0xfdae0000-0xfdaeffff: good > pcib2: matched entry for 2.0.INTA > pcib2: slot 0 INTA hardwired to IRQ 18 > pci2: at device 0.0 (no driver attached) > atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 > atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 > ioapic0: routing intpin 22 (PCI IRQ 22) to vector 49 > atapci0: [MPSAFE] > atapci0: [ITHREAD] > atapci0: AHCI Version 01.10 controller with 4 ports detected > ata2: on atapci0 > ata2: SATA connect time=0ms > ata2: SIGNATURE: 00000101 > ata2: ahci_reset devices=0x1 > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci0 > ata3: SATA connect status=00000000 > ata3: ahci_reset devices=0x0 > ata3: [MPSAFE] > ata3: [ITHREAD] > ata4: on atapci0 > ata4: SATA connect status=00000000 > ata4: ahci_reset devices=0x0 > ata4: [MPSAFE] > ata4: [ITHREAD] > ata5: on atapci0 > ata5: SATA connect status=00000000 > ata5: ahci_reset devices=0x0 > ata5: [MPSAFE] > ata5: [ITHREAD] > ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 > ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 > ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 3 ports with 3 removable, self powered > ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 > ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 > ioapic0: routing intpin 17 (PCI IRQ 17) to vector 51 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > ehci0: Dropped interrupts workaround enabled > usb2: EHCI version 1.0 > usb2: companion controllers, 3 ports each: usb0 usb1 > usb2: on ehci0 > usb2: USB revision 2.0 > uhub2: on usb2 > uhub2: 6 ports with 6 removable, self powered > ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 > ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 > ioapic0: routing intpin 18 (PCI IRQ 18) to vector 52 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: SMM does not respond, resetting > usb3: on ohci2 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 3 ports with 3 removable, self powered > ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 > ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: SMM does not respond, resetting > usb4: on ohci3 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 3 ports with 3 removable, self powered > ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 > ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 > ioapic0: routing intpin 19 (PCI IRQ 19) to vector 53 > ehci1: [GIANT-LOCKED] > ehci1: [ITHREAD] > ehci1: Dropped interrupts workaround enabled > usb5: EHCI version 1.0 > usb5: companion controllers, 3 ports each: usb3 usb4 > usb5: on ehci1 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 6 ports with 6 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 > ata0: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=03 ostat0=7f ostat1=50 > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata0: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata0: reset tp2 stat0=ff stat1=00 devices=0x8 > ioapic0: routing intpin 14 (ISA IRQ 14) to vector 54 > ata0: [MPSAFE] > ata0: [ITHREAD] > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib3: at device 20.4 on pci0 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0xc000-0xcfff > pcib3: memory decode 0xfdc00000-0xfdcfffff > pcib3: prefetched decode 0xfdb00000-0xfdbfffff > pcib3: Subtractively decoded bridge. > pci3: on pcib3 > pci3: domain=0, physical bus=3 > found-> vendor=0x1317, dev=0x0985, revid=0x11 > domain=0, bus=3, slot=6, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0290, cachelnsz=1 (dwords) > lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x80 (32000 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled > pcib3: requested I/O range 0xce00-0xceff: in range > map[14]: type Memory, range 32, base 0xfdcff000, size 10, enabled > pcib3: requested memory range 0xfdcff000-0xfdcff3ff: good > pcib3: matched entry for 3.6.INTA > pcib3: slot 6 INTA hardwired to IRQ 20 > dc0: port 0xce00-0xceff mem 0xfdcff000-0xfdcff3ff irq 20 at device 6.0 on pci3 > dc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xce00 > miibus0: on dc0 > ukphy0: PHY 1 on miibus0 > ukphy0: OUI 0x000749, model 0x0001, rev. 1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: bpf attached > dc0: Ethernet address: 00:00:e8:12:73:a7 > ioapic0: routing intpin 20 (PCI IRQ 20) to vector 55 > dc0: [MPSAFE] > dc0: [ITHREAD] > ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 > ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb6: OHCI version 1.0, legacy support > usb6: SMM does not respond, resetting > usb6: on ohci4 > usb6: USB revision 1.0 > uhub6: on usb6 > uhub6: 2 ports with 2 removable, self powered > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > cpu0: on acpi0 > cpu0: switching to generic Cx mode > powernow0: on cpu0 > cpu1: on acpi0 > powernow1: on cpu1 > ata: ata0 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcd7ff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > adv0: not probed (disabled) > aha0: not probed (disabled) > aic0: not probed (disabled) > ata1 failed to probe at port 0x170 irq 15 on isa0 > bt0: not probed (disabled) > cs0: not probed (disabled) > ed0: not probed (disabled) > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > fe0: not probed (disabled) > ie0: not probed (disabled) > le0: not probed (disabled) > ppc0: parallel port found at 0x378 > ppc0: using extended I/O port range > ppc0: SPP > ppc0: at port 0x378-0x37f irq 7 on isa0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > ioapic0: routing intpin 7 (ISA IRQ 7) to vector 57 > ppbus0: [MPSAFE] > ppbus0: [ITHREAD] > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > sio0 failed to probe at port 0x3f8 irq 4 on isa0 > sio1 failed to probe at port 0x2f8 irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > Device configuration finished. > Reducing kern.maxvnodes 130270 -> 100000 > procfs registered > lapic: Divisor 2, Frequency 100213866 hz > Timecounter "TSC" frequency 2505346537 Hz quality -100 > Timecounters tick every 1.000 msec > lo0: bpf attached > ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA40 cable=40 wire > acd0: setting PIO4 on IXP700 chip > acd0: DMA limited to UDMA33, device found non-ATA66 cable > acd0: setting UDMA33 on IXP700 chip > acd0: CDRW drive at ata0 as slave > acd0: read 4134KB/s (8958KB/s) write 8958KB/s (8958KB/s), 2048KB buffer, UDMA33 > acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet > acd0: Writes: CDR, CDRW, test write, burnproof > acd0: Audio: play, 255 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: CD-ROM 120mm data disc > ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad4: 305244MB at ata2-master SATA300 > ad4: 625140335 sectors [620178C/16H/63S] 16 sectors/interrupt 1 depth queue > GEOM: new disk ad4 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > (probe0:ata0:0:1:0): error 22 > (probe0:ata0:0:1:0): Unretryable Error > (probe0:ata0:0:1:0): Down reving Protocol Version from 2 to 0? > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > (probe0:ata0:0:1:0): error 22 > (probe0:ata0:0:1:0): Unretryable Error > pass0 at ata0 bus 0 target 1 lun 0 > pass0: Removable CD-ROM SCSI-0 device > pass0: 33.000MB/s transfers > GEOM: new disk cd0 > cd0 at ata0 bus 0 target 1 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 33.000MB/s transfers > cd0: cd present [294606 x 2048 byte records] > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x80050010 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 7 to local APIC 1 > ioapic0: Assigning ISA IRQ 9 to local APIC 0 > ioapic0: Assigning ISA IRQ 14 to local APIC 1 > ioapic0: Assigning PCI IRQ 16 to local APIC 0 > ioapic0: Assigning PCI IRQ 17 to local APIC 1 > ioapic0: Assigning PCI IRQ 18 to local APIC 0 > ioapic0: Assigning PCI IRQ 19 to local APIC 1 > ioapic0: Assigning PCI IRQ 20 to local APIC 0 > ioapic0: Assigning PCI IRQ 22 to local APIC 1 > scsi_cd.c::ioctl cmd=4400648b error=25 > Trying to mount root from ufs:/dev/ad4s2a > start_init: trying /sbin/init > Linux ELF exec handler installed > fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090408/5eb1cdc5/attachment-0001.pgp From nakal at web.de Wed Apr 8 14:11:15 2009 From: nakal at web.de (Martin) Date: Wed Apr 8 14:11:23 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090408190805.GA1368@smyrak.com> References: <20090408190805.GA1368@smyrak.com> Message-ID: <20090408224925.3dd1f8ab@zelda.local> Am Wed, 8 Apr 2009 21:08:05 +0200 schrieb Piotr Smyrak : > First I started with my old build of 6.2, then upgraded to 6.4 > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > issue. None of versions gave me USB mouse support. I have tried > connecting 3 various mice. No luck. The only effect I can achieve > after connecting a mouse, is a somewhat delayed message on console: Hi, I have had also problems with recent Gigabyte Mainboards and USB mice. Something is really broken in this branch. Unlike you, I could always get my mouse to work by re-attaching it. You should perhaps take a look at the BIOS USB settings, so you could get at least the re-attaching work-around to work. BIOS settings that influence the behavior of USB mice are: - any "legacy USB support" settings - so-called "BIOS support for USB mice" Because -STABLE has been really frustrating, I migrated all my desktops to -CURRENT that has the new USB-v2 stack. The USB problems disappeared there. I'm overall satisfied with -CURRENT. I've always wanted to say that FreeBSD developers do a really great job on the -CURRENT branch. It's running very stable and has plenty of new features. I know I shouldn't recommend to migrate to -CURRENT, but I'm almost sure, it runs much better than every -CURRENT I've seen before and sometimes I have the impression that it's even nicer than the -STABLE branch. Everyone who does not like the buggy USB v1, could try to do a second installation on a free partition to get rid of the annoyances. -- Martin From 000.fbsd at quip.cz Wed Apr 8 14:59:23 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Wed Apr 8 14:59:30 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <49DD1E2E.4030009@quip.cz> Ivan Voras wrote: > Ivan Voras wrote: > > >>* Are the issues on the list still there? >>* Are there any new issues? >>* Is somebody running ZFS in production (non-trivial loads) with >>success? What architecture / RAM / load / applications used? >>* How is your memory load? (does it leave enough memory for other services) > > > also: what configuration (RAIDZ, mirror, etc.?) I have two production servers with ZFS. First is HP ProLiant ML110 G5 with 4x 1TB SATA Samsung drives in RAIDZ + 5GB RAM running FreeBSD 7.1-RELEASE amd64 (GENERIC) Root is on USB flash drive with UFS, main storage is on ZFS. # zfs list NAME USED AVAIL REFER MOUNTPOINT tank 1.34T 1.33T 29.9K /tank tank/system 1.04G 1.33T 28.4K /tank/system tank/system/tmp 52.4K 1.33T 52.4K /tmp tank/system/usr 611M 1.33T 95.0K /tank/system/usr tank/system/usr/obj 26.9K 1.33T 26.9K /usr/obj tank/system/usr/ports 443M 1.33T 214M /usr/ports tank/system/usr/ports/distfiles 105M 1.33T 105M /usr/ports/distfiles tank/system/usr/ports/packages 123M 1.33T 123M /usr/ports/packages tank/system/usr/src 168M 1.33T 168M /usr/src tank/system/var 459M 1.33T 213K /var tank/system/var/db 421M 1.33T 420M /var/db tank/system/var/db/pkg 387K 1.33T 387K /var/db/pkg tank/system/var/log 37.8M 1.33T 37.8M /var/log tank/system/var/run 60.6K 1.33T 60.6K /var/run tank/vol0 1.34T 1.33T 1.34T /vol0 This server is storage for backups made every night by rsync from 10 FreeBSD machines. It takes about 1 hour every night to do rsync backup of all machines. Rsync is used for "snapshots" with --link-dest= (each day has own directory and all unchenged files are hardlinked to previous day and I have history of two month back). Backups are stored on /vol0 with compression enabled. (compression is enabled on /usr/ports, /usr/src, /var/db/pkg, /vol0) # df -hi /vol0/ Filesystem Size Used Avail Capacity iused ifree %iused Mounted on tank/vol0 2.7T 1.3T 1.3T 50% 17939375 11172232 62% /vol0 This backup server is in service from october 2008 with just one panic (kmem related). After proper loader.conf tuning it is working well. # cat /boot/loader.conf ## ZFS tuning vm.kmem_size="1280M" vm.kmem_size_max="1280M" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="128M" up 80+04:52:10 23:33:40 28 processes: 1 running, 27 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 17M Active, 26M Inact, 1541M Wired, 328K Cache, 204M Buf, 3234M Free The second server with ZFS is used as Jails hosting. It is buil on Sun Fire X2100 M2 with 2x 500GB SATA drives + 4GB RAM running FreeBSD 7.1-STABLE amd64 from Wed Feb 11 09:56:08 CET 2009 (GENERIC kernel) The hard drives are splitted to two slices, where first slice is used for gmirrored system (about 20GB) and the rest is used for ZFS mirror. There are 5 Jails running. One with postfix as backup MX and BIND as slave DNS for little webhosting company. Few jails for webdevelopers (not heavily loaded), but last jail has 240GB of audio files for streaming throught Lighttpd with speed about 30Mbps. There are some issues with Lighttpd in conjunction with ZFS - after about 30-60 minutes, Lighttpd decrease the speed to less than 7Mbps until it is restarted, then everything works well. The server has uptime 56 days without any panic or other stability issues. Another box with Lighttpd + UFS (not in jail) is serving same files by 65Mbps without problem. (Lighttpd problem may be related to jail instead of ZFS - I did not test it yet) All jails are on compressed filesystems and there are some snapshots of each jail. # cat /boot/loader.conf ## gmirror RAID1 geom_mirror_load="YES" ## ZFS tuning vm.kmem_size="1280M" vm.kmem_size_max="1280M" kern.maxvnodes="400000" vfs.zfs.prefetch_disable="1" vfs.zfs.arc_min="16M" vfs.zfs.arc_max="128M" Miroslav Lachman From bkoenig at alpha-tierchen.de Wed Apr 8 15:20:55 2009 From: bkoenig at alpha-tierchen.de (Bjoern Koenig) Date: Wed Apr 8 15:21:02 2009 Subject: fxp: stalled transfers Message-ID: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> Hello, after upgrading my system from 7.1-RELEASE to recent RELENG_7 I noticed stalled network transfers in certain cases. I have an Intel PRO/100 ethernet adapter (card=0x00408086 chip=0x12298086 rev=0x0c). In general networking works fine. I can ping hosts, surf on websites and so on. But if I send large files (>1 MB) to my server the transfer stalls after a few kilobytes. This concerns FTP and SCP likewise. While trying to find a reason for this problem I did a binary search on the source tree using a generic kernel configuration and found out that the following commit is responsible for this: SVN rev 188374 on 2009-02-09 03:48:49Z by yongari MFC r185330: Implement TSO for 82550/82551 controllers. o Configure controller to use dynamic TBD as TSO requires that operation mode. o Add a dummy TBD to tx_cb_u as TSO can access one more TBD in TSO operation. o Increase a DMA segment size to 4096 to hold a full IP segment with link layer header. o Unlike other TSO capable controllers, 82550/82551 does not modify the first IP packet in TSO operation so driver should create an IP packet with proper header. Subsequent IP packets are generated from the header information in the first IP packet header. Likewise pseudo checksum also should be computed by driver for the first packet. o TSO requires one more TBD to hold total TCP payload. To make code simple for TSO/non-TSO case, increase the index of the first available TBD array. o Remove KASSERT that checks the size of a DMA segment should be less than or equal to MCLBYTES as it's no longer valid in TSO. o Tx threshold and number of TBDs field is used to store MSS in TSO. So don't set the Tx threshold in TSO case. I didn't look further on this commit for now. Please review it. Probably someone of you can give me a hint. Regards Bj?rn From ivoras at freebsd.org Wed Apr 8 15:35:42 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 8 15:35:49 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: <49DD1E2E.4030009@quip.cz> References: <49DD1E2E.4030009@quip.cz> Message-ID: <9bbcef730904081535l2339dc7fk6ce7957976d9425@mail.gmail.com> 2009/4/8 Miroslav Lachman <000.fbsd@quip.cz>: > (Lighttpd problem may be related to jail instead of ZFS - I did not test it > yet) Completely unrelated to ZFS, but wasn't there some issue with lighttpd and sendfile() relatively recently (sendfile is the default)? Have you tried server.network-backend = "writev" ? From fbsd-stable at mawer.org Wed Apr 8 16:26:58 2009 From: fbsd-stable at mawer.org (Antony Mawer) Date: Wed Apr 8 16:27:05 2009 Subject: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?] In-Reply-To: <200904080959.49201.fjwcash@gmail.com> References: <200904080959.49201.fjwcash@gmail.com> Message-ID: <49DD2B44.5020808@mawer.org> Freddie Cash wrote: ... > We've also heavily modified /etc/sysctl.conf and upped a bunch of the > network-related sysctls. Doing so increased our SSH throughput from ~30 > Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. Are you able to share any of these with the list? It would be useful to compare as a lot of these tunings people do individually and it would be good to allow others to test in their environments to see if they help, as well as potentially adding them to the tuning man-page. -- Antony From pyunyh at gmail.com Wed Apr 8 17:03:25 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Apr 8 17:03:32 2009 Subject: fxp: stalled transfers In-Reply-To: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> Message-ID: <20090409000427.GD37714@michelle.cdnetworks.co.kr> On Thu, Apr 09, 2009 at 12:05:06AM +0200, Bjoern Koenig wrote: > Hello, > > after upgrading my system from 7.1-RELEASE to recent RELENG_7 I noticed > stalled network transfers in certain cases. I have an Intel PRO/100 > ethernet adapter (card=0x00408086 chip=0x12298086 rev=0x0c). In general > networking works fine. I can ping hosts, surf on websites and so on. But > if I send large files (>1 MB) to my server the transfer stalls after a few > kilobytes. This concerns FTP and SCP likewise. While trying to find a > reason for this problem I did a binary search on the source tree using a > generic kernel configuration and found out that the following commit is > responsible for this: > > SVN rev 188374 on 2009-02-09 03:48:49Z by yongari > > MFC r185330: > Implement TSO for 82550/82551 controllers. > o Configure controller to use dynamic TBD as TSO requires that > operation mode. > o Add a dummy TBD to tx_cb_u as TSO can access one more TBD in TSO > operation. > o Increase a DMA segment size to 4096 to hold a full IP segment > with link layer header. > o Unlike other TSO capable controllers, 82550/82551 does not > modify the first IP packet in TSO operation so driver should > create an IP packet with proper header. Subsequent IP packets > are generated from the header information in the first IP packet > header. Likewise pseudo checksum also should be computed by > driver for the first packet. > o TSO requires one more TBD to hold total TCP payload. To make > code simple for TSO/non-TSO case, increase the index of the > first available TBD array. > o Remove KASSERT that checks the size of a DMA segment should be > less than or equal to MCLBYTES as it's no longer valid in TSO. > o Tx threshold and number of TBDs field is used to store MSS in > TSO. So don't set the Tx threshold in TSO case. > > > I didn't look further on this commit for now. Please review it. Probably > someone of you can give me a hint. > Could you disable TSO and try again?('ifconfig fxp0 -tso' will do the job). From mandrews at bit0.com Wed Apr 8 22:52:38 2009 From: mandrews at bit0.com (Mike Andrews) Date: Wed Apr 8 22:52:46 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <49DD88E0.7060209@bit0.com> Ivan Voras wrote: > Ivan Voras wrote: > >> * Are the issues on the list still there? >> * Are there any new issues? >> * Is somebody running ZFS in production (non-trivial loads) with >> success? What architecture / RAM / load / applications used? >> * How is your memory load? (does it leave enough memory for other services) > > also: what configuration (RAIDZ, mirror, etc.?) With 7.0 and 7.1 I had frequent livelocks with ZFS when it was unable to get more memory from the kernel. Tuning kmem up to 768K helped but didn't 100% eliminate the issues... still had to reboot systems every few weeks. Since most were either in a redundant cluster or personal machines, I kinda lived with it. With the increase in default kmem size in 7.2, I removed the kmem_size tuning and have not had a single ZFS-related hang since. The only tuning I use is vfs.zfs.arc_max="100M" and disabling prefetch (but leaving zil on) -- and I'm seriously considering throwing those two out (or at least raising arc_max) and seeing what happens. I'm much happier with how 7.2's ZFS behaves than 7.1's. It's definitely "getting there"... with one catch (see below). Anyone running an up-to-date STABLE -- on amd64, anyway -- should consider removing kmem_size tweaks from their loader.conf... You don't need 8.x for that, just 7.2-prerelease/beta. I don't know about i386, I'd be a bit nervous about ZFS on i386 given how much memory it wants on amd64... There is a significant issue with MySQL InnoDB logs getting corrupted if the system ever does crash/lose power/etc, very reproducible on demand on multiple 7.2/7.1/7.0 machines, but is not reproducible in HEAD and its newer ZFS v13 (which is why I never opened a pr on it). For now any MySQL masters I run must stay on UFS2, because of that showstopper... if anyone wants to try to look at it, I can open a pr or send more details, just ask. I have seen one file get corrupted in a zpool, in two separate instances (different machines each time), but was never able to reproduce it ever again. Next time it happens I'll dig into it a bit more. This is on about seven Core 2 Quad boxes with 8 GB of memory (some have only 4) and amd64. Most disk IO is writing http logs, which can get pretty busy on our webservers (usually hundreds of apache processes plus nginx, previously lighttpd, serving a few thousand concurrent hits)... plus some light maildir, some not-so-light rsync at night... Most are simple mirrored pairs of SATA disks. A few are hardware raid10 (LSI SAS, 3ware SAS) and ZFS is given just a single device... even though I know that's not optimal (two hardware raid1's or jbod would be more reliable)... those are personal boxes and not production though. I'm not brave enough to attempt booting off of ZFS yet; I use a small gmirrored UFS2 for /. I'm not swapping to ZFS either. From bkoenig at alpha-tierchen.de Thu Apr 9 00:15:14 2009 From: bkoenig at alpha-tierchen.de (Bjoern Koenig) Date: Thu Apr 9 00:15:21 2009 Subject: fxp: stalled transfers In-Reply-To: <20090409000427.GD37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> Message-ID: <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> pyunyh@gmail.com wrote: > Could you disable TSO and try again?('ifconfig fxp0 -tso' will do > the job). Yes, disabling TSO helps. That's a reasonable workaround for me. Thanks. Let me know if you need further information in case you want to make changes to the fxp driver regarding this problem. Bj?rn From pyunyh at gmail.com Thu Apr 9 00:22:02 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Apr 9 00:22:11 2009 Subject: fxp: stalled transfers In-Reply-To: <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> Message-ID: <20090409072309.GF37714@michelle.cdnetworks.co.kr> On Thu, Apr 09, 2009 at 09:15:12AM +0200, Bjoern Koenig wrote: > pyunyh@gmail.com wrote: > > > Could you disable TSO and try again?('ifconfig fxp0 -tso' will do > > the job). > > Yes, disabling TSO helps. That's a reasonable workaround for me. Thanks. > > Let me know if you need further information in case you want to make > changes to the fxp driver regarding this problem. > If you can easily reproduce the issue, can you capture stalled TCP session with tcpdump on receiving host?(Make sure to disable Rx checksum offload prior to capturing the session.) From danny at cs.huji.ac.il Thu Apr 9 00:43:08 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Thu Apr 9 00:43:42 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig90DADA8437A99D893FB775F8 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > Danny Braniss wrote: > >> Garance A Drosihn wrote: > >>> Some friends of mine are looking at the new "DroboPro", which makes a= > > >>> lot of disk space available via iSCSI (in addition to firewire 800), > >>> and they were wondering how well iSCSI works with FreeBSD. I haven't= > > >>> paid attention to iSCSI support. Is there anyone using it heavily > >>> for disk-storage under FreeBSD? Has there been much changed for > >>> iSCSI support in the 8.x branch, or is 7.x support working fine? > >> I suppose you are interested in the "client" (initiator) side of iSCSI= > > >> support. It hasn't changed much between 7.x and 8.x but there are > >> apparently some announcements of a newer version: > >> > >> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html= > > >> > >> I can't find any more information on it. > > > > the latest is in: > > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > > Thanks! > > Is there anything in particular you'd like to get tested in the new > version, any significant changes or improvements? mainly fixed some bugs, and some code cleanup. give it a spin, and let me know what target you are testing. btw, the default tag opening is a bit concervative (1), you might want to change it to somewhat larger, say 64 or 128. cheers, danny From 000.fbsd at quip.cz Thu Apr 9 00:56:24 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Thu Apr 9 00:56:32 2009 Subject: ZFSKnownProblems - needs revision? / Lighttpd In-Reply-To: <9bbcef730904081535l2339dc7fk6ce7957976d9425@mail.gmail.com> References: <49DD1E2E.4030009@quip.cz> <9bbcef730904081535l2339dc7fk6ce7957976d9425@mail.gmail.com> Message-ID: <49DDAA11.1040804@quip.cz> Ivan Voras wrote: > 2009/4/8 Miroslav Lachman <000.fbsd@quip.cz>: > >>(Lighttpd problem may be related to jail instead of ZFS - I did not test it >>yet) > > Completely unrelated to ZFS, but wasn't there some issue with lighttpd > and sendfile() relatively recently (sendfile is the default)? Have you > tried server.network-backend = "writev" ? I know about the problem with sendfile as I was hit by it on the main server with Lighttpd + UFS. It has different behavior and it was fixed in the latest version of Lighttpd from ports. Both servers (main with UFS and second with ZFS + Jail) are running this fixed version. I will test it with "writev", thanks for suggestion. With lower load, Lighttpd is shown in `top` with state 'kqread', but with higher load in the case of slowdown, the state is 'zfs->io'. Miroslav Lachman From goran.lowkrantz at ismobile.com Thu Apr 9 01:35:35 2009 From: goran.lowkrantz at ismobile.com (Goran Lowkrantz) Date: Thu Apr 9 01:35:44 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <24AB3B457082F236919D1D72@syn> Trying to build 2.1.1 on a CURRENT results in this: ===> iscsi/initiator (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_open': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:120: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:122: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:126: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_close': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:149: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:154: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_ioctl': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:184: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:210: error: invalid operands to binary & /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: In function 'iscsi_read': /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c:290: error: invalid operands to binary & /glz --On April 9, 2009 10:43:06 +0300 Danny Braniss wrote: >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enig90DADA8437A99D893FB775F8 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> Danny Braniss wrote: >> >> Garance A Drosihn wrote: >> >>> Some friends of mine are looking at the new "DroboPro", which makes >> >>> a= >> >> >>> lot of disk space available via iSCSI (in addition to firewire 800), >> >>> and they were wondering how well iSCSI works with FreeBSD. I >> >>> haven't= >> >> >>> paid attention to iSCSI support. Is there anyone using it heavily >> >>> for disk-storage under FreeBSD? Has there been much changed for >> >>> iSCSI support in the 8.x branch, or is 7.x support working fine? >> >> I suppose you are interested in the "client" (initiator) side of >> >> iSCSI= >> >> >> support. It hasn't changed much between 7.x and 8.x but there are >> >> apparently some announcements of a newer version: >> >> >> >> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.htm >> >> l= >> >> >> >> >> I can't find any more information on it. >> > >> > the latest is in: >> > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz >> >> Thanks! >> >> Is there anything in particular you'd like to get tested in the new >> version, any significant changes or improvements? > mainly fixed some bugs, and some code cleanup. > > give it a spin, and let me know what target you are testing. > btw, the default tag opening is a bit concervative (1), you might want to > change it to somewhat larger, say 64 or 128. > > cheers, > danny > > > > _______________________________________________ > 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" ................................................... the future isMobile Goran Lowkrantz System Architect, isMobile AB Sandviksgatan 81, PO Box 58, S-971 03 Lule?, Sweden Mobile: +46(0)70-587 87 82 http://www.ismobile.com ............................................... From bkoenig at alpha-tierchen.de Thu Apr 9 02:02:07 2009 From: bkoenig at alpha-tierchen.de (Bjoern Koenig) Date: Thu Apr 9 02:02:15 2009 Subject: fxp: stalled transfers In-Reply-To: <20090409072309.GF37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> Message-ID: pyunyh@gmail.com wrote: > If you can easily reproduce the issue, can you capture stalled TCP > session with tcpdump on receiving host?(Make sure to disable Rx > checksum offload prior to capturing the session.) I transferred a 256 kiB file and these are the tcpdumps: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt Actually the transfer doesn't stall although ftp and scp told me so. It becomes incredibly slow. It seems like that the chunks are too large and a smaller packet will be resent. I decreased the MTU from 1500 to 1492 and it works fine with TSO enabled. I also captured the traffic on my router: http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt It reveals a suspect information: "truncated-ip - 8 bytes missing!" I almost suppose that this is a PPPoE-related configuration issue and the fxp driver is not necessarily the problem since decreasing the MTU of the LAN host solves it. Bj?rn From ivoras at freebsd.org Thu Apr 9 03:55:32 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 9 03:55:40 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: <24AB3B457082F236919D1D72@syn> References: <24AB3B457082F236919D1D72@syn> Message-ID: Goran Lowkrantz wrote: > Trying to build 2.1.1 on a CURRENT results in this: > ===> iscsi/initiator (all) > cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE > -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer > -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone > -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -std=iso9899:1999 -fstack-protector -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c > /usr/src/sys/modules/iscsi/initiator/../../../dev/iscsi/initiator/iscsi.c: Passed on 7-STABLE amd64. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090409/4baa32b4/signature.pgp From piotr.smyrak at heron.pl Thu Apr 9 03:57:33 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Thu Apr 9 03:57:40 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090408224925.3dd1f8ab@zelda.local> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> Message-ID: <20090409104532.M16424@heron.pl> On Wed, 8 Apr 2009 22:49:25 +0200, Martin wrote > Am Wed, 8 Apr 2009 21:08:05 +0200 > schrieb Piotr Smyrak : > > > First I started with my old build of 6.2, then upgraded to 6.4 > > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > > issue. None of versions gave me USB mouse support. I have tried > > connecting 3 various mice. No luck. The only effect I can achieve > > after connecting a mouse, is a somewhat delayed message on console: > > I have had also problems with recent Gigabyte Mainboards > and USB mice. Something is really broken in this branch. > Unlike you, I could always get my mouse to work by re- > attaching it. You should perhaps take a look at the BIOS > USB settings, so you could get at least the re-attaching > work-around to work. > > BIOS settings that influence the behavior of USB mice are: > - any "legacy USB support" settings > - so-called "BIOS support for USB mice" I have 5 options regarding USB in the BIOS: * OnChip USB controller * USB EHCI controller * USB Keyboard support * USB Mouse support * Legacy USB storage detect Should mention in the original post, I have them all but the first one disabled. I have tried many combinations including disabling the OnChip controller totally. All in vain. > Because -STABLE has been really frustrating, I migrated > all my desktops to -CURRENT that has the new USB-v2 stack. > The USB problems disappeared there. > > I'm overall satisfied with -CURRENT. I've always wanted to > say that FreeBSD developers do a really great job on the > -CURRENT branch. It's running very stable and has plenty > of new features. I know I shouldn't recommend to migrate > to -CURRENT, but I'm almost sure, it runs much better than > every -CURRENT I've seen before and sometimes I have the > impression that it's even nicer than the -STABLE branch. Well, I am not scared by -CURRENT at all, but I was hesitating to upgrade main build since it is after all a moving target and I would like to keep my main work horse as much steady as possible. Thanks for suggestions, -- Piotr Smyrak piotr.smyrak@heron.pl From piotr.smyrak at heron.pl Thu Apr 9 04:01:15 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Thu Apr 9 04:01:22 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <1239223684.4491.12.camel@balrog.2hip.net> References: <20090408190805.GA1368@smyrak.com> <1239223684.4491.12.camel@balrog.2hip.net> Message-ID: <20090409110112.M98284@heron.pl> On Wed, 08 Apr 2009 15:48:04 -0500, Robert Noland wrote > On Wed, 2009-04-08 at 21:08 +0200, Piotr Smyrak wrote: > > > > I recently upgraded my system to newer hardware with motherboard > > GIGABYTE GA-MA74GM-S2 Rev 1.0 with AMD 740G chipset (north bridge) > > and AMD SB700 (south) where USB support is located. Everything > > would be fine except there is no USB mice detection by FreeBSD at > > all. And I am stuck with USB mise since the mobo has no PS/2 port. > > > > First I started with my old build of 6.2, then upgraded to 6.4 > > STABLE, to finally upgrade to 7.2 PRERELEASE in hope of fixing the > > issue. None of versions gave me USB mouse support. I have tried > > connecting 3 various mice. No luck. The only effect I can achieve > > after connecting a mouse, is a somewhat delayed message on console: > > rebuild/reinstall devel/libpciaccess now that you have > updated kernel. I think I was not clear in my first post. My issue is the kernel does not recognizes my USB mice, so I get no /dev/ums* devices at all. I have made a clean install of all my ports after upgrade. Thanks for your suggestion. -- Piotr Smyrak piotr.smyrak@heron.pl From ivoras at freebsd.org Thu Apr 9 04:44:51 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 9 04:45:06 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: Danny Braniss wrote: >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) >> --------------enig90DADA8437A99D893FB775F8 >> Content-Type: text/plain; charset=UTF-8 >> Content-Transfer-Encoding: quoted-printable >> >> Danny Braniss wrote: >>>> Garance A Drosihn wrote: >>>>> Some friends of mine are looking at the new "DroboPro", which makes a= >>>>> lot of disk space available via iSCSI (in addition to firewire 800), >>>>> and they were wondering how well iSCSI works with FreeBSD. I haven't= >>>>> paid attention to iSCSI support. Is there anyone using it heavily >>>>> for disk-storage under FreeBSD? Has there been much changed for >>>>> iSCSI support in the 8.x branch, or is 7.x support working fine? >>>> I suppose you are interested in the "client" (initiator) side of iSCSI= >>>> support. It hasn't changed much between 7.x and 8.x but there are >>>> apparently some announcements of a newer version: >>>> >>>> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html= >>>> I can't find any more information on it. >>> the latest is in: >>> http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz >> Thanks! >> >> Is there anything in particular you'd like to get tested in the new >> version, any significant changes or improvements? > mainly fixed some bugs, and some code cleanup. > > give it a spin, and let me know what target you are testing. > btw, the default tag opening is a bit concervative (1), you might want to > change it to somewhat larger, say 64 or 128. Hi, "camcontrol tags" hangs: Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0 Apr 9 15:36:36 terminator kernel: da3: Fixed Direct Access SCSI-5 device Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing device entry terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da* /dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c /dev/da1 /dev/da3 terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3 The configuration is: target0 { targetaddress = 161.53.72.65 targetname = iqn.2007-09.jp.ne.peach:disk1 tags = 16 } -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090409/a41d1ecb/signature.pgp From ivoras at freebsd.org Thu Apr 9 04:50:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 9 04:50:14 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: <2C0AE775-B15B-4B56-A915-6E126F25C8B0@inoc.net> References: <2C0AE775-B15B-4B56-A915-6E126F25C8B0@inoc.net> Message-ID: Robert Blayzor wrote: > On Apr 7, 2009, at 5:43 PM, Garance A Drosihn wrote: >> Some friends of mine are looking at the new "DroboPro", which makes a >> lot of disk space available via iSCSI (in addition to firewire 800), >> and they were wondering how well iSCSI works with FreeBSD. I haven't >> paid attention to iSCSI support. Is there anyone using it heavily >> for disk-storage under FreeBSD? Has there been much changed for >> iSCSI support in the 8.x branch, or is 7.x support working fine? > > > > If you're looking for "production ready" iSCSI initiator support in > FreeBSD, do yourself a favor, save some time, and look into something > else. Seriously, we went down this road just recently testing both > FreeBSD 7.0/7.1 amd64 on various Dell servers with Intel (em) Gig-E > NIC's and it was very easy to basically get the box to lock up solid > and/or panic. Our targets were both Netapp and Equallogic iSCSI SAN's. > We didn't have a lot of time to debug it, our setup was pretty simple.. > yet when we tried to run various simulated real world load on it the > boxes just caved. Even with jumbo frames enabled on the NIC's the > performance was mediocre at best. Unfortunately due a time constraint > we had to move the clients to CentOS 5.2/5.3 and things have been very > good so far. I was hoping that FreeBSD's iSCSI support was a bit more > solid, or at least hoping that the (isp) driver had support for the > QLogic iSCSI HBA's... no luck. I have a feeling this is because the ISCSI initiator in FreeBSD hasn't been updated since 2007. There have been patches and new development but nothing committed and/or MFC-ed. I'm just starting to evaluate it, so I can't say anything about its stability yet. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090409/9135f2db/signature.pgp From freegih at gmail.com Wed Apr 8 23:49:07 2009 From: freegih at gmail.com (GOD) Date: Thu Apr 9 05:07:48 2009 Subject: system report 7.2 beta1 Message-ID: <49DD95EB.9040606@gmail.com> I trace all of 7.* version on my laptop. But some thing is always a problem! 1. The acpi is not well supported. I try acpiconf -s 3 , the system will die. 2 The ath0 wifi support, I test and nerver find it can transfer with more than 5MB per second rate. 3 The big problem of my laptop is the intel video card, xorg eat up half of my memory,and it's very slow moving windows . Please check my log in attachments! And please tell me any more testing infomation you want ?! -------------- 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 7.2-PRERELEASE #1: Tue Apr 7 12:39:46 CST 2009 root@lvm.net:/usr/obj/usr/src/sys/kernel Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz (1795.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fd Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 2 real memory = 1037762560 (989 MB) avail memory = 1001181184 (954 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported unknown: I/O range not supported acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 3dd00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x5c00-0x5c07 mem 0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 32764k stolen memory agp0: aperture size is 256M acpi_video0: on vgapci0 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 vgapci1: at device 2.1 on pci0 uhci0: port 0x5880-0x589f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x5800-0x581f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x5480-0x549f irq 19 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfe0fbc00-0xfe0fbfff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered hdac0: mem 0xfe0f4000-0xfe0f7fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.1 on pci0 pci2: on pcib2 ath0: irq 17 at device 0.0 on pci2 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: Ethernet address: 00:23:4d:dc:31:d3 ath0: mac 14.2 phy 7.0 radio 10.2 pcib3: irq 18 at device 28.2 on pci0 pci3: on pcib3 pcib4: irq 19 at device 28.3 on pci0 pci12: on pcib4 re0: port 0xe800-0xe8ff mem 0xfcfff000-0xfcffffff,0xfcfe0000-0xfcfeffff irq 19 at device 0.0 on pci12 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:22:15:b1:6f:b2 re0: [FILTER] uhci3: port 0x5400-0x541f irq 23 at device 29.0 on pci0 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 0x5080-0x509f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0x5000-0x501f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xfe0fb800-0xfe0fbbff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib5: at device 30.0 on pci0 pci13: on pcib5 fwohci0: <1394 Open Host Controller Interface> mem 0xfebff800-0xfebfffff irq 16 at device 0.0 on pci13 fwohci0: [FILTER] fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:06:1b:00:00:82:51:4e fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:06:1b:82:51:4e fwe0: Ethernet address: 02:06:1b:82:51:4e fwip0: on firewire0 fwip0: Firewire address: 00:06:1b:00:00:82:51:4e @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1074000 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci13: at device 0.1 (no driver attached) pci13: at device 0.2 (no driver attached) pci13: at device 0.3 (no driver attached) pci13: at device 0.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x4c00-0x4c07,0x4880-0x4883,0x4800-0x4807,0x4480-0x4483,0x4400-0x441f mem 0xfe0fb000-0xfe0fb7ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.20 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: port not implemented ata4: [ITHREAD] ata5: on atapci0 ata5: port not implemented ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 battery0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [SSDT] - 4A, should be D9 [20070320] ACPI Warning (tbutils-0243): Incorrect checksum in table [ATKG] - 2A, should be 64 [20070320] est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 617092506000925 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcf7ff pnpid ORM0000 on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad4: 152627MB at ata2-master SATA150 acd0: CDRW at ata3-master SATA150 hdac0: HDA Codec #0: Conexant CX20561 (Hermosa) hdac0: HDA Codec #2: Intel G45 HDMI pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 2 nid 1 on hdac0 SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a -------------- next part -------------- 0: udi = '/org/freedesktop/Hal/devices/psm_0' info.udi = '/org/freedesktop/Hal/devices/psm_0' (string) input.device = '/dev/psm0' (string) info.subsystem = 'platform' (string) input.x11_driver = 'mouse' (string) info.product = 'PS/2 Mouse' (string) info.addons = { 'hald-addon-mouse-sysmouse' } (string list) freebsd.driver = 'psm' (string) platform.id = 'psm.0' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/atkbdc_0' (string) freebsd.device_file = '/dev/psm0' (string) info.capabilities = { 'input', 'input.mouse' } (string list) info.category = 'input.mouse' (string) 1: udi = '/org/freedesktop/Hal/devices/pcm_0_oss_mixer_0' oss.device_file = '/dev/mixer0' (string) info.udi = '/org/freedesktop/Hal/devices/pcm_0_oss_mixer_0' (string) info.product = 'HDA Conexant CX20561 (Hermosa) PCM #0 Analog (mixer)' (string) oss.originating_device = '/org/freedesktop/Hal/devices/pcm_0' (string) oss.device_id = 'HDA Conexant CX20561 (Hermosa) PCM #0 Analog (mixer)' (string) oss.type = 'mixer' (string) info.parent = '/org/freedesktop/Hal/devices/pcm_0' (string) oss.card = 0 (0x0) (int) info.capabilities = { 'oss' } (string list) oss.device = 0 (0x0) (int) info.category = 'oss' (string) oss.card_id = 'snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex default)' (string) 2: udi = '/org/freedesktop/Hal/devices/pcm_0_oss_pcm_0' oss.device_file = '/dev/dsp0' (string) info.udi = '/org/freedesktop/Hal/devices/pcm_0_oss_pcm_0' (string) info.product = 'HDA Conexant CX20561 (Hermosa) PCM #0 Analog (pcm)' (string) oss.originating_device = '/org/freedesktop/Hal/devices/pcm_0' (string) oss.device_id = 'HDA Conexant CX20561 (Hermosa) PCM #0 Analog (pcm)' (string) oss.type = 'pcm' (string) info.parent = '/org/freedesktop/Hal/devices/pcm_0' (string) oss.card = 0 (0x0) (int) info.capabilities = { 'oss' } (string list) oss.device = 0 (0x0) (int) info.category = 'oss' (string) oss.card_id = 'snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex default)' (string) 3: udi = '/org/freedesktop/Hal/devices/pcm_1_oss_mixer_1' oss.device_file = '/dev/mixer1' (string) info.udi = '/org/freedesktop/Hal/devices/pcm_1_oss_mixer_1' (string) info.product = 'HDA Conexant CX20561 (Hermosa) PCM #1 Analog (mixer)' (string) oss.originating_device = '/org/freedesktop/Hal/devices/pcm_1' (string) oss.device_id = 'HDA Conexant CX20561 (Hermosa) PCM #1 Analog (mixer)' (string) oss.type = 'mixer' (string) info.parent = '/org/freedesktop/Hal/devices/pcm_1' (string) oss.card = 1 (0x1) (int) info.capabilities = { 'oss' } (string list) oss.device = 1 (0x1) (int) info.category = 'oss' (string) oss.card_id = 'snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex)' (string) 4: udi = '/org/freedesktop/Hal/devices/pcm_1_oss_pcm_1' oss.device_file = '/dev/dsp1' (string) info.udi = '/org/freedesktop/Hal/devices/pcm_1_oss_pcm_1' (string) info.product = 'HDA Conexant CX20561 (Hermosa) PCM #1 Analog (pcm)' (string) oss.originating_device = '/org/freedesktop/Hal/devices/pcm_1' (string) oss.device_id = 'HDA Conexant CX20561 (Hermosa) PCM #1 Analog (pcm)' (string) oss.type = 'pcm' (string) info.parent = '/org/freedesktop/Hal/devices/pcm_1' (string) oss.card = 1 (0x1) (int) info.capabilities = { 'oss' } (string list) oss.device = 1 (0x1) (int) info.category = 'oss' (string) oss.card_id = 'snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex)' (string) 5: udi = '/org/freedesktop/Hal/devices/pcm_2_oss_mixer_2' oss.device_file = '/dev/mixer2' (string) info.udi = '/org/freedesktop/Hal/devices/pcm_2_oss_mixer_2' (string) info.product = 'HDA Intel G45 HDMI PCM #0 Digital (mixer)' (string) oss.originating_device = '/org/freedesktop/Hal/devices/pcm_2' (string) oss.device_id = 'HDA Intel G45 HDMI PCM #0 Digital (mixer)' (string) oss.type = 'mixer' (string) info.parent = '/org/freedesktop/Hal/devices/pcm_2' (string) oss.card = 2 (0x2) (int) info.capabilities = { 'oss' } (string list) oss.device = 2 (0x2) (int) info.category = 'oss' (string) oss.card_id = 'snd_hda [MPSAFE] (1p:1v/0r:0v channels)' (string) 6: udi = '/org/freedesktop/Hal/devices/pcm_2_oss_pcm_2' oss.device_file = '/dev/dsp2' (string) info.udi = '/org/freedesktop/Hal/devices/pcm_2_oss_pcm_2' (string) info.product = 'HDA Intel G45 HDMI PCM #0 Digital (pcm)' (string) oss.originating_device = '/org/freedesktop/Hal/devices/pcm_2' (string) oss.device_id = 'HDA Intel G45 HDMI PCM #0 Digital (pcm)' (string) oss.type = 'pcm' (string) info.parent = '/org/freedesktop/Hal/devices/pcm_2' (string) oss.card = 2 (0x2) (int) info.capabilities = { 'oss' } (string list) oss.device = 2 (0x2) (int) info.category = 'oss' (string) oss.card_id = 'snd_hda [MPSAFE] (1p:1v/0r:0v channels)' (string) 7: udi = '/org/freedesktop/Hal/devices/acpi_video_0_display_device_lcd_0' info.udi = '/org/freedesktop/Hal/devices/acpi_video_0_display_device_lcd_0' (string) info.product = 'lcd' (string) display_device.type = 'lcd' (string) display_device.lcd.brightness = 100 (0x64) (int) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/acpi_video_0' (string) info.capabilities = { 'display_device' } (string list) info.category = 'display_device' (string) 8: udi = '/org/freedesktop/Hal/devices/acpi_video_0_display_device_crt_0' info.udi = '/org/freedesktop/Hal/devices/acpi_video_0_display_device_crt_0' (string) info.product = 'crt' (string) display_device.type = 'crt' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/acpi_video_0' (string) info.capabilities = { 'display_device' } (string list) info.category = 'display_device' (string) 9: udi = '/org/freedesktop/Hal/devices/sio_0_serial_platform_0' serial.device = '/dev/ttyd0' (string) info.udi = '/org/freedesktop/Hal/devices/sio_0_serial_platform_0' (string) serial.port = 0 (0x0) (int) serial.type = 'platform' (string) info.parent = '/org/freedesktop/Hal/devices/sio_0' (string) info.capabilities = { 'serial' } (string list) info.category = 'serial' (string) serial.originating_device = '/org/freedesktop/Hal/devices/sio_0' (string) 10: udi = '/org/freedesktop/Hal/devices/net_00_22_15_b1_6f_b2' info.udi = '/org/freedesktop/Hal/devices/net_00_22_15_b1_6f_b2' (string) net.interface_up = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.WakeOnLan' } (string list) info.product = 'Networking Interface' (string) net.physical_device = '/org/freedesktop/Hal/devices/pci_10ec_8168' (string) net.80203.mac_address = 146392838066 (0x2215b16fb2) (uint64) net.80203.rate = 0 (0x0) (uint64) net.address = '00:22:15:b1:6f:b2' (string) net.80203.link = true (bool) net.interface = 're0' (string) org.freedesktop.Hal.Device.WakeOnLan.method_names = { 'GetSupported', 'GetEnabled', 'SetEnabled' } (string list) net.originating_device = '/org/freedesktop/Hal/devices/pci_10ec_8168' (string) org.freedesktop.Hal.Device.WakeOnLan.method_signatures = { '', '', 'b' } (string list) info.parent = '/org/freedesktop/Hal/devices/pci_10ec_8168' (string) net.media = 'Ethernet autoselect (none)' (string) org.freedesktop.Hal.Device.WakeOnLan.method_argnames = { '', '', 'enable' } (string list) info.capabilities = { 'net', 'net.80203', 'wake_on_lan' } (string list) net.arp_proto_hw_id = 1 (0x1) (int) org.freedesktop.Hal.Device.WakeOnLan.method_execpaths = { 'hal-system-wol-supported', 'hal-system-wol-enabled', 'hal-system-wol-enable' } (string list) net.freebsd.ifindex = 2 (0x2) (int) info.category = 'net.80203' (string) 11: udi = '/org/freedesktop/Hal/devices/net_00_23_4d_dc_31_d3' info.udi = '/org/freedesktop/Hal/devices/net_00_23_4d_dc_31_d3' (string) net.80211.mac_address = 151630131667 (0x234ddc31d3) (uint64) net.interface_up = true (bool) info.product = 'WLAN Networking Interface' (string) net.physical_device = '/org/freedesktop/Hal/devices/pci_168c_001c' (string) net.address = '00:23:4d:dc:31:d3' (string) net.interface = 'ath0' (string) net.originating_device = '/org/freedesktop/Hal/devices/pci_168c_001c' (string) info.parent = '/org/freedesktop/Hal/devices/pci_168c_001c' (string) net.media = 'IEEE 802.11 Wireless Ethernet autoselect (autoselect)' (string) info.capabilities = { 'net', 'net.80211' } (string list) net.arp_proto_hw_id = 1 (0x1) (int) net.freebsd.ifindex = 1 (0x1) (int) info.category = 'net.80211' (string) 12: udi = '/org/freedesktop/Hal/devices/storage_serial_HE46_007380' block.device = '/dev/acd0' (string) storage.cdrom.write_speed = 4234 (0x108a) (int) block.major = 0 (0x0) (int) block.minor = 107 (0x6b) (int) storage.bus = 'sata' (string) info.udi = '/org/freedesktop/Hal/devices/storage_serial_HE46_007380' (string) storage.drive_type = 'cdrom' (string) freebsd.driver = 'acd' (string) info.subsystem = 'block' (string) storage.removable = true (bool) freebsd.unit = 0 (0x0) (int) info.product = 'DVD/CDRW UJDA782' (string) storage.requires_eject = true (bool) storage.hotpluggable = false (bool) storage.media_check_enabled = true (bool) storage.automount_enabled_hint = true (bool) storage.no_partitions_hint = true (bool) info.vendor = 'DVD/CDRW' (string) storage.removable.support_async_notification = false (bool) storage.originating_device = '/org/freedesktop/Hal/devices/ide_3_0' (string) storage.model = 'DVD/CDRW UJDA782' (string) storage.vendor = 'DVD/CDRW' (string) storage.serial = 'HE46 007380' (string) storage.firmware_revision = 'VB23' (string) block.is_volume = false (bool) freebsd.device_file = '/dev/acd0' (string) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_HE46_007380' (string) storage.cdrom.cdr = true (bool) info.capabilities = { 'block', 'storage', 'storage.cdrom' } (string list) info.category = 'storage.cdrom' (string) storage.cdrom.cdrw = true (bool) storage.cdrom.dvd = true (bool) storage.cdrom.dvdr = false (bool) storage.cdrom.dvdrw = false (bool) info.addons = { 'hald-addon-storage' } (string list) storage.cdrom.dvdram = false (bool) storage.cdrom.dvdplusr = false (bool) storage.cdrom.dvdplusrw = false (bool) storage.cdrom.write_speeds = { '4234', '2822', '1411', '706' } (string list) info.interfaces = { 'org.freedesktop.Hal.Device.Storage', 'org.freedesktop.Hal.Device.Storage', 'org.freedesktop.Hal.Device.Storage.Removable' } (string list) storage.cdrom.dvdplusrdl = false (bool) storage.removable.media_available = false (bool) storage.cdrom.dvdplusrwdl = false (bool) org.freedesktop.Hal.Device.Storage.method_names = { 'Eject', 'CloseTray' } (string list) storage.cdrom.bd = false (bool) org.freedesktop.Hal.Device.Storage.method_signatures = { 'as', 'as' } (string list) storage.cdrom.bdr = false (bool) org.freedesktop.Hal.Device.Storage.method_argnames = { 'extra_options', 'extra_options' } (string list) storage.cdrom.bdre = false (bool) org.freedesktop.Hal.Device.Storage.method_execpaths = { 'hal-storage-eject', 'hal-storage-closetray' } (string list) storage.cdrom.hddvd = false (bool) info.parent = '/org/freedesktop/Hal/devices/ide_3_0' (string) storage.cdrom.hddvdr = false (bool) storage.cdrom.hddvdrw = false (bool) storage.cdrom.support_media_changed = false (bool) storage.cdrom.read_speed = 4234 (0x108a) (int) 13: udi = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' storage.automount_enabled_hint = true (bool) info.vendor = 'FUJITSU' (string) info.udi = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) info.subsystem = 'block' (string) storage.no_partitions_hint = false (bool) block.device = '/dev/ad4' (string) storage.removable.support_async_notification = false (bool) info.product = 'FUJITSU MHZ2160BH G1' (string) block.major = 0 (0x0) (int) storage.originating_device = '/org/freedesktop/Hal/devices/ide_2_0' (string) block.minor = 95 (0x5f) (int) storage.model = 'FUJITSU MHZ2160BH G1' (string) freebsd.driver = 'ad' (string) storage.bus = 'sata' (string) storage.vendor = 'FUJITSU' (string) freebsd.unit = 4 (0x4) (int) storage.drive_type = 'disk' (string) storage.serial = 'K60WT8A2DGTB' (string) storage.removable = false (bool) storage.firmware_revision = '0084000A' (string) info.parent = '/org/freedesktop/Hal/devices/ide_2_0' (string) freebsd.device_file = '/dev/ad4' (string) storage.requires_eject = false (bool) block.is_volume = false (bool) info.capabilities = { 'block', 'storage' } (string list) storage.hotpluggable = false (bool) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) info.category = 'storage' (string) storage.media_check_enabled = false (bool) 14: udi = '/org/freedesktop/Hal/devices/volume_size_2147483648' volume.num_blocks = 4194304 (0x400000) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_size_2147483648' (string) info.subsystem = 'block' (string) volume.is_mounted = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.Volume' } (string list) block.device = '/dev/ad4s1a' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume (ufs)' (string) block.major = 0 (0x0) (int) volume.is_partition = false (bool) volume.mount_point = '/' (string) block.minor = 100 (0x64) (int) volume.ignore = false (bool) volume.fsversion = '2' (string) volume.fsusage = 'filesystem' (string) org.freedesktop.Hal.Device.Volume.method_names = { 'Mount', 'Unmount', 'Eject' } (string list) volume.fstype = 'ufs' (string) org.freedesktop.Hal.Device.Volume.method_signatures = { 'ssas', 'as', 'as' } (string list) volume.label = '' (string) org.freedesktop.Hal.Device.Volume.method_argnames = { 'mount_point fstype extra_options', 'extra_options', 'extra_options' } (string list) info.parent = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) volume.uuid = '' (string) block.is_volume = true (bool) org.freedesktop.Hal.Device.Volume.method_execpaths = { 'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject' } (string list) info.capabilities = { 'block', 'volume' } (string list) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.mount.valid_options = { 'ro', 'noexec', 'noatime' } (string list) info.category = 'volume' (string) volume.size = 2147483648 (0x80000000) (uint64) 15: udi = '/org/freedesktop/Hal/devices/volume_size_536870912' volume.num_blocks = 1048576 (0x100000) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_size_536870912' (string) info.subsystem = 'block' (string) volume.is_mounted = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.Volume' } (string list) block.device = '/dev/ad4s1d' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume (ufs)' (string) block.major = 0 (0x0) (int) volume.is_partition = false (bool) volume.mount_point = '/tmp' (string) block.minor = 102 (0x66) (int) volume.ignore = false (bool) volume.fsversion = '2' (string) volume.fsusage = 'filesystem' (string) org.freedesktop.Hal.Device.Volume.method_names = { 'Mount', 'Unmount', 'Eject' } (string list) volume.fstype = 'ufs' (string) org.freedesktop.Hal.Device.Volume.method_signatures = { 'ssas', 'as', 'as' } (string list) volume.label = '' (string) org.freedesktop.Hal.Device.Volume.method_argnames = { 'mount_point fstype extra_options', 'extra_options', 'extra_options' } (string list) info.parent = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) volume.uuid = '' (string) block.is_volume = true (bool) org.freedesktop.Hal.Device.Volume.method_execpaths = { 'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject' } (string list) info.capabilities = { 'block', 'volume' } (string list) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.mount.valid_options = { 'ro', 'noexec', 'noatime' } (string list) info.category = 'volume' (string) volume.size = 536870912 (0x20000000) (uint64) 16: udi = '/org/freedesktop/Hal/devices/volume_size_8589934592' volume.num_blocks = 16777216 (0x1000000) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_size_8589934592' (string) info.subsystem = 'block' (string) volume.is_mounted = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.Volume' } (string list) block.device = '/dev/ad4s1e' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume (ufs)' (string) block.major = 0 (0x0) (int) volume.is_partition = false (bool) volume.mount_point = '/var' (string) block.minor = 103 (0x67) (int) volume.ignore = false (bool) volume.fsversion = '2' (string) volume.fsusage = 'filesystem' (string) org.freedesktop.Hal.Device.Volume.method_names = { 'Mount', 'Unmount', 'Eject' } (string list) volume.fstype = 'ufs' (string) org.freedesktop.Hal.Device.Volume.method_signatures = { 'ssas', 'as', 'as' } (string list) volume.label = '' (string) org.freedesktop.Hal.Device.Volume.method_argnames = { 'mount_point fstype extra_options', 'extra_options', 'extra_options' } (string list) info.parent = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) volume.uuid = '' (string) block.is_volume = true (bool) org.freedesktop.Hal.Device.Volume.method_execpaths = { 'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject' } (string list) info.capabilities = { 'block', 'volume' } (string list) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.mount.valid_options = { 'ro', 'noexec', 'noatime' } (string list) info.category = 'volume' (string) volume.size = 8589934592 (0x200000000) (uint64) 17: udi = '/org/freedesktop/Hal/devices/volume_size_68719476736' volume.num_blocks = 134217728 (0x8000000) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_size_68719476736' (string) info.subsystem = 'block' (string) volume.is_mounted = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.Volume' } (string list) block.device = '/dev/ad4s1f' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume (ufs)' (string) block.major = 0 (0x0) (int) volume.is_partition = false (bool) volume.mount_point = '/home' (string) block.minor = 104 (0x68) (int) volume.ignore = false (bool) volume.fsversion = '2' (string) volume.fsusage = 'filesystem' (string) org.freedesktop.Hal.Device.Volume.method_names = { 'Mount', 'Unmount', 'Eject' } (string list) volume.fstype = 'ufs' (string) org.freedesktop.Hal.Device.Volume.method_signatures = { 'ssas', 'as', 'as' } (string list) volume.label = '' (string) org.freedesktop.Hal.Device.Volume.method_argnames = { 'mount_point fstype extra_options', 'extra_options', 'extra_options' } (string list) info.parent = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) volume.uuid = '' (string) block.is_volume = true (bool) org.freedesktop.Hal.Device.Volume.method_execpaths = { 'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject' } (string list) info.capabilities = { 'block', 'volume' } (string list) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.mount.valid_options = { 'ro', 'noexec', 'noatime' } (string list) info.category = 'volume' (string) volume.size = 68719476736 (0x1000000000) (uint64) 18: udi = '/org/freedesktop/Hal/devices/volume_size_45097156608' volume.num_blocks = 88080384 (0x5400000) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_size_45097156608' (string) info.subsystem = 'block' (string) volume.is_mounted = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.Volume' } (string list) block.device = '/dev/ad4s1g' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume (ufs)' (string) block.major = 0 (0x0) (int) volume.is_partition = false (bool) volume.mount_point = '/usr' (string) block.minor = 105 (0x69) (int) volume.ignore = false (bool) volume.fsversion = '2' (string) volume.fsusage = 'filesystem' (string) org.freedesktop.Hal.Device.Volume.method_names = { 'Mount', 'Unmount', 'Eject' } (string list) volume.fstype = 'ufs' (string) org.freedesktop.Hal.Device.Volume.method_signatures = { 'ssas', 'as', 'as' } (string list) volume.label = '' (string) org.freedesktop.Hal.Device.Volume.method_argnames = { 'mount_point fstype extra_options', 'extra_options', 'extra_options' } (string list) info.parent = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) volume.uuid = '' (string) block.is_volume = true (bool) org.freedesktop.Hal.Device.Volume.method_execpaths = { 'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject' } (string list) info.capabilities = { 'block', 'volume' } (string list) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.mount.valid_options = { 'ro', 'noexec', 'noatime' } (string list) info.category = 'volume' (string) volume.size = 45097156608 (0xa80000000) (uint64) 19: udi = '/org/freedesktop/Hal/devices/volume_uuid_91D6_1EF2' volume.num_blocks = 68258434 (0x4118a82) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_uuid_91D6_1EF2' (string) info.subsystem = 'block' (string) volume.is_mounted = true (bool) info.interfaces = { 'org.freedesktop.Hal.Device.Volume' } (string list) block.device = '/dev/ad4s1h' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume (vfat)' (string) block.major = 0 (0x0) (int) volume.is_partition = false (bool) volume.mount_point = '/lvm' (string) block.minor = 106 (0x6a) (int) volume.ignore = false (bool) volume.fsversion = 'FAT32' (string) volume.fsusage = 'filesystem' (string) org.freedesktop.Hal.Device.Volume.method_names = { 'Mount', 'Unmount', 'Eject' } (string list) volume.fstype = 'vfat' (string) org.freedesktop.Hal.Device.Volume.method_signatures = { 'ssas', 'as', 'as' } (string list) volume.label = '' (string) org.freedesktop.Hal.Device.Volume.method_argnames = { 'mount_point fstype extra_options', 'extra_options', 'extra_options' } (string list) info.parent = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) volume.uuid = '91D6-1EF2' (string) block.is_volume = true (bool) org.freedesktop.Hal.Device.Volume.method_execpaths = { 'hal-storage-mount', 'hal-storage-unmount', 'hal-storage-eject' } (string list) info.capabilities = { 'block', 'volume' } (string list) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.mount.valid_options = { 'ro', 'noexec', 'noatime', 'longnames', 'shortnames', 'nowin95', '-u=', '-g=', '-m=', '-M=', '-L=', '-D=', 'large' } (string list) info.category = 'volume' (string) volume.size = 34948318208 (0x823150400) (uint64) 20: udi = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' volume.partition.media_size = 160039240704 (0x2543150400) (uint64) volume.num_blocks = 312576642 (0x12a18a82) (uint64) info.udi = '/org/freedesktop/Hal/devices/volume_part1_size_160039240704' (string) info.subsystem = 'block' (string) volume.partition.start = 32256 (0x7e00) (uint64) volume.is_mounted = false (bool) block.device = '/dev/ad4s1' (string) volume.is_disc = false (bool) volume.is_mounted_read_only = false (bool) info.product = 'Volume' (string) block.major = 0 (0x0) (int) volume.is_partition = true (bool) volume.mount_point = '' (string) block.minor = 96 (0x60) (int) volume.ignore = true (bool) volume.fsusage = 'partitiontable' (string) volume.fstype = '' (string) volume.label = '' (string) info.parent = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) volume.partition.number = 1 (0x1) (int) volume.uuid = '' (string) block.is_volume = true (bool) info.capabilities = { 'block', 'volume' } (string list) volume.partition.scheme = 'mbr' (string) volume.block_size = 512 (0x200) (uint64) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_K60WT8A2DGTB' (string) info.category = 'volume' (string) volume.partition.type = '0xa5' (string) volume.size = 160039240704 (0x2543150400) (uint64) 21: udi = '/org/freedesktop/Hal/devices/computer_scsi_host' info.udi = '/org/freedesktop/Hal/devices/computer_scsi_host' (string) info.subsystem = 'scsi_host' (string) info.product = 'SCSI Host Adapter' (string) scsi_host.host = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) 22: udi = '/org/freedesktop/Hal/devices/ide_3_0' info.udi = '/org/freedesktop/Hal/devices/ide_3_0' (string) ide.host = 3 (0x3) (int) info.subsystem = 'ide' (string) ide.channel = 0 (0x0) (int) info.product = 'IDE Device (Master)' (string) info.parent = '/org/freedesktop/Hal/devices/ide_host_3' (string) 23: udi = '/org/freedesktop/Hal/devices/ide_2_0' info.udi = '/org/freedesktop/Hal/devices/ide_2_0' (string) ide.host = 2 (0x2) (int) info.subsystem = 'ide' (string) ide.channel = 0 (0x0) (int) info.product = 'IDE Device (Master)' (string) info.parent = '/org/freedesktop/Hal/devices/ide_host_2' (string) 24: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_6_if0' usb.bus_number = 7 (0x7) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_6_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 512 (0x200) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 6 (0x6) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_6' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 294912 (0x48000) (int) usb.device_protocol = 1 (0x1) (int) usb.interface.number = 0 (0x0) (int) 25: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_6' info.vendor = 'Intel' (string) usb_device.speed_bcd = 294912 (0x48000) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_6' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 7 (0x7) (int) usb_device.version_bcd = 512 (0x200) (int) info.product = 'EHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'EHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 1 (0x1) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 7 (0x7) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_293a' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 6 (0x6) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 26: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_5_if0' usb.bus_number = 6 (0x6) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_5_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 256 (0x100) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 2 (0x2) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_5' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 4608 (0x1200) (int) usb.device_protocol = 0 (0x0) (int) usb.interface.number = 0 (0x0) (int) 27: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_5' info.vendor = 'Intel' (string) usb_device.speed_bcd = 4608 (0x1200) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_5' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 6 (0x6) (int) usb_device.version_bcd = 256 (0x100) (int) info.product = 'UHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'UHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 0 (0x0) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 6 (0x6) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2936' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 2 (0x2) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 28: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_4_if0' usb.bus_number = 5 (0x5) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_4_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 256 (0x100) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 2 (0x2) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_4' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 4608 (0x1200) (int) usb.device_protocol = 0 (0x0) (int) usb.interface.number = 0 (0x0) (int) 29: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_4' info.vendor = 'Intel' (string) usb_device.speed_bcd = 4608 (0x1200) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_4' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 5 (0x5) (int) usb_device.version_bcd = 256 (0x100) (int) info.product = 'UHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'UHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 0 (0x0) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 5 (0x5) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2935' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 2 (0x2) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 30: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_3_if0' usb.bus_number = 4 (0x4) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_3_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 256 (0x100) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 2 (0x2) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_3' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 4608 (0x1200) (int) usb.device_protocol = 0 (0x0) (int) usb.interface.number = 0 (0x0) (int) 31: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_3' info.vendor = 'Intel' (string) usb_device.speed_bcd = 4608 (0x1200) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_3' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 4 (0x4) (int) usb_device.version_bcd = 256 (0x100) (int) info.product = 'UHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'UHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 0 (0x0) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 4 (0x4) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2934' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 2 (0x2) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 32: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_2_if0' usb.bus_number = 3 (0x3) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_2_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 512 (0x200) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 6 (0x6) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_2' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 294912 (0x48000) (int) usb.device_protocol = 1 (0x1) (int) usb.interface.number = 0 (0x0) (int) 33: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_2' info.vendor = 'Intel' (string) usb_device.speed_bcd = 294912 (0x48000) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_2' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 3 (0x3) (int) usb_device.version_bcd = 512 (0x200) (int) info.product = 'EHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'EHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 1 (0x1) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 3 (0x3) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_293c' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 6 (0x6) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 34: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_1_if0' usb.bus_number = 2 (0x2) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_1_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 256 (0x100) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 2 (0x2) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_1' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 4608 (0x1200) (int) usb.device_protocol = 0 (0x0) (int) usb.interface.number = 0 (0x0) (int) 35: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_1' info.vendor = 'Intel' (string) usb_device.speed_bcd = 4608 (0x1200) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_1' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 2 (0x2) (int) usb_device.version_bcd = 256 (0x100) (int) info.product = 'UHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'UHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 0 (0x0) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 2 (0x2) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2939' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 2 (0x2) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 36: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_0_if0' usb.bus_number = 1 (0x1) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_0_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 256 (0x100) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 2 (0x2) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_0' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 4608 (0x1200) (int) usb.device_protocol = 0 (0x0) (int) usb.interface.number = 0 (0x0) (int) 37: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_0' info.vendor = 'Intel' (string) usb_device.speed_bcd = 4608 (0x1200) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_0' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 1 (0x1) (int) usb_device.version_bcd = 256 (0x100) (int) info.product = 'UHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'UHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 0 (0x0) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 1 (0x1) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2938' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 2 (0x2) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 38: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_if0' usb.bus_number = 0 (0x0) (int) usb.vendor = 'Intel' (string) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial_if0' (string) info.subsystem = 'usb' (string) usb.version_bcd = 256 (0x100) (int) usb.is_self_powered = true (bool) usb.configuration_value = 1 (0x1) (int) usb.can_wake_up = false (bool) info.product = 'USB Hub Interface' (string) usb.product_id = 0 (0x0) (int) usb.max_power = 0 (0x0) (int) usb.num_configurations = 1 (0x1) (int) usb.num_interfaces = 1 (0x1) (int) usb.vendor_id = 0 (0x0) (int) usb.num_ports = 2 (0x2) (int) usb.device_class = 9 (0x9) (int) usb.port_number = 1 (0x1) (int) usb.device_revision_bcd = 256 (0x100) (int) usb.interface.class = 9 (0x9) (int) info.parent = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial' (string) usb.device_subclass = 0 (0x0) (int) usb.interface.subclass = 0 (0x0) (int) usb.product = 'USB Hub Interface' (string) usb.interface.protocol = 0 (0x0) (int) info.bus = 'usb' (string) usb.speed_bcd = 4608 (0x1200) (int) usb.device_protocol = 0 (0x0) (int) usb.interface.number = 0 (0x0) (int) 39: udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial' info.vendor = 'Intel' (string) usb_device.speed_bcd = 4608 (0x1200) (int) info.udi = '/org/freedesktop/Hal/devices/usb_device_0_0_noserial' (string) info.subsystem = 'usb_device' (string) usb_device.bus_number = 0 (0x0) (int) usb_device.version_bcd = 256 (0x100) (int) info.product = 'UHCI root hub' (string) usb_device.configuration_value = 1 (0x1) (int) usb_device.product_id = 0 (0x0) (int) usb_device.num_configurations = 1 (0x1) (int) usb_device.vendor_id = 0 (0x0) (int) usb_device.device_class = 9 (0x9) (int) usb_device.device_revision_bcd = 256 (0x100) (int) usb_device.device_subclass = 0 (0x0) (int) usb_device.product = 'UHCI root hub' (string) freebsd.driver = 'uhub' (string) usb_device.device_protocol = 0 (0x0) (int) usb_device.vendor = 'Intel' (string) freebsd.unit = 0 (0x0) (int) usb_device.is_self_powered = true (bool) usb_device.can_wake_up = false (bool) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2937' (string) usb_device.max_power = 0 (0x0) (int) usb_device.num_interfaces = 1 (0x1) (int) usb_device.num_ports = 2 (0x2) (int) info.bus = 'usb_device' (string) usb_device.port_number = 1 (0x1) (int) 40: udi = '/org/freedesktop/Hal/devices/acpi_acad_0' info.udi = '/org/freedesktop/Hal/devices/acpi_acad_0' (string) ac_adapter.present = true (bool) info.subsystem = 'platform' (string) info.product = 'AC Adapter' (string) freebsd.driver = 'acpi_acad' (string) platform.id = 'acpi_acad.0' (string) freebsd.unit = 0 (0x0) (int) pnp.id = 'ACPI0003' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.capabilities = { 'ac_adapter' } (string list) info.category = 'ac_adapter' (string) 41: udi = '/org/freedesktop/Hal/devices/acpi_button_0' info.udi = '/org/freedesktop/Hal/devices/acpi_button_0' (string) info.subsystem = 'platform' (string) info.product = 'Sleep Button' (string) freebsd.driver = 'acpi_button' (string) platform.id = 'acpi_button.0' (string) freebsd.unit = 0 (0x0) (int) pnp.id = 'PNP0C0E' (string) pnp.description = 'ACPI sleep button device' (string) button.type = 'sleep' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.capabilities = { 'button' } (string list) info.category = 'button' (string) 42: udi = '/org/freedesktop/Hal/devices/acpi_lid_0' info.udi = '/org/freedesktop/Hal/devices/ignored-device' (string) info.subsystem = 'platform' (string) info.product = 'Ignored Device' (string) freebsd.driver = 'acpi_lid' (string) platform.id = 'acpi_lid.0' (string) freebsd.unit = 0 (0x0) (int) pnp.id = 'PNP0C0D' (string) pnp.description = 'ACPI lid device' (string) button.type = 'lid' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.ignore = true (bool) button.has_state = true (bool) button.state.value = false (bool) 43: udi = '/org/freedesktop/Hal/devices/acpi_tz_0' info.udi = '/org/freedesktop/Hal/devices/acpi_tz_0' (string) info.subsystem = 'platform' (string) info.product = 'Thermal Zone' (string) freebsd.driver = 'acpi_tz' (string) sensor.type = 'temperature' (string) platform.id = 'acpi_tz.0' (string) freebsd.unit = 0 (0x0) (int) sensor.location = 'cpu' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.capabilities = { 'sensor' } (string list) info.category = 'sensor' (string) 44: udi = '/org/freedesktop/Hal/devices/acpi_video_0' info.udi = '/org/freedesktop/Hal/devices/acpi_video_0' (string) info.subsystem = 'platform' (string) info.product = 'ACPI video extension' (string) freebsd.driver = 'acpi_video' (string) platform.id = 'acpi_video.0' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2a42' (string) 45: udi = '/org/freedesktop/Hal/devices/ide_host_0' info.udi = '/org/freedesktop/Hal/devices/ide_host_0' (string) info.subsystem = 'ide_host' (string) ide_host.number = 0 (0x0) (int) freebsd.driver = 'ata' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2919' (string) 46: udi = '/org/freedesktop/Hal/devices/ide_host_1' info.udi = '/org/freedesktop/Hal/devices/ide_host_1' (string) info.subsystem = 'ide_host' (string) ide_host.number = 1 (0x1) (int) freebsd.driver = 'ata' (string) freebsd.unit = 1 (0x1) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2919' (string) 47: udi = '/org/freedesktop/Hal/devices/ide_host_2' info.udi = '/org/freedesktop/Hal/devices/ide_host_2' (string) info.subsystem = 'ide_host' (string) info.product = 'ATA channel 0' (string) ide_host.number = 2 (0x2) (int) freebsd.driver = 'ata' (string) freebsd.unit = 2 (0x2) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) 48: udi = '/org/freedesktop/Hal/devices/ide_host_3' info.udi = '/org/freedesktop/Hal/devices/ide_host_3' (string) info.subsystem = 'ide_host' (string) info.product = 'ATA channel 1' (string) ide_host.number = 3 (0x3) (int) freebsd.driver = 'ata' (string) freebsd.unit = 3 (0x3) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) 49: udi = '/org/freedesktop/Hal/devices/ide_host_4' info.udi = '/org/freedesktop/Hal/devices/ide_host_4' (string) info.subsystem = 'ide_host' (string) info.product = 'ATA channel 2' (string) ide_host.number = 4 (0x4) (int) freebsd.driver = 'ata' (string) freebsd.unit = 4 (0x4) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) 50: udi = '/org/freedesktop/Hal/devices/ide_host_5' info.udi = '/org/freedesktop/Hal/devices/ide_host_5' (string) info.subsystem = 'ide_host' (string) info.product = 'ATA channel 3' (string) ide_host.number = 5 (0x5) (int) freebsd.driver = 'ata' (string) freebsd.unit = 5 (0x5) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) 51: udi = '/org/freedesktop/Hal/devices/ide_host_6' info.udi = '/org/freedesktop/Hal/devices/ide_host_6' (string) info.subsystem = 'ide_host' (string) info.product = 'ATA channel 4' (string) ide_host.number = 6 (0x6) (int) freebsd.driver = 'ata' (string) freebsd.unit = 6 (0x6) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) 52: udi = '/org/freedesktop/Hal/devices/ide_host_7' info.udi = '/org/freedesktop/Hal/devices/ide_host_7' (string) info.subsystem = 'ide_host' (string) info.product = 'ATA channel 5' (string) ide_host.number = 7 (0x7) (int) freebsd.driver = 'ata' (string) freebsd.unit = 7 (0x7) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) 53: udi = '/org/freedesktop/Hal/devices/atkbd_0' info.udi = '/org/freedesktop/Hal/devices/atkbd_0' (string) input.device = '' (string) info.subsystem = 'platform' (string) input.x11_driver = 'kbd' (string) info.product = 'AT Keyboard' (string) freebsd.driver = 'atkbd' (string) platform.id = 'atkbd.0' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/atkbdc_0' (string) freebsd.device_file = '/dev/atkbd0' (string) info.capabilities = { 'input', 'input.keyboard' } (string list) info.category = 'input.keyboard' (string) 54: udi = '/org/freedesktop/Hal/devices/battery_0' battery.reporting.last_full = 52230 (0xcc06) (int) battery.reporting.low = 1554 (0x612) (int) battery.reporting.warning = 5180 (0x143c) (int) battery.charge_level.unit = 'mWh' (string) info.udi = '/org/freedesktop/Hal/devices/battery_0' (string) battery.reporting.unit = 'mWh' (string) freebsd.driver = 'battery' (string) info.subsystem = 'platform' (string) battery.charge_level.design = 51840 (0xca80) (int) freebsd.unit = 0 (0x0) (int) info.product = 'ACPI Control Method Battery' (string) battery.charge_level.last_full = 52230 (0xcc06) (int) battery.charge_level.current = 51840 (0xca80) (int) battery.charge_level.rate = 0 (0x0) (int) battery.charge_level.warning = 5180 (0x143c) (int) battery.charge_level.low = 1554 (0x612) (int) info.vendor = '' (string) battery.charge_level.granularity_1 = 518 (0x206) (int) battery.charge_level.granularity_2 = 518 (0x206) (int) battery.is_rechargeable = true (bool) battery.charge_level.percentage = 99 (0x63) (int) battery.rechargeable.is_charging = false (bool) platform.id = 'battery.0' (string) pnp.id = 'PNP0C0A' (string) battery.rechargeable.is_discharging = false (bool) pnp.description = 'ACPI Control Method Battery' (string) battery.vendor = '' (string) battery.model = '' (string) info.capabilities = { 'battery' } (string list) battery.technology = '' (string) info.category = 'battery' (string) battery.serial = '' (string) battery.type = 'primary' (string) battery.present = true (bool) battery.voltage.unit = 'mV' (string) battery.voltage.current = 12486 (0x30c6) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) battery.voltage.design = 10800 (0x2a30) (int) battery.reporting.design = 51840 (0xca80) (int) battery.reporting.current = 51840 (0xca80) (int) battery.reporting.rate = 0 (0x0) (int) 55: udi = '/org/freedesktop/Hal/devices/cpu_0' info.udi = '/org/freedesktop/Hal/devices/cpu_0' (string) info.subsystem = 'platform' (string) info.product = 'ACPI CPU' (string) freebsd.driver = 'cpu' (string) processor.number = 0 (0x0) (int) platform.id = 'cpu.0' (string) freebsd.unit = 0 (0x0) (int) processor.can_throttle = true (bool) processor.maximum_speed = 1800 (0x708) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.capabilities = { 'processor' } (string list) info.category = 'processor' (string) 56: udi = '/org/freedesktop/Hal/devices/cpu_1' info.udi = '/org/freedesktop/Hal/devices/cpu_1' (string) info.subsystem = 'platform' (string) info.product = 'ACPI CPU' (string) freebsd.driver = 'cpu' (string) processor.number = 1 (0x1) (int) platform.id = 'cpu.1' (string) freebsd.unit = 1 (0x1) (int) processor.can_throttle = true (bool) processor.maximum_speed = 1800 (0x708) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) info.capabilities = { 'processor' } (string list) info.category = 'processor' (string) 57: udi = '/org/freedesktop/Hal/devices/pci_8086_2a42_drm_i915_card0' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2a42_drm_i915_card0' (string) info.vendor = 'Intel Graphics' (string) info.subsystem = 'drm' (string) info.product = 'Direct Rendering Manager Device' (string) drm.dri_library = 'i915' (string) drm.version = 'drm 1.6.0 20080730' (string) freebsd.driver = 'drm' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2a42' (string) freebsd.device_file = '/dev/dri/card0' (string) info.capabilities = { 'drm' } (string list) info.category = 'drm' (string) 58: udi = '/org/freedesktop/Hal/devices/pcm_0' info.udi = '/org/freedesktop/Hal/devices/pcm_0' (string) info.subsystem = 'platform' (string) info.product = 'HDA Conexant CX20561 (Hermosa) PCM #0 Analog' (string) freebsd.driver = 'pcm' (string) platform.id = 'pcm.0' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_293e' (string) 59: udi = '/org/freedesktop/Hal/devices/pcm_1' info.udi = '/org/freedesktop/Hal/devices/pcm_1' (string) info.subsystem = 'platform' (string) info.product = 'HDA Conexant CX20561 (Hermosa) PCM #1 Analog' (string) freebsd.driver = 'pcm' (string) platform.id = 'pcm.1' (string) freebsd.unit = 1 (0x1) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_293e' (string) 60: udi = '/org/freedesktop/Hal/devices/pcm_2' info.udi = '/org/freedesktop/Hal/devices/pcm_2' (string) info.subsystem = 'platform' (string) info.product = 'HDA Intel G45 HDMI PCM #0 Digital' (string) freebsd.driver = 'pcm' (string) platform.id = 'pcm.2' (string) freebsd.unit = 2 (0x2) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_293e' (string) 61: udi = '/org/freedesktop/Hal/devices/atkbdc_0' info.udi = '/org/freedesktop/Hal/devices/atkbdc_0' (string) info.subsystem = 'platform' (string) info.product = 'Keyboard controller (i8042)' (string) freebsd.driver = 'atkbdc' (string) platform.id = 'atkbdc.0' (string) freebsd.unit = 0 (0x0) (int) pnp.id = 'PNP0303' (string) pnp.description = 'IBM Enhanced (101/102-key, PS/2 mouse support)' (string) info.parent = '/org/freedesktop/Hal/devices/computer' (string) 62: udi = '/org/freedesktop/Hal/devices/sio_0' info.udi = '/org/freedesktop/Hal/devices/sio_0' (string) info.subsystem = 'platform' (string) freebsd.driver = 'sio' (string) platform.id = 'sio.0' (string) freebsd.unit = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2919' (string) 63: udi = '/org/freedesktop/Hal/devices/pci_8086_2a40' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2a40' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10816 (0x2a40) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = 'Mobile 4 Series Chipset Memory Controller Hub' (string) pci.product = 'Mobile 4 Series Chipset Memory Controller Hub' (string) pci.subsys_product_id = 8416 (0x20e0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'hostb' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 0 (0x0) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 64: udi = '/org/freedesktop/Hal/devices/pci_8086_2a42' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2a42' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10818 (0x2a42) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = 'Mobile 4 Series Chipset Integrated Graphics Controller' (string) pci.product = 'Mobile 4 Series Chipset Integrated Graphics Controller' (string) pci.subsys_product_id = 8420 (0x20e4) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'vgapci' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 2 (0x2) (int) pci.device_class = 3 (0x3) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 0 (0x0) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 65: udi = '/org/freedesktop/Hal/devices/pci_8086_2a43' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2a43' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10819 (0x2a43) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = 'Mobile 4 Series Chipset Integrated Graphics Controller' (string) pci.product = 'Mobile 4 Series Chipset Integrated Graphics Controller' (string) pci.subsys_product_id = 8420 (0x20e4) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'vgapci' (string) freebsd.unit = 1 (0x1) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 2 (0x2) (int) pci.device_class = 3 (0x3) (int) pci.freebsd.function = 1 (0x1) (int) pci.device_subclass = 128 (0x80) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 66: udi = '/org/freedesktop/Hal/devices/pci_8086_2937' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2937' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10551 (0x2937) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB UHCI Controller #4' (string) pci.product = '82801I (ICH9 Family) USB UHCI Controller #4' (string) pci.subsys_product_id = 8432 (0x20f0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'uhci' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 26 (0x1a) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 67: udi = '/org/freedesktop/Hal/devices/pci_8086_2938' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2938' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10552 (0x2938) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB UHCI Controller #5' (string) pci.product = '82801I (ICH9 Family) USB UHCI Controller #5' (string) pci.subsys_product_id = 8432 (0x20f0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'uhci' (string) freebsd.unit = 1 (0x1) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 26 (0x1a) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 1 (0x1) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 68: udi = '/org/freedesktop/Hal/devices/pci_8086_2939' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2939' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10553 (0x2939) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB UHCI Controller #6' (string) pci.product = '82801I (ICH9 Family) USB UHCI Controller #6' (string) pci.subsys_product_id = 8432 (0x20f0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'uhci' (string) freebsd.unit = 2 (0x2) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 26 (0x1a) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 2 (0x2) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 69: udi = '/org/freedesktop/Hal/devices/pci_8086_293c' info.udi = '/org/freedesktop/Hal/devices/pci_8086_293c' (string) pci.device_protocol = 32 (0x20) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10556 (0x293c) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB2 EHCI Controller #2' (string) pci.product = '82801I (ICH9 Family) USB2 EHCI Controller #2' (string) pci.subsys_product_id = 8433 (0x20f1) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'ehci' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 26 (0x1a) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 7 (0x7) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 70: udi = '/org/freedesktop/Hal/devices/pci_8086_293e' info.udi = '/org/freedesktop/Hal/devices/pci_8086_293e' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10558 (0x293e) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) HD Audio Controller' (string) pci.product = '82801I (ICH9 Family) HD Audio Controller' (string) pci.subsys_product_id = 8434 (0x20f2) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'hdac' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 27 (0x1b) (int) pci.device_class = 4 (0x4) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 71: udi = '/org/freedesktop/Hal/devices/pci_8086_2940' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2940' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10560 (0x2940) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) PCI Express Port 1' (string) pci.product = '82801I (ICH9 Family) PCI Express Port 1' (string) pci.subsys_product_id = 8435 (0x20f3) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'pcib' (string) freebsd.unit = 1 (0x1) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 28 (0x1c) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 4 (0x4) (int) pci.freebsd.secondary_bus = 1 (0x1) (int) 72: udi = '/org/freedesktop/Hal/devices/pci_168c_001c' info.udi = '/org/freedesktop/Hal/devices/pci_168c_001c' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Atheros Communications Inc.' (string) info.subsystem = 'pci' (string) pci.product_id = 28 (0x1c) (int) pci.vendor = 'Atheros Communications Inc.' (string) pci.vendor_id = 5772 (0x168c) (int) info.product = 'AR242x 802.11abg Wireless PCI Express Adapter' (string) pci.product = 'AR242x 802.11abg Wireless PCI Express Adapter' (string) pci.subsys_product_id = 53 (0x35) (int) pci.subsys_vendor = 'Atheros Communications Inc.' (string) pci.subsys_vendor_id = 5772 (0x168c) (int) freebsd.driver = 'ath' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 2 (0x2) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2942' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 2 (0x2) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 0 (0x0) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 73: udi = '/org/freedesktop/Hal/devices/pci_8086_2942' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2942' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10562 (0x2942) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) PCI Express Port 2' (string) pci.product = '82801I (ICH9 Family) PCI Express Port 2' (string) pci.subsys_product_id = 8435 (0x20f3) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'pcib' (string) freebsd.unit = 2 (0x2) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 28 (0x1c) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 1 (0x1) (int) pci.device_subclass = 4 (0x4) (int) pci.freebsd.secondary_bus = 2 (0x2) (int) 74: udi = '/org/freedesktop/Hal/devices/pci_8086_2944' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2944' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10564 (0x2944) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) PCI Express Port 3' (string) pci.product = '82801I (ICH9 Family) PCI Express Port 3' (string) pci.subsys_product_id = 8435 (0x20f3) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'pcib' (string) freebsd.unit = 3 (0x3) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 28 (0x1c) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 2 (0x2) (int) pci.device_subclass = 4 (0x4) (int) pci.freebsd.secondary_bus = 3 (0x3) (int) 75: udi = '/org/freedesktop/Hal/devices/pci_10ec_8168' info.udi = '/org/freedesktop/Hal/devices/pci_10ec_8168' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Realtek Semiconductor Co., Ltd.' (string) info.subsystem = 'pci' (string) pci.product_id = 33128 (0x8168) (int) pci.vendor = 'Realtek Semiconductor Co., Ltd.' (string) pci.vendor_id = 4332 (0x10ec) (int) info.product = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' (string) pci.product = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' (string) pci.subsys_product_id = 8456 (0x2108) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 're' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 12 (0xc) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2946' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 2 (0x2) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 0 (0x0) (int) pci.freebsd.secondary_bus = 240 (0xf0) (int) 76: udi = '/org/freedesktop/Hal/devices/pci_8086_2946' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2946' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10566 (0x2946) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) PCI Express Port 4' (string) pci.product = '82801I (ICH9 Family) PCI Express Port 4' (string) pci.subsys_product_id = 8435 (0x20f3) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'pcib' (string) freebsd.unit = 4 (0x4) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 28 (0x1c) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 3 (0x3) (int) pci.device_subclass = 4 (0x4) (int) pci.freebsd.secondary_bus = 12 (0xc) (int) 77: udi = '/org/freedesktop/Hal/devices/pci_8086_2934' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2934' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10548 (0x2934) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB UHCI Controller #1' (string) pci.product = '82801I (ICH9 Family) USB UHCI Controller #1' (string) pci.subsys_product_id = 8432 (0x20f0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'uhci' (string) freebsd.unit = 3 (0x3) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 29 (0x1d) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 78: udi = '/org/freedesktop/Hal/devices/pci_8086_2935' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2935' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10549 (0x2935) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB UHCI Controller #2' (string) pci.product = '82801I (ICH9 Family) USB UHCI Controller #2' (string) pci.subsys_product_id = 8432 (0x20f0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'uhci' (string) freebsd.unit = 4 (0x4) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 29 (0x1d) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 1 (0x1) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 79: udi = '/org/freedesktop/Hal/devices/pci_8086_2936' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2936' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10550 (0x2936) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB UHCI Controller #3' (string) pci.product = '82801I (ICH9 Family) USB UHCI Controller #3' (string) pci.subsys_product_id = 8432 (0x20f0) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'uhci' (string) freebsd.unit = 5 (0x5) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 29 (0x1d) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 2 (0x2) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 80: udi = '/org/freedesktop/Hal/devices/pci_8086_293a' info.udi = '/org/freedesktop/Hal/devices/pci_8086_293a' (string) pci.device_protocol = 32 (0x20) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10554 (0x293a) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801I (ICH9 Family) USB2 EHCI Controller #1' (string) pci.product = '82801I (ICH9 Family) USB2 EHCI Controller #1' (string) pci.subsys_product_id = 8433 (0x20f1) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'ehci' (string) freebsd.unit = 1 (0x1) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 29 (0x1d) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 7 (0x7) (int) pci.device_subclass = 3 (0x3) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 81: udi = '/org/freedesktop/Hal/devices/pci_1180_0832' info.udi = '/org/freedesktop/Hal/devices/pci_1180_0832' (string) pci.device_protocol = 16 (0x10) (int) info.vendor = 'Ricoh Co Ltd' (string) info.subsystem = 'pci' (string) pci.product_id = 2098 (0x832) (int) pci.vendor = 'Ricoh Co Ltd' (string) pci.vendor_id = 4480 (0x1180) (int) info.product = 'R5C832 IEEE 1394 Controller' (string) pci.product = 'R5C832 IEEE 1394 Controller' (string) pci.subsys_product_id = 8457 (0x2109) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'fwohci' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 13 (0xd) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 12 (0xc) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 0 (0x0) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 82: udi = '/org/freedesktop/Hal/devices/pci_1180_0822' info.udi = '/org/freedesktop/Hal/devices/pci_1180_0822' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Ricoh Co Ltd' (string) info.subsystem = 'pci' (string) pci.product_id = 2082 (0x822) (int) pci.vendor = 'Ricoh Co Ltd' (string) pci.vendor_id = 4480 (0x1180) (int) info.product = 'R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter' (string) pci.product = 'R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter' (string) pci.subsys_product_id = 8458 (0x210a) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) pci.freebsd.bus = 13 (0xd) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 8 (0x8) (int) pci.freebsd.function = 1 (0x1) (int) pci.device_subclass = 5 (0x5) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 83: udi = '/org/freedesktop/Hal/devices/pci_1180_0843' info.udi = '/org/freedesktop/Hal/devices/pci_1180_0843' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Ricoh Co Ltd' (string) info.subsystem = 'pci' (string) pci.product_id = 2115 (0x843) (int) pci.vendor = 'Ricoh Co Ltd' (string) pci.vendor_id = 4480 (0x1180) (int) info.product = 'R5C843 MMC Host Controller' (string) pci.product = 'R5C843 MMC Host Controller' (string) pci.subsys_product_id = 8459 (0x210b) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) pci.freebsd.bus = 13 (0xd) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 8 (0x8) (int) pci.freebsd.function = 2 (0x2) (int) pci.device_subclass = 128 (0x80) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 84: udi = '/org/freedesktop/Hal/devices/pci_1180_0592' info.udi = '/org/freedesktop/Hal/devices/pci_1180_0592' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Ricoh Co Ltd' (string) info.subsystem = 'pci' (string) pci.product_id = 1426 (0x592) (int) pci.vendor = 'Ricoh Co Ltd' (string) pci.vendor_id = 4480 (0x1180) (int) info.product = 'R5C592 Memory Stick Bus Host Adapter' (string) pci.product = 'R5C592 Memory Stick Bus Host Adapter' (string) pci.subsys_product_id = 8460 (0x210c) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) pci.freebsd.bus = 13 (0xd) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 8 (0x8) (int) pci.freebsd.function = 3 (0x3) (int) pci.device_subclass = 128 (0x80) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 85: udi = '/org/freedesktop/Hal/devices/pci_1180_0852' info.udi = '/org/freedesktop/Hal/devices/pci_1180_0852' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Ricoh Co Ltd' (string) info.subsystem = 'pci' (string) pci.product_id = 2130 (0x852) (int) pci.vendor = 'Ricoh Co Ltd' (string) pci.vendor_id = 4480 (0x1180) (int) info.product = 'xD-Picture Card Controller' (string) pci.product = 'xD-Picture Card Controller' (string) pci.subsys_product_id = 8461 (0x210d) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) pci.freebsd.bus = 13 (0xd) (int) info.parent = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) pci.freebsd.device = 0 (0x0) (int) pci.device_class = 8 (0x8) (int) pci.freebsd.function = 4 (0x4) (int) pci.device_subclass = 128 (0x80) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 86: udi = '/org/freedesktop/Hal/devices/pci_8086_2448' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2448' (string) pci.device_protocol = 1 (0x1) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 9288 (0x2448) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = '82801 Mobile PCI Bridge' (string) pci.product = '82801 Mobile PCI Bridge' (string) pci.subsys_product_id = 8436 (0x20f4) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'pcib' (string) freebsd.unit = 5 (0x5) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 30 (0x1e) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 4 (0x4) (int) pci.freebsd.secondary_bus = 13 (0xd) (int) 87: udi = '/org/freedesktop/Hal/devices/pci_8086_2919' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2919' (string) pci.device_protocol = 0 (0x0) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10521 (0x2919) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = 'ICH9M LPC Interface Controller' (string) pci.product = 'ICH9M LPC Interface Controller' (string) pci.subsys_product_id = 8438 (0x20f6) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'isab' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 31 (0x1f) (int) pci.device_class = 6 (0x6) (int) pci.freebsd.function = 0 (0x0) (int) pci.device_subclass = 1 (0x1) (int) pci.freebsd.secondary_bus = 0 (0x0) (int) 88: udi = '/org/freedesktop/Hal/devices/pci_8086_2929' info.udi = '/org/freedesktop/Hal/devices/pci_8086_2929' (string) pci.device_protocol = 1 (0x1) (int) info.vendor = 'Intel Corporation' (string) info.subsystem = 'pci' (string) pci.product_id = 10537 (0x2929) (int) pci.vendor = 'Intel Corporation' (string) pci.vendor_id = 32902 (0x8086) (int) info.product = 'ICH9M/M-E SATA AHCI Controller' (string) pci.product = 'ICH9M/M-E SATA AHCI Controller' (string) pci.subsys_product_id = 8440 (0x20f8) (int) pci.subsys_vendor = 'Lenovo' (string) pci.subsys_vendor_id = 6058 (0x17aa) (int) freebsd.driver = 'atapci' (string) freebsd.unit = 0 (0x0) (int) pci.freebsd.bus = 0 (0x0) (int) info.parent = '/org/freedesktop/Hal/devices/computer' (string) pci.freebsd.device = 31 (0x1f) (int) pci.device_class = 1 (0x1) (int) pci.freebsd.function = 2 (0x2) (int) pci.device_subclass = 6 (0x6) (int) pci.freebsd.secondary_bus = 72 (0x48) (int) 89: udi = '/org/freedesktop/Hal/devices/computer' info.udi = '/org/freedesktop/Hal/devices/computer' (string) system.firmware.version = '6AET48WW' (string) power_management.can_suspend_to_disk = true (bool) info.subsystem = 'unknown' (string) system.firmware.release_date = '10/01/2008' (string) info.interfaces = { 'org.freedesktop.Hal.Device.SystemPowerManagement' } (string list) info.product = 'Computer' (string) system.hardware.vendor = 'LENOVO' (string) org.freedesktop.Hal.Device.SystemPowerManagement.method_names = { 'Suspend', 'SuspendHybrid', 'Hibernate', 'Shutdown', 'Reboot', 'SetPowerSave' } (string list) system.kernel.name = 'FreeBSD' (string) system.hardware.product = '27437DC' (string) org.freedesktop.Hal.Device.SystemPowerManagement.method_signatures = { 'i', 'i', '', '', '', 'b' } (string list) system.kernel.version = '7.2-PRERELEASE' (string) system.hardware.version = 'ThinkPad SL400' (string) org.freedesktop.Hal.Device.SystemPowerManagement.method_argnames = { 'num_seconds_to_sleep', 'num_seconds_to_sleep', '', '', '', 'enable_power_save' } (string list) system.kernel.machine = 'i386' (string) system.hardware.serial = 'L3AXA6A' (string) org.freedesktop.Hal.Device.SystemPowerManagement.method_execpaths = { 'hal-system-power-suspend', 'hal-system-power-suspend-hybrid', 'hal-system-power-hibernate', 'hal-system-power-shutdown', 'hal-system-power-reboot', 'hal-system-power-set-power-save' } (string list) system.formfactor = 'laptop' (string) system.hardware.uuid = '808144AD-80B6-DD81-3616-002215B16FB2' (string) power_management.is_powersave_set = false (bool) power_management.type = 'acpi' (string) system.chassis.manufacturer = 'LENOVO' (string) info.callouts.add = { 'hal-storage-cleanup-all-mountpoints' } (string list) power_management.can_suspend = true (bool) system.chassis.type = 'Notebook' (string) power_management.can_hibernate = true (bool) system.product = '27437DC ThinkPad SL400' (string) system.firmware.vendor = 'LENOVO' (string) power_management.can_suspend_to_ram = true (bool) -------------- next part -------------- Id Refs Address Size Name 1 20 0xc0400000 a1ec60 kernel 2 2 0xc0e1f000 4a62c sound.ko 3 1 0xc0e6a000 1ae38 snd_hda.ko 4 1 0xc0e85000 55d0 acpi_video.ko 5 2 0xc0e8b000 6a45c acpi.ko 6 1 0xc0ef6000 a2d4 i915.ko 7 2 0xc0f01000 1634c drm.ko 8 1 0xc46f4000 7000 linprocfs.ko 9 1 0xc46fb000 22000 linux.ko -------------- next part -------------- kern.ostype: FreeBSD kern.osrelease: 7.2-PRERELEASE kern.osrevision: 199506 kern.version: FreeBSD 7.2-PRERELEASE #1: Tue Apr 7 12:39:46 CST 2009 root@lvm.net:/usr/obj/usr/src/sys/kernel kern.maxvnodes: 67569 kern.maxproc: 6164 kern.maxfiles: 12328 kern.argmax: 262144 kern.securelevel: -1 kern.hostname: lvm.net kern.hostid: 2971900183 kern.clockrate: { hz = 1000, tick = 1000, profhz = 2000, stathz = 133 } kern.posix1version: 200112 kern.ngroups: 16 kern.job_control: 1 kern.saved_ids: 0 kern.boottime: { sec = 1239190035, usec = 919969 } Wed Apr 8 19:27:15 2009 kern.domainname: kern.osreldate: 701106 kern.bootfile: /boot/kernel/kernel kern.maxfilesperproc: 11095 kern.maxprocperuid: 5547 kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 40 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 100 kern.ipc.max_datalen: 104 kern.ipc.nmbjumbo16: 3200 kern.ipc.nmbjumbo9: 6400 kern.ipc.nmbjumbop: 12800 kern.ipc.nmbclusters: 25600 kern.ipc.piperesizeallowed: 1 kern.ipc.piperesizefail: 0 kern.ipc.pipeallocfail: 0 kern.ipc.pipefragretry: 0 kern.ipc.pipekva: 671744 kern.ipc.maxpipekva: 16764928 kern.ipc.msgseg: 2048 kern.ipc.msgssz: 8 kern.ipc.msgtql: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgmni: 40 kern.ipc.msgmax: 16384 kern.ipc.semaem: 16384 kern.ipc.semvmx: 32767 kern.ipc.semusz: 136 kern.ipc.semume: 10 kern.ipc.semopm: 100 kern.ipc.semmsl: 60 kern.ipc.semmnu: 30 kern.ipc.semmns: 60 kern.ipc.semmni: 10 kern.ipc.semmap: 30 kern.ipc.shm_allow_removed: 0 kern.ipc.shm_use_phys: 0 kern.ipc.shmall: 8192 kern.ipc.shmseg: 128 kern.ipc.shmmni: 192 kern.ipc.shmmin: 1 kern.ipc.shmmax: 33554432 kern.ipc.maxsockets: 25600 kern.ipc.numopensockets: 109 kern.ipc.nsfbufsused: 0 kern.ipc.nsfbufspeak: 5 kern.ipc.nsfbufs: 6656 kern.dummy: 0 kern.ps_strings: 3217031152 kern.usrstack: 3217031168 kern.logsigexit: 1 kern.iov_max: 1024 kern.hostuuid: 808144ad-80b6-dd81-3616-002215b16fb2 kern.cam.cam_srch_hi: 0 kern.cam.scsi_delay: 5000 kern.cam.cd.retry_count: 4 kern.cam.cd.changer.max_busy_seconds: 15 kern.cam.cd.changer.min_busy_seconds: 5 kern.cam.da.da_send_ordered: 1 kern.cam.da.default_timeout: 60 kern.cam.da.retry_count: 4 kern.dcons.poll_hz: 100 kern.disks: ad4 kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.elf32.fallback_brand: -1 kern.init_shutdown_timeout: 120 kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall kern.acct_suspended: 0 kern.acct_configured: 0 kern.acct_chkfreq: 15 kern.acct_resume: 4 kern.acct_suspend: 2 kern.cp_times: 29282 1488 14587 894 200671 30147 1081 15023 4128 195881 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 kern.cp_time: 59429 2569 29611 5022 396553 kern.openfiles: 449 kern.kq_calloutmax: 4096 kern.ps_arg_cache_limit: 256 kern.stackprot: 7 kern.randompid: 0 kern.lastpid: 26698 kern.ktrace.request_pool: 100 kern.ktrace.genio_size: 4096 kern.module_path: /boot/kernel;/boot/modules;/usr/local/modules kern.malloc_count: 268 kern.fallback_elf_brand: -1 kern.features.compat_freebsd6: 1 kern.features.compat_freebsd5: 1 kern.features.compat_freebsd4: 1 kern.maxusers: 384 kern.ident: WONDER kern.kstack_pages: 2 kern.shutdown.kproc_shutdown_wait: 60 kern.shutdown.poweroff_delay: 5000 kern.sync_on_panic: 0 kern.corefile: %N.core kern.nodump_coredump: 0 kern.coredump: 1 kern.sugid_coredump: 0 kern.sigqueue.alloc_fail: 0 kern.sigqueue.overflow: 0 kern.sigqueue.preallocate: 1024 kern.sigqueue.max_pending_per_proc: 128 kern.forcesigexit: 1 kern.fscale: 2048 kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 37350 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 11879265 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1073449235 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 64309144 kern.timecounter.tc.TSC.frequency: 300000000 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 0 kern.threads.virtual_cpu: 2 kern.threads.max_threads_hits: 0 kern.threads.max_threads_per_proc: 1500 kern.ccpu: 0 kern.sched.preemption: 1 kern.sched.topology: 0 kern.sched.steal_thresh: 1 kern.sched.steal_idle: 1 kern.sched.steal_htt: 1 kern.sched.balance_interval: 133 kern.sched.balance: 1 kern.sched.tryself: 1 kern.sched.affinity: 3 kern.sched.pick_pri: 1 kern.sched.preempt_thresh: 64 kern.sched.interact: 30 kern.sched.slice: 13 kern.sched.name: ULE kern.devstat.version: 6 kern.devstat.generation: 237 kern.devstat.numdevs: 1 kern.kobj_methodcount: 154 kern.log_wakeups_per_second: 5 kern.sgrowsiz: 131072 kern.maxssiz: 67108864 kern.dflssiz: 8388608 kern.maxdsiz: 734003200 kern.dfldsiz: 134217728 kern.maxtsiz: 134217728 kern.maxbcache: 209715200 kern.maxswzone: 33554432 kern.nswbuf: 256 kern.nbuf: 6918 kern.ncallout: 18508 kern.hz: 1000 kern.msgbuf_clear: 0 kern.msgbuf: kern.always_console_output: 0 kern.log_console_output: 1 kern.smp.forward_roundrobin_enabled: 1 kern.smp.forward_signal_enabled: 1 kern.smp.cpus: 2 kern.smp.disabled: 0 kern.smp.active: 1 kern.smp.maxcpus: 16 kern.smp.maxid: 15 kern.nselcoll: 0 kern.tty_nout: 366134 kern.tty_nin: 2831 kern.drainwait: 300 kern.constty_wakeups_per_second: 5 kern.consmsgbuf_size: 8192 kern.consmute: 0 kern.console: consolectl,dcons,/dcons,consolectl,ttyd0, kern.minvnodes: 16892 kern.metadelay: 28 kern.dirdelay: 29 kern.filedelay: 30 kern.chroot_allow_open_directories: 1 kern.rpc.invalid: 0 kern.rpc.unexpected: 0 kern.rpc.timeouts: 0 kern.rpc.request: 0 kern.rpc.retries: 0 kern.random.yarrow.gengateinterval: 10 kern.random.yarrow.bins: 10 kern.random.yarrow.fastthresh: 192 kern.random.yarrow.slowthresh: 256 kern.random.yarrow.slowoverthresh: 2 kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 kern.random.sys.harvest.interrupt: 1 kern.random.sys.harvest.swi: 0 vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 1 Page Wait: 0 Sleep: 78) Virtual Memory: (Total: 2680784K, Active 430944K) Real Memory: (Total: 386436K Active 196904K) Shared Virtual Memory: (Total: 84048K Active: 79864K) Shared Real Memory: (Total: 54352K Active: 51868K) Free Memory Pages: 141252K vm.loadavg: { 0.30 0.41 0.34 } vm.v_free_min: 1595 vm.v_free_target: 6749 vm.v_free_reserved: 369 vm.v_inactive_target: 10123 vm.v_cache_min: 6749 vm.v_cache_max: 13498 vm.v_pageout_free_min: 34 vm.pageout_algorithm: 0 vm.swap_enabled: 1 vm.kmem_size_scale: 3 vm.kmem_size_max: 335544320 vm.kmem_size_min: 0 vm.kmem_size: 335355904 vm.nswapdev: 1 vm.dmmax: 32 vm.swap_async_max: 4 vm.zone_count: 100 vm.swap_idle_threshold2: 10 vm.swap_idle_threshold1: 2 vm.exec_map_entries: 16 vm.stats.misc.zero_page_count: 1 vm.stats.misc.cnt_prezero: 0 vm.stats.vm.v_kthreadpages: 0 vm.stats.vm.v_rforkpages: 0 vm.stats.vm.v_vforkpages: 1484921 vm.stats.vm.v_forkpages: 3254436 vm.stats.vm.v_kthreads: 59 vm.stats.vm.v_rforks: 0 vm.stats.vm.v_vforks: 9532 vm.stats.vm.v_forks: 17107 vm.stats.vm.v_interrupt_free_min: 2 vm.stats.vm.v_pageout_free_min: 34 vm.stats.vm.v_cache_max: 13498 vm.stats.vm.v_cache_min: 6749 vm.stats.vm.v_cache_count: 8 vm.stats.vm.v_inactive_count: 112354 vm.stats.vm.v_inactive_target: 10123 vm.stats.vm.v_active_count: 32486 vm.stats.vm.v_wire_count: 65280 vm.stats.vm.v_free_count: 35305 vm.stats.vm.v_free_min: 1595 vm.stats.vm.v_free_target: 6749 vm.stats.vm.v_free_reserved: 369 vm.stats.vm.v_page_count: 245623 vm.stats.vm.v_page_size: 4096 vm.stats.vm.v_tfree: 3259193 vm.stats.vm.v_pfree: 2087601 vm.stats.vm.v_dfree: 0 vm.stats.vm.v_tcached: 1598 vm.stats.vm.v_pdpages: 0 vm.stats.vm.v_pdwakeups: 0 vm.stats.vm.v_reactivated: 939 vm.stats.vm.v_intrans: 132 vm.stats.vm.v_vnodepgsout: 0 vm.stats.vm.v_vnodepgsin: 17764 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodein: 2175 vm.stats.vm.v_swappgsout: 0 vm.stats.vm.v_swappgsin: 0 vm.stats.vm.v_swapout: 0 vm.stats.vm.v_swapin: 0 vm.stats.vm.v_ozfod: 67852 vm.stats.vm.v_zfod: 1991834 vm.stats.vm.v_cow_optim: 2972 vm.stats.vm.v_cow_faults: 648150 vm.stats.vm.v_vm_faults: 3242094 vm.stats.sys.v_soft: 338424 vm.stats.sys.v_intr: 317071 vm.stats.sys.v_syscall: 21971796 vm.stats.sys.v_trap: 3381162 vm.stats.sys.v_swtch: 4664007 vm.stats.object.bypasses: 5970 vm.stats.object.collapses: 85324 vm.v_free_severe: 982 vm.max_proc_mmap: 49317 vm.old_msync: 0 vm.msync_flush_flags: 3 vm.boot_pages: 48 vm.max_wired: 80655 vm.pageout_lock_miss: 0 vm.disable_swapspace_pageouts: 0 vm.defer_swapspace_pageouts: 0 vm.swap_idle_enabled: 0 vm.pageout_stats_interval: 5 vm.pageout_full_stats_interval: 20 vm.pageout_stats_max: 6749 vm.max_launder: 32 vm.phys_segs: SEGMENT 0: start: 0x1000 end: 0x9e000 free list: 0xc0cec3c8 SEGMENT 1: start: 0x100000 end: 0x400000 free list: 0xc0cec3c8 SEGMENT 2: start: 0x1025000 end: 0x3cbff000 free list: 0xc0cec2c0 vm.phys_free: FREE LIST 0: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 2 | 0 7 ( 512K) | 0 | 0 6 ( 256K) | 1 | 0 5 ( 128K) | 1 | 0 4 ( 64K) | 1 | 0 3 ( 32K) | 1 | 0 2 ( 16K) | 0 | 0 1 ( 8K) | 0 | 0 0 ( 4K) | 0 | 0 FREE LIST 1: ORDER (SIZE) | NUMBER | POOL 0 | POOL 1 -- -- -- -- -- -- 10 ( 4096K) | 0 | 0 9 ( 2048K) | 0 | 0 8 ( 1024K) | 0 | 0 7 ( 512K) | 0 | 0 6 ( 256K) | 0 | 0 5 ( 128K) | 0 | 0 4 ( 64K) | 0 | 0 3 ( 32K) | 0 | 0 2 ( 16K) | 0 | 0 1 ( 8K) | 0 | 0 0 ( 4K) | 0 | 0 vm.reserv.reclaimed: 10 vm.reserv.partpopq: LEVEL SIZE NUMBER -1: 138720K, 44 vm.reserv.freed: 1673 vm.reserv.broken: 0 vm.idlezero_enable: 0 vm.kvm_free: 415232000 vm.kvm_size: 1073737728 vm.pmap.pmap_collect_active: 0 vm.pmap.pmap_collect_inactive: 0 vm.pmap.pv_entry_spare: 10918 vm.pmap.pv_entry_allocs: 16272911 vm.pmap.pv_entry_frees: 16199157 vm.pmap.pc_chunk_tryfail: 0 vm.pmap.pc_chunk_frees: 73574 vm.pmap.pc_chunk_allocs: 73826 vm.pmap.pc_chunk_count: 252 vm.pmap.pv_entry_count: 73754 vm.pmap.pde.promotions: 0 vm.pmap.pde.p_failures: 0 vm.pmap.pde.mappings: 0 vm.pmap.pde.demotions: 0 vm.pmap.shpgperproc: 200 vm.pmap.pv_entry_max: 1478736 vm.pmap.pg_ps_enabled: 0 vfs.nfs4.access_cache_timeout: 60 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.skip_wcc_data_onerr: 1 vfs.nfs.nfs3_jukebox_delay: 10 vfs.nfs.reconnects: 0 vfs.nfs.bufpackets: 4 vfs.nfs.realign_count: 0 vfs.nfs.realign_test: 0 vfs.nfs.defect: 0 vfs.nfs.iodmax: 20 vfs.nfs.iodmin: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.diskless_rootpath: vfs.nfs.diskless_valid: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.nfs_directio_allow_mmap: 1 vfs.nfs.nfs_directio_enable: 0 vfs.nfs.clean_pages_on_close: 1 vfs.nfs.nfsv3_commit_on_close: 0 vfs.nfs.prime_access_cache: 1 vfs.nfs.access_cache_timeout: 60 vfs.ufs.dirhash_docheck: 0 vfs.ufs.dirhash_mem: 2037017 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_minsize: 2560 vfs.devfs.rule_depth: 1 vfs.devfs.generation: 129 vfs.pfs.trace: 0 vfs.pfs.vncache.misses: 2 vfs.pfs.vncache.hits: 2 vfs.pfs.vncache.maxentries: 1 vfs.pfs.vncache.entries: 0 vfs.flushwithdeps: 0 vfs.getnewbufrestarts: 0 vfs.getnewbufcalls: 119088 vfs.hifreebuffers: 778 vfs.lofreebuffers: 389 vfs.numfreebuffers: 6895 vfs.dirtybufthresh: 1574 vfs.hidirtybuffers: 1749 vfs.lodirtybuffers: 874 vfs.numdirtybuffers: 23 vfs.recursiveflushes: 2212 vfs.altbufferflushes: 0 vfs.bdwriteskip: 0 vfs.dirtybufferflushes: 0 vfs.hirunningspace: 1048576 vfs.lorunningspace: 524288 vfs.bufdefragcnt: 0 vfs.buffreekvacnt: 0 vfs.bufreusecnt: 6874 vfs.hibufspace: 112689152 vfs.lobufspace: 112623616 vfs.maxmallocbufspace: 5634457 vfs.bufmallocspace: 0 vfs.maxbufspace: 113344512 vfs.bufspace: 112623616 vfs.runningbufspace: 0 vfs.vmiodirenable: 1 vfs.cache.numfullpathfound: 10792 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathcalls: 10792 vfs.cache.nchstats: 2177354 168604 213 0 779119 0 88178 89093 vfs.cache.numneghits: 168604 vfs.cache.numnegzaps: 44 vfs.cache.numposhits: 2177354 vfs.cache.numposzaps: 169 vfs.cache.nummisszap: 99 vfs.cache.nummiss: 779020 vfs.cache.numchecks: 3309246 vfs.cache.dotdothits: 134272 vfs.cache.dothits: 2927 vfs.cache.numcalls: 3262489 vfs.cache.numcache: 61566 vfs.cache.numneg: 3847 vfs.read_max: 8 vfs.write_behind: 1 vfs.lookup_shared: 0 vfs.usermount: 1 vfs.worklist_len: 7 vfs.timestamp_precision: 0 vfs.reassignbufcalls: 35487 vfs.freevnodes: 16862 vfs.wantfreevnodes: 16892 vfs.numvnodes: 57808 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.commit_miss: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.async: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.gatherdelay_v3: 0 vfs.nfsrv.gatherdelay: 10000 vfs.ffs.doreallocblks: 1 vfs.ffs.doasyncfree: 1 vfs.ffs.compute_summary_at_mount: 0 net.local.stream.recvspace: 8192 net.local.stream.sendspace: 8192 net.local.dgram.recvspace: 4096 net.local.dgram.maxdgram: 2048 net.local.recycled: 0 net.local.taskcount: 0 net.local.inflight: 0 net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.forwarding: 0 net.inet.ip.redirect: 1 net.inet.ip.ttl: 64 net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 net.inet.ip.sourceroute: 0 net.inet.ip.intr_queue_maxlen: 50 net.inet.ip.intr_queue_drops: 0 net.inet.ip.accept_sourceroute: 0 net.inet.ip.keepfaith: 0 net.inet.ip.gifttl: 30 net.inet.ip.same_prefix_carp_only: 0 net.inet.ip.subnets_are_local: 0 net.inet.ip.fastforwarding: 0 net.inet.ip.maxfragpackets: 800 net.inet.ip.maxfragsperpacket: 16 net.inet.ip.fragpackets: 0 net.inet.ip.check_interface: 0 net.inet.ip.random_id: 0 net.inet.ip.sendsourcequench: 0 net.inet.ip.process_options: 1 net.inet.icmp.maskrepl: 0 net.inet.icmp.icmplim: 200 net.inet.icmp.bmcastecho: 0 net.inet.icmp.quotelen: 8 net.inet.icmp.reply_from_interface: 0 net.inet.icmp.reply_src: net.inet.icmp.icmplim_output: 1 net.inet.icmp.log_redirect: 0 net.inet.icmp.drop_redirect: 0 net.inet.icmp.maskfake: 0 net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 1 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 3 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 net.inet.udp.checksum: 1 net.inet.udp.maxdgram: 9216 net.inet.udp.recvspace: 42080 net.inet.udp.soreceive_dgram_enabled: 1 net.inet.udp.blackhole: 0 net.inet.udp.log_in_vain: 0 net.inet.sctp.nat_friendly_init: 1 net.inet.sctp.enable_sack_immediately: 0 net.inet.sctp.udp_tunneling_port: 0 net.inet.sctp.udp_tunneling_for_client_enable: 0 net.inet.sctp.mobility_fasthandoff: 0 net.inet.sctp.mobility_base: 0 net.inet.sctp.default_frag_interleave: 1 net.inet.sctp.default_cc_module: 0 net.inet.sctp.log_level: 0 net.inet.sctp.max_retran_chunk: 30 net.inet.sctp.min_residual: 1452 net.inet.sctp.strict_data_order: 0 net.inet.sctp.abort_at_limit: 0 net.inet.sctp.hb_max_burst: 4 net.inet.sctp.do_sctp_drain: 1 net.inet.sctp.max_chained_mbufs: 5 net.inet.sctp.abc_l_var: 1 net.inet.sctp.nat_friendly: 1 net.inet.sctp.auth_disable: 0 net.inet.sctp.asconf_auth_nochk: 0 net.inet.sctp.early_fast_retran_msec: 250 net.inet.sctp.early_fast_retran: 0 net.inet.sctp.cwnd_maxburst: 1 net.inet.sctp.cmt_pf: 0 net.inet.sctp.cmt_use_dac: 0 net.inet.sctp.nr_sack_on_off: 0 net.inet.sctp.cmt_on_off: 0 net.inet.sctp.outgoing_streams: 10 net.inet.sctp.add_more_on_output: 1452 net.inet.sctp.path_rtx_max: 5 net.inet.sctp.assoc_rtx_max: 10 net.inet.sctp.init_rtx_max: 8 net.inet.sctp.valid_cookie_life: 60000 net.inet.sctp.init_rto_max: 60000 net.inet.sctp.rto_initial: 3000 net.inet.sctp.rto_min: 1000 net.inet.sctp.rto_max: 60000 net.inet.sctp.secret_lifetime: 3600 net.inet.sctp.shutdown_guard_time: 180 net.inet.sctp.pmtu_raise_time: 600 net.inet.sctp.heartbeat_interval: 30000 net.inet.sctp.asoc_resource: 10 net.inet.sctp.sys_resource: 1000 net.inet.sctp.sack_freq: 2 net.inet.sctp.delayed_sack_time: 200 net.inet.sctp.chunkscale: 10 net.inet.sctp.min_split_point: 2904 net.inet.sctp.pcbhashsize: 256 net.inet.sctp.tcbhashsize: 1024 net.inet.sctp.maxchunks: 3200 net.inet.sctp.maxburst: 4 net.inet.sctp.peer_chkoh: 256 net.inet.sctp.strict_init: 1 net.inet.sctp.loopback_nocsum: 1 net.inet.sctp.strict_sacks: 1 net.inet.sctp.ecn_nonce: 0 net.inet.sctp.ecn_enable: 1 net.inet.sctp.auto_asconf: 1 net.inet.sctp.recvspace: 233016 net.inet.sctp.sendspace: 233016 net.inet.raw.recvspace: 9216 net.inet.raw.maxdgram: 9216 net.inet.accf.unloadable: 0 net.link.generic.system.ifcount: 7 net.link.ether.inet.log_arp_permanent_modify: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.useloopback: 1 net.link.ether.inet.maxtries: 5 net.link.ether.inet.max_age: 1200 net.link.ether.ipfw: 0 net.link.gif.parallel_tunnels: 0 net.link.gif.max_nesting: 1 net.link.log_link_state_change: 1 net.link.tun.devfs_cloning: 1 net.inet6.ip6.forwarding: 0 net.inet6.ip6.redirect: 1 net.inet6.ip6.hlim: 64 net.inet6.ip6.maxfragpackets: 6400 net.inet6.ip6.accept_rtadv: 1 net.inet6.ip6.keepfaith: 0 net.inet6.ip6.log_interval: 5 net.inet6.ip6.hdrnestlimit: 15 net.inet6.ip6.dad_count: 1 net.inet6.ip6.auto_flowlabel: 1 net.inet6.ip6.defmcasthlim: 1 net.inet6.ip6.gifhlim: 30 net.inet6.ip6.kame_version: FreeBSD net.inet6.ip6.use_deprecated: 1 net.inet6.ip6.rr_prune: 5 net.inet6.ip6.v6only: 1 net.inet6.ip6.rtexpire: 3600 net.inet6.ip6.rtminexpire: 10 net.inet6.ip6.rtmaxcache: 128 net.inet6.ip6.use_tempaddr: 0 net.inet6.ip6.temppltime: 86400 net.inet6.ip6.tempvltime: 604800 net.inet6.ip6.auto_linklocal: 1 net.inet6.ip6.prefer_tempaddr: 0 net.inet6.ip6.use_defaultzone: 0 net.inet6.ip6.maxfrags: 6400 net.inet6.ip6.mcast_pmtu: 0 net.inet6.icmp6.rediraccept: 1 net.inet6.icmp6.redirtimeout: 600 net.inet6.icmp6.nd6_prune: 1 net.inet6.icmp6.nd6_delay: 5 net.inet6.icmp6.nd6_umaxtries: 3 net.inet6.icmp6.nd6_mmaxtries: 3 net.inet6.icmp6.nd6_useloopback: 1 net.inet6.icmp6.nodeinfo: 3 net.inet6.icmp6.errppslimit: 100 net.inet6.icmp6.nd6_maxnudhint: 0 net.inet6.icmp6.nd6_debug: 0 net.inet6.icmp6.nd6_maxqueuelen: 1 net.inet6.icmp6.nd6_onlink_ns_rfc4861: 0 net.bpf.maxinsns: 512 net.bpf.maxbufsize: 524288 net.bpf.bufsize: 4096 net.isr.swi_count: 420 net.isr.drop: 0 net.isr.queued: 423 net.isr.deferred: 0 net.isr.directed: 0 net.isr.count: 0 net.isr.direct: 1 net.raw.recvspace: 8192 net.raw.sendspace: 8192 net.my_fibnum: 0 net.add_addr_allfibs: 1 net.fibs: 1 net.route.netisr_maxqlen: 256 net.wlan.recv_bar: 1 net.wlan.debug: 0 net.wlan.0.%parent: ath0 net.wlan.0.debug: 0 net.wlan.0.inact_run: 300 net.wlan.0.inact_probe: 30 net.wlan.0.inact_auth: 180 net.wlan.0.inact_init: 30 net.wlan.0.driver_caps: 1736699151 net.wlan.0.bmiss_max: 2 debug.pfugidhack: 0 debug.firewire_debug: 0 debug.fwmem_debug: 0 debug.if_fwe_debug: 0 debug.if_fwip_debug: 0 debug.sbp_debug: 0 debug.mddebug: 0 debug.elf32_legacy_coredump: 0 debug.elf32_trace: 0 debug.bootverbose: 0 debug.boothowto: -2147483648 debug.cpufreq.verbose: 0 debug.cpufreq.lowest: 0 debug.sizeof.cdev_priv: 236 debug.sizeof.cdev: 184 debug.sizeof.g_bioq: 36 debug.sizeof.g_consumer: 60 debug.sizeof.g_provider: 88 debug.sizeof.g_geom: 68 debug.sizeof.g_class: 68 debug.sizeof.kinfo_proc: 768 debug.sizeof.buf: 356 debug.sizeof.bio: 132 debug.sizeof.proc: 696 debug.sizeof.vnode: 276 debug.sizeof.devstat: 240 debug.sizeof.namecache: 36 debug.to_avg_mpcalls: 1510 debug.to_avg_mtxcalls: 0 debug.to_avg_gcalls: 778 debug.to_avg_depth: 2548 debug.umtx.umtx_pi_allocated: 0 debug.kdb.stop_cpus: 1 debug.kdb.trap_code: 0 debug.kdb.trap: 0 debug.kdb.panic: 0 debug.kdb.enter: 0 debug.kdb.current: debug.kdb.available: debug.rman_debug: 0 debug.ttydebug: 0 debug.disablefullpath: 0 debug.disablecwd: 0 debug.vfscache: 1 debug.numcachehv: 14195 debug.numcache: 61566 debug.numneg: 3847 debug.ncnegfactor: 16 debug.nchash: 131071 debug.vnlru_nowhere: 0 debug.rush_requests: 0 debug.mpsafevfs: 1 debug.if_tun_debug: 0 debug.nlm_debug: 0 debug.collectsnapstats: 0 debug.snapdebug: 0 debug.dopersistence: 0 debug.dir_entry: 33 debug.direct_blk_ptrs: 8 debug.inode_bitmap: 28 debug.indir_blk_ptrs: 15 debug.sync_limit_hit: 0 debug.ino_limit_hit: 0 debug.blk_limit_hit: 0 debug.ino_limit_push: 0 debug.blk_limit_push: 0 debug.worklist_push: 0 debug.maxindirdeps: 50 debug.tickdelay: 2 debug.max_softdeps: 270276 debug.dobkgrdwrite: 1 debug.bigcgs: 0 debug.dircheck: 0 debug.psm.pkterrthresh: 2 debug.psm.usecs: 500000 debug.psm.secs: 0 debug.psm.errusecs: 0 debug.psm.errsecs: 2 debug.psm.hz: 20 debug.psm.loglevel: 0 debug.minidump: 1 debug.stop_cpus_with_nmi: 1 debug.PMAP1unchanged: 7433929 debug.PMAP1changed: 56195 debug.PMAP1changedcpu: 50 debug.acpi.suspend_bounce: 0 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 20070320 debug.acpi.ec.timeout: 750 debug.acpi.ec.polled: 0 debug.acpi.ec.burst: 0 debug.acpi.batt.batt_sleep_ms: 0 debug.acpi.semaphore_debug: 0 debug.acpi.resume_beep: 0 hw.machine: i386 hw.model: Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 1024622592 hw.usermem: 757219328 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.realmem: 1037762560 hw.aac.iosize_max: 65536 hw.amr.force_sg32: 0 hw.an.an_cache_iponly: 1 hw.an.an_cache_mcastonly: 0 hw.an.an_cache_mode: dbm hw.an.an_dump: off hw.ata.wc: 1 hw.ata.atapi_dma: 1 hw.ata.ata_dma_check_80pin: 1 hw.ata.ata_dma: 1 hw.ath.txbuf: 200 hw.ath.rxbuf: 40 hw.ath.regdomain: 0 hw.ath.countrycode: 0 hw.ath.xchanmode: 1 hw.ath.outdoor: 1 hw.ath.calibrate: 30 hw.ath.hal.swba_backoff: 0 hw.ath.hal.sw_brt: 10 hw.ath.hal.dma_brt: 2 hw.bce.msi_enable: 1 hw.bce.tso_enable: 1 hw.bge.allow_asf: 0 hw.cardbus.cis_debug: 0 hw.cardbus.debug: 0 hw.cs.recv_delay: 570 hw.cs.ignore_checksum_failure: 0 hw.cs.debug: 0 hw.firewire.hold_count: 3 hw.firewire.try_bmr: 1 hw.firewire.fwmem.speed: 2 hw.firewire.fwmem.eui64_lo: 0 hw.firewire.fwmem.eui64_hi: 0 hw.firewire.phydma_enable: 1 hw.firewire.nocyclemaster: 0 hw.firewire.fwe.rx_queue_len: 128 hw.firewire.fwe.tx_speed: 2 hw.firewire.fwe.stream_ch: 1 hw.firewire.fwip.rx_queue_len: 128 hw.firewire.sbp.tags: 0 hw.firewire.sbp.use_doorbell: 0 hw.firewire.sbp.scan_delay: 500 hw.firewire.sbp.login_delay: 1000 hw.firewire.sbp.exclusive_login: 1 hw.firewire.sbp.max_speed: 2 hw.firewire.sbp.auto_login: 1 hw.mfi.max_cmds: 128 hw.mfi.event_class: 0 hw.mfi.event_locale: 65535 hw.pccard.cis_debug: 0 hw.pccard.debug: 0 hw.cbb.debug: 0 hw.cbb.start_32_io: 4096 hw.cbb.start_16_io: 256 hw.cbb.start_memory: 2281701376 hw.pcic.pd6722_vsense: 1 hw.pcic.intr_mask: 57016 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.pci.do_power_resume: 1 hw.pci.do_power_nodriver: 0 hw.pci.enable_io_modes: 1 hw.pci.host_mem_start: 2147483648 hw.pci.irq_override_mask: 57080 hw.syscons.kbd_debug: 1 hw.syscons.kbd_reboot: 1 hw.syscons.bell: 1 hw.syscons.saver.keybonly: 1 hw.syscons.sc_no_suspend_vtswitch: 0 hw.usb.uplcom.interval: 100 hw.usb.uvscom.interval: 100 hw.usb.uvscom.opktsize: 8 hw.wi.debug: 0 hw.wi.txerate: 0 hw.xe.debug: 0 hw.intr_storm_threshold: 1000 hw.availpages: 250152 hw.bus.devctl_disable: 0 hw.ste.rxsyncs: 0 hw.psm.tap_timeout: 125000 hw.psm.tap_threshold: 25 hw.kbd.keymap_restrict_change: 0 hw.busdma.total_bpages: 820 hw.busdma.zone0.total_bpages: 303 hw.busdma.zone0.free_bpages: 303 hw.busdma.zone0.reserved_bpages: 0 hw.busdma.zone0.active_bpages: 0 hw.busdma.zone0.total_bounced: 0 hw.busdma.zone0.total_deferred: 0 hw.busdma.zone0.lowaddr: 0xffffffff hw.busdma.zone0.alignment: 4096 hw.busdma.zone0.boundary: 0 hw.busdma.zone1.total_bpages: 517 hw.busdma.zone1.free_bpages: 517 hw.busdma.zone1.reserved_bpages: 0 hw.busdma.zone1.active_bpages: 0 hw.busdma.zone1.total_bounced: 0 hw.busdma.zone1.total_deferred: 0 hw.busdma.zone1.lowaddr: 0xffffffff hw.busdma.zone1.alignment: 2 hw.busdma.zone1.boundary: 65536 hw.clockrate: 600 hw.via_feature_xcrypt: 0 hw.via_feature_rng: 0 hw.instruction_sse: 1 hw.apic.enable_extint: 0 hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_formats: 1 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_buffersize: 16384 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.verbose: 1 hw.snd.maxautovchans: 16 hw.snd.default_unit: 0 hw.snd.version: 2007061600/i386 hw.snd.default_auto: 0 hw.midi.instroff: 0 hw.midi.dumpraw: 0 hw.midi.debug: 0 hw.midi.stat.verbose: 0 hw.midi.seq.debug: 0 hw.acpi.supported_sleep_state: S1 S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.video.ext0.active: 0 hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 0 hw.acpi.video.lcd0.brightness: 60 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 90 hw.acpi.video.lcd0.levels: 100 90 85 80 75 70 65 60 55 50 45 40 35 30 25 20 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 42.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 105.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 110.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 2 hw.acpi.thermal.tz0._TC2: 10 hw.acpi.thermal.tz0._TSP: 100 hw.acpi.acline: 1 hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.cpu.cx_lowest: C1 hw.dri.0.name: i915 0x24 pci:0000:00:02.0 hw.dri.0.vm: slot offset size type flags address mtrr 0 0x0000000080000000 0x00080000 REG 0x88 0x00000000e4523000 no 1 0x00000000c861d000 0x00002000 SHM 0x20 0x00000000c861d000 no 2 0x00000000d0000000 0x00020000 AGP 0x00 0x0000000000000000 yes 3 0x00000000d02fe000 0x00dc0000 AGP 0x00 0x0000000000000000 yes 4 0x00000000d4978000 0x00dc0000 AGP 0x00 0x0000000000000000 yes 5 0x00000000d5738000 0x00dc0000 AGP 0x00 0x0000000000000000 yes 6 0x00000000d64f8000 0x02000000 AGP 0x00 0x0000000000000000 yes hw.dri.0.clients: a dev pid uid magic ioctls y 0 2651 0 0 320824 hw.dri.0.debug: 0 machdep.enable_panic_key: 0 machdep.adjkerntz: -28800 machdep.wall_cmos_clock: 1 machdep.disable_rtc_set: 0 machdep.conspeed: 9600 machdep.gdbspeed: 9600 machdep.conrclk: 1843200 machdep.disable_mtrrs: 0 machdep.guessed_bootdev: 2686451712 machdep.cpu_idle_hlt: 1 machdep.hlt_cpus: 0 machdep.prot_fault_translation: 0 machdep.panic_on_nmi: 1 machdep.tsc_freq: 1200000000 machdep.i8254_freq: 1193182 machdep.acpi_timer_freq: 3579545 machdep.acpi_root: 1020624 machdep.hlt_logical_cpus: 0 machdep.logical_cpus_mask: 2 user.cs_path: /usr/bin:/bin:/usr/sbin:/sbin: user.bc_base_max: 99 user.bc_dim_max: 2048 user.bc_scale_max: 99 user.bc_string_max: 1000 user.coll_weights_max: 0 user.expr_nest_max: 32 user.line_max: 2048 user.re_dup_max: 255 user.posix2_version: 199212 user.posix2_c_bind: 0 user.posix2_c_dev: 0 user.posix2_char_term: 0 user.posix2_fort_dev: 0 user.posix2_fort_run: 0 user.posix2_localedef: 0 user.posix2_sw_dev: 0 user.posix2_upe: 0 user.stream_max: 20 user.tzname_max: 255 p1003_1b.asynchronous_io: 0 p1003_1b.mapped_files: 1 p1003_1b.memlock: 0 p1003_1b.memlock_range: 0 p1003_1b.memory_protection: 0 p1003_1b.message_passing: 0 p1003_1b.prioritized_io: 0 p1003_1b.priority_scheduling: 1 p1003_1b.realtime_signals: 200112 p1003_1b.semaphores: 0 p1003_1b.fsync: 0 p1003_1b.shared_memory_objects: 1 p1003_1b.synchronized_io: 0 p1003_1b.timers: 200112 p1003_1b.aio_listio_max: -1 p1003_1b.aio_max: -1 p1003_1b.aio_prio_delta_max: -1 p1003_1b.delaytimer_max: 2147483647 p1003_1b.mq_open_max: 0 p1003_1b.pagesize: 4096 p1003_1b.rtsig_max: 62 p1003_1b.sem_nsems_max: 0 p1003_1b.sem_value_max: 0 p1003_1b.sigqueue_max: 128 p1003_1b.timer_max: 32 security.jail.jailed: 0 security.jail.jail_max_af_ips: 255 security.jail.mount_allowed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 0 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 0 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 security.bsd.suser_enabled: 1 security.bsd.unprivileged_proc_debug: 1 security.bsd.conservative_signals: 1 security.bsd.see_other_gids: 1 security.bsd.see_other_uids: 1 security.bsd.unprivileged_read_msgbuf: 1 security.bsd.hardlink_check_gid: 0 security.bsd.hardlink_check_uid: 0 security.bsd.unprivileged_get_quota: 0 compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.20 compat.linux.osname: Linux dev.nexus.0.%driver: nexus dev.nexus.0.%parent: root0 dev.ram.0.%desc: System RAM dev.ram.0.%driver: ram dev.ram.0.%parent: nexus0 dev.npx.0.%desc: math processor dev.npx.0.%driver: npx dev.npx.0.%parent: nexus0 dev.acpi.0.%desc: LENOVO TP-6A dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x1b, ECDT dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%location: handle=\_SB_.PCI0.SBRG.EC0_ dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%parent: acpi0 dev.acpi_sysresource.0.%desc: System Resource dev.acpi_sysresource.0.%driver: acpi_sysresource dev.acpi_sysresource.0.%location: handle=\_SB_.PCI0.MCH_ dev.acpi_sysresource.0.%pnpinfo: _HID=PNP0C02 _UID=10 dev.acpi_sysresource.0.%parent: acpi0 dev.acpi_sysresource.1.%desc: System Resource dev.acpi_sysresource.1.%driver: acpi_sysresource dev.acpi_sysresource.1.%location: handle=\_SB_.PCI0.SBRG.RMSC dev.acpi_sysresource.1.%pnpinfo: _HID=PNP0C02 _UID=16 dev.acpi_sysresource.1.%parent: acpi0 dev.acpi_sysresource.2.%desc: System Resource dev.acpi_sysresource.2.%driver: acpi_sysresource dev.acpi_sysresource.2.%location: handle=\_SB_.PCI0.SBRG.FWH_ dev.acpi_sysresource.2.%pnpinfo: _HID=PNP0C02 _UID=2 dev.acpi_sysresource.2.%parent: acpi0 dev.acpi_sysresource.3.%desc: System Resource dev.acpi_sysresource.3.%driver: acpi_sysresource dev.acpi_sysresource.3.%location: handle=\_SB_.PCI0.SBRG.FWHE dev.acpi_sysresource.3.%pnpinfo: _HID=PNP0C02 _UID=3 dev.acpi_sysresource.3.%parent: acpi0 dev.acpi_sysresource.4.%desc: System Resource dev.acpi_sysresource.4.%driver: acpi_sysresource dev.acpi_sysresource.4.%location: handle=\_SB_.PCI0.SBRG.OMSC dev.acpi_sysresource.4.%pnpinfo: _HID=PNP0C02 _UID=0 dev.acpi_sysresource.4.%parent: acpi0 dev.acpi_sysresource.5.%desc: System Resource dev.acpi_sysresource.5.%driver: acpi_sysresource dev.acpi_sysresource.5.%location: handle=\_SB_.PCI0.PCIE dev.acpi_sysresource.5.%pnpinfo: _HID=PNP0C02 _UID=17 dev.acpi_sysresource.5.%parent: acpi0 dev.acpi_sysresource.6.%desc: System Resource dev.acpi_sysresource.6.%driver: acpi_sysresource dev.acpi_sysresource.6.%location: handle=\_SB_.RMEM dev.acpi_sysresource.6.%pnpinfo: _HID=PNP0C01 _UID=1 dev.acpi_sysresource.6.%parent: acpi0 dev.acpi_timer.0.%desc: 24-bit timer at 3.579545MHz dev.acpi_timer.0.%driver: acpi_timer dev.acpi_timer.0.%location: unknown dev.acpi_timer.0.%pnpinfo: unknown dev.acpi_timer.0.%parent: acpi0 dev.pci_link.0.%desc: ACPI PCI Link LNKA dev.pci_link.0.%driver: pci_link dev.pci_link.0.%location: handle=\_SB_.LNKA dev.pci_link.0.%pnpinfo: _HID=PNP0C0F _UID=1 dev.pci_link.0.%parent: acpi0 dev.pci_link.1.%desc: ACPI PCI Link LNKB dev.pci_link.1.%driver: pci_link dev.pci_link.1.%location: handle=\_SB_.LNKB dev.pci_link.1.%pnpinfo: _HID=PNP0C0F _UID=2 dev.pci_link.1.%parent: acpi0 dev.pci_link.2.%desc: ACPI PCI Link LNKC dev.pci_link.2.%driver: pci_link dev.pci_link.2.%location: handle=\_SB_.LNKC dev.pci_link.2.%pnpinfo: _HID=PNP0C0F _UID=3 dev.pci_link.2.%parent: acpi0 dev.pci_link.3.%desc: ACPI PCI Link LNKD dev.pci_link.3.%driver: pci_link dev.pci_link.3.%location: handle=\_SB_.LNKD dev.pci_link.3.%pnpinfo: _HID=PNP0C0F _UID=4 dev.pci_link.3.%parent: acpi0 dev.pci_link.4.%desc: ACPI PCI Link LNKE dev.pci_link.4.%driver: pci_link dev.pci_link.4.%location: handle=\_SB_.LNKE dev.pci_link.4.%pnpinfo: _HID=PNP0C0F _UID=5 dev.pci_link.4.%parent: acpi0 dev.pci_link.5.%desc: ACPI PCI Link LNKF dev.pci_link.5.%driver: pci_link dev.pci_link.5.%location: handle=\_SB_.LNKF dev.pci_link.5.%pnpinfo: _HID=PNP0C0F _UID=6 dev.pci_link.5.%parent: acpi0 dev.pci_link.6.%desc: ACPI PCI Link LNKG dev.pci_link.6.%driver: pci_link dev.pci_link.6.%location: handle=\_SB_.LNKG dev.pci_link.6.%pnpinfo: _HID=PNP0C0F _UID=7 dev.pci_link.6.%parent: acpi0 dev.pci_link.7.%desc: ACPI PCI Link LNKH dev.pci_link.7.%driver: pci_link dev.pci_link.7.%location: handle=\_SB_.LNKH dev.pci_link.7.%pnpinfo: _HID=PNP0C0F _UID=8 dev.pci_link.7.%parent: acpi0 dev.acpi_hpet.0.%desc: High Precision Event Timer dev.acpi_hpet.0.%driver: acpi_hpet dev.acpi_hpet.0.%location: unknown dev.acpi_hpet.0.%pnpinfo: unknown dev.acpi_hpet.0.%parent: acpi0 dev.pcib.0.%desc: ACPI Host-PCI bridge dev.pcib.0.%driver: pcib dev.pcib.0.%location: handle=\_SB_.PCI0 dev.pcib.0.%pnpinfo: _HID=PNP0A08 _UID=0 dev.pcib.0.%parent: acpi0 dev.pcib.1.%desc: ACPI PCI-PCI bridge dev.pcib.1.%driver: pcib dev.pcib.1.%location: slot=28 function=0 handle=\_SB_.PCI0.P0P2 dev.pcib.1.%pnpinfo: vendor=0x8086 device=0x2940 subvendor=0x17aa subdevice=0x20f3 class=0x060400 dev.pcib.1.%parent: pci0 dev.pcib.1.wake: 0 dev.pcib.2.%desc: ACPI PCI-PCI bridge dev.pcib.2.%driver: pcib dev.pcib.2.%location: slot=28 function=1 handle=\_SB_.PCI0.P0P3 dev.pcib.2.%pnpinfo: vendor=0x8086 device=0x2942 subvendor=0x17aa subdevice=0x20f3 class=0x060400 dev.pcib.2.%parent: pci0 dev.pcib.2.wake: 0 dev.pcib.3.%desc: ACPI PCI-PCI bridge dev.pcib.3.%driver: pcib dev.pcib.3.%location: slot=28 function=2 handle=\_SB_.PCI0.P0P4 dev.pcib.3.%pnpinfo: vendor=0x8086 device=0x2944 subvendor=0x17aa subdevice=0x20f3 class=0x060400 dev.pcib.3.%parent: pci0 dev.pcib.3.wake: 0 dev.pcib.4.%desc: ACPI PCI-PCI bridge dev.pcib.4.%driver: pcib dev.pcib.4.%location: slot=28 function=3 handle=\_SB_.PCI0.P0P6 dev.pcib.4.%pnpinfo: vendor=0x8086 device=0x2946 subvendor=0x17aa subdevice=0x20f3 class=0x060400 dev.pcib.4.%parent: pci0 dev.pcib.4.wake: 0 dev.pcib.5.%desc: ACPI PCI-PCI bridge dev.pcib.5.%driver: pcib dev.pcib.5.%location: slot=30 function=0 handle=\_SB_.PCI0.P0P8 dev.pcib.5.%pnpinfo: vendor=0x8086 device=0x2448 subvendor=0x17aa subdevice=0x20f4 class=0x060401 dev.pcib.5.%parent: pci0 dev.pcib.5.wake: 0 dev.pci.0.%desc: ACPI PCI bus dev.pci.0.%driver: pci dev.pci.0.%parent: pcib0 dev.pci.1.%desc: ACPI PCI bus dev.pci.1.%driver: pci dev.pci.1.%parent: pcib1 dev.pci.1.wake: 0 dev.pci.2.%desc: ACPI PCI bus dev.pci.2.%driver: pci dev.pci.2.%parent: pcib2 dev.pci.2.wake: 0 dev.pci.3.%desc: ACPI PCI bus dev.pci.3.%driver: pci dev.pci.3.%parent: pcib3 dev.pci.3.wake: 0 dev.pci.12.%desc: ACPI PCI bus dev.pci.12.%driver: pci dev.pci.12.%parent: pcib4 dev.pci.12.wake: 0 dev.pci.13.%desc: ACPI PCI bus dev.pci.13.%driver: pci dev.pci.13.%parent: pcib5 dev.pci.13.wake: 0 dev.hostb.0.%desc: Host to PCI bridge dev.hostb.0.%driver: hostb dev.hostb.0.%location: slot=0 function=0 dev.hostb.0.%pnpinfo: vendor=0x8086 device=0x2a40 subvendor=0x17aa subdevice=0x20e0 class=0x060000 dev.hostb.0.%parent: pci0 dev.vgapci.0.%desc: VGA-compatible display dev.vgapci.0.%driver: vgapci dev.vgapci.0.%location: slot=2 function=0 handle=\_SB_.PCI0.VGA_ dev.vgapci.0.%pnpinfo: vendor=0x8086 device=0x2a42 subvendor=0x17aa subdevice=0x20e4 class=0x030000 dev.vgapci.0.%parent: pci0 dev.vgapci.1.%desc: VGA-compatible display dev.vgapci.1.%driver: vgapci dev.vgapci.1.%location: slot=2 function=1 dev.vgapci.1.%pnpinfo: vendor=0x8086 device=0x2a43 subvendor=0x17aa subdevice=0x20e4 class=0x038000 dev.vgapci.1.%parent: pci0 dev.agp.0.%desc: Intel GM45 SVGA controller dev.agp.0.%driver: agp dev.agp.0.%parent: vgapci0 dev.acpi_video.0.%desc: ACPI video extension dev.acpi_video.0.%driver: acpi_video dev.acpi_video.0.%parent: vgapci0 dev.drm.0.%desc: Mobile Intel? GM45 Express Chipset dev.drm.0.%driver: drm dev.drm.0.%parent: vgapci0 dev.uhci.0.%desc: UHCI (generic) USB controller dev.uhci.0.%driver: uhci dev.uhci.0.%location: slot=26 function=0 handle=\_SB_.PCI0.USB3 dev.uhci.0.%pnpinfo: vendor=0x8086 device=0x2937 subvendor=0x17aa subdevice=0x20f0 class=0x0c0300 dev.uhci.0.%parent: pci0 dev.uhci.0.wake: 0 dev.uhci.1.%desc: UHCI (generic) USB controller dev.uhci.1.%driver: uhci dev.uhci.1.%location: slot=26 function=1 handle=\_SB_.PCI0.USB4 dev.uhci.1.%pnpinfo: vendor=0x8086 device=0x2938 subvendor=0x17aa subdevice=0x20f0 class=0x0c0300 dev.uhci.1.%parent: pci0 dev.uhci.1.wake: 0 dev.uhci.2.%desc: UHCI (generic) USB controller dev.uhci.2.%driver: uhci dev.uhci.2.%location: slot=26 function=2 handle=\_SB_.PCI0.USB6 dev.uhci.2.%pnpinfo: vendor=0x8086 device=0x2939 subvendor=0x17aa subdevice=0x20f0 class=0x0c0300 dev.uhci.2.%parent: pci0 dev.uhci.2.wake: 0 dev.uhci.3.%desc: UHCI (generic) USB controller dev.uhci.3.%driver: uhci dev.uhci.3.%location: slot=29 function=0 handle=\_SB_.PCI0.USB0 dev.uhci.3.%pnpinfo: vendor=0x8086 device=0x2934 subvendor=0x17aa subdevice=0x20f0 class=0x0c0300 dev.uhci.3.%parent: pci0 dev.uhci.3.wake: 0 dev.uhci.4.%desc: UHCI (generic) USB controller dev.uhci.4.%driver: uhci dev.uhci.4.%location: slot=29 function=1 handle=\_SB_.PCI0.USB1 dev.uhci.4.%pnpinfo: vendor=0x8086 device=0x2935 subvendor=0x17aa subdevice=0x20f0 class=0x0c0300 dev.uhci.4.%parent: pci0 dev.uhci.4.wake: 0 dev.uhci.5.%desc: UHCI (generic) USB controller dev.uhci.5.%driver: uhci dev.uhci.5.%location: slot=29 function=2 handle=\_SB_.PCI0.USB2 dev.uhci.5.%pnpinfo: vendor=0x8086 device=0x2936 subvendor=0x17aa subdevice=0x20f0 class=0x0c0300 dev.uhci.5.%parent: pci0 dev.uhci.5.wake: 0 dev.usb.0.%desc: UHCI (generic) USB controller dev.usb.0.%driver: usb dev.usb.0.%parent: uhci0 dev.usb.1.%desc: UHCI (generic) USB controller dev.usb.1.%driver: usb dev.usb.1.%parent: uhci1 dev.usb.2.%desc: UHCI (generic) USB controller dev.usb.2.%driver: usb dev.usb.2.%parent: uhci2 dev.usb.3.%desc: EHCI (generic) USB 2.0 controller dev.usb.3.%driver: usb dev.usb.3.%parent: ehci0 dev.usb.4.%desc: UHCI (generic) USB controller dev.usb.4.%driver: usb dev.usb.4.%parent: uhci3 dev.usb.5.%desc: UHCI (generic) USB controller dev.usb.5.%driver: usb dev.usb.5.%parent: uhci4 dev.usb.6.%desc: UHCI (generic) USB controller dev.usb.6.%driver: usb dev.usb.6.%parent: uhci5 dev.usb.7.%desc: EHCI (generic) USB 2.0 controller dev.usb.7.%driver: usb dev.usb.7.%parent: ehci1 dev.uhub.0.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.0.%driver: uhub dev.uhub.0.%parent: usb0 dev.uhub.1.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.1.%driver: uhub dev.uhub.1.%parent: usb1 dev.uhub.2.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.2.%driver: uhub dev.uhub.2.%parent: usb2 dev.uhub.3.%desc: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.3.%driver: uhub dev.uhub.3.%parent: usb3 dev.uhub.4.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.4.%driver: uhub dev.uhub.4.%parent: usb4 dev.uhub.5.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.5.%driver: uhub dev.uhub.5.%parent: usb5 dev.uhub.6.%desc: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 dev.uhub.6.%driver: uhub dev.uhub.6.%parent: usb6 dev.uhub.7.%desc: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 dev.uhub.7.%driver: uhub dev.uhub.7.%parent: usb7 dev.ehci.0.%desc: EHCI (generic) USB 2.0 controller dev.ehci.0.%driver: ehci dev.ehci.0.%location: slot=26 function=7 handle=\_SB_.PCI0.USBE dev.ehci.0.%pnpinfo: vendor=0x8086 device=0x293c subvendor=0x17aa subdevice=0x20f1 class=0x0c0320 dev.ehci.0.%parent: pci0 dev.ehci.0.wake: 0 dev.ehci.1.%desc: EHCI (generic) USB 2.0 controller dev.ehci.1.%driver: ehci dev.ehci.1.%location: slot=29 function=7 handle=\_SB_.PCI0.EUSB dev.ehci.1.%pnpinfo: vendor=0x8086 device=0x293a subvendor=0x17aa subdevice=0x20f1 class=0x0c0320 dev.ehci.1.%parent: pci0 dev.ehci.1.wake: 0 dev.hdac.0.%desc: Intel 82801I High Definition Audio Controller dev.hdac.0.%driver: hdac dev.hdac.0.%location: slot=27 function=0 handle=\_SB_.PCI0.HDAC dev.hdac.0.%pnpinfo: vendor=0x8086 device=0x293e subvendor=0x17aa subdevice=0x20f2 class=0x040300 dev.hdac.0.%parent: pci0 dev.hdac.0.wake: 0 dev.hdac.0.polling: 0 dev.hdac.0.polling_interval: 250 dev.hdac.0.pindump: 0 dev.ath.0.%desc: Atheros 5424/2424 dev.ath.0.%driver: ath dev.ath.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P3.WLAN dev.ath.0.%pnpinfo: vendor=0x168c device=0x001c subvendor=0x168c subdevice=0x0035 class=0x020000 dev.ath.0.%parent: pci2 dev.ath.0.smoothing_rate: 95 dev.ath.0.sample_rate: 10 dev.ath.0.countrycode: 0 dev.ath.0.regdomain: 103 dev.ath.0.slottime: 20 dev.ath.0.acktimeout: 48 dev.ath.0.ctstimeout: 48 dev.ath.0.softled: 0 dev.ath.0.ledpin: 0 dev.ath.0.ledon: 0 dev.ath.0.ledidle: 2700 dev.ath.0.txantenna: 0 dev.ath.0.rxantenna: 2 dev.ath.0.diversity: 1 dev.ath.0.txintrperiod: 5 dev.ath.0.diag: 0 dev.ath.0.tpscale: 0 dev.ath.0.tpc: 0 dev.ath.0.tpack: 63 dev.ath.0.tpcts: 63 dev.ath.0.rfsilent: 1 dev.ath.0.rfkill: 1 dev.ath.0.monpass: 24 dev.ath.0.wake: 0 dev.re.0.%desc: RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet dev.re.0.%driver: re dev.re.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P6.GLAN dev.re.0.%pnpinfo: vendor=0x10ec device=0x8168 subvendor=0x17aa subdevice=0x2108 class=0x020000 dev.re.0.%parent: pci12 dev.re.0.wake: 0 dev.miibus.0.%desc: MII bus dev.miibus.0.%driver: miibus dev.miibus.0.%parent: re0 dev.rgephy.0.%desc: RTL8169S/8110S/8211B media interface dev.rgephy.0.%driver: rgephy dev.rgephy.0.%location: phyno=1 dev.rgephy.0.%pnpinfo: oui=0x732 model=0x11 rev=0x2 dev.rgephy.0.%parent: miibus0 dev.fwohci.0.%desc: 1394 Open Host Controller Interface dev.fwohci.0.%driver: fwohci dev.fwohci.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P0P8.CBUS dev.fwohci.0.%pnpinfo: vendor=0x1180 device=0x0832 subvendor=0x17aa subdevice=0x2109 class=0x0c0010 dev.fwohci.0.%parent: pci13 dev.firewire.0.%desc: IEEE1394(FireWire) bus dev.firewire.0.%driver: firewire dev.firewire.0.%parent: fwohci0 dev.fwe.0.%desc: Ethernet over FireWire dev.fwe.0.%driver: fwe dev.fwe.0.%parent: firewire0 dev.fwip.0.%desc: IP over FireWire dev.fwip.0.%driver: fwip dev.fwip.0.%parent: firewire0 dev.sbp.0.%desc: SBP-2/SCSI over FireWire dev.sbp.0.%driver: sbp dev.sbp.0.%parent: firewire0 dev.dcons_crom.0.%desc: dcons configuration ROM dev.dcons_crom.0.%driver: dcons_crom dev.dcons_crom.0.%parent: firewire0 dev.isab.0.%desc: PCI-ISA bridge dev.isab.0.%driver: isab dev.isab.0.%location: slot=31 function=0 handle=\_SB_.PCI0.SBRG dev.isab.0.%pnpinfo: vendor=0x8086 device=0x2919 subvendor=0x17aa subdevice=0x20f6 class=0x060100 dev.isab.0.%parent: pci0 dev.isa.0.%desc: ISA bus dev.isa.0.%driver: isa dev.isa.0.%parent: isab0 dev.atapci.0.%desc: Intel AHCI controller dev.atapci.0.%driver: atapci dev.atapci.0.%location: slot=31 function=2 handle=\_SB_.PCI0.IDE0 dev.atapci.0.%pnpinfo: vendor=0x8086 device=0x2929 subvendor=0x17aa subdevice=0x20f8 class=0x010601 dev.atapci.0.%parent: pci0 dev.ata.2.%desc: ATA channel 0 dev.ata.2.%driver: ata dev.ata.2.%parent: atapci0 dev.ata.3.%desc: ATA channel 1 dev.ata.3.%driver: ata dev.ata.3.%parent: atapci0 dev.ata.4.%desc: ATA channel 2 dev.ata.4.%driver: ata dev.ata.4.%parent: atapci0 dev.ata.5.%desc: ATA channel 3 dev.ata.5.%driver: ata dev.ata.5.%parent: atapci0 dev.ata.6.%desc: ATA channel 4 dev.ata.6.%driver: ata dev.ata.6.%parent: atapci0 dev.ata.7.%desc: ATA channel 5 dev.ata.7.%driver: ata dev.ata.7.%parent: atapci0 dev.ata.0.%driver: ata dev.ata.0.%parent: isa0 dev.ata.1.%driver: ata dev.ata.1.%parent: isa0 dev.acpi_button.0.%desc: Sleep Button dev.acpi_button.0.%driver: acpi_button dev.acpi_button.0.%location: handle=\_SB_.SLPB dev.acpi_button.0.%pnpinfo: _HID=PNP0C0E _UID=0 dev.acpi_button.0.%parent: acpi0 dev.acpi_button.0.wake: 1 dev.acpi_lid.0.%desc: Control Method Lid Switch dev.acpi_lid.0.%driver: acpi_lid dev.acpi_lid.0.%location: handle=\_SB_.LID_ dev.acpi_lid.0.%pnpinfo: _HID=PNP0C0D _UID=0 dev.acpi_lid.0.%parent: acpi0 dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 dev.acpi_acad.0.%desc: AC Adapter dev.acpi_acad.0.%driver: acpi_acad dev.acpi_acad.0.%location: handle=\_SB_.PCI0.AC0_ dev.acpi_acad.0.%pnpinfo: _HID=ACPI0003 _UID=0 dev.acpi_acad.0.%parent: acpi0 dev.battery.0.%desc: ACPI Control Method Battery dev.battery.0.%driver: battery dev.battery.0.%location: handle=\_SB_.PCI0.BAT0 dev.battery.0.%pnpinfo: _HID=PNP0C0A _UID=0 dev.battery.0.%parent: acpi0 dev.atpic.0.%desc: AT interrupt controller dev.atpic.0.%driver: atpic dev.atpic.0.%location: handle=\_SB_.PCI0.SBRG.PIC_ dev.atpic.0.%pnpinfo: _HID=PNP0000 _UID=0 dev.atpic.0.%parent: acpi0 dev.atdma.0.%desc: AT DMA controller dev.atdma.0.%driver: atdma dev.atdma.0.%location: handle=\_SB_.PCI0.SBRG.DMAD dev.atdma.0.%pnpinfo: _HID=PNP0200 _UID=0 dev.atdma.0.%parent: acpi0 dev.attimer.0.%desc: AT timer dev.attimer.0.%driver: attimer dev.attimer.0.%location: handle=\_SB_.PCI0.SBRG.TMR_ dev.attimer.0.%pnpinfo: _HID=PNP0100 _UID=0 dev.attimer.0.%parent: acpi0 dev.attimer.1.%desc: AT realtime clock dev.attimer.1.%driver: attimer dev.attimer.1.%location: handle=\_SB_.PCI0.SBRG.RTC0 dev.attimer.1.%pnpinfo: _HID=PNP0B00 _UID=0 dev.attimer.1.%parent: acpi0 dev.atkbdc.0.%desc: Keyboard controller (i8042) dev.atkbdc.0.%driver: atkbdc dev.atkbdc.0.%location: handle=\_SB_.PCI0.SBRG.PS2K dev.atkbdc.0.%pnpinfo: _HID=PNP0303 _UID=0 dev.atkbdc.0.%parent: acpi0 dev.atkbd.0.%desc: AT Keyboard dev.atkbd.0.%driver: atkbd dev.atkbd.0.%parent: atkbdc0 dev.psmcpnp.0.%desc: PS/2 mouse port dev.psmcpnp.0.%driver: psmcpnp dev.psmcpnp.0.%location: handle=\_SB_.PCI0.SBRG.PS2M dev.psmcpnp.0.%pnpinfo: _HID=LEN0013 _UID=0 dev.psmcpnp.0.%parent: acpi0 dev.psm.0.%desc: PS/2 Mouse dev.psm.0.%driver: psm dev.psm.0.%parent: atkbdc0 dev.npxisa.0.%desc: Legacy ISA coprocessor support dev.npxisa.0.%driver: npxisa dev.npxisa.0.%location: handle=\_SB_.PCI0.SBRG.COPR dev.npxisa.0.%pnpinfo: _HID=PNP0C04 _UID=0 dev.npxisa.0.%parent: acpi0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 1200 dev.cpu.0.freq_levels: 1800/35000 1575/30625 1350/26250 1200/16000 1050/14000 900/12000 750/10000 600/8000 450/6000 300/4000 150/2000 dev.cpu.0.cx_supported: C1/0 C2/10 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU0 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/0 C2/10 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% dev.acpi_perf.0.%driver: acpi_perf dev.acpi_perf.0.%parent: cpu0 dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.%driver: est dev.est.0.%parent: cpu0 dev.est.0.freq_settings: 1800/35000 1200/16000 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 dev.cpufreq.1.%driver: cpufreq dev.cpufreq.1.%parent: cpu1 dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.%driver: p4tcc dev.p4tcc.0.%parent: cpu0 dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%driver: p4tcc dev.p4tcc.1.%parent: cpu1 dev.p4tcc.1.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.apic.0.%desc: APIC resources dev.apic.0.%driver: apic dev.apic.0.%parent: nexus0 dev.pmtimer.0.%driver: pmtimer dev.pmtimer.0.%parent: isa0 dev.orm.0.%desc: ISA Option ROM dev.orm.0.%driver: orm dev.orm.0.%pnpinfo: pnpid=ORM0000 dev.orm.0.%parent: isa0 dev.sc.0.%desc: System console dev.sc.0.%driver: sc dev.sc.0.%parent: isa0 dev.sio.0.%driver: sio dev.sio.0.%parent: isa0 dev.vga.0.%desc: Generic ISA VGA dev.vga.0.%driver: vga dev.vga.0.%parent: isa0 dev.ad.4.%desc: FUJITSU MHZ2160BH G1/0084000A dev.ad.4.%driver: ad dev.ad.4.%parent: ata2 dev.subdisk.4.%driver: subdisk dev.subdisk.4.%parent: ad4 dev.acd.0.%desc: DVD/CDRW UJDA782/VB23 dev.acd.0.%driver: acd dev.acd.0.%parent: ata3 dev.pcm.0.%desc: HDA Conexant CX20561 (Hermosa) PCM #0 Analog dev.pcm.0.%driver: pcm dev.pcm.0.%parent: hdac0 dev.pcm.0.play.vchans: 1 dev.pcm.0.play.vchanrate: 48000 dev.pcm.0.play.vchanformat: s16le dev.pcm.0.rec.vchans: 1 dev.pcm.0.rec.vchanrate: 48000 dev.pcm.0.rec.vchanformat: s16le dev.pcm.0.buffersize: 16384 dev.pcm.1.%desc: HDA Conexant CX20561 (Hermosa) PCM #1 Analog dev.pcm.1.%driver: pcm dev.pcm.1.%parent: hdac0 dev.pcm.1.play.vchans: 1 dev.pcm.1.play.vchanrate: 48000 dev.pcm.1.play.vchanformat: s16le dev.pcm.1.rec.vchans: 1 dev.pcm.1.rec.vchanrate: 48000 dev.pcm.1.rec.vchanformat: s16le dev.pcm.1.buffersize: 16384 dev.pcm.2.%desc: HDA Intel G45 HDMI PCM #0 Digital dev.pcm.2.%driver: pcm dev.pcm.2.%parent: hdac0 dev.pcm.2.play.vchans: 1 dev.pcm.2.play.vchanrate: 48000 dev.pcm.2.play.vchanformat: s16le dev.pcm.2.buffersize: 16384 hptmv.status: RocketRAID 182x SATA Controller driver Version v1.12 -------------- next part -------------- X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE i386 Current Operating System: FreeBSD lix.xil 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #1: Tue Apr 7 12:39:46 CST 2009 root@lvm.net:/usr/obj/usr/src/sys/kernel i386 Build Date: 07 April 2009 02:59:32PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Apr 8 19:45:02 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "StandbyTime" "10" (**) Option "SuspendTime" "10" (**) Option "OffTime" "10" (==) Automatically adding devices (==) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to "/usr/local/lib/xorg/modules" (**) Extension "Composite" is enabled (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 (II) Loader magic: 0x6a0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0@0:2:0) Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7, Mem @ 0x80000000/4194304, 0xd0000000/268435456, I/O @ 0x00005c00/8, BIOS @ 0x????????/65536 (--) PCI: (0@0:2:1) Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded by default. (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "xtrap" (WW) Warning, couldn't open module xtrap (II) UnloadModule: "xtrap" (EE) Failed to load module "xtrap" (module does not exist, 0) (II) LoadModule: "freetype" (WW) Warning, couldn't open module freetype (II) UnloadModule: "freetype" (EE) Failed to load module "freetype" (module does not exist, 0) (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "intel" (II) Loading /usr/local/lib/xorg/modules/drivers//intel_drv.so (II) Module intel: vendor="X.Org Foundation" compiled for 1.6.0, module version = 2.6.3 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) intel: Driver for Intel Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, Mobile Intel? GM45 Express Chipset, Intel Integrated Graphics Device, G45/G43, Q45/Q43, G41 (II) Primary Device is: PCI 00@00:02:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.6.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 5.0 (**) intel(0): Depth 24, (--) framebuffer bpp 32 (==) intel(0): RGB weight 888 (==) intel(0): Default visual is TrueColor (II) intel(0): Integrated Graphics Chipset: Intel(R) Mobile Intel? GM45 Express Chipset (--) intel(0): Chipset: "Mobile Intel? GM45 Express Chipset" (--) intel(0): Linear framebuffer at 0xD0000000 (--) intel(0): IO registers at addr 0x80000000 (==) intel(0): Using EXA for acceleration (II) intel(0): 2 display pipes available. (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) intel(0): Output VGA using monitor section Monitor1 (**) intel(0): Option "RightOf" "LVDS" (II) intel(0): Output LVDS using monitor section Monitor0 (**) intel(0): Option "Position" "0 0" (II) intel(0): I2C bus "LVDSDDC_C" initialized. (II) intel(0): Attempting to determine panel fixed mode. (II) intel(0): I2C device "LVDSDDC_C:E-EDID segment register" registered at address 0x60. (II) intel(0): I2C device "LVDSDDC_C:ddc2" registered at address 0xA0. (II) intel(0): EDID vendor "LEN", prod id 16433 (II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" initialized. (II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" registered at address 0x70. (II) intel(0): No SDVO device found on SDVOB (II) intel(0): I2C device "SDVOCTRL_E for SDVOB:SDVO Controller B" removed. (II) intel(0): I2C bus "SDVOCTRL_E for SDVOB" removed. (II) intel(0): Output HDMI-1 has no monitor section (II) intel(0): I2C bus "HDMIDDC_B" initialized. (II) intel(0): HDMI output 1 detected (II) intel(0): Output TV has no monitor section (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) intel(0): Resizable framebuffer: not available (1 3) (II) intel(0): EDID vendor "LEN", prod id 16433 (II) intel(0): Output VGA disconnected (II) intel(0): Output LVDS connected (II) intel(0): Output HDMI-1 disconnected (II) intel(0): Output TV disconnected (II) intel(0): Using user preference for initial modes (II) intel(0): Output LVDS using initial mode 1280x800 (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) intel(0): detected 512 kB GTT. (II) intel(0): detected 32764 kB stolen memory. (==) intel(0): video overlay key set to 0x101fe (==) intel(0): Will not try to enable page flipping (==) intel(0): Triple buffering disabled (==) intel(0): Using gamma correction (1.0, 1.0, 1.0) (==) intel(0): DPI set to (96, 96) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/local/lib/xorg/modules//libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.6.0, module version = 2.4.0 ABI class: X.Org Video Driver, version 5.0 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (II) intel(0): Comparing regs from server start up to After PreInit (WW) intel(0): Register 0x61200 (PP_STATUS) changed from 0xc0000008 to 0xd000000a (WW) intel(0): PP_STATUS before: on, ready, sequencing idle (WW) intel(0): PP_STATUS after: on, ready, sequencing on (WW) intel(0): Register 0x70024 (PIPEASTAT) changed from 0x00000000 to 0x00000206 (WW) intel(0): PIPEASTAT before: status: (WW) intel(0): PIPEASTAT after: status: VSYNC_INT_STATUS SVBLANK_INT_STATUS VBLANK_INT_STATUS (WW) intel(0): Register 0x68084 (TV_FILTER_CTL_2) changed from 0x00012d2d to 0x00028283 (WW) intel(0): Register 0x68088 (TV_FILTER_CTL_3) changed from 0x00009696 to 0x00014141 (WW) intel(0): Register 0x321b (FBC_FENCE_OFF) changed from 0x96025800 to 0xec00c000 (==) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprD) [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprD) [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprD) [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) intel(0): Kernel reported 241152 total, 0 used (II) intel(0): I830CheckAvailableMemory: 964608 kB available (WW) intel(0): DRI2 requires UXA drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: Searching for BusID pci:0000:00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 9, (OK) drmOpenByBusid: drmOpenMinor returns 9 drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) intel(0): [drm] Using the DRM lock SAREA also for drawables. (II) intel(0): [drm] framebuffer mapped by ddx driver (II) intel(0): [drm] added 1 reserved context for kernel (II) intel(0): X context handle = 0x1 (II) intel(0): [drm] installed DRM signal handler (**) intel(0): Framebuffer compression enabled (**) intel(0): Tiling enabled (==) intel(0): VideoRam: 262144 KB (II) intel(0): Attempting memory allocation with tiled buffers. (II) intel(0): Tiled allocation successful. (II) intel(0): [drm] Registers = 0x80000000 (II) intel(0): [drm] ring buffer = 0xd0000000 (II) intel(0): [drm] mapped front buffer at 0xd02fe000, handle = 0xd02fe000 (II) intel(0): [drm] mapped back buffer at 0xd4978000, handle = 0xd4978000 (II) intel(0): [drm] mapped depth buffer at 0xd5738000, handle = 0xd5738000 (II) intel(0): [drm] mapped classic textures at 0xd64f8000, handle = 0xd64f8000 (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432 (II) intel(0): [dri] visual configs initialized (II) intel(0): Page Flipping disabled (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) intel(0): Write-combining range (0xa0000,0x10000) was already clear (II) EXA(0): Offscreen pixmap area of 43253760 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (==) intel(0): Backing store disabled (==) intel(0): Silken mouse enabled (II) intel(0): Initializing HW Cursor (II) intel(0): [DRI] installation complete (II) intel(0): xf86BindGARTMemory: bind key 8 at 0x01fff000 (pgoffset 8191) (II) intel(0): xf86BindGARTMemory: bind key 9 at 0x02036000 (pgoffset 8246) (II) intel(0): xf86BindGARTMemory: bind key 10 at 0x04976000 (pgoffset 18806) (II) intel(0): xf86BindGARTMemory: bind key 11 at 0x04977000 (pgoffset 18807) (II) intel(0): xf86BindGARTMemory: bind key 12 at 0x04978000 (pgoffset 18808) (II) intel(0): xf86BindGARTMemory: bind key 13 at 0x05738000 (pgoffset 22328) (II) intel(0): xf86BindGARTMemory: bind key 14 at 0x064f8000 (pgoffset 25848) (II) intel(0): Fixed memory allocation layout: (II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB) (II) intel(0): 0x00020000-0x001f3fff: compressed frame buffer (1872 kB, 0x000000003e020000 physical ) (II) intel(0): 0x001f4000-0x001fdfff: HW cursors (40 kB) (II) intel(0): 0x001fe000-0x002fdfff: fake bufmgr (1024 kB) (II) intel(0): 0x002fe000-0x02035fff: front buffer (29920 kB) (II) intel(0): 0x01fff000: end of stolen memory (II) intel(0): 0x02036000-0x04975fff: exa offscreen (42240 kB) (II) intel(0): 0x04976000-0x04976fff: power context (4 kB) (II) intel(0): 0x04977000-0x04977fff: HW status (4 kB) (II) intel(0): 0x04978000-0x05737fff: back buffer (14080 kB) (II) intel(0): 0x05738000-0x064f7fff: depth buffer (14080 kB) (II) intel(0): 0x064f8000-0x084f7fff: classic textures (32768 kB) (II) intel(0): 0x10000000: end of aperture (WW) intel(0): ESR is 0x00000010, page table error (WW) intel(0): PGTBL_ER is 0x00100000, CS instruction GTT PTE (WW) intel(0): Existing errors found in hardware state. (II) intel(0): using SSC reference clock of 100 MHz (II) intel(0): Selecting standard 18 bit TMDS pixel format. (II) intel(0): Output configuration: (II) intel(0): Pipe A is off (II) intel(0): Display plane A is now disabled and connected to pipe A. (II) intel(0): Pipe B is on (II) intel(0): Display plane B is now enabled and connected to pipe B. (II) intel(0): Output VGA is connected to pipe none (II) intel(0): Output LVDS is connected to pipe B (II) intel(0): Output HDMI-1 is connected to pipe none (II) intel(0): Output TV is connected to pipe none (II) intel(0): [drm] dma control initialized, using IRQ 16 (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. (**) Option "dpms" (**) intel(0): DPMS enabled (==) intel(0): Intel XvMC decoder disabled (II) intel(0): Set up textured video (II) intel(0): direct rendering: XF86DRI Enabled (WW) intel(0): Option "PreferedMode" is not used (WW) intel(0): Option "Position" is not used (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) intel(0): Setting screen physical size to 303 x 190 (II) config/hal: Adding input device PS/2 Mouse (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (**) PS/2 Mouse: Device: "/dev/psm0" (==) PS/2 Mouse: Protocol: "Auto" (**) PS/2 Mouse: always reports core events (**) Option "Device" "/dev/psm0" (==) PS/2 Mouse: Emulate3Buttons, Emulate3Timeout: 50 (**) PS/2 Mouse: ZAxisMapping: buttons 4 and 5 (**) PS/2 Mouse: Buttons: 9 (**) PS/2 Mouse: Sensitivity: 1 (II) XINPUT: Adding extended input device "PS/2 Mouse" (type: MOUSE) (**) PS/2 Mouse: (accel) keeping acceleration scheme 1 (**) PS/2 Mouse: (accel) filter chain progression: 2.00 (**) PS/2 Mouse: (accel) filter stage 0: 20.00 ms (**) PS/2 Mouse: (accel) set acceleration profile 0 (II) PS/2 Mouse: SetupAuto: hw.iftype is 3, hw.model is 0 (II) PS/2 Mouse: SetupAuto: protocol is PS/2 (II) PS/2 Mouse: ps2EnableDataReporting: succeeded (II) config/hal: Adding input device AT Keyboard (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (**) AT Keyboard: always reports core events (**) Option "Protocol" "standard" (**) AT Keyboard: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) AT Keyboard: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) AT Keyboard: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) AT Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) AT Keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) exaCopyDirty: Pending damage region empty! From gavin at FreeBSD.org Thu Apr 9 06:39:18 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Apr 9 06:39:29 2009 Subject: system report 7.2 beta1 In-Reply-To: <49DD95EB.9040606@gmail.com> References: <49DD95EB.9040606@gmail.com> Message-ID: <1239284354.29188.37.camel@buffy.york.ac.uk> On Thu, 2009-04-09 at 14:30 +0800, GOD wrote: > I trace all of 7.* version on my laptop. But some thing is always a > problem! > 1. The acpi is not well supported. I try acpiconf -s 3 , the system > will > die. I take it you are running i386 then? Can you try compiling SMP support out of your kernel, disabling the second core in the BIOS, and seeing if you have the same problem? If suspend starts to work then the problem is that i386 suspend isn't properly implemented for SMP. Recently, amd64 gained suspend/resume and works on SMP. Although this support hasn't been merged back to 7.x, it might be worthwhile booting the 8.0 amd64 live CD and seeing if that works for you - if it does, there's probably more chance the amd64 support will appear in 7.x before the i386 suspend support, so maybe you could consider moving to amd64. > 2 The ath0 wifi support, I test and nerver find it can transfer with > more than 5MB per second rate. > 3 The big problem of my laptop is the intel video card, xorg eat up half > of my memory,and it's very slow moving windows . I'm afraid I can't help with these, other than to say that wireless support in 8.x is much better than in 7.x. Indeed, given how close 8.0 is to being released (a few months away, I believe), it may be best either to wait, or to consider upgrading your system to -CURRENT amd64 and seeing if your problems are already resolved. Gavin From danny at cs.huji.ac.il Thu Apr 9 07:32:09 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Thu Apr 9 07:32:17 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: > Danny Braniss wrote: > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > >> --------------enig90DADA8437A99D893FB775F8 > >> Content-Type: text/plain; charset=3DUTF-8 > >> Content-Transfer-Encoding: quoted-printable > >> > >> Danny Braniss wrote: > >>>> Garance A Drosihn wrote: > >>>>> Some friends of mine are looking at the new "DroboPro", which makes= > a=3D > >>>>> lot of disk space available via iSCSI (in addition to firewire 800)= > , > >>>>> and they were wondering how well iSCSI works with FreeBSD. I haven= > 't=3D > >>>>> paid attention to iSCSI support. Is there anyone using it heavily > >>>>> for disk-storage under FreeBSD? Has there been much changed for > >>>>> iSCSI support in the 8.x branch, or is 7.x support working fine? > >>>> I suppose you are interested in the "client" (initiator) side of iSC= > SI=3D > >>>> support. It hasn't changed much between 7.x and 8.x but there are > >>>> apparently some announcements of a newer version: > >>>> > >>>> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.ht= > ml=3D > >>>> I can't find any more information on it. > >>> the latest is in: > >>> http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > >> Thanks! > >> > >> Is there anything in particular you'd like to get tested in the new > >> version, any significant changes or improvements? > > mainly fixed some bugs, and some code cleanup. > >=20 > > give it a spin, and let me know what target you are testing. > > btw, the default tag opening is a bit concervative (1), you might want = > to > > change it to somewhat larger, say 64 or 128. > > Hi, > > "camcontrol tags" hangs: > > Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0 > Apr 9 15:36:36 terminator kernel: da3: Fixed > Direct Access SCSI-5 device > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing device en= > try > terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da* > /dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c > /dev/da1 /dev/da3 > terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3 > > > The configuration is: > > target0 { > targetaddress =3D 161.53.72.65 > targetname =3D iqn.2007-09.jp.ne.peach:disk1 > tags =3D 16 > } > Q: what kernel? Q: what target? btw, without the camcontrol tags, is it working? danny From ivoras at freebsd.org Thu Apr 9 08:01:35 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 9 08:01:42 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <9bbcef730904090801n31a0bf27of01c2d82ba1e93c8@mail.gmail.com> 2009/4/9 Danny Braniss : >> The configuration is: >> >> target0 { >> ? ? ? ? targetaddress =3D 161.53.72.65 >> ? ? ? ? targetname =3D iqn.2007-09.jp.ne.peach:disk1 >> ? ? ? ? tags =3D 16 >> } >> > > Q: what kernel? > Q: what target? 7-STABLE AMD64. > btw, without the camcontrol tags, is it working? It appears it can be made to hang under some circumstances, possibly if there is a spelling error in the configuration file. After a reboot, both regular usage and "camcontrol tags" work. From lists at jnielsen.net Thu Apr 9 08:07:59 2009 From: lists at jnielsen.net (John Nielsen) Date: Thu Apr 9 08:08:07 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <200904091043.25425.lists@jnielsen.net> On Thursday 09 April 2009 10:32:05 am Danny Braniss wrote: > > Danny Braniss wrote: > > >> This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > > >> --------------enig90DADA8437A99D893FB775F8 > > >> Content-Type: text/plain; charset=3DUTF-8 > > >> Content-Transfer-Encoding: quoted-printable > > >> > > >> Danny Braniss wrote: > > >>>> Garance A Drosihn wrote: > > >>>>> Some friends of mine are looking at the new "DroboPro", which > > >>>>> makes= > > > > a=3D > > > > >>>>> lot of disk space available via iSCSI (in addition to firewire > > >>>>> 800)= > > > > , > > > > >>>>> and they were wondering how well iSCSI works with FreeBSD. I > > >>>>> haven= > > > > 't=3D > > > > >>>>> paid attention to iSCSI support. Is there anyone using it > > >>>>> heavily for disk-storage under FreeBSD? Has there been much > > >>>>> changed for iSCSI support in the 8.x branch, or is 7.x support > > >>>>> working fine? > > >>>> > > >>>> I suppose you are interested in the "client" (initiator) side of > > >>>> iSC= > > > > SI=3D > > > > >>>> support. It hasn't changed much between 7.x and 8.x but there > > >>>> are apparently some announcements of a newer version: > > >>>> > > >>>> http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/00383 > > >>>>4.ht= > > > > ml=3D > > > > >>>> I can't find any more information on it. > > >>> > > >>> the latest is in: > > >>> http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > > >> > > >> Thanks! > > >> > > >> Is there anything in particular you'd like to get tested in the > > >> new version, any significant changes or improvements? > > > > > > mainly fixed some bugs, and some code cleanup. > > >=20 > > > give it a spin, and let me know what target you are testing. > > > btw, the default tag opening is a bit concervative (1), you might > > > want = > > > > to > > > > > change it to somewhat larger, say 64 or 128. > > > > Hi, > > > > "camcontrol tags" hangs: > > > > Apr 9 15:36:36 terminator kernel: da3 at iscsi0 bus 0 target 1 lun 0 > > Apr 9 15:36:36 terminator kernel: da3: > > Fixed Direct Access SCSI-5 device > > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): lost device > > Apr 9 15:36:38 terminator kernel: (da2:iscsi0:0:0:0): removing > > device en= try > > terminator:~ivoras/temp/sbin/iscontrol# ls /dev/da* > > /dev/da0 /dev/da0s1 /dev/da0s1a /dev/da0s1b /dev/da0s1c > > /dev/da1 /dev/da3 > > terminator:~ivoras/temp/sbin/iscontrol# camcontrol tags da3 > > > > > > The configuration is: > > > > target0 { > > targetaddress =3D 161.53.72.65 > > targetname =3D iqn.2007-09.jp.ne.peach:disk1 > > tags =3D 16 > > } > > Q: what kernel? From his previous message it looks like 7-STABLE amd64 > Q: what target? From the targetname it looks like the recently committed net/istgt running on another FreeBSD machine. > btw, without the camcontrol tags, is it working? That one I can't infer. :) JN From zkolic at sbb.co.yu Thu Apr 9 08:25:15 2009 From: zkolic at sbb.co.yu (Zoran Kolic) Date: Thu Apr 9 08:25:23 2009 Subject: atapicam question Message-ID: <20090409152509.GA972@faust.net> Howdy! Amd64, 7.1. Few days ago I replaced dieing dvd writer with brand new pioneer 116d. In the kernel I removed all not needed stuff and included atapicam and both cd and acd. Previously I used cd only with no hiss. Making dvd I first encountered error at the very beginning of the whole process: acd: Failure - Inquiry illegal request. Using growisofs I got another errors, but nothing that made dvd unusable: "failure - read_toc illegal request" and "failure - unknown cmd". Dvd that contained files with typos, with "(", ")" and "`" gave me some "looking for lun" message du- ring the write. Not shown in /var/log/messages anyway. Since I included atapicam into the kernel and it booted fine, it works with both device drivers. I found some posts that hal could be set not to probe writer, but it is not good, for acd to read dvd. Any opinion on this topic? Maybe some growisofs bug I'm not aware of. I have an impression dvd device is not broken, aside it is new one. Firmware version is 1.06, with 1.09 as the lattest on pioneer site. Another topic could be "how to reflash" dvd writer from freebsd?". Best reagards Zoran From sclark46 at earthlink.net Thu Apr 9 09:33:13 2009 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Apr 9 09:33:21 2009 Subject: 6.x acpi powerbutton Message-ID: <49DE1F8B.2080400@earthlink.net> Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? Thanks, Steve From ivoras at freebsd.org Thu Apr 9 10:14:06 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 9 10:14:15 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: <200904091043.25425.lists@jnielsen.net> References: <200904091043.25425.lists@jnielsen.net> Message-ID: <9bbcef730904091013q4c0aebd0o27f66376efdfb9a6@mail.gmail.com> 2009/4/9 John Nielsen : >> Q: what kernel? > > From his previous message it looks like 7-STABLE amd64 > >> Q: what target? > > From the targetname it looks like the recently committed net/istgt running > on another FreeBSD machine. Correct on both :) From avg at icyb.net.ua Thu Apr 9 10:20:51 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 9 10:20:59 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49DE1F8B.2080400@earthlink.net> References: <49DE1F8B.2080400@earthlink.net> Message-ID: <49DE2E6D.5050001@icyb.net.ua> on 09/04/2009 19:17 Stephen Clark said the following: > Hello, > > I am trying to figure out what happens on a soft poweroff? Is there a > userspace script that gets called? If everything works correctly, then acpi driver sends a signal to init which causes a typical graceful shutdown. BTW, was this really a question for stable ml? -- Andriy Gapon From sclark46 at earthlink.net Thu Apr 9 13:24:17 2009 From: sclark46 at earthlink.net (Stephen Clark) Date: Thu Apr 9 13:24:25 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49DE2E6D.5050001@icyb.net.ua> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> Message-ID: <49DE596E.2050406@earthlink.net> Andriy Gapon wrote: on 09/04/2009 19:17 Stephen Clark said the following: Hello, I am trying to figure out what happens on a soft poweroff? Is there a userspace script that gets called? If everything works correctly, then acpi driver sends a signal to init which causes a typical graceful shutdown. BTW, was this really a question for stable ml? Probably not. But I spent a couple of hours googling without much luck so I got desperate. ;-) Is there a reason it doesn't send and event like Linux that can be acted upon by user space other than signaling init? I like to have a message written in /var/log/messages that someone pressed the powerbutton. Thanks -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From lopez.on.the.lists at yellowspace.net Thu Apr 9 13:45:13 2009 From: lopez.on.the.lists at yellowspace.net (Lorenzo Perone) Date: Thu Apr 9 13:45:21 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: References: Message-ID: <4457FAEE-A54F-4C4A-B625-5EB3A51BD47A@yellowspace.net> Hi, in one production case (1), haven't seen panics or deadlocks for a long time, yet on another much more powerful machine (2), I could not get rid of "vm_thread_new: kstack allocation failed", ultimately rendering the machine useless pretty fast. This was at least till RELENG_7/november (7.1-PRERELEASE), where I decided to stop the zfs experiment for now and went back to ufs. trying to understand now if 7.2 is worth a new try, or if, for that matter, the only reasonable wait is until 8.0. perhaps worth of note, the kstack errors still occurred (albeit after more time) with all zpools exported (and system rebooted) but the zfs.ko still loaded. only after rebooting without zfs_load="YES" the server began to work seemlessly for months. I'm asking myself if/how important the underlying driver/provider (mfi, mpt, ad, ciss, etc..) can be in regard to the remaining/ recurring problems with zfs.. (since I've seen so different behaviors with different machines...)? (1) Homebrewn Opteron / 2GB RAM / SATA ad / 7.1-PRERELEASE w. usual tuning, one zpool on a SATA mirror for backups via rsync of several servers (2) DELL PE 1950 1 Quad-Xeon / 8GB RAM / LSI mpt / 7.1-PRERELEASE w. many tunings tried, one zpool on a partition on top of HW RAID 1, moderately loaded mailserver box running courier and mysql Regards, Lorenzo From josemi at freebsd.jazztel.es Thu Apr 9 15:09:34 2009 From: josemi at freebsd.jazztel.es (Jose M Rodriguez) Date: Thu Apr 9 15:09:41 2009 Subject: libc ABI changes in RELENG_7 Message-ID: <200904092120.n39LKRgl008326@orion.redesjm.local> Hi Building a samba package in a recent RELENG_7 box and install on a 7.1-RELEASE system I found ABI changes that make ldconfig fail. This is related to a new strndup symbol in libc that samba build autodetect and use. This is really necesary? -- josemi From delphij at delphij.net Thu Apr 9 15:43:32 2009 From: delphij at delphij.net (Xin LI) Date: Thu Apr 9 15:43:40 2009 Subject: libc ABI changes in RELENG_7 In-Reply-To: <200904092120.n39LKRgl008326@orion.redesjm.local> References: <200904092120.n39LKRgl008326@orion.redesjm.local> Message-ID: <49DE7A03.70409@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jose, Jose M Rodriguez wrote: > Hi > Building a samba package in a recent RELENG_7 box and install on a > 7.1-RELEASE system I found ABI changes that make ldconfig fail. > > This is related to a new strndup symbol in libc that samba build autodetect > and use. This is really necesary? The only way to guarantee a package is usable under 7.1-RELEASE is to build it under a 7.1-RELEASE chroot or jail, when building it on a newer host system. That's said, we strive our best to maintain backward compatibility, i.e. make sure that newer FreeBSD versions would always run older binaries; we do want to keep some sort of upward compatibility, for instance, when you build a binary on newer FreeBSD version, it's *likely* that it can be run on older FreeBSD version, but this is not strictly guaranteed or we can not add any new functionalities into new FreeBSD versions. I personally feel very strongly against of not having a POSIX-defined libc function just because older 7.x does not have it, unless we want the whole 7.x branch to be EoL'ed soon. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkneeYgACgkQi+vbBBjt66CUlwCeJINd92n72WiiV1fBkwR6Oisp KCkAoMDxWdNd3r1654Vddf+ZFmOILrH0 =wJnZ -----END PGP SIGNATURE----- From fjwcash at gmail.com Thu Apr 9 16:10:14 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Apr 9 16:10:21 2009 Subject: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?] In-Reply-To: <49DD2B44.5020808@mawer.org> References: <200904080959.49201.fjwcash@gmail.com> <49DD2B44.5020808@mawer.org> Message-ID: On Wed, Apr 8, 2009 at 3:55 PM, Antony Mawer wrote: > Freddie Cash wrote: > ... >> We've also heavily modified /etc/sysctl.conf and upped a bunch of the >> network-related sysctls. ?Doing so increased our SSH throughput from ~30 >> Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. > > Are you able to share any of these with the list? It would be useful to > compare as a lot of these tunings people do individually and it would be > good to allow others to test in their environments to see if they help, as > well as potentially adding them to the tuning man-page. They're all taken from the HPN-SSH website and various google searches related to HPN-enabled OpenSSH. I don't know exactly what all the different, individual sysctls do, nor whether this is the most optimal setup, but here's the sysctl.conf that we use. This is on 2 systems using a quad-port gigabit NIC where the top two ports are connected via lagg(4) and the bottom two ports are connected via lagg(4), with the two laggX interfaces on separate networks. I did a bunch of scp/sftp transfers of 100 MB files filled with random data pulled from /dev/random between these two boxes tweaking the options one at a time, but didn't do too much in the way of scientific/empirical measurements and comparisons beyond the throughput data that scp/sftp shows. If there are any glaring errors, gotchas, or "why would you ever do that"s, let me know. :) # General network settings net.isr.direct=1 # Whether to enable Direct Dispatch for netisr # IP options net.inet.ip.forwarding=0 # Whether to enable packet forwarding for NAT/routing net.inet.ip.process_options=0 # Disable processing of IP options (nothing uses this field) net.inet.ip.random_id=1 # Randomise the IP header ID number net.inet.ip.redirect=0 # Whether to allow redirect packets #net.inet.ip.stealth=0 # Whether to appear in traceroute output # ICMP options net.inet.icmp.icmplim=200 # Limit ICMP packets to this many per second net.inet.icmp.drop_redirect=1 # Drop ICMP redirect packets net.inet.icmp.log_redirect=0 # Don't log ICMP redirect packets # TCP options net.inet.tcp.blackhole=1 # Drop packets destined to unused ports net.inet.tcp.inflight.enable=0 # Use automatic TCP window-scaling net.inet.tcp.log_in_vain=0 # Don't log the blackholed packets net.inet.tcp.path_mtu_discovery=1 # Use ICMP type 3 to find the MTU to use net.inet.tcp.recvbuf_max=16777216 # The max size of the receive buffer (16 MB) net.inet.tcp.recvspace=131072 # The initial size in bytes of the receive buffer net.inet.tcp.sack.enable=1 # Enable Selective ACKs net.inet.tcp.sendbuf_max=16777216 # The max size of the send buffer net.inet.tcp.sendspace=131072 # The initial size in bytes of the send buffer net.inet.tcp.syncookies=1 # Enable SYN cookie protection net.inet.tcp.rfc1323=1 # Enable RFC1323 extensions (TCP window scaling) # UDP options net.inet.udp.blackhole=1 # Drop packets destined to unused ports net.inet.udp.checksum=1 # Enable UDP checksums net.inet.udp.log_in_vain=0 # Don't log the blackholed packets net.inet.udp.recvspace=65536 # Size in bytes of the receive buffer # Debug options debug.minidump=1 # Disable the small kernel core dump (only mem in use) debug.mpsafevfs=1 # Enable threaded VFS subsystem # Kernel options kern.coredump=0 # Disable kernel core dumps kern.ipc.maxsockbuf=4194304 # Set the max size of the socket buffers (4 MB) kern.ipc.somaxconn=1024 # Expand the IP listen queue kern.maxvnodes=250000 # Bump up the max number of vnodes # PCI bus options hw.pci.enable_msix=1 # Enable Message Signalled Interrupts - Extended hw.pci.enable_msi=1 # Enable Message Signalled Interrupts hw.pci.enable_io_modes=1 # Enable alternate I/O access modes -- Freddie Cash fjwcash@gmail.com From matheus at eternamente.info Thu Apr 9 16:15:11 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Thu Apr 9 16:15:18 2009 Subject: anyone using seagate microdrives and freebsd ? Message-ID: <94b70a65b8e00354631e491f8bf0cc25.squirrel@10.1.1.10> I have on and no luck in working this config out. If anyone could give any hint. I've seen this pr http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/110407 and some other cases from some searching, but no one ever said anything about success case. thanks, matheus -- We will call you cygnus, The God of balance you shall be From pyunyh at gmail.com Thu Apr 9 17:14:22 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Apr 9 17:14:29 2009 Subject: fxp: stalled transfers In-Reply-To: References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> Message-ID: <20090410001536.GH37714@michelle.cdnetworks.co.kr> On Thu, Apr 09, 2009 at 11:02:06AM +0200, Bjoern Koenig wrote: > pyunyh@gmail.com wrote: > > > If you can easily reproduce the issue, can you capture stalled TCP > > session with tcpdump on receiving host?(Make sure to disable Rx > > checksum offload prior to capturing the session.) > > I transferred a 256 kiB file and these are the tcpdumps: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > Actually the transfer doesn't stall although ftp and scp told me so. It > becomes incredibly slow. It seems like that the chunks are too large and a > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > it works fine with TSO enabled. > > I also captured the traffic on my router: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > I almost suppose that this is a PPPoE-related configuration issue and the > fxp driver is not necessarily the problem since decreasing the MTU of the > LAN host solves it. > I think you're right. Thanks a lot! From a.j.werven at student.utwente.nl Thu Apr 9 17:45:12 2009 From: a.j.werven at student.utwente.nl (A.J. "Fonz" van Werven) Date: Thu Apr 9 17:45:19 2009 Subject: anyone using seagate microdrives and freebsd ? In-Reply-To: <94b70a65b8e00354631e491f8bf0cc25.squirrel@10.1.1.10> Message-ID: <200904100032.n3A0WfnL011942@satellite.xs4all.nl> Nenhum_de_Nos wrote: > I have on and no luck in working this config out. I remember microdrives... those are from long ago, when the C64s and ZX Spectrums ruled the world ;-) Alphons (sorry, couldn't resist) -- All right, that does it Bill [Donahue]. I'm pretty sure that killing Jesus is not very Christian. -- Pope Benedict XVI, Southpark season 11 episode 5 From pyunyh at gmail.com Thu Apr 9 21:42:21 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Apr 9 21:42:29 2009 Subject: watchdog timeout In-Reply-To: References: <20090407120032.633E410656D5@hub.freebsd.org> Message-ID: <20090410044340.GJ37714@michelle.cdnetworks.co.kr> On Wed, Apr 08, 2009 at 10:41:44AM +0200, xer wrote: > Hello > I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to > 6.4-STABLE. > > This machine has two 3com nics (one is LAN other is WAN) and i see too much > "watchdog timeout" on both cards. > This on/off up/down on cards, affect the interrupt to clients that are > downloading from apache web server, especially on large files. > > -------------------------------------------- > xer:/root# dmesg > xl1: watchdog timeout > xl1: link state changed to DOWN > xl1: link state changed to UP > xl1: watchdog timeout > xl1: link state changed to DOWN > xl1: link state changed to UP > xl1: watchdog timeout > xl1: link state changed to DOWN > xl1: link state changed to UP > --------------------------------------------- > > xer:/root# cat /var/run/dmesg.boot | grep xl > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem > 0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2 > miibus0: on xl0 > xlphy0: <3c905C 10/100 internal PHY> on miibus0 > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl0: Ethernet address: 00:01:02:e0:04:1b > xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xe880-0xe8ff mem > 0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2 > miibus1: on xl1 > xlphy1: <3c905C 10/100 internal PHY> on miibus1 > xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > xl1: Ethernet address: 00:01:02:df:fe:ed > --------------------------------------------- > Another doubt would be my kernel config, maybe there is something wrong > that i cannot see, i'll post at the end of this post, 'cause is too long. > > As you can see, the cards are 3c905C-TX model. > Someone told me to change drivers, but i cannot understand this advice. > I got same errors with same cards but with another mainboard, same problem, > watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. > > I don't think that to change nic's pci slots, will solve the problem, i > think that maybe change the nics would resolve the matter, but i cannot > access to both FreeBSD phisically, cause the boxes are too far from me > (about 3500 km). > > I'm asking you some advices, and i can i fix this problem. > p.s. with both 5.4 or 5.5 old kernel, the nics was fine. > I vaguely remember there were a couple of reports on xl(4) watchdog timeouts. I'm not sure this came from missing Tx interrupts but would you try attached patch? Note, it was generated against HEAD and you should experiment the attached patch on local box prior to applying to your production server. -------------- next part -------------- A non-text attachment was scrubbed... Name: xl.watchdog.patch Type: text/x-diff Size: 1882 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090410/4ce016dd/xl.watchdog.bin From bkoenig at alpha-tierchen.de Thu Apr 9 23:46:11 2009 From: bkoenig at alpha-tierchen.de (Bjoern Koenig) Date: Thu Apr 9 23:46:18 2009 Subject: fxp: stalled transfers In-Reply-To: References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> Message-ID: <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> I wrote: > >> If you can easily reproduce the issue, can you capture stalled TCP >> session with tcpdump on receiving host?(Make sure to disable Rx >> checksum offload prior to capturing the session.) > > I transferred a 256 kiB file and these are the tcpdumps: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > Actually the transfer doesn't stall although ftp and scp told me so. It > becomes incredibly slow. It seems like that the chunks are too large and a > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > it works fine with TSO enabled. > > I also captured the traffic on my router: > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > I almost suppose that this is a PPPoE-related configuration issue and the > fxp driver is not necessarily the problem since decreasing the MTU of the > LAN host solves it. Hello, it's me again. :) It's not PPPoE-related. I was able to reproduce the behaviour within a regular LAN from host to host. I also have another symptom which denies the PPPoE assumption: If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll get the message "N bytes missing!" in the tcpdump output. For example: ifconfig fxp0 mtu 1448 # works ifconfig fxp0 mtu 1412 # still works ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) ifconfig fxp0 mtu 1400 # works ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) Regards Bj?rn From xernet at hotmail.it Fri Apr 10 00:01:11 2009 From: xernet at hotmail.it (xer) Date: Fri Apr 10 00:01:18 2009 Subject: watchdog timeout In-Reply-To: <20090410044340.GJ37714@michelle.cdnetworks.co.kr> References: <20090407120032.633E410656D5@hub.freebsd.org> <20090410044340.GJ37714@michelle.cdnetworks.co.kr> Message-ID: Thank you Pyun I found this another one: http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 And it seems a lot different.. which one will bet to try? Regards -------------------------------------------------- From: "Pyun YongHyeon" Sent: Friday, April 10, 2009 6:43 AM To: "xer" Cc: Subject: Re: watchdog timeout > > I vaguely remember there were a couple of reports on xl(4) watchdog > timeouts. I'm not sure this came from missing Tx interrupts but > would you try attached patch? > Note, it was generated against HEAD and you should experiment the > attached patch on local box prior to applying to your production > server. > From pyunyh at gmail.com Fri Apr 10 00:31:38 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Apr 10 00:31:44 2009 Subject: watchdog timeout In-Reply-To: References: <20090407120032.633E410656D5@hub.freebsd.org> <20090410044340.GJ37714@michelle.cdnetworks.co.kr> Message-ID: <20090410073259.GK37714@michelle.cdnetworks.co.kr> On Fri, Apr 10, 2009 at 09:01:15AM +0200, xer wrote: > Thank you Pyun > I found this another one: > http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 > > And it seems a lot different.. which one will bet to try? I think the patch in the PR is not right fix. Drivers should not rearm watchdog timeouts in Tx completion handler, otherwise it would hide root cause of timeouts. if_start handler should be the only place to arm the timer. Try attached patch in previous mail. > Regards > > -------------------------------------------------- > From: "Pyun YongHyeon" > Sent: Friday, April 10, 2009 6:43 AM > To: "xer" > Cc: > Subject: Re: watchdog timeout > > > > >I vaguely remember there were a couple of reports on xl(4) watchdog > >timeouts. I'm not sure this came from missing Tx interrupts but > >would you try attached patch? > >Note, it was generated against HEAD and you should experiment the > >attached patch on local box prior to applying to your production > >server. > > From avg at icyb.net.ua Fri Apr 10 01:12:11 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Apr 10 01:12:22 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49DE596E.2050406@earthlink.net> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> Message-ID: <49DEFF53.1040306@icyb.net.ua> on 09/04/2009 23:24 Stephen Clark said the following: > Probably not. But I spent a couple of hours googling without much luck > so I got desperate. ;-) Let me introduce freebsd-acpi@freebsd.org > Is there a reason it doesn't send and event like Linux that can be acted > upon by user space other > than signaling init? I like to have a message written in > /var/log/messages that someone pressed > the powerbutton. I think that for all suspend states except S5 userland is notified via devd mechanism and potentially can veto the suspend. S5 (soft-off) is coded to start shutdown immediately. You can try to hack on acpi_ReqSleepState in sys/dev/acpica/acpi.c. I am not sure what is the reason for this special behavior of S5. But I like it, because it sometimes allows me to perform semi-clean shutdown when X goes crazy. But I also see when it could be useful to have S5 request go through userland. So this could be configurable. -- Andriy Gapon From kamikaze at bsdforen.de Fri Apr 10 01:34:12 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Fri Apr 10 01:34:19 2009 Subject: ports/133541: [maintainer-update] www/xpi-modify_headers In-Reply-To: <200904091819.n39IJjDb027358@freefall.freebsd.org> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> Message-ID: <49DF0478.3020902@bsdforen.de> miwi@FreeBSD.org wrote: > Synopsis: [maintainer-update] www/xpi-modify_headers > > State-Changed-From-To: open->feedback > State-Changed-By: miwi > State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 > State-Changed-Why: > > Howdy, > > Patch rejected: > http://64bit.miwibox.org/index.php?action=describe_port&id=2152 > http://32bit.miwibox.org/index.php?action=describe_port&id=2042 > OK, this really sucks. diff has lost the -P option, that I've been relying on. Compare: http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE It used to say: -P When comparing directories, if a file appears only in the second directory of the two, treat it as present but empty in the other. Now it's gone. Regression? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133541 > From pyunyh at gmail.com Fri Apr 10 03:13:22 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Apr 10 03:13:29 2009 Subject: fxp: stalled transfers In-Reply-To: <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> Message-ID: <20090410101445.GL37714@michelle.cdnetworks.co.kr> On Fri, Apr 10, 2009 at 08:46:08AM +0200, Bjoern Koenig wrote: > I wrote: > > > >> If you can easily reproduce the issue, can you capture stalled TCP > >> session with tcpdump on receiving host?(Make sure to disable Rx > >> checksum offload prior to capturing the session.) > > > > I transferred a 256 kiB file and these are the tcpdumps: > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > > > Actually the transfer doesn't stall although ftp and scp told me so. It > > becomes incredibly slow. It seems like that the chunks are too large and a > > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > > it works fine with TSO enabled. > > > > I also captured the traffic on my router: > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > > > I almost suppose that this is a PPPoE-related configuration issue and the > > fxp driver is not necessarily the problem since decreasing the MTU of the > > LAN host solves it. > > Hello, it's me again. :) > > It's not PPPoE-related. I was able to reproduce the behaviour within a > regular LAN from host to host. I also have another symptom which denies > the PPPoE assumption: > > If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll > get the message "N bytes missing!" in the tcpdump output. For example: > > ifconfig fxp0 mtu 1448 # works > ifconfig fxp0 mtu 1412 # still works > ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) > ifconfig fxp0 mtu 1400 # works > ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) > Hmm, I can't reproduce this. Can you send me a URL to captured data for broken case? From kamikaze at bsdforen.de Fri Apr 10 07:53:26 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Fri Apr 10 07:54:04 2009 Subject: powerd broken In-Reply-To: <1238778004.65025.30.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> Message-ID: <49DF5D60.9010803@bsdforen.de> Robert Noland wrote: > I've been working on the Intel vblank / irq issues. Every time I commit > something thinking that I have it resolved, it isn't. So I'm waiting on > hardware to arrive that will let me test this all more thoroughly. I do > have a patch that I think fixes most of the issues on Intel, but the ddx > driver is still doing some silly things that cause issues in some cases. > I *think* the only outstanding issue I have with Intel is if something > is rendering (synced to vblank or not) when the display goes into dpms > sleep, there isn't anything to block that app, so it renders as hard as > it can even though it isn't being displayed. In reality, this probably > isn't a huge issue, but running gears while the display is asleep keeps > the cpu at 100%, which isn't ideal. Normal apps that aren't trying to > draw as fast as they can, shouldn't cause an issue. With the latest drm, the IRQ craziness is gone. However, the crappy performance remains. 2 months ago a RELENG_7 with all packages up to date yielded 124fps in a q3 timedemo that now yields 80fps. Regards From petefrench at ticketswitch.com Fri Apr 10 09:32:10 2009 From: petefrench at ticketswitch.com (Pete French) Date: Fri Apr 10 09:32:16 2009 Subject: bce + lagg not working on STABLE Message-ID: I just upgraded a test server to STABLE from today (good friday, around mid-day GMT), and though it all came up without errors I could not get any network connectivity out of the machine. The ethernet uses lagg to bindle two bce interfaces together - I know here were updates to the bce drive recently, but I have not been able to try them in isolation. The box in question is an HP ProLiant DL360 G5, and I spent some time trying to get some life out of it, but to no avail. I have had to roll this back for now so can't investigate further unfortunately. Sorry, I know this is a fairly useless bug report, but I wanted to at least get the info out there that this doesn't work. Will try again when I have a bit more access to the maachine. Anyone else seen similar ? -pete. From nate at root.org Fri Apr 10 10:06:03 2009 From: nate at root.org (Nate Lawson) Date: Fri Apr 10 10:06:10 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49DEFF53.1040306@icyb.net.ua> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> Message-ID: <49DF7A1C.90009@root.org> Andriy Gapon wrote: > on 09/04/2009 23:24 Stephen Clark said the following: >> Is there a reason it doesn't send and event like Linux that can be acted >> upon by user space other >> than signaling init? I like to have a message written in >> /var/log/messages that someone pressed >> the powerbutton. > > I think that for all suspend states except S5 userland is notified via > devd mechanism and potentially can veto the suspend. S5 (soft-off) is > coded to start shutdown immediately. You can try to hack on > acpi_ReqSleepState in sys/dev/acpica/acpi.c. > > I am not sure what is the reason for this special behavior of S5. But I > like it, because it sometimes allows me to perform semi-clean shutdown > when X goes crazy. But I also see when it could be useful to have S5 > request go through userland. So this could be configurable. The reason for userland getting into the loop in the first place was to run programs to shut down devices and reinit them after resume. This isn't necessary in the shutdown case because init already sends a signal, as you mention. There's already a mechanism for timing out if userland is not responding, so a suspend will ultimately happen whether or not it answers. However, that waits for a while (1 minute?) and devd used to be optional, so I thought it best to keep the existing S5 behavior (immediate shutdown). It may be ok to enable this for S5 but I don't think it's very useful. -- Nate From rnoland at FreeBSD.org Fri Apr 10 10:22:42 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 10 10:22:49 2009 Subject: powerd broken In-Reply-To: <49DF5D60.9010803@bsdforen.de> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> Message-ID: <1239384104.1922.70.camel@balrog.2hip.net> On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: > Robert Noland wrote: > > I've been working on the Intel vblank / irq issues. Every time I commit > > something thinking that I have it resolved, it isn't. So I'm waiting on > > hardware to arrive that will let me test this all more thoroughly. I do > > have a patch that I think fixes most of the issues on Intel, but the ddx > > driver is still doing some silly things that cause issues in some cases. > > I *think* the only outstanding issue I have with Intel is if something > > is rendering (synced to vblank or not) when the display goes into dpms > > sleep, there isn't anything to block that app, so it renders as hard as > > it can even though it isn't being displayed. In reality, this probably > > isn't a huge issue, but running gears while the display is asleep keeps > > the cpu at 100%, which isn't ideal. Normal apps that aren't trying to > > draw as fast as they can, shouldn't cause an issue. > > With the latest drm, the IRQ craziness is gone. However, the crappy > performance remains. 2 months ago a RELENG_7 with all packages > up to date yielded 124fps in a q3 timedemo that now yields 80fps. Things are still not quite right with the Intel driver. But performance regressions are reported across Linux as well. A little of this might be us, but most of it is Intel... robert. > Regards -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090410/faad3630/attachment.pgp From jesco.freund at my-universe.com Fri Apr 10 10:48:27 2009 From: jesco.freund at my-universe.com (Jesco Freund) Date: Fri Apr 10 10:48:35 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: <4457FAEE-A54F-4C4A-B625-5EB3A51BD47A@yellowspace.net> References: <4457FAEE-A54F-4C4A-B625-5EB3A51BD47A@yellowspace.net> Message-ID: On Thu, 9 Apr 2009 22:35:06 +0200, Lorenzo Perone wrote: > trying to understand now if > 7.2 is worth a new try, or if, for that matter, the only reasonable > wait is until 8.0. The deadlock issues should be fixed with ZFS v.13 which is only available in CURRENT. AFAIK, RELENG_7 will most probably stick with v.6, so the problems occurring with 7.1 will be most likely the same with 7.2. HTH Jesco From dennis.melentyev at gmail.com Fri Apr 10 11:30:43 2009 From: dennis.melentyev at gmail.com (Dennis Melentyev) Date: Fri Apr 10 11:30:50 2009 Subject: Appeal for active bug reports relating to TCP, UDP, routing locking in 7-STABLE In-Reply-To: References: Message-ID: Hi Robert, Could you please have a look into PR 133572? It's pretty critical for me (no incoming VPN to the office). Looks like related to this posting for me. If more info is needed, I'd be happy to provide. Including an ssh access for you, or person you name. /dennis 2009/3/17 Robert Watson : > > Dear all: > > With 7.2 approaching, I wanted to review the set of known network bug > reports (especially panics, hangs, lock order reversals) relating to TCP, > UDP, sockets, and routing in 7-STABLE. > > If you are aware of problems along these that you can confirm definitely > occur with 7-STABLE checked out no earlier than 17 March, 2009, please drop > me a private e-mail with a pointer to the thread, PR, or a reminder that > you've sent me the details already. ?If you don't have a PR open on the > problem, opening one and forwarding me the receipt so I can grab ownership > would be most welcome. > > I don't promise I can get them fixed by the release, but doing a review and > prioritizing the bugs that are known is a useful step in that direction. ?I > am specifically not interested in device driver-related problems, not > because they shouldn't be fixed, but because there's only so much time in > the day and it appears folks like Pyun have it well in hand :-). > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > 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" > -- Dennis Melentyev From kmacy at freebsd.org Fri Apr 10 14:43:28 2009 From: kmacy at freebsd.org (Kip Macy) Date: Fri Apr 10 14:43:37 2009 Subject: Network sysctl tuning [was Re: ZFSKnownProblems - needs revision?] In-Reply-To: References: <200904080959.49201.fjwcash@gmail.com> <49DD2B44.5020808@mawer.org> Message-ID: <3c1674c90904101423v68d1bb42q5b4ab510cc4cda1d@mail.gmail.com> I think most if not all of the gains are from increasing the maximum tcp socket buffer sizes. You might test it out with only those to confirm. -Kip On Thu, Apr 9, 2009 at 3:42 PM, Freddie Cash wrote: > On Wed, Apr 8, 2009 at 3:55 PM, Antony Mawer wrote: >> Freddie Cash wrote: >> ... >>> We've also heavily modified /etc/sysctl.conf and upped a bunch of the >>> network-related sysctls. ?Doing so increased our SSH throughput from ~30 >>> Mbits/sec across all connections to over 90 Mbits/sec per SSH connection. >> >> Are you able to share any of these with the list? It would be useful to >> compare as a lot of these tunings people do individually and it would be >> good to allow others to test in their environments to see if they help, as >> well as potentially adding them to the tuning man-page. > > They're all taken from the HPN-SSH website and various google searches > related to HPN-enabled OpenSSH. > > I don't know exactly what all the different, individual sysctls do, > nor whether this is the most optimal setup, but here's the sysctl.conf > that we use. ?This is on 2 systems using a quad-port gigabit NIC where > the top two ports are connected via lagg(4) and the bottom two ports > are connected via lagg(4), with the two laggX interfaces on separate > networks. > > I did a bunch of scp/sftp transfers of 100 MB files filled with random > data pulled from /dev/random between these two boxes tweaking the > options one at a time, but didn't do too much in the way of > scientific/empirical measurements and comparisons beyond the > throughput data that scp/sftp shows. > > If there are any glaring errors, gotchas, or "why would you ever do > that"s, let me know. ?:) > > # General network settings > net.isr.direct=1 ? ? ? ? ? ? ? ? ? ? ? ?# Whether to enable Direct > Dispatch for netisr > > > # IP options > net.inet.ip.forwarding=0 ? ? ? ? ? ? ? ?# Whether to enable packet > forwarding for NAT/routing > net.inet.ip.process_options=0 ? ? ? ? ? # Disable processing of IP > options (nothing uses this field) > net.inet.ip.random_id=1 ? ? ? ? ? ? ? ? # Randomise the IP header ID number > net.inet.ip.redirect=0 ? ? ? ? ? ? ? ? ?# Whether to allow redirect packets > #net.inet.ip.stealth=0 ? ? ? ? ? ? ? ? ?# Whether to appear in traceroute output > > > # ICMP options > net.inet.icmp.icmplim=200 ? ? ? ? ? ? ? # Limit ICMP packets to this > many per second > net.inet.icmp.drop_redirect=1 ? ? ? ? ? # Drop ICMP redirect packets > net.inet.icmp.log_redirect=0 ? ? ? ? ? ?# Don't log ICMP redirect packets > > > # TCP options > net.inet.tcp.blackhole=1 ? ? ? ? ? ? ? ?# Drop packets destined to unused ports > net.inet.tcp.inflight.enable=0 ? ? ? ? ?# Use automatic TCP window-scaling > net.inet.tcp.log_in_vain=0 ? ? ? ? ? ? ?# Don't log the blackholed packets > net.inet.tcp.path_mtu_discovery=1 ? ? ? # Use ICMP type 3 to find the MTU to use > net.inet.tcp.recvbuf_max=16777216 ? ? ? # The max size of the receive > buffer (16 MB) > net.inet.tcp.recvspace=131072 ? ? ? ? ? # The initial size in bytes of > the receive buffer > net.inet.tcp.sack.enable=1 ? ? ? ? ? ? ?# Enable Selective ACKs > net.inet.tcp.sendbuf_max=16777216 ? ? ? # The max size of the send buffer > net.inet.tcp.sendspace=131072 ? ? ? ? ? # The initial size in bytes of > the send buffer > net.inet.tcp.syncookies=1 ? ? ? ? ? ? ? # Enable SYN cookie protection > net.inet.tcp.rfc1323=1 ? ? ? ? ? ? ? ? ?# Enable RFC1323 extensions > (TCP window scaling) > > > # UDP options > net.inet.udp.blackhole=1 ? ? ? ? ? ? ? ?# Drop packets destined to unused ports > net.inet.udp.checksum=1 ? ? ? ? ? ? ? ? # Enable UDP checksums > net.inet.udp.log_in_vain=0 ? ? ? ? ? ? ?# Don't log the blackholed packets > net.inet.udp.recvspace=65536 ? ? ? ? ? ?# Size in bytes of the receive buffer > > > # Debug options > debug.minidump=1 ? ? ? ? ? ? ? ? ? ? ? ?# Disable the small kernel > core dump (only mem in use) > debug.mpsafevfs=1 ? ? ? ? ? ? ? ? ? ? ? # Enable threaded VFS subsystem > > > # Kernel options > kern.coredump=0 ? ? ? ? ? ? ? ? ? ? ? ? # Disable kernel core dumps > kern.ipc.maxsockbuf=4194304 ? ? ? ? ? ? # Set the max size of the > socket buffers (4 MB) > kern.ipc.somaxconn=1024 ? ? ? ? ? ? ? ? # Expand the IP listen queue > kern.maxvnodes=250000 ? ? ? ? ? ? ? ? ? # Bump up the max number of vnodes > > > # PCI bus options > hw.pci.enable_msix=1 ? ? ? ? ? ? ? ? ? ?# Enable Message Signalled > Interrupts - Extended > hw.pci.enable_msi=1 ? ? ? ? ? ? ? ? ? ? # Enable Message Signalled Interrupts > hw.pci.enable_io_modes=1 ? ? ? ? ? ? ? ?# Enable alternate I/O access modes > > -- > Freddie Cash > fjwcash@gmail.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" > -- All that is necessary for the triumph of evil is that good men do nothing. Edmund Burke From pyunyh at gmail.com Fri Apr 10 20:44:44 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Apr 10 20:44:57 2009 Subject: fxp: stalled transfers In-Reply-To: <20090410101445.GL37714@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> <20090410101445.GL37714@michelle.cdnetworks.co.kr> Message-ID: <20090411034613.GA54253@michelle.cdnetworks.co.kr> On Fri, Apr 10, 2009 at 07:14:45PM +0900, Pyun YongHyeon wrote: > On Fri, Apr 10, 2009 at 08:46:08AM +0200, Bjoern Koenig wrote: > > I wrote: > > > > > >> If you can easily reproduce the issue, can you capture stalled TCP > > >> session with tcpdump on receiving host?(Make sure to disable Rx > > >> checksum offload prior to capturing the session.) > > > > > > I transferred a 256 kiB file and these are the tcpdumps: > > > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso.txt > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso.txt > > > > > > Actually the transfer doesn't stall although ftp and scp told me so. It > > > becomes incredibly slow. It seems like that the chunks are too large and a > > > smaller packet will be resent. I decreased the MTU from 1500 to 1492 and > > > it works fine with TSO enabled. > > > > > > I also captured the traffic on my router: > > > > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-with-tso-router.txt > > > http://www.alpha-tierchen.de/~bkoenig/fxp0-without-tso-router.txt > > > > > > It reveals a suspect information: "truncated-ip - 8 bytes missing!" > > > > > > I almost suppose that this is a PPPoE-related configuration issue and the > > > fxp driver is not necessarily the problem since decreasing the MTU of the > > > LAN host solves it. > > > > Hello, it's me again. :) > > > > It's not PPPoE-related. I was able to reproduce the behaviour within a > > regular LAN from host to host. I also have another symptom which denies > > the PPPoE assumption: > > > > If I set MTU to value X then it doesn't work with MTU X+N anymore. I'll > > get the message "N bytes missing!" in the tcpdump output. For example: > > > > ifconfig fxp0 mtu 1448 # works > > ifconfig fxp0 mtu 1412 # still works > > ifconfig fxp0 mtu 1448 # doesn't work (36 bytes missing) > > ifconfig fxp0 mtu 1400 # works > > ifconfig fxp0 mtu 1412 # doesn't work (12 bytes missing) > > > > Hmm, I can't reproduce this. Can you send me a URL to captured > data for broken case? Ok, I've reproduced it, it seems that it happens when sender and receiver has advertised different MSS. Try attached patch and let me know how it goes on your setup. -------------- next part -------------- A non-text attachment was scrubbed... Name: fxp.tso.patch Type: text/x-diff Size: 561 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090411/ba2eefff/fxp.tso.bin From pyunyh at gmail.com Sat Apr 11 01:36:26 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Apr 11 01:36:33 2009 Subject: fxp unusable after make world In-Reply-To: <20090309000610.GA5039@michelle.cdnetworks.co.kr> References: <49B1AC25.3000700@onetel.com> <27998819.871236382003017.JavaMail.HALO$@halo> <1d001f850903061814k2577f3ccs94be86bcc87b9efd@mail.gmail.com> <49B38AEF.8070909@beatsnet.com> <20090308093653.GD1531@michelle.cdnetworks.co.kr> <49B3FAA3.9010302@beatsnet.com> <20090309000610.GA5039@michelle.cdnetworks.co.kr> Message-ID: <20090411083759.GB54253@michelle.cdnetworks.co.kr> On Mon, Mar 09, 2009 at 09:06:10AM +0900, Pyun YongHyeon wrote: > On Sun, Mar 08, 2009 at 06:04:35PM +0100, Beat Siegenthaler wrote: > > Pyun YongHyeon wrote: > > > > > > > > I touched fxp(4) to add more hardware assistance so it could cause > > > problems on your box. Please show me dmesg output and > > > "ifconfig fxp0" > > > output. > > > > > > If you doubt checksum offloading or TSO issues, try > > > "ifconfig fxp0 -tso -txcsum -rxcsum". > > > > > And the command above fixed your issue? > It seems that fxp(4) has a TSO bug. Would you try attached patch? (Make sure to enable TSO to check whether the issue was resolved.) -------------- next part -------------- A non-text attachment was scrubbed... Name: fxp.tso.patch Type: text/x-diff Size: 561 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090411/52707626/fxp.tso.bin From raul at b2n.org Sat Apr 11 04:10:46 2009 From: raul at b2n.org (Raul) Date: Sat Apr 11 04:10:53 2009 Subject: problems with 7.2, vm_page_insert: page already inserted Message-ID: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> Hello! Last night I've switched at home from 7.1R to RELENG_7. Everything went smooth but 2 hours 46 mins later the box paniced with: vm_page_insert: page already inserted. The 1688MB dump stopped at 1417 ... there is no dump available :/. The box, a dell t105, has been rock solid (as freeBSD) until yesterday since 7.0R. It runs a bit complex mixture of things: xorp, racoon, ipsec, pf, several openvpn udp tunnels, pppoe client (mpd5), intensive use of zfs, some nfs, samba, apache, php, postgresql, mysql, dovecot, postfix ... well, the list is never ending and I have no idea where to start to track the problem. dmesg available at http://pastebin.com/m4d640f31 feel free to ask for whatever more info HELP! Thanks a lot in advance, Cheers. From kamikaze at bsdforen.de Sat Apr 11 04:49:05 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sat Apr 11 04:49:12 2009 Subject: diff regression In-Reply-To: <200904091819.n39IJjDb027358@freefall.freebsd.org> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> Message-ID: <49E083AD.5030608@bsdforen.de> miwi@FreeBSD.org wrote: > Synopsis: [maintainer-update] www/xpi-modify_headers > > State-Changed-From-To: open->feedback > State-Changed-By: miwi > State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 > State-Changed-Why: > > Howdy, > > Patch rejected: > http://64bit.miwibox.org/index.php?action=describe_port&id=2152 > http://32bit.miwibox.org/index.php?action=describe_port&id=2042 > OK, this really sucks. diff has lost the -P option, that I've been relying on. Compare: http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE It used to say: -P When comparing directories, if a file appears only in the second directory of the two, treat it as present but empty in the other. Now it's gone. Regression? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133541 > _______________________________________________ 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 bkoenig at alpha-tierchen.de Sat Apr 11 05:18:39 2009 From: bkoenig at alpha-tierchen.de (Bjoern Koenig) Date: Sat Apr 11 05:18:46 2009 Subject: fxp: stalled transfers In-Reply-To: <20090411034613.GA54253@michelle.cdnetworks.co.kr> References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> <20090410101445.GL37714@michelle.cdnetworks.co.kr> <20090411034613.GA54253@michelle.cdnetworks.co.kr> Message-ID: Pyun YongHyeon wrote: > Ok, I've reproduced it, it seems that it happens when sender and > receiver has advertised different MSS. Try attached patch and let > me know how it goes on your setup. The patch works. The problem is gone. Thank you. Bj?rn From delphij at delphij.net Sat Apr 11 05:42:58 2009 From: delphij at delphij.net (Xin LI) Date: Sat Apr 11 05:43:06 2009 Subject: diff regression In-Reply-To: <49E083AD.5030608@bsdforen.de> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> Message-ID: <49E09045.30904@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominic Fandrey wrote: | miwi@FreeBSD.org wrote: |> Synopsis: [maintainer-update] www/xpi-modify_headers |> |> State-Changed-From-To: open->feedback |> State-Changed-By: miwi |> State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 |> State-Changed-Why: |> |> Howdy, |> |> Patch rejected: |> http://64bit.miwibox.org/index.php?action=describe_port&id=2152 |> http://32bit.miwibox.org/index.php?action=describe_port&id=2042 |> | | OK, this really sucks. diff has lost the -P option, that I've been | relying on. Compare: | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE | | It used to say: | -P When comparing directories, if a file appears only in the second | directory of the two, treat it as present but empty in the | other. | | Now it's gone. Regression? What's wrong with -N? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkngkEUACgkQOfuToMruuMB4MwCdGvD/nC/YGkq0hYeqyq06dyPY 3JUAn399negHDECAUmTQFM/5KpmBP8Q1 =pRzw -----END PGP SIGNATURE----- From kamikaze at bsdforen.de Sat Apr 11 05:51:38 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sat Apr 11 05:51:46 2009 Subject: diff regression In-Reply-To: <49E09045.30904@delphij.net> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> <49E09045.30904@delphij.net> Message-ID: <49E09258.1040103@bsdforen.de> Xin LI wrote: > Dominic Fandrey wrote: > | miwi@FreeBSD.org wrote: > |> Synopsis: [maintainer-update] www/xpi-modify_headers > |> > |> State-Changed-From-To: open->feedback > |> State-Changed-By: miwi > |> State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 > |> State-Changed-Why: > |> > |> Howdy, > |> > |> Patch rejected: > |> http://64bit.miwibox.org/index.php?action=describe_port&id=2152 > |> http://32bit.miwibox.org/index.php?action=describe_port&id=2042 > |> > | > | OK, this really sucks. diff has lost the -P option, that I've been > | relying on. Compare: > | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE > | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE > | > | It used to say: > | -P When comparing directories, if a file appears only in > the second > | directory of the two, treat it as present but empty > in the > | other. > | > | Now it's gone. Regression? > > What's wrong with -N? Nothing, I just didn't know about -N. From swhetzel at gmail.com Sat Apr 11 05:54:00 2009 From: swhetzel at gmail.com (Scot Hetzel) Date: Sat Apr 11 05:54:06 2009 Subject: diff regression In-Reply-To: <49E083AD.5030608@bsdforen.de> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> Message-ID: <790a9fff0904110522r23e8b868l753fc59fb0838402@mail.gmail.com> On Sat, Apr 11, 2009 at 6:49 AM, Dominic Fandrey wrote: > OK, this really sucks. diff has lost the -P option, that I've been > relying on. Compare: > http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE > http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE > > It used to say: > ? ? ? -P ? ? When comparing directories, if a file appears only in the second > ? ? ? ? ? ? ?directory of the two, treat it ?as ?present ?but ?empty ?in ?the > ? ? ? ? ? ? ?other. > > Now it's gone. Regression? > >> It looks like the -P option was removed from diff between FreeBSD 6.2-Release and FreeBSD 6.3-Release (diffutils 2.8.7). You can use --unidirectional-new-file instead. Scot From delphij at delphij.net Sat Apr 11 06:31:19 2009 From: delphij at delphij.net (Xin LI) Date: Sat Apr 11 06:31:27 2009 Subject: diff regression In-Reply-To: <49E09258.1040103@bsdforen.de> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> <49E09045.30904@delphij.net> <49E09258.1040103@bsdforen.de> Message-ID: <49E09B9E.2010002@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dominic Fandrey wrote: | Xin LI wrote: |> Dominic Fandrey wrote: |> | miwi@FreeBSD.org wrote: |> |> Synopsis: [maintainer-update] www/xpi-modify_headers |> |> |> |> State-Changed-From-To: open->feedback |> |> State-Changed-By: miwi |> |> State-Changed-When: Thu Apr 9 18:19:08 UTC 2009 |> |> State-Changed-Why: |> |> |> |> Howdy, |> |> |> |> Patch rejected: |> |> http://64bit.miwibox.org/index.php?action=describe_port&id=2152 |> |> http://32bit.miwibox.org/index.php?action=describe_port&id=2042 |> |> |> | |> | OK, this really sucks. diff has lost the -P option, that I've been |> | relying on. Compare: |> | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+6.0-RELEASE |> | http://www.freebsd.org/cgi/man.cgi?query=diff&manpath=FreeBSD+7.1-RELEASE |> | |> | It used to say: |> | -P When comparing directories, if a file appears only in |> the second |> | directory of the two, treat it as present but empty |> in the |> | other. |> | |> | Now it's gone. Regression? |> |> What's wrong with -N? | | Nothing, I just didn't know about -N. I'm not very sure, are the two option functionally same? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkngm54ACgkQOfuToMruuMBn0gCfd/NMu8to+3fG1oaAqjukmHKk PB4AnirvAUQzu1XPWgzF2XHcvuhSIWTA =LqUx -----END PGP SIGNATURE----- From swhetzel at gmail.com Sat Apr 11 06:56:14 2009 From: swhetzel at gmail.com (Scot Hetzel) Date: Sat Apr 11 06:56:21 2009 Subject: diff regression In-Reply-To: <49E09B9E.2010002@delphij.net> References: <200904091819.n39IJjDb027358@freefall.freebsd.org> <49E083AD.5030608@bsdforen.de> <49E09045.30904@delphij.net> <49E09258.1040103@bsdforen.de> <49E09B9E.2010002@delphij.net> Message-ID: <790a9fff0904110656m8505444gc25152129d63ef48@mail.gmail.com> On 4/11/09, Xin LI wrote: > |> | It used to say: > |> | -P When comparing directories, if a file appears only in > |> the second > |> | directory of the two, treat it as present but empty > |> in the > |> | other. > |> | > |> | Now it's gone. Regression? > |> > |> What's wrong with -N? > | > | Nothing, I just didn't know about -N. > > I'm not very sure, are the two option functionally same? According to the diff.1 man page -N (--new-file) Treat absent files as empty --unidirectional-new-file (-P) Treat absent first files as empty So it would seem the two options are different. Scot From xernet at hotmail.it Sat Apr 11 09:37:47 2009 From: xernet at hotmail.it (xer) Date: Sat Apr 11 09:37:54 2009 Subject: apache 2.0.63 and php5 In-Reply-To: <20090409120815.A0FAB10658D2@hub.freebsd.org> References: <20090409120815.A0FAB10658D2@hub.freebsd.org> Message-ID: Hello any1 Strange, i have a apache web 2.0.63 and php5 on a 6.4-STABLE, but every time i reboot the server, the php pages does not work at all, especially some self tools made with sh scripts and sudo (tail cat and some php buttons), refresh of the page does not solve the matter.. For fix it, i need to make a simple apachectl stop and start, then the php pages start to works... the logs did tell anything... any ideas? appreciate your help TIA From kometen at gmail.com Sat Apr 11 11:07:30 2009 From: kometen at gmail.com (Claus Guttesen) Date: Sat Apr 11 11:07:37 2009 Subject: apache 2.0.63 and php5 In-Reply-To: References: <20090409120815.A0FAB10658D2@hub.freebsd.org> Message-ID: > Strange, i have a apache web 2.0.63 and php5 on a 6.4-STABLE, but every time > i reboot the server, the php pages does not work at all, especially some > self tools made with sh scripts and sudo (tail cat and some php buttons), > refresh of the page does not solve the matter.. > > For fix it, i need to make a simple apachectl stop and start, then the php > pages start to works... > > the logs did tell anything... > > any ideas? Could be an apache module which is not started if the hostname is required but not yet known, since ethernet is not up and the server can't perform a dns-query. You can try to add the hostname to /etc/hosts. -- regards Claus When lenity and cruelty play for a kingdom, the gentler gamester is the soonest winner. Shakespeare From raul at b2n.org Sat Apr 11 17:04:42 2009 From: raul at b2n.org (Raul) Date: Sat Apr 11 17:04:50 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> Message-ID: <1239494679.15226.23.camel@ws.pinlabs.b2n.org> Hi again. El s?b, 11-04-2009 a las 12:55 +0200, Raul escribi?: > Hello! > > Last night I've switched at home from 7.1R to RELENG_7. Everything went > smooth but 2 hours 46 mins later the box paniced with: vm_page_insert: > page already inserted. The 1688MB dump stopped at 1417 ... there is no > dump available :/. I've rebuilt all ports twice without a glitch, except isc-dhcp30-server but that's another story. Can this double rebuilt help somehow with that sort of error?. I'm still out of ideas ... As a side note, isc-dhcp30-server port doesn't like the new jail stuff with default port setings (WITH_DHCP_JAIL=true): [....] Making all in server cc -O2 -fno-strict-aliasing -pipe -D_PATH_DHCPD_CONF= \"/usr/local/etc/dhcpd.conf\" -D_PATH_DHCPD_DB=\"/var/db/dhcpd.leases\" -D_PATH_DHCPD_PID=\"/var/run/dhcpd.pid\" -D_PATH_DHCRELAY_PID= \"/var/run/dhcrelay.pid\" -D_PATH_DHCLIENT_CONF= \"/usr/local/etc/dhclient.conf\" -D_PATH_DHCLIENT_SCRIPT= \"/usr/local/sbin/dhclient-script\" -D_PATH_DHCLIENT_DB= \"/var/db/dhclient.leases\" -D_PATH_DHCLIENT_PID=\"/var/run/dhclient.pid \" -Dwarn=dhcp_warn -DNOMINUM -DPARANOIA -DJAIL -I/usr/ports/net/isc-dhcp30-server/work/dhcp-3.0.7 -I/usr/ports/net/isc-dhcp30-server/work/dhcp-3.0.7/includes -O -Wall -Wno-unused -c dhcpd.c dhcpd.c: In function 'setup_jail': dhcpd.c:234: error: 'struct jail' has no member named 'ip_number' *** Error code 1 [....] may I fill a PR about this? Regards Raul From dimitry at andric.com Sat Apr 11 17:13:53 2009 From: dimitry at andric.com (Dimitry Andric) Date: Sat Apr 11 17:14:02 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239494679.15226.23.camel@ws.pinlabs.b2n.org> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> Message-ID: <49E1323F.5040408@andric.com> On 2009-04-12 02:04, Raul wrote: > As a side note, isc-dhcp30-server port doesn't like the new jail stuff Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=131515 for a possible fix. From kensmith at cse.Buffalo.EDU Sat Apr 11 17:30:52 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Apr 11 17:30:59 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239494679.15226.23.camel@ws.pinlabs.b2n.org> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> Message-ID: <1239496242.58897.7.camel@bauer.cse.buffalo.edu> On Sun, 2009-04-12 at 02:04 +0200, Raul wrote: > I've rebuilt all ports twice without a glitch, except isc-dhcp30-server > but that's another story. Can this double rebuilt help somehow with that > sort of error?. I'm still out of ideas ... If the double rebuild did help somehow it's still an issue that would need to be addressed. Stuff user-level does shouldn't cause the kernel to panic - that's never a good thing. You're the second one to report this panic so it's caught our notice as something to watch over. One report of a panic like this is potentially issues with memory errors or any number of other possibilities given this area of code but more than that deserves us paying more attention to it. Mike, you were the first to report this - have you had recurrences? That said if there is a bug it's likely to be something fairly difficult to reproduce (lots of people are running 7.2-PRERELEASE and so far only two reports of this issue) so it's not a shock for you to have only had it happen once so far. Odds are it takes a rare sequence of events to trigger it. -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090412/5480095b/attachment.pgp From alan.l.cox at gmail.com Sat Apr 11 17:37:26 2009 From: alan.l.cox at gmail.com (Alan Cox) Date: Sat Apr 11 17:37:33 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> Message-ID: Please post your kernel configuration file. Regards, Alan From raul at b2n.org Sat Apr 11 17:53:50 2009 From: raul at b2n.org (Raul) Date: Sat Apr 11 17:53:57 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> Message-ID: <1239497628.15226.28.camel@ws.pinlabs.b2n.org> El s?b, 11-04-2009 a las 19:37 -0500, Alan Cox escribi?: > Please post your kernel configuration file. It's rather simple: [....] include GENERIC ident TURING options IPSEC device enc device crypto [....] That's all. Regards Raul From raul at b2n.org Sat Apr 11 18:04:14 2009 From: raul at b2n.org (Raul) Date: Sat Apr 11 18:04:21 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> Message-ID: <1239498248.15226.32.camel@ws.pinlabs.b2n.org> El s?b, 11-04-2009 a las 19:37 -0500, Alan Cox escribi?: > Please post your kernel configuration file. Maybe loaded kernel modules are also interesting: [....] Id Refs Address Size Name 1 17 0xffffffff80100000 c13558 kernel 2 1 0xffffffff80e22000 8113c zfs.ko 3 1 0xffffffff80ea4000 111b opensolaris.ko 4 1 0xffffffff80ea6000 240e if_vlan.ko 5 1 0xffffffff80ea9000 972 pflog.ko 6 1 0xffffffff80eaa000 2ae58 pf.ko 7 1 0xffffffff80ed5000 19ba ng_socket.ko 8 8 0xffffffff80ed7000 8f74 netgraph.ko 9 1 0xffffffff80ee0000 184b ng_mppc.ko 10 1 0xffffffff80ee2000 23e rc4.ko 11 1 0xffffffff80ee3000 1446 ng_iface.ko 12 1 0xffffffff80ee5000 45fe ng_ppp.ko 13 1 0xffffffff80eea000 a9e ng_tee.ko 14 1 0xffffffff80eeb000 12a6 ng_ether.ko 15 1 0xffffffff80eed000 30be ng_pppoe.ko 16 1 0xffffffff80ef1000 9e2 ng_tcpmss.ko [....] Regards Raul From alc at cs.rice.edu Sat Apr 11 18:23:40 2009 From: alc at cs.rice.edu (Alan Cox) Date: Sat Apr 11 18:23:47 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239497628.15226.28.camel@ws.pinlabs.b2n.org> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239497628.15226.28.camel@ws.pinlabs.b2n.org> Message-ID: <49E14291.2080901@cs.rice.edu> Raul wrote: > El s?b, 11-04-2009 a las 19:37 -0500, Alan Cox escribi?: > > >> Please post your kernel configuration file. >> > > It's rather simple: > > [....] > include GENERIC > ident TURING > > options IPSEC > device enc > device crypto > [....] > > That's all. > Ok, thanks. Alan From dan at langille.org Sat Apr 11 19:53:48 2009 From: dan at langille.org (Dan Langille) Date: Sat Apr 11 19:53:55 2009 Subject: kernel: problems compiling if_ath.c Message-ID: <49E15409.3000100@langille.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did a cvsup for RELENG_7 earlier today. # uname -a FreeBSD polo.example.org 7.1-STABLE FreeBSD 7.1-STABLE #8: Sat Apr 11 18:50:17 EDT 2009 dan@polo.example.org:/usr/obj/usr/src/sys/PHENOM amd64 No idea what went wrong here. Clues please. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 - -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx - -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding - -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' *** Error code 1 Stop in /usr/obj/usr/src/sys/PHENOM. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknhVAgACgkQCgsXFM/7nTzaZQCg9vSAstcI2+nCiU8pUOGH+AUg /1EAn1mv5gKUOk0JnjZW0kIr15ekSWSW =J+pi -----END PGP SIGNATURE----- From dan at langille.org Sat Apr 11 20:12:29 2009 From: dan at langille.org (Dan Langille) Date: Sat Apr 11 20:12:36 2009 Subject: kernel: problems compiling if_ath.c In-Reply-To: <49E15409.3000100@langille.org> References: <49E15409.3000100@langille.org> Message-ID: <49E15C10.6030309@langille.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Langille wrote: > I did a cvsup for RELENG_7 earlier today. > > # uname -a > FreeBSD polo.example.org 7.1-STABLE FreeBSD 7.1-STABLE #8: Sat Apr 11 > 18:50:17 EDT 2009 dan@polo.example.org:/usr/obj/usr/src/sys/PHENOM > amd64 > > No idea what went wrong here. Clues please. > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 > -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx > -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath > /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': > /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' > has no member named 'rs_flags' > /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' > has no member named 'rs_flags' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/PHENOM. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > Fixed. The above was based upon an old GENERIC. Sorry. - -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknhXA8ACgkQCgsXFM/7nTwBfQCaA3UWngIxYgm34CIL8+Nersd+ b40AniDxutvGFxjvyoALjxafXn+R+uY3 =ATAk -----END PGP SIGNATURE----- From mike at sentex.net Sat Apr 11 20:37:59 2009 From: mike at sentex.net (Mike Tancsa) Date: Sat Apr 11 20:38:06 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239496242.58897.7.camel@bauer.cse.buffalo.edu> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> <1239496242.58897.7.camel@bauer.cse.buffalo.edu> Message-ID: <200904120334.n3C3YYoi012896@lava.sentex.ca> At 08:30 PM 4/11/2009, Ken Smith wrote: >On Sun, 2009-04-12 at 02:04 +0200, Raul wrote: > > I've rebuilt all ports twice without a glitch, except isc-dhcp30-server > > but that's another story. Can this double rebuilt help somehow with that > > sort of error?. I'm still out of ideas ... > >If the double rebuild did help somehow it's still an issue that would >need to be addressed. Stuff user-level does shouldn't cause the kernel >to panic - that's never a good thing. > >You're the second one to report this panic so it's caught our notice as >something to watch over. One report of a panic like this is potentially >issues with memory errors or any number of other possibilities given >this area of code but more than that deserves us paying more attention >to it. > >Mike, you were the first to report this - have you had recurrences? Hi Ken, I have not see it again. I am wondering if it was an issue of not having swap. It happened last weekend when some level 0 dumps over nfs are run, so its possible too much demand on memory and 'bad things' started to happen. I have since enabled swap and no issues since. On another box which has a similar mix of spamd,clamav, sendmail, no issues at all. ---Mike >That said if there is a bug it's likely to be something fairly difficult >to reproduce (lots of people are running 7.2-PRERELEASE and so far only >two reports of this issue) so it's not a shock for you to have only had >it happen once so far. Odds are it takes a rare sequence of events to >trigger it. > >-- > Ken Smith >- From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > > From kensmith at cse.Buffalo.EDU Sat Apr 11 21:00:50 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Apr 11 21:00:57 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <200904120334.n3C3YYoi012896@lava.sentex.ca> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> <1239496242.58897.7.camel@bauer.cse.buffalo.edu> <200904120334.n3C3YYoi012896@lava.sentex.ca> Message-ID: <1239508836.51116.2.camel@neo.cse.buffalo.edu> On Sat, 2009-04-11 at 23:35 -0400, Mike Tancsa wrote: > I am wondering if it was an issue > of not having swap. Raul, Any chance your machine might have somehow run low on available memory (either by not having swap enabled, or perhaps not enough swap space)? Thanks (and thanks Mike). -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090412/1c2e4996/attachment.pgp From raul at b2n.org Sun Apr 12 01:09:22 2009 From: raul at b2n.org (Raul) Date: Sun Apr 12 01:09:30 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239508836.51116.2.camel@neo.cse.buffalo.edu> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> <1239496242.58897.7.camel@bauer.cse.buffalo.edu> <200904120334.n3C3YYoi012896@lava.sentex.ca> <1239508836.51116.2.camel@neo.cse.buffalo.edu> Message-ID: <1239523758.19319.27.camel@ws.pinlabs.b2n.org> El dom, 12-04-2009 a las 00:00 -0400, Ken Smith escribi?: > On Sat, 2009-04-11 at 23:35 -0400, Mike Tancsa wrote: > > I am wondering if it was an issue > > of not having swap. > > Raul, > > Any chance your machine might have somehow run low on available memory > (either by not having swap enabled, or perhaps not enough swap space)? I can't say no, is connected throught internet and run maybe some poorly tunned services, but fairly difficult. The worst memory scenario that I remember was artificially stressing zfs ... around 1.5Gb 'Inact' and no swap in use. The box has 4Gb of memory and a 4Gb swap partition enabled practically never used. Given said that, and related to zfs the box 'constrain' kernel memory. The loader.conf looks like: [....] vm.kmem_size="1536M" vm.kmem_size_max="1536M" [....] This are normal figures from top, perhaps a little higher (wired) but not much: [....] last pid: 90354; load averages: 0.03, 0.05, 0.05 up 0+09:55:09 09:51:46 115 processes: 2 running, 113 sleeping CPU: 2.3% user, 1.5% nice, 0.2% system, 0.0% interrupt, 96.1% idle Mem: 356M Active, 2502M Inact, 873M Wired, 99M Cache, 399M Buf, 108M Free Swap: 4096M Total, 24K Used, 4096M Free [....] Regards Raul From petefrench at ticketswitch.com Sun Apr 12 02:25:06 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sun Apr 12 02:25:13 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <200904120334.n3C3YYoi012896@lava.sentex.ca> Message-ID: >You're the second one to report this panic so it's caught our notice as >something to watch over. One report of a panic like this is potentially >issues with memory errors or any number of other possibilities given >this area of code but more than that deserves us paying more attention >to it. Well, here's a third report for you - I saw the same panic, and I was also running without swap at the time. I was migrating a system from UFS to using ZFS, which I did by NFS mounting some space, copying the files there, then repartitioning the original machine and copying them back. I got the panic during one of the big copy sessions, but I can't rememer the direction I'm afraid. The system is running STABLE from early March. I didn't report it at the time as I just assumed it was a ZFS tuning issue, but now I see this thread and I realise I've never seen that panic on any ZFS machines. It was a one-off, but that does make three of us now. Is the common factor that we all had swap disabled at the time ? That worries me as I now install all our webservers with twice the RAM and no swap, due to the fact that having swap gves us worse behaviour when we get overloaded. -pete. From kamikaze at bsdforen.de Sun Apr 12 07:50:34 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Sun Apr 12 08:35:22 2009 Subject: powerd broken In-Reply-To: <1239384104.1922.70.camel@balrog.2hip.net> References: <1238293386.00093672.1238281804@10.7.7.3> <49CF0803.1070505@FreeBSD.org> <49CF2F8D.6000905@bsdforen.de> <49CF4EB9.60108@FreeBSD.org> <49CF49F5.6010800@bsdforen.de> <49CF615A.6050304@FreeBSD.org> <49CF595A.30805@bsdforen.de> <49CF6B28.2080400@FreeBSD.org> <49CF60AB.4040709@bsdforen.de> <49CF6899.2060002@bsdforen.de> <49CF8E8D.1080604@bsdforen.de> <49CF9C19.3020509@FreeBSD.org> <49D5DA33.4010800@bsdforen.de> <1238778004.65025.30.camel@balrog.2hip.net> <49DF5D60.9010803@bsdforen.de> <1239384104.1922.70.camel@balrog.2hip.net> Message-ID: <49E1FFB6.5000708@bsdforen.de> Robert Noland wrote: > On Fri, 2009-04-10 at 16:53 +0200, Dominic Fandrey wrote: >> Robert Noland wrote: >>> I've been working on the Intel vblank / irq issues. Every time I commit >>> something thinking that I have it resolved, it isn't. So I'm waiting on >>> hardware to arrive that will let me test this all more thoroughly. I do >>> have a patch that I think fixes most of the issues on Intel, but the ddx >>> driver is still doing some silly things that cause issues in some cases. >>> I *think* the only outstanding issue I have with Intel is if something >>> is rendering (synced to vblank or not) when the display goes into dpms >>> sleep, there isn't anything to block that app, so it renders as hard as >>> it can even though it isn't being displayed. In reality, this probably >>> isn't a huge issue, but running gears while the display is asleep keeps >>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying to >>> draw as fast as they can, shouldn't cause an issue. >> With the latest drm, the IRQ craziness is gone. However, the crappy >> performance remains. 2 months ago a RELENG_7 with all packages >> up to date yielded 124fps in a q3 timedemo that now yields 80fps. > > Things are still not quite right with the Intel driver. But performance > regressions are reported across Linux as well. A little of this might > be us, but most of it is Intel... > > robert. > After a couple of hours uptime (~9), the IRQ problem reappeared. So, it takes a lot more time to occur, but it still happens. From rabe at uugrn.org Sun Apr 12 08:58:46 2009 From: rabe at uugrn.org (Raphael Becker) Date: Sun Apr 12 09:50:17 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <1239496242.58897.7.camel@bauer.cse.buffalo.edu> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> <1239496242.58897.7.camel@bauer.cse.buffalo.edu> Message-ID: <20090412155740.GC1948@ma.sigsys.de> On Sat, Apr 11, 2009 at 08:30:42PM -0400, Ken Smith wrote: > That said if there is a bug it's likely to be something fairly difficult > to reproduce (lots of people are running 7.2-PRERELEASE and so far only > two reports of this issue) so it's not a shock for you to have only had > it happen once so far. Odds are it takes a rare sequence of events to > trigger it. I also reported this in Mar 19th with some kgdb-output: http://lists.freebsd.org/pipermail/freebsd-stable/2009-March/048911.html == uname -a == FreeBSD top.uugrn.org 7.1-STABLE FreeBSD 7.1-STABLE #0: Sat Mar 14 20:06:04 CET 2009 root@top.uugrn.org:/usr/obj/usr/src_RELENG_7/sys/TOP i386 == /usr/src/sys/i386/conf/TOP == include GENERIC ident TOP nodevice plip # TCP/IP over parallel == kldstat == Id Refs Address Size Name 1 9 0xc0400000 9ec994 kernel 2 1 0xc0ded000 164e8 geom_mirror.ko 3 1 0xc0e04000 6a45c acpi.ko 4 1 0xc5b9a000 e000 ipfw.ko 5 1 0xc5c94000 4000 logo_saver.ko 6 1 0xc5cf4000 4000 nullfs.ko 7 1 0xc5cfc000 4000 fdescfs.ko == Hardware == The machine ran about 30 months without crashes, at last with 6.4-RELEASE. The storage was on a 3ware with two attached SATA150 drives. Then we replaced the old 3ware + 2xSATA by two onboard-attached SATA300 drives with geom mirror configuration. The new OS is 7.1-STABLE from Mar 14th, which crashed with "vm_page_insert: page already inserted" under i/o load. geom mirror status: Name Status Components mirror/TOPRAID COMPLETE ad4 ad6 atapci1@pci0:0:31:2: class=0x010601 card=0x778015d9 chip=0x27c18086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801GB I/O Controller Hub SATA cc=AHCI' class = mass storage subclass = SATA Mar 14 22:45:37 top kernel: atapci1: port 0x6898-0x689f,0x687c-0x687f,0x6890-0x6897,0x6878-0x687b,0x6880-0x688f mem 0xed000400-0xed0007ff irq 19 at device 31.2 on pci0 Mar 14 22:45:37 top kernel: atapci1: [ITHREAD] Mar 14 22:45:37 top kernel: atapci1: AHCI Version 01.10 controller with 4 ports detected Mar 14 22:45:37 top kernel: ata2: on atapci1 Mar 14 22:45:37 top kernel: ata2: [ITHREAD] Mar 14 22:45:37 top kernel: ata3: on atapci1 Mar 14 22:45:37 top kernel: ata3: [ITHREAD] Mar 14 22:45:37 top kernel: ad4: 381554MB at ata2-master SATA300 Mar 14 22:45:37 top kernel: ad6: 381554MB at ata3-master SATA300 == What happened == The crash happened while cvsupping from local cvsup-mirror, hence there was pretty much read-write i/o on the geom while having some CPU load. After rebooting the geom-mirror was degraded and rebuilded within some couple of hours. I didn't have had any crashes since then but don't want to provoke this since this server is kind of "productive". Maybe those "environmental" information does help someone to spot the cause of this error. Regards Raphael Becker -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- 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/20090412/b679116e/attachment.pgp From rabe at uugrn.org Sun Apr 12 09:10:13 2009 From: rabe at uugrn.org (Raphael Becker) Date: Sun Apr 12 09:50:53 2009 Subject: apache 2.0.63 and php5 In-Reply-To: References: <20090409120815.A0FAB10658D2@hub.freebsd.org> Message-ID: <20090412160949.GD1948@ma.sigsys.de> On Sat, Apr 11, 2009 at 06:37:48PM +0200, xer wrote: > For fix it, i need to make a simple apachectl stop and start, then the php > pages start to works... > > any ideas? When you use apachectl start apache inherits the environment of the user from apachectl, especially PATH. PATH is different for /root and boot. Create a simple php with "" in it and compare the Values for PATH a) after boot b) after restart by apachectl HTH Raphael -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- 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/20090412/6db1faf8/attachment.pgp From bp at barryp.org Sun Apr 12 09:10:55 2009 From: bp at barryp.org (Barry Pederson) Date: Sun Apr 12 09:50:54 2009 Subject: apache 2.0.63 and php5 In-Reply-To: References: <20090409120815.A0FAB10658D2@hub.freebsd.org> Message-ID: <49E20DFB.9000208@barryp.org> xer wrote: > Hello any1 > Strange, i have a apache web 2.0.63 and php5 on a 6.4-STABLE, but every > time i reboot the server, the php pages does not work at all, especially > some self tools made with sh scripts and sudo (tail cat and some php > buttons), refresh of the page does not solve the matter.. > > For fix it, i need to make a simple apachectl stop and start, then the > php pages start to works... > > the logs did tell anything... > > any ideas? > > appreciate your help > TIA I'd guess something like /usr/local/(s)bin not being in the process path when the machine boots, but when you restart it by hand it picks up the path you have in your shell. I've been burned by this a fair number of times, wish there was some good way of having things starting from /usr/local/etc/rc.d to have /usr/local/bin and sbin in the path on a consistent basis. Barry From piotr.smyrak at heron.pl Sun Apr 12 13:49:04 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Sun Apr 12 14:40:55 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090409104532.M16424@heron.pl> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> Message-ID: <20090412151547.M42910@heron.pl> On Thu, 9 Apr 2009 12:57:30 +0200, piotr.smyrak wrote > On Wed, 8 Apr 2009 22:49:25 +0200, Martin wrote > > Am Wed, 8 Apr 2009 21:08:05 +0200 > > schrieb Piotr Smyrak : > > > > I'm overall satisfied with -CURRENT. I've always wanted to > > say that FreeBSD developers do a really great job on the > > -CURRENT branch. It's running very stable and has plenty > > of new features. I know I shouldn't recommend to migrate > > to -CURRENT, but I'm almost sure, it runs much better than > > every -CURRENT I've seen before and sometimes I have the > > impression that it's even nicer than the -STABLE branch. > > Well, I am not scared by -CURRENT at all, but I was > hesitating to upgrade main build since it is after all a > moving target and I would like to keep my main work horse > as much steady as possible. > Sadly this is all I can get out of 8.0-CURRENT as of yesterday. Both with BIOS option for "USB mouse support" on and off. Apr 12 17:25:05 current kernel: usb2_alloc_device:1541: set address 2 failed (USB_ERR_TIMEOUT, ignored) Apr 12 17:25:06 current kernel: usb2_alloc_device:1578: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Apr 12 17:25:08 current kernel: usb2_req_re_enumerate:1510: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Apr 12 17:25:09 current kernel: usb2_req_re_enumerate:1524: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Apr 12 17:25:11 current kernel: usb2_req_re_enumerate:1510: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Apr 12 17:25:12 current kernel: usb2_req_re_enumerate:1524: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Apr 12 17:25:12 current kernel: ugen0.2: <> at usbus0 (disconnected) Apr 12 17:25:12 current kernel: uhub_reattach_port:417: could not allocate new device! -- Piotr Smyrak piotr.smyrak@heron.pl From varga.michal at gmail.com Sun Apr 12 15:12:11 2009 From: varga.michal at gmail.com (Michal Varga) Date: Sun Apr 12 15:57:46 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090412151547.M42910@heron.pl> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> Message-ID: <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> 2009/4/12 : > On Thu, 9 Apr 2009 12:57:30 +0200, piotr.smyrak wrote >> On Wed, 8 Apr 2009 22:49:25 +0200, Martin wrote >> > Am Wed, 8 Apr 2009 21:08:05 +0200 >> > schrieb Piotr Smyrak : >> > >> > I'm overall satisfied with -CURRENT. I've always wanted to >> > say that FreeBSD developers do a really great job on the >> > -CURRENT branch. It's running very stable and has plenty >> > of new features. I know I shouldn't recommend to migrate >> > to -CURRENT, but I'm almost sure, it runs much better than >> > every -CURRENT I've seen before and sometimes I have the >> > impression that it's even nicer than the -STABLE branch. >> >> Well, I am not scared by -CURRENT at all, but I was >> hesitating to upgrade main build since it is after all a >> moving target and I would like to keep my main work horse >> as much steady as possible. >> > Sadly this is all I can get out of 8.0-CURRENT as of yesterday. Both with BIOS option for "USB mouse support" on and > off. > Don't bother with BIOS settings for "USB/keyboard mouse support", they won't help. This is a long standing (bios?) bug for *MANY* Gigabyte motherboards (like this one from 2007: http://lists.freebsd.org/pipermail/freebsd-current/2007-October/078191.html ). A quick workaround is to attach your mouse (or any other USB device that dies during boot - mices, keyboards, card readers, etc. do this with FreeBSD 6/7's usb1 and Gigabyte boards) -after- all USB drivers are loaded and initialized. That always works. Also in one case I know of, having an external powered USB hub 'solved' the issue (if that counts as a fix). Still, having it properly fixed in usb1 drivers wouldn't hurt, of course, but until then, just detach your mouse before boot, plug it after, and you're fine. m. From piotr.smyrak at heron.pl Sun Apr 12 15:58:27 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Sun Apr 12 16:28:03 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> Message-ID: <20090412224548.M53466@heron.pl> On Mon, 13 Apr 2009 00:12:09 +0200, Michal Varga wrote > 2009/4/12 : > > On Thu, 9 Apr 2009 12:57:30 +0200, piotr.smyrak wrote > >> On Wed, 8 Apr 2009 22:49:25 +0200, Martin wrote > >> > Am Wed, 8 Apr 2009 21:08:05 +0200 > >> > schrieb Piotr Smyrak : > >> > > >> > I'm overall satisfied with -CURRENT. I've always wanted to > >> > say that FreeBSD developers do a really great job on the > >> > -CURRENT branch. It's running very stable and has plenty > >> > of new features. I know I shouldn't recommend to migrate > >> > to -CURRENT, but I'm almost sure, it runs much better than > >> > every -CURRENT I've seen before and sometimes I have the > >> > impression that it's even nicer than the -STABLE branch. > >> > >> Well, I am not scared by -CURRENT at all, but I was > >> hesitating to upgrade main build since it is after all a > >> moving target and I would like to keep my main work horse > >> as much steady as possible. > >> > > Sadly this is all I can get out of 8.0-CURRENT as of yesterday. Both with BIOS option for "USB mouse support" on and > > off. > > Don't bother with BIOS settings for "USB/keyboard mouse > support", they won't help. This is a long standing (bios?) > bug for *MANY* Gigabyte motherboards (like this one from 2007: > http://lists.freebsd.org/pipermail/freebsd-current/2007- October/078191.html > ). A quick workaround is to attach your mouse (or any > other USB device that dies during boot - mices, keyboards, > card readers, etc. do this with FreeBSD 6/7's usb1 and > Gigabyte boards) -after- all USB drivers are loaded and > initialized. That always works. Unfortunately not in my case. I have tried this path before without success. > Also in one case I know of, > having an external powered USB hub 'solved' the issue (if > that counts as a fix). > Still, having it properly fixed in usb1 drivers wouldn't > hurt, of course, How do you go about that? I mean fixing a device in usb1.1. -- Piotr Smyrak piotr.smyrak@heron.pl From pyunyh at gmail.com Sun Apr 12 17:33:58 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sun Apr 12 18:23:36 2009 Subject: fxp: stalled transfers In-Reply-To: References: <70ba25e4f1a5e43ab8d99b361235dda2.squirrel@webmail.alpha-tierchen.de> <20090409000427.GD37714@michelle.cdnetworks.co.kr> <2f68678165f20f2e1dae10cb0e63761d.squirrel@webmail.alpha-tierchen.de> <20090409072309.GF37714@michelle.cdnetworks.co.kr> <37a8d3252c3d50682f4fb790e30e09f3.squirrel@webmail.alpha-tierchen.de> <20090410101445.GL37714@michelle.cdnetworks.co.kr> <20090411034613.GA54253@michelle.cdnetworks.co.kr> Message-ID: <20090413003552.GA65724@michelle.cdnetworks.co.kr> On Sat, Apr 11, 2009 at 02:18:37PM +0200, Bjoern Koenig wrote: > Pyun YongHyeon wrote: > > > Ok, I've reproduced it, it seems that it happens when sender and > > receiver has advertised different MSS. Try attached patch and let > > me know how it goes on your setup. > > The patch works. The problem is gone. Thank you. > Thanks. Committed in HEAD(r190982) From varga.michal at gmail.com Sun Apr 12 17:35:39 2009 From: varga.michal at gmail.com (Michal Varga) Date: Sun Apr 12 18:23:54 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090412224548.M53466@heron.pl> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> Message-ID: <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> 2009/4/13 : >> ). A quick workaround is to attach your mouse (or any >> other USB device that dies during boot - mices, keyboards, >> card readers, etc. do this with FreeBSD 6/7's usb1 and >> Gigabyte boards) -after- all USB drivers are loaded and >> initialized. That always works. > > Unfortunately not in my case. I have tried this path before without > success. > Are you sure you plugged the mouse out, then powered the computer on, and plugged the mouse back in only after FreeBSD fully finished booting? To make it perfectly redundantly safe, let's say, plugged mouse in at the login prompt? Because I'm 100% positive (well, me and everyone else with any recent Gigabyte board that I know) that plugging the device in after the USB drivers are fully initialized will prevent the lockup and port timeout, always. >> Still, having it properly fixed in usb1 drivers wouldn't >> hurt, of course, > > How do you go about that? I mean fixing a device in usb1.1. > Well, I guess that would need someone with both FreeBSD USB expertise and some interest in fixing that bug (and probably an access to particular Gigabyte hardware, though as it seems so far, anything recent from Gigabyte and probably AMD6xx/7xx based will do it). Anyway, I tried reporting it back then in 2007, all I got was a bunch of arguments about power source fluctuations, carbon footprints, Windows, PS/2 mices (for christ sake..), and well, being a lazy coward, I gave up. Maybe you'll be luckier this time. m. From brett at lariat.net Sun Apr 12 18:14:09 2009 From: brett at lariat.net (Brett Glass) Date: Sun Apr 12 18:27:58 2009 Subject: Please commit fixes to userland PPP before FreeBSD-7.2 RC1 Message-ID: <200904130036.SAA01943@lariat.net> Please commit the fixes for PRs bin/130159 and bin/131250 prior to FreeBSD RC1. These are critical for the use of userland ppp as a server, especially if it is performing proxy ARP. --Brett Glass From ben at wanderview.com Sun Apr 12 19:43:27 2009 From: ben at wanderview.com (Ben Kelly) Date: Sun Apr 12 20:38:07 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: <49DD1E2E.4030009@quip.cz> References: <49DD1E2E.4030009@quip.cz> Message-ID: On Apr 8, 2009, at 5:59 PM, Miroslav Lachman wrote: > Rsync is used for "snapshots" with --link-dest= (each day has own > directory and all unchenged files are hardlinked to previous day and > I have history of two month back). > Backups are stored on /vol0 with compression enabled. (compression > is enabled on /usr/ports, /usr/src, /var/db/pkg, /vol0) > > # df -hi /vol0/ > Filesystem Size Used Avail Capacity iused ifree %iused > Mounted on > tank/vol0 2.7T 1.3T 1.3T 50% 17939375 11172232 62% / > vol0 > > This backup server is in service from october 2008 with just one > panic (kmem related). After proper loader.conf tuning it is working > well. You might want to look at this commit if you are using rsync --link- dest and getting kmem panics: http://svn.freebsd.org/viewvc/base?view=revision&revision=187460 and the MFC: http://svn.freebsd.org/viewvc/base?view=revision&revision=190837 It seems quite possible to me that kmem panics could be mistakenly attributed to zfs when the name cache is eating up memory. Hope that helps. - Ben From ben at wanderview.com Sun Apr 12 19:43:28 2009 From: ben at wanderview.com (Ben Kelly) Date: Sun Apr 12 20:38:08 2009 Subject: ZFSKnownProblems - needs revision? In-Reply-To: <14989d6e0904080918l78d6e52eja46d7dd258b1659a@mail.gmail.com> References: <14989d6e0904080918l78d6e52eja46d7dd258b1659a@mail.gmail.com> Message-ID: <52250990-6DD5-4FCE-8804-59D0B17D6790@wanderview.com> On Apr 8, 2009, at 12:18 PM, Christian Walther wrote: > I used geli encrypted ZFS including Root on my IBM Thinkpad T31 with > 1GB RAM on a 160GB HDD. (i386 7-STABLE) > Swap on a dedicated slice. Some Z Filesystems used compression > (/usr/ports, /usr/src, for example). > > I encountered several crashes, especially during heavy loads, such as > compiling big ports. Can you clarify what you mean by "crashes"? I have a very similar system here using zfs on geli with compression on a non-SMP i386 machine. The only real difference is that I am running 8-CURRENT. With this setup I've found that I can reliably get the system to go into livelock under load. I posted some analysis and a possible patch in this thread: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=832196+0+archive/2009/freebsd-current/20090322.freebsd-current I'm still investigating what exactly triggers the problem, but it appears that if the ARC cache comes under memory pressure at the wrong time certain zfs transaction threads can enter an interlocked looping pattern. Without proper thread prioritization this can prevent the system from writing data out and thus keep the loop running forever. You can find a better copy of the patch here: http://www.wanderview.com/svn/public/misc/zfs_livelock/zfs_thread_priority.diff I intend to update this with some tweaked priority values, but this should still work fine. Please note, however, that at least one person encountered a panic when they tried this patch. Its not clear if this was due to the thread priority changes interacting with their zfs-on-root configuration or if it was unrelated 8-CURRENT changes. Also, I have not tested the patch against 7-STABLE. I'd be interested to know if it helps with your systems (although it sounds like you abandoned zfs already). Anyway, I hope that helps. - Ben From xernet at hotmail.it Mon Apr 13 01:51:10 2009 From: xernet at hotmail.it (xer) Date: Mon Apr 13 02:11:59 2009 Subject: apache 2.0.63 and php5 In-Reply-To: <20090412160949.GD1948@ma.sigsys.de> References: <20090409120815.A0FAB10658D2@hub.freebsd.org> <20090412160949.GD1948@ma.sigsys.de> Message-ID: Thank you a lot Raphael, you were right! The PATH enviroment are (poor) after a reboot and fixed after apachectl stop and start. How you suggest me to fix it? There is a better way before i will do something wrong? Thanx in advance -------------------------------------------------- From: "Raphael Becker" Sent: Sunday, April 12, 2009 6:09 PM Subject: Re: apache 2.0.63 and php5 When you use apachectl start apache inherits the environment of the user from apachectl, especially PATH. PATH is different for /root and boot. Create a simple php with "" in it and compare the Values for PATH a) after boot b) after restart by apachectl From petefrench at ticketswitch.com Mon Apr 13 02:16:28 2009 From: petefrench at ticketswitch.com (Pete French) Date: Mon Apr 13 03:11:00 2009 Subject: bce and lagg revisited Message-ID: well, I tried to narrow this down a bit by removing lagg from the equation, but the switch requires LACP to be active on those ports so I can't test in isolation unfortunately. Is anyone running 7.2 on a DL360 G5 with working ether ? -pete. From avg at icyb.net.ua Mon Apr 13 04:48:34 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 13 05:42:38 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <20090412155740.GC1948@ma.sigsys.de> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> <1239496242.58897.7.camel@bauer.cse.buffalo.edu> <20090412155740.GC1948@ma.sigsys.de> Message-ID: <49E3268B.3020503@icyb.net.ua> Here's another one: panic: vm_page_insert: page already inserted cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff8018bd85 = db_trace_self_wrapper+0x2a kdb_backtrace() at 0xffffffff802d3717 = kdb_backtrace+0x32 panic() at 0xffffffff802a95ac = panic+0x1b0 vm_page_insert() at 0xffffffff8041aa1c = vm_page_insert+0x2e vm_page_alloc() at 0xffffffff8041af09 = vm_page_alloc+0x3c0 kmem_malloc() at 0xffffffff8040fd98 = kmem_malloc+0x329 page_alloc() at 0xffffffff80407280 = page_alloc+0x18 uma_large_malloc() at 0xffffffff80409b0b = uma_large_malloc+0x4d malloc() at 0xffffffff802999a3 = malloc+0x97 zfs_kmem_alloc() at 0xffffffff807836ed = zfs_kmem_alloc+0x12 zio_data_buf_alloc() at 0xffffffff807cbca3 = zio_data_buf_alloc+0xe arc_get_data_buf() at 0xffffffff807924f3 = arc_get_data_buf+0x28e arc_buf_alloc() at 0xffffffff80792736 = arc_buf_alloc+0xe0 arc_read() at 0xffffffff807938b6 = arc_read+0x2bb dbuf_prefetch() at 0xffffffff80797aa8 = dbuf_prefetch+0x146 dmu_zfetch_dofetch() at 0xffffffff807aa102 = dmu_zfetch_dofetch+0x102 dmu_zfetch() at 0xffffffff807aa80c = dmu_zfetch+0x55a dbuf_read() at 0xffffffff807965c5 = dbuf_read+0x37f dmu_buf_hold_array_by_dnode() at 0xffffffff80798e92 = dmu_buf_hold_array_by_dnode+0x1ed dmu_buf_hold_array() at 0xffffffff8079922c = dmu_buf_hold_array+0x57 dmu_read_uio() at 0xffffffff8079928e = dmu_read_uio+0x3f zfs_freebsd_read() at 0xffffffff807dcb84 = zfs_freebsd_read+0x4b1 VOP_READ_APV() at 0xffffffff8047f7e4 = VOP_READ_APV+0x47 vn_read() at 0xffffffff803392b2 = vn_read+0x275 dofileread() at 0xffffffff802e1246 = dofileread+0x96 kern_preadv() at 0xffffffff802e13d1 = kern_preadv+0x6a pread() at 0xffffffff802e149f = pread+0x51 syscall() at 0xffffffff8044755d = syscall+0x347 Xfast_syscall() at 0xffffffff8042c51b = Xfast_syscall+0xab -- Andriy Gapon From bazerka at beardz.net Mon Apr 13 05:03:35 2009 From: bazerka at beardz.net (Jase Thew) Date: Mon Apr 13 05:51:40 2009 Subject: apache 2.0.63 and php5 In-Reply-To: <49E20DFB.9000208@barryp.org> References: <20090409120815.A0FAB10658D2@hub.freebsd.org> <49E20DFB.9000208@barryp.org> Message-ID: <49E325A1.9000602@beardz.net> Barry Pederson wrote: > > I've been burned by this a fair number of times, wish there was some > good way of having things starting from /usr/local/etc/rc.d to have > /usr/local/bin and sbin in the path on a consistent basis. > > Barry Hi, /etc/profile is the system wide profile for sh shell. So, should you need to do this for all sh scripts ( including /usr/local/etc/rc.d/ scripts), simply add a PATH line to /etc/profile, eg: PATH=/foo/bar:/bar/baz:$PATH; export PATH or PATH=$PATH:/foo/bar:/bar/baz; export PATH depending on whether you want your additional directories to be searched before or after the default path. Regards, Jase. From jwyatt at rwsystems.net Mon Apr 13 05:55:44 2009 From: jwyatt at rwsystems.net (James Wyatt) Date: Mon Apr 13 06:42:10 2009 Subject: watchdog timeout In-Reply-To: <20090410044340.GJ37714@michelle.cdnetworks.co.kr> References: <20090407120032.633E410656D5@hub.freebsd.org> <20090410044340.GJ37714@michelle.cdnetworks.co.kr> Message-ID: <20090410083808.F88691@extra.rwsystems.net> On Fri, 10 Apr 2009, Pyun YongHyeon wrote: > On Wed, Apr 08, 2009 at 10:41:44AM +0200, xer wrote: >> Hello >> I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to >> 6.4-STABLE. >> >> This machine has two 3com nics (one is LAN other is WAN) and i see too much >> "watchdog timeout" on both cards. >> This on/off up/down on cards, affect the interrupt to clients that are >> downloading from apache web server, especially on large files. >> >> -------------------------------------------- >> xer:/root# dmesg >> xl1: watchdog timeout >> xl1: link state changed to DOWN >> xl1: link state changed to UP >> xl1: watchdog timeout >> xl1: link state changed to DOWN >> xl1: link state changed to UP >> xl1: watchdog timeout >> xl1: link state changed to DOWN >> xl1: link state changed to UP >> --------------------------------------------- [ . . . ] >> As you can see, the cards are 3c905C-TX model. >> Someone told me to change drivers, but i cannot understand this advice. >> I got same errors with same cards but with another mainboard, same problem, >> watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. >> >> I don't think that to change nic's pci slots, will solve the problem, i >> think that maybe change the nics would resolve the matter, but i cannot >> access to both FreeBSD phisically, cause the boxes are too far from me >> (about 3500 km). >> >> I'm asking you some advices, and i can i fix this problem. >> p.s. with both 5.4 or 5.5 old kernel, the nics was fine. > > I vaguely remember there were a couple of reports on xl(4) watchdog > timeouts. I'm not sure this came from missing Tx interrupts but > would you try attached patch? > Note, it was generated against HEAD and you should experiment the > attached patch on local box prior to applying to your production > server. Perhaps the case can convey the amount of hair I lost over this: HAVE YOU CHECKED YOUR BIOS AND ONBOARD IO SETTINGS? I have been swapping boards for days for another firewall project and finally figured it out last night. I would get messages like these, depending on the 3rd card used: xl0: Watchdog Timeout pcn0: Watchdog timeout Finally the Sierra Nevada Porter kicked-in and an old idea came back to me: I was running out of interrupts! 1/2 (^_^) The hint was from a combination of having the earlier advice of "set the 'PNP OS' to false" fail and a Tom's Hardware mobo review complaint about 5-slot PCI mobos having IRQ sharing issues. Thanks to you both wherever you are! Finally I went in and disabled all the onboard IO I wasn't using to free up IRQs. Disable the onboard serial if you aren't using them. If you are, then an 8-port board or USB serial, can save COM1 and COM2 IRQs. No video IRQ needed for simple console work. No parallel needed, so saved that one. No floppy nowadays, either. Lots of options for you! Thinking I hadn't had IRQ issues in 15 years or so, it sure reminded me that we still have the legacy x86 IRQ limitations. This has pushed me to thinking more about shifting to trunked VLANs to save ENet ports and make recovery easier. FWIW: I tend to use different cards so the network ports don't "float" to other numbers if one dies. This made the problem worse because the drivers assign IRQs when they load, so it looked like xl0 cards were the issue when 'de*' and 'dc*' worked. Changing slots changed things too! This explains some of what you're experience shows. There is no way I can give back to this list what it's given me in technical support, but if this makes things work for you, then I've given *something* back and it really is a Good Friday - Jy@ From naddy at mips.inka.de Mon Apr 13 07:03:24 2009 From: naddy at mips.inka.de (Christian Weisgerber) Date: Mon Apr 13 07:24:06 2009 Subject: RELENG_7: chatty geom Message-ID: I updated to today's RELENG_7 and geom(4) has become kind of chatty. Near the end of kernel autoconf, I get a line like GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. for each file system. Then during startup, there is a further GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. and finally another GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. for a total of four lines for each file system. Is this spew really helpful? -- Christian "naddy" Weisgerber naddy@mips.inka.de From bp at barryp.org Mon Apr 13 07:15:11 2009 From: bp at barryp.org (Barry Pederson) Date: Mon Apr 13 07:55:27 2009 Subject: apache 2.0.63 and php5 In-Reply-To: <49E325A1.9000602@beardz.net> References: <20090409120815.A0FAB10658D2@hub.freebsd.org> <49E20DFB.9000208@barryp.org> <49E325A1.9000602@beardz.net> Message-ID: <49E348DD.3080700@barryp.org> Jase Thew wrote: > Hi, > > /etc/profile is the system wide profile for sh shell. So, should you > need to do this for all sh scripts ( including /usr/local/etc/rc.d/ > scripts), simply add a PATH line to /etc/profile, eg: > > PATH=/foo/bar:/bar/baz:$PATH; export PATH > > or > > PATH=$PATH:/foo/bar:/bar/baz; export PATH > > depending on whether you want your additional directories to be searched > before or after the default path. > > Regards, > > Jase. Thanks, that's an easy fix. ---- There are some inconsistencies though in the default paths used in various places around the system. It seems that we have (on 7.1 at least) /etc/rc: /sbin:/bin:/usr/sbin:/usr/bin /etc/rc.shutdown: /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin (why no /usr/local/bin ?) /etc/login.conf, /usr/share/skel/dot.profile, /usr/share/skel/dot.cshrc: /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:~/bin Would it make any sense to do something like to add /usr/local/s?bin later in the rc startup as a system default - to make automatic boot-startup behavior more similar to manual service-starting behavior... --- defaults/rc.conf.original 2009-01-19 22:58:58.490989000 -0600 +++ defaults/rc.conf 2009-04-13 09:09:01.680065507 -0500 @@ -51,6 +51,7 @@ populate_var="AUTO" # Set to YES to always (re)populate /var, NO to never cleanvar_enable="YES" # Clean the /var directory local_startup="/usr/local/etc/rc.d" # startup script dirs. +local_startup_path="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin" # Path to use when starting local scripts script_name_sep=" " # Change if your startup scripts' names contain spaces rc_conf_files="/etc/rc.conf /etc/rc.conf.local" --- rc.original 2009-01-19 22:56:22.411969000 -0600 +++ rc 2009-04-13 09:07:16.046050290 -0500 @@ -100,7 +100,10 @@ # case ${local_startup} in [Nn][Oo] | '') ;; -*) find_local_scripts_new ;; +*) find_local_scripts_new + PATH=local_startup_path + export PATH + ;; esac files=`rcorder ${skip} /etc/rc.d/* ${local_rc} 2>/dev/null` ----------------- You could also perhaps pull that $local_startup_path into rc.shutdown Barry From mikej at rogers.com Mon Apr 13 09:50:03 2009 From: mikej at rogers.com (Mike Jakubik) Date: Mon Apr 13 10:17:30 2009 Subject: RELENG_7: chatty geom In-Reply-To: References: Message-ID: <903df7091089b1351bfc99310c128d5c.squirrel@wettoast.dyndns.org> Just an FYI, i am also seeing this on a recent cvsup. Apr 8 14:27:15 iwinbackdb kernel: ACPI APIC Table: Apr 8 14:27:15 iwinbackdb kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs ... Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1a is ufsid/49c7c009b41af703. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1d is ufsid/49c7c015ce349fa2. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1e is ufsid/49c7c00985844142. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1f is ufsid/49c7c0090e1a2de8. Apr 8 14:27:15 iwinbackdb kernel: Trying to mount root from ufs:/dev/mfid0s1a Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c009b41af703 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1a is ufsid/49c7c009b41af703. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c00985844142 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1e is ufsid/49c7c00985844142. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c0090e1a2de8 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1f is ufsid/49c7c0090e1a2de8. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c015ce349fa2 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1d is ufsid/49c7c015ce349fa2. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c009b41af703 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c00985844142 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c0090e1a2de8 removed. Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label ufsid/49c7c015ce349fa2 removed. On Mon, April 13, 2009 9:31 am, Christian Weisgerber wrote: > I updated to today's RELENG_7 and geom(4) has become kind of chatty. > Near the end of kernel autoconf, I get a line like > > GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. > > for each file system. Then during startup, there is a further > > GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. > GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. > > and finally another > > GEOM_LABEL: Label ufsid/49b818dc7f60a735 removed. > > for a total of four lines for each file system. > Is this spew really helpful? > From piotr.smyrak at heron.pl Mon Apr 13 11:38:33 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Mon Apr 13 12:29:58 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> Message-ID: <20090413104255.M2582@heron.pl> On Mon, 13 Apr 2009 02:35:37 +0200, Michal Varga wrote > 2009/4/13 : > >> ). A quick workaround is to attach your mouse (or any > >> other USB device that dies during boot - mices, keyboards, > >> card readers, etc. do this with FreeBSD 6/7's usb1 and > >> Gigabyte boards) -after- all USB drivers are loaded and > >> initialized. That always works. > > > > Unfortunately not in my case. I have tried this path before > > without success. > > Are you sure you plugged the mouse out, then powered the > computer on, and plugged the mouse back in only after > FreeBSD fully finished booting? To make it perfectly > redundantly safe, let's say, plugged mouse in at the login > prompt? Because I'm 100% positive (well, me and everyone > else with any recent Gigabyte board that I know) that > plugging the device in after the USB drivers are fully initialized > will prevent the lockup and port timeout, always. Yes, I'm 100% positive I tried plugging mouse after the boot up had finished. Honestly I am late asking here. I was struggling with this and looking for cases online for more than 2 weeks at least. And I came across your thread from 2007, too. > >> Still, having it properly fixed in usb1 drivers wouldn't > >> hurt, of course, > > > > How do you go about that? I mean fixing a device in usb1.1. > > > Well, I guess that would need someone with both FreeBSD > USB expertise and some interest in fixing that bug (and > probably an access to particular Gigabyte hardware, though > as it seems so far, anything recent from Gigabyte and > probably AMD6xx/7xx based will do it). Anyway, I tried > reporting it back then in 2007, all I got was a bunch of > arguments about power source fluctuations, carbon > footprints, Windows, PS/2 mices (for christ sake..), and > well, being a lazy coward, I gave up. Maybe you'll be > luckier this time. Well, I don't like the idea of giving up. I have been using the OS since the 90's, almost exclusively and that's the first time I got such unresolvable problems. But I need a functional work environment. -- Piotr Smyrak piotr.smyrak@heron.pl From varga.michal at gmail.com Mon Apr 13 12:18:00 2009 From: varga.michal at gmail.com (Michal Varga) Date: Mon Apr 13 12:36:20 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090413104255.M2582@heron.pl> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> <20090413104255.M2582@heron.pl> Message-ID: <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> 2009/4/13 : > Yes, I'm 100% positive I tried plugging mouse after the boot up had > finished. Honestly I am late asking here. I was struggling with > this and looking for cases online for more than 2 weeks at least. > And I came across your thread from 2007, too. > That's really bad. Though closest I can find to your board with freebsd people I know is AMD770+SB600, while your is AMD740G+SB700, all of them dating back to my first AMD690G/V (and maybe prior to that) so far exhibited the same symptoms and the late-plug approach always worked.. Yours would be then the first one that Gigabyte botched even more (congrats). I guess that's one more reason to push on USB guys to finally fix it. While I'm not really sure what to propose, maybe starting a new thread "Attention Gigabyte owners - speak up!" could achieve something. At least I know few of them that never bothered reporting anything, because "somebody will fix it eventually, it's a known issue". Maybe it's not that well known for someone to consider it a priority yet.. From ivoras at freebsd.org Mon Apr 13 16:53:09 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Apr 13 17:21:52 2009 Subject: RELENG_7: chatty geom In-Reply-To: <903df7091089b1351bfc99310c128d5c.squirrel@wettoast.dyndns.org> References: <903df7091089b1351bfc99310c128d5c.squirrel@wettoast.dyndns.org> Message-ID: Mike Jakubik wrote: > Just an FYI, i am also seeing this on a recent cvsup. > Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label for provider mfid0s1a > is ufsid/49c7c009b41af703. Glabel is telling you you can abandon mounting device nodes and can use labels for it. > Apr 8 14:27:15 iwinbackdb kernel: GEOM_LABEL: Label > ufsid/49c7c009b41af703 removed. Now Glabel is complaining you didn't use a label and have used a device node as the mount point :) I'll commit a silencing patch as soon as I get approval for it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090413/5f044fe1/signature.pgp From andymac at bullseye.apana.org.au Tue Apr 14 04:09:11 2009 From: andymac at bullseye.apana.org.au (Andrew MacIntyre) Date: Tue Apr 14 04:47:50 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> <20090413104255.M2582@heron.pl> <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> Message-ID: <49E46AF6.30407@bullseye.andymac.org> Michal Varga wrote: > 2009/4/13 : >> Yes, I'm 100% positive I tried plugging mouse after the boot up had >> finished. Honestly I am late asking here. I was struggling with >> this and looking for cases online for more than 2 weeks at least. >> And I came across your thread from 2007, too. >> > That's really bad. Though closest I can find to your board with > freebsd people I know is AMD770+SB600, while your is AMD740G+SB700, > all of them dating back to my first AMD690G/V (and maybe prior to > that) so far exhibited the same symptoms and the late-plug approach > always worked.. Yours would be then the first one that Gigabyte > botched even more (congrats). I guess that's one more reason to push > on USB guys to finally fix it. If it works with the OP's USB mouse, a USB -> PS/2 (male) adapter might at least get him running provided that the mobo has a PS/2 port... (I know at least some of the Gigabyte 780G boards do, but I don't have any USB mice...) -- ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac@bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac@pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia From varga.michal at gmail.com Tue Apr 14 05:12:24 2009 From: varga.michal at gmail.com (Michal Varga) Date: Tue Apr 14 05:55:23 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <49E46AF6.30407@bullseye.andymac.org> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> <20090413104255.M2582@heron.pl> <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> <49E46AF6.30407@bullseye.andymac.org> Message-ID: <3f1fd1ea0904140512hf9ba4ebw5d3920f064f26998@mail.gmail.com> On Tue, Apr 14, 2009 at 12:52 PM, Andrew MacIntyre wrote: > If it works with the OP's USB mouse, a USB -> PS/2 (male) adapter might > at least get him running provided that the mobo has a PS/2 port... [...] > Guess what :-) http://www.gigabyte.com.tr/images/products/motherboard_productimageback_ga-ma74gm-s2_big.jpg (yes, I know it's not really funny under the circumstances, but still made me chuckle in a way..) m. From oleg at opentransfer.com Tue Apr 14 06:45:11 2009 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Tue Apr 14 07:09:35 2009 Subject: 7.2-PRERELEASE: make process waiting indefinitely Message-ID: <20090414160411.042472seockg0css@webmail.opentransfer.com> Have experienced today strange issue with my fresh RELENG_7 ( sources from yesterday April 13, userland and kernel in sync ) - sometimes some processes stop running without any visible reason. Have seen it twice today during KDE compilation - make process just waiting for something while nothing else compiles or some other way prevents this process from running ( no SIGSTOP performed, no Ctrl-S performed on console). Well it possible related to ( or triggered by ) new ports compilation feature for SMP machines ( most of KDE port marked as MAKE_JOBS_SAFE=yes ) but anyway this stuck process behavior is strange. kill -SIGCONT not helps, but it killable ( Ctrl-C helps at least ) Well some info related to this process: procstat -t 63472 output: PID TID COMM TDNAME CPU PRI STATE WCHAN 63472 100059 make - 1 92 sleep wait procstat -kk 63472 output: PID TID COMM TDNAME KSTACK 63472 100059 make - mi_switch+0x2c8 sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_wait_sig+0x14 _sleep+0x307 kern_wait+0xa36 wait4+0x3b syscall+0x2b3 Xint0x80_syscall+0x20 Some related sysctls output: kern.smp.cpus: 2 kern.smp.disabled: 0 kern.smp.active: 1 uname -msr output: FreeBSD 7.2-PRERELEASE i386 From rabe at uugrn.org Tue Apr 14 07:27:08 2009 From: rabe at uugrn.org (Raphael Becker) Date: Tue Apr 14 08:04:04 2009 Subject: mount_ext2fs in 7-STABLE? Message-ID: <20090414142641.GB71083@ma.sigsys.de> Hi, I noticed that mount_ext2 isn't "connected" to the normal "buildworld" but sys/*/ext2fs seems to. Building and using it from recent RELENG_7 sources works for me (having ext2fs loaded as module in GENERIC). I mounted an ext3 rw, edited grub's menu.lst, wrote and umounted without any problems. It seems recent bugs got pathched in January (http://www.freebsd.org/cgi/query-pr.cgi?pr=131024) Is there a good reason NOT to use ext2fs in 7.2-PRE? BTW: dmesg conseals the Linux-partitions (hda5, hda6 alias /dev/ad0s5 and /dev/ad0s6) residing in a "DOS Extended" partition (/dev/ad0s3). Shouldn't there be a notice about the mapped ad0s5 and ad0s6? BTW2: shouldn't the mapped by label to /dev/ext2fs/foo like /dev/ntfs/bar or /dev/msdosfs/baz ? Regards Raphael -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- 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/20090414/53c89a4d/attachment.pgp From rabe at uugrn.org Tue Apr 14 07:38:00 2009 From: rabe at uugrn.org (Raphael Becker) Date: Tue Apr 14 08:06:49 2009 Subject: RELENG_7: chatty geom In-Reply-To: References: <903df7091089b1351bfc99310c128d5c.squirrel@wettoast.dyndns.org> Message-ID: <20090414143734.GC71083@ma.sigsys.de> On Tue, Apr 14, 2009 at 01:52:27AM +0200, Ivan Voras wrote: [Labels apperaring ad disappearing] > Now Glabel is complaining you didn't use a label and have used a device > node as the mount point :) This isn't new (to me). Having ufs-labelled md-devices brings me those messages since 6.x (since in use geom labels), because the mdconfig rc-scripts don't know about "/dev/md0 == /dev/ufs/FOO" and therefore mount the md-devices directly instead of the labels which makes the labels disappear directly after mdconfig has just "created" them. > I'll commit a silencing patch as soon as I get approval for it. How would one get the ids of ufsid-labels when hidden? glabel list shows only the "active" labels, especially doesn't show the ufsid-label if the device is mounted by its "legacy" devicename (just tried that). dmesg seems the only source of information for that so far. Regards Raphael Becker PS: In gerneral I find it very useful to operate on labels instead of "legacy" device names, especially for S-SATA disks. I even use /dev/ufs/ROOT instead of /dev/ads1a which works perfectly: # dmesg | grep ROOT GEOM_LABEL: Label for provider ad6s1a is ufs/ROOT. Trying to mount root from ufs:/dev/ufs/ROOT -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- 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/20090414/bc081fc4/attachment.pgp From sergey.dyatko at gmail.com Tue Apr 14 08:16:00 2009 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Tue Apr 14 09:01:31 2009 Subject: problem with if_re on RELENG_7 Message-ID: <20090414174527.145c6448@notebook> Hi list, Are there any problems with the if_re ? After upgrade RELENG_7 on my laptop NIC stopped to work:( uname -a: FreeBSD notebook.minsk.domain 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #3: Fri Apr 10 20:38:55 EEST 2009 root@notebook.minsk.domain:/usr/obj/usr/src/sys/tiger-asus-a6m i386 notebook# dhclient re0 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 3 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 12 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 17 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 No DHCPOFFERS received. No working leases in persistent database - sleeping. /var/log/messages: Apr 14 14:52:27 notebook kernel: re0: link state changed to DOWN Apr 14 14:52:29 notebook kernel: re0: link state changed to UP %ifconfig re0 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:1a:92:ca:b3:bc inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 media: Ethernet autoselect (100baseTX ) status: active dmesg: http://tiger.byfly.by/files/dmesg.boot pciconf -lv: http://tiger.byfly.by/files/pciconf.txt kernel config: http://tiger.byfly.by/files/tiger-asus-a6m I also try with enabled INET6 and SCTP options (just in case) but same result. -- wbr, tiger From naddy at mips.inka.de Tue Apr 14 10:35:21 2009 From: naddy at mips.inka.de (Christian Weisgerber) Date: Tue Apr 14 11:07:50 2009 Subject: RELENG_7: chatty geom References: <903df7091089b1351bfc99310c128d5c.squirrel@wettoast.dyndns.org> <20090414143734.GC71083@ma.sigsys.de> Message-ID: Raphael Becker wrote: > How would one get the ids of ufsid-labels when hidden? glabel list shows > only the "active" labels, especially doesn't show the ufsid-label if the > device is mounted by its "legacy" devicename (just tried that). dmesg > seems the only source of information for that so far. dumpfs(8) shows the ID of a UFS file system. GEOM_LABEL: Label for provider ad6s1a is ufsid/49b818dc7f60a735. $ dumpfs ad6s1a magic 19540119 (UFS2) time Mon Apr 13 15:15:27 2009 superblock location 65536 id [ 49b818dc 7f60a735 ] [...] -- Christian "naddy" Weisgerber naddy@mips.inka.de From pluknet at gmail.com Tue Apr 14 11:58:33 2009 From: pluknet at gmail.com (pluknet) Date: Tue Apr 14 12:21:49 2009 Subject: mount_ext2fs in 7-STABLE? In-Reply-To: <20090414142641.GB71083@ma.sigsys.de> References: <20090414142641.GB71083@ma.sigsys.de> Message-ID: 2009/4/14 Raphael Becker : > Hi, > > I noticed that mount_ext2 isn't "connected" to the normal "buildworld" > but sys/*/ext2fs seems to. > > Building and using it from recent RELENG_7 sources works for me (having > ext2fs loaded as module in GENERIC). I mounted an ext3 rw, edited > grub's menu.lst, wrote and umounted without any problems. > > It seems recent bugs got pathched in January > (http://www.freebsd.org/cgi/query-pr.cgi?pr=131024) > > Is there a good reason NOT to use ext2fs in 7.2-PRE? > Looks like src/sbin/Makefile, rev1.164 was disconnected mount_ext2fs from the build to replace with single mount, and mount -t ext2fs is not still implemented. I see ext2fs in remountable_fs_names[], but don't in const char *fs[] in use_mountprog(). -- wbr, pluknet From doconnor at gsoft.com.au Tue Apr 14 19:21:56 2009 From: doconnor at gsoft.com.au (Daniel O'Connor) Date: Tue Apr 14 20:01:30 2009 Subject: RELENG_7: chatty geom In-Reply-To: <20090414143734.GC71083@ma.sigsys.de> References: <20090414143734.GC71083@ma.sigsys.de> Message-ID: <200904151151.50333.doconnor@gsoft.com.au> On Wed, 15 Apr 2009, Raphael Becker wrote: > PS: In gerneral I find it very useful to operate on labels instead of > "legacy" device names, especially for S-SATA disks. I even use > /dev/ufs/ROOT instead of /dev/ads1a which works perfectly: I advise you to preface the label with the hostname. It can be veeery annoying when you plug that disk into another machine and the label conflicts :) (Although now the ID one works I think I will change over to that) -- 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: 187 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090415/28eb436b/attachment.pgp From freebsd at hub.org Tue Apr 14 19:26:15 2009 From: freebsd at hub.org (Marc G. Fournier) Date: Tue Apr 14 20:13:55 2009 Subject: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ... Message-ID: <54F1B57E4F5953BBDCE2F1F3@ganymede.hub.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ... Over the past little while, two of my servers have suddenly started to hang ... servers that up until this started, have been reasonably rock solid ... they are generally within a day of each other for source code, and the hardware on both are pretty much identical (HP Proliant DL360 Servers) ... I have serial console configured on both so that I can do CR ~ ^b to get to DDB ... except, when it hangs, all I get is: "KDB: enter: Break sequence on console" And it hangs there, no prompt. I setup a simple script (see attached) to run every 5 minutes that gathers various pieces of info that I think are pertinent, but most likely don't cover everything ... Whenever this happens, on either machine, vmstat show data *like* (notice the high procs -> w values?): procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us sy id 165 106 2 12699168 33840 3080 38 2 2 3082 1623 0 0 337 36961 4731 18 7 75 64 75 4 12761744 23084 46809 623 65 43 19307 116 334 0 1189 83674 11708 70 20 10 1 68 25 12773980 23068 11036 3003 9 36 4055 116 282 0 1336 78346 14869 56 16 28 0 71 25 12774236 23084 186 769 1 5 18 80 249 0 609 9298 5894 5 5 91 5 90 31 12747296 23352 626 2546 5 104 1147 368 281 0 1536 40945 19980 6 5 90 Where procs -> w just seems to keep rising ... note that the output for vmstat *5 minutes before* shows: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr da0 pa0 in sy cs us sy id 35 121 0 12414692 90552 3080 32 2 1 3090 1403 0 0 337 37022 4730 18 7 75 31 93 0 12314408 62024 36550 414 46 6 34285 27 563 0 916 94851 8813 67 33 0 43 179 0 12270932 23080 24035 101 41 12 13887 36 375 0 766 61969 6945 69 23 7 92 44 0 12265524 119804 2122 2028 1 32 13051 1096092 205 0 558 19460 4561 19 50 32 38 34 0 12330068 89140 30758 103 39 119 37037 2837365 165 0 773 92041 7111 47 53 0 I have one QEMU VPS running on this box, with kqemu running the latest kernel module ... but the other machine experiencing the same issue is only running FreeBSD jails ... Both servers are running SCHED_4BSD, if that matters any ... ? I'm at a loss as to what to look at / for next ... pointers would be greatly appreciated ... I have the various output files that the script generates available if anyone thinks they would be useful ... thank you ... Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknlRcMACgkQ4QvfyHIvDvNmIgCfSWdT9gug6VCjYM1VVMuv1UkN K28AoK298b6mxEeiddu4BAH0+IpkRsti =q6lD -----END PGP SIGNATURE----- -------------- next part -------------- Skipped content of type multipart/mixed From pyunyh at gmail.com Tue Apr 14 21:12:54 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Apr 14 21:29:17 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090414174527.145c6448@notebook> References: <20090414174527.145c6448@notebook> Message-ID: <20090415041516.GF65724@michelle.cdnetworks.co.kr> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. Dyatko wrote: > Hi list, > > Are there any problems with the if_re ? > After upgrade RELENG_7 on my laptop NIC stopped to work:( > Would you let me know what was the last good working revision of if_re.c on your box? > uname -a: > FreeBSD notebook.minsk.domain 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #3: > Fri Apr 10 20:38:55 EEST 2009 > root@notebook.minsk.domain:/usr/obj/usr/src/sys/tiger-asus-a6m i386 > > notebook# dhclient re0 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 3 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 12 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 17 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 5 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > /var/log/messages: > Apr 14 14:52:27 notebook kernel: re0: link state changed to DOWN > Apr 14 14:52:29 notebook kernel: re0: link state changed to UP > > > %ifconfig re0 > re0: flags=8843 metric 0 mtu > 1500 > options=389b > ether 00:1a:92:ca:b3:bc inet 0.0.0.0 netmask 0xff000000 broadcast > 255.255.255.255 media: Ethernet autoselect (100baseTX ) > status: active > > dmesg: http://tiger.byfly.by/files/dmesg.boot > pciconf -lv: http://tiger.byfly.by/files/pciconf.txt > kernel config: http://tiger.byfly.by/files/tiger-asus-a6m > > I also try with enabled INET6 and SCTP options (just in case) but same > result. > > -- > wbr, tiger From petefrench at ticketswitch.com Tue Apr 14 22:34:25 2009 From: petefrench at ticketswitch.com (Pete French) Date: Tue Apr 14 23:12:54 2009 Subject: bce + lagg not working on STABLE Message-ID: I found a machine wityh identical hardware that wasn't using lagg, and have tested there to see if bce on it's own works. It does. So noew I am wondering if... a) Does something in the new bce changes stop it working ith lagg? b) Is there something broken in lagg indepeendent of bce? c) Is my config slightly wrong, but that didnt show up until now? Can someone remind me when the bce chnages went into STABLE so I can try a 'before' /'after' test to see if a) is true ? cheers, -pete. From sergey.dyatko at gmail.com Wed Apr 15 00:05:00 2009 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Wed Apr 15 00:37:39 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090415041516.GF65724@michelle.cdnetworks.co.kr> References: <20090414174527.145c6448@notebook> <20090415041516.GF65724@michelle.cdnetworks.co.kr> Message-ID: <20090415100456.55bbe358@tiger.minsk.domain> On Wed, 15 Apr 2009 13:15:16 +0900 Pyun YongHyeon wrote: PY> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. Dyatko wrote: PY> > Hi list, PY> > PY> > Are there any problems with the if_re ? PY> > After upgrade RELENG_7 on my laptop NIC stopped to work:( PY> > PY> PY> Would you let me know what was the last good working revision of PY> if_re.c on your box? PY> revision 189945 work fine for me. -- wbr, tiger From pyunyh at gmail.com Wed Apr 15 00:39:21 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Apr 15 01:04:30 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090415100456.55bbe358@tiger.minsk.domain> References: <20090414174527.145c6448@notebook> <20090415041516.GF65724@michelle.cdnetworks.co.kr> <20090415100456.55bbe358@tiger.minsk.domain> Message-ID: <20090415074144.GH65724@michelle.cdnetworks.co.kr> On Wed, Apr 15, 2009 at 10:04:56AM +0300, Sergey V. Dyatko wrote: > On Wed, 15 Apr 2009 13:15:16 +0900 > Pyun YongHyeon wrote: > > PY> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. Dyatko wrote: > PY> > Hi list, > PY> > > PY> > Are there any problems with the if_re ? > PY> > After upgrade RELENG_7 on my laptop NIC stopped to work:( > PY> > > PY> > PY> Would you let me know what was the last good working revision of > PY> if_re.c on your box? > PY> > > revision 189945 work fine for me. > There are just three commits(r189946, r189947, r190663 after this one. However I have no idea how these can break your controller. Would you check which one broke re(4)? From sergey.dyatko at gmail.com Wed Apr 15 01:43:49 2009 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Wed Apr 15 02:17:11 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090415074144.GH65724@michelle.cdnetworks.co.kr> References: <20090414174527.145c6448@notebook> <20090415041516.GF65724@michelle.cdnetworks.co.kr> <20090415100456.55bbe358@tiger.minsk.domain> <20090415074144.GH65724@michelle.cdnetworks.co.kr> Message-ID: <20090415114343.6a72784d@tiger.minsk.domain> ? Wed, 15 Apr 2009 16:41:44 +0900 Pyun YongHyeon ?????: PY> On Wed, Apr 15, 2009 at 10:04:56AM +0300, Sergey V. Dyatko wrote: PY> > On Wed, 15 Apr 2009 13:15:16 +0900 PY> > Pyun YongHyeon wrote: PY> > PY> > PY> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. Dyatko PY> > PY> wrote: PY> > PY> > Hi list, PY> > PY> > PY> > PY> > Are there any problems with the if_re ? PY> > PY> > After upgrade RELENG_7 on my laptop NIC stopped to work:( PY> > PY> > PY> > PY> PY> > PY> Would you let me know what was the last good working revision PY> > PY> of if_re.c on your box? PY> > PY> PY> > PY> > revision 189945 work fine for me. PY> > PY> PY> There are just three commits(r189946, r189947, r190663 after this PY> one. However I have no idea how these can break your controller. PY> Would you check which one broke re(4)? I have tried to reduce the revision number starting with r190663. result below: http://tiger.byfly.by/files/step-by-step.txt -- wbr, tiger From ronald-freebsd8 at klop.yi.org Wed Apr 15 02:14:43 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Wed Apr 15 02:42:18 2009 Subject: 7.2-PRERELEASE: make process waiting indefinitely In-Reply-To: <20090414160411.042472seockg0css@webmail.opentransfer.com> References: <20090414160411.042472seockg0css@webmail.opentransfer.com> Message-ID: On Tue, 14 Apr 2009 15:04:11 +0200, Oleg V. Nauman wrote: > > Have experienced today strange issue with my fresh RELENG_7 ( sources > from yesterday April 13, userland and kernel in sync ) - sometimes some > processes stop running without any visible reason. Have seen it twice > today during KDE compilation - make process just waiting for something > while nothing else compiles or some other way prevents this process from > running ( no SIGSTOP performed, no Ctrl-S performed on console). Well it > possible related to ( or triggered by ) new ports compilation feature > for SMP machines ( most of KDE port marked as MAKE_JOBS_SAFE=yes ) but > anyway this stuck process behavior is strange. kill -SIGCONT not helps, > but it killable ( Ctrl-C helps at least ) > Well some info related to this process: > procstat -t 63472 output: > > PID TID COMM TDNAME CPU PRI STATE WCHAN > 63472 100059 make - 1 92 sleep wait > > procstat -kk 63472 output: > > PID TID COMM TDNAME KSTACK > 63472 100059 make - mi_switch+0x2c8 > sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_wait_sig+0x14 > _sleep+0x307 kern_wait+0xa36 wait4+0x3b syscall+0x2b3 > Xint0x80_syscall+0x20 > > Some related sysctls output: > > kern.smp.cpus: 2 > kern.smp.disabled: 0 > kern.smp.active: 1 > > uname -msr output: > FreeBSD 7.2-PRERELEASE i386 It sounds like http://www.mail-archive.com/freebsd-stable@freebsd.org/msg102628.html . There are some tips in that mailthread about debugging it. Ronald. From pyunyh at gmail.com Wed Apr 15 03:27:59 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Apr 15 03:46:34 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090415114343.6a72784d@tiger.minsk.domain> References: <20090414174527.145c6448@notebook> <20090415041516.GF65724@michelle.cdnetworks.co.kr> <20090415100456.55bbe358@tiger.minsk.domain> <20090415074144.GH65724@michelle.cdnetworks.co.kr> <20090415114343.6a72784d@tiger.minsk.domain> Message-ID: <20090415103026.GJ65724@michelle.cdnetworks.co.kr> On Wed, Apr 15, 2009 at 11:43:43AM +0300, Sergey V. Dyatko wrote: > ? Wed, 15 Apr 2009 16:41:44 +0900 > Pyun YongHyeon ?????: > > PY> On Wed, Apr 15, 2009 at 10:04:56AM +0300, Sergey V. Dyatko wrote: > PY> > On Wed, 15 Apr 2009 13:15:16 +0900 > PY> > Pyun YongHyeon wrote: > PY> > > PY> > PY> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. Dyatko > PY> > PY> wrote: > PY> > PY> > Hi list, > PY> > PY> > > PY> > PY> > Are there any problems with the if_re ? > PY> > PY> > After upgrade RELENG_7 on my laptop NIC stopped to work:( > PY> > PY> > > PY> > PY> > PY> > PY> Would you let me know what was the last good working revision > PY> > PY> of if_re.c on your box? > PY> > PY> > PY> > > PY> > revision 189945 work fine for me. > PY> > > PY> > PY> There are just three commits(r189946, r189947, r190663 after this > PY> one. However I have no idea how these can break your controller. > PY> Would you check which one broke re(4)? > I have tried to reduce the revision number starting with r190663. > result below: http://tiger.byfly.by/files/step-by-step.txt > Ok, would you set a tunable hw.re.msi_disable="1" with kenv(1) before loading re(4) and send me re(4) related dmesg output? (Make sure to back out all changes made in if_re.c before testing) From sergey.dyatko at gmail.com Wed Apr 15 03:38:09 2009 From: sergey.dyatko at gmail.com (Sergey V. Dyatko) Date: Wed Apr 15 03:49:44 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090415103026.GJ65724@michelle.cdnetworks.co.kr> References: <20090414174527.145c6448@notebook> <20090415041516.GF65724@michelle.cdnetworks.co.kr> <20090415100456.55bbe358@tiger.minsk.domain> <20090415074144.GH65724@michelle.cdnetworks.co.kr> <20090415114343.6a72784d@tiger.minsk.domain> <20090415103026.GJ65724@michelle.cdnetworks.co.kr> Message-ID: <20090415133820.42211c98@notebook> ? Wed, 15 Apr 2009 19:30:26 +0900 Pyun YongHyeon ?????: PY> On Wed, Apr 15, 2009 at 11:43:43AM +0300, Sergey V. Dyatko wrote: PY> > ? Wed, 15 Apr 2009 16:41:44 +0900 PY> > Pyun YongHyeon ?????: PY> > PY> > PY> On Wed, Apr 15, 2009 at 10:04:56AM +0300, Sergey V. Dyatko PY> > PY> wrote: PY> > PY> > On Wed, 15 Apr 2009 13:15:16 +0900 PY> > PY> > Pyun YongHyeon wrote: PY> > PY> > PY> > PY> > PY> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. PY> > PY> > PY> Dyatko wrote: PY> > PY> > PY> > Hi list, PY> > PY> > PY> > PY> > PY> > PY> > Are there any problems with the if_re ? PY> > PY> > PY> > After upgrade RELENG_7 on my laptop NIC stopped to PY> > PY> > PY> > work:( PY> > PY> > PY> > PY> > PY> > PY> PY> > PY> > PY> Would you let me know what was the last good working PY> > PY> > PY> revision of if_re.c on your box? PY> > PY> > PY> PY> > PY> > PY> > PY> > revision 189945 work fine for me. PY> > PY> > PY> > PY> PY> > PY> There are just three commits(r189946, r189947, r190663 after PY> > PY> this one. However I have no idea how these can break your PY> > PY> controller. Would you check which one broke re(4)? PY> > I have tried to reduce the revision number starting with r190663. PY> > result below: http://tiger.byfly.by/files/step-by-step.txt PY> > PY> PY> Ok, would you set a tunable hw.re.msi_disable="1" with kenv(1) PY> before loading re(4) and send me re(4) related dmesg output? PY> (Make sure to back out all changes made in if_re.c before PY> testing) notebook# kenv hw.re.msi_disable 1 notebook# kldload ./if_re.ko notebook# cat /var/log/messages Apr 15 13:33:56 notebook kernel: re0: port 0xd800-0xd8ff mem 0xdf6ff000-0xdf6fffff irq 17 at device 0.0 on pci2 Apr 15 13:33:56 notebook kernel: re0: turning off MSI enable bit. Apr 15 13:33:56 notebook kernel: re0: Chip rev. 0x38000000 Apr 15 13:33:56 notebook kernel: re0: MAC rev. 0x00000000 Apr 15 13:33:56 notebook kernel: re0: Ethernet address: 00:1a:92:ca:b3:bc Apr 15 13:33:56 notebook kernel: re0: [FILTER] Apr 15 13:33:56 notebook kernel: miibus0: on re0 Apr 15 13:33:56 notebook kernel: rgephy0: PHY 1 on miibus0 Apr 15 13:33:56 notebook kernel: rgephy0: interface> 10baseT,10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto Apr 15 13:33:56 notebook kernel: re0: link state changed to DOWN Apr 15 13:33:58 notebook kernel: re0: link state changed to UP notebook# dhclient re0 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 DHCPOFFER from 192.168.9.1 DHCPREQUEST on re0 to 255.255.255.255 port 67 DHCPACK from 192.168.9.1 bound to 192.168.9.103 -- renewal in 7200 seconds. -- wbr, tiger From pyunyh at gmail.com Wed Apr 15 03:46:06 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Apr 15 04:16:59 2009 Subject: problem with if_re on RELENG_7 In-Reply-To: <20090415133820.42211c98@notebook> References: <20090414174527.145c6448@notebook> <20090415041516.GF65724@michelle.cdnetworks.co.kr> <20090415100456.55bbe358@tiger.minsk.domain> <20090415074144.GH65724@michelle.cdnetworks.co.kr> <20090415114343.6a72784d@tiger.minsk.domain> <20090415103026.GJ65724@michelle.cdnetworks.co.kr> <20090415133820.42211c98@notebook> Message-ID: <20090415104831.GK65724@michelle.cdnetworks.co.kr> On Wed, Apr 15, 2009 at 01:38:20PM +0300, Sergey V. Dyatko wrote: > ? Wed, 15 Apr 2009 19:30:26 +0900 > Pyun YongHyeon ?????: > > PY> On Wed, Apr 15, 2009 at 11:43:43AM +0300, Sergey V. Dyatko wrote: > PY> > ? Wed, 15 Apr 2009 16:41:44 +0900 > PY> > Pyun YongHyeon ?????: > PY> > > PY> > PY> On Wed, Apr 15, 2009 at 10:04:56AM +0300, Sergey V. Dyatko > PY> > PY> wrote: > PY> > PY> > On Wed, 15 Apr 2009 13:15:16 +0900 > PY> > PY> > Pyun YongHyeon wrote: > PY> > PY> > > PY> > PY> > PY> On Tue, Apr 14, 2009 at 05:45:27PM +0300, Sergey V. > PY> > PY> > PY> Dyatko wrote: > PY> > PY> > PY> > Hi list, > PY> > PY> > PY> > > PY> > PY> > PY> > Are there any problems with the if_re ? > PY> > PY> > PY> > After upgrade RELENG_7 on my laptop NIC stopped to > PY> > PY> > PY> > work:( > PY> > PY> > PY> > > PY> > PY> > PY> > PY> > PY> > PY> Would you let me know what was the last good working > PY> > PY> > PY> revision of if_re.c on your box? > PY> > PY> > PY> > PY> > PY> > > PY> > PY> > revision 189945 work fine for me. > PY> > PY> > > PY> > PY> > PY> > PY> There are just three commits(r189946, r189947, r190663 after > PY> > PY> this one. However I have no idea how these can break your > PY> > PY> controller. Would you check which one broke re(4)? > PY> > I have tried to reduce the revision number starting with r190663. > PY> > result below: http://tiger.byfly.by/files/step-by-step.txt > PY> > > PY> > PY> Ok, would you set a tunable hw.re.msi_disable="1" with kenv(1) > PY> before loading re(4) and send me re(4) related dmesg output? > PY> (Make sure to back out all changes made in if_re.c before > PY> testing) > > notebook# kenv hw.re.msi_disable > 1 > notebook# kldload ./if_re.ko > notebook# cat /var/log/messages > Apr 15 13:33:56 notebook kernel: re0: 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe Gigabit Ethernet> > port 0xd800-0xd8ff mem 0xdf6ff000-0xdf6fffff irq 17 at device 0.0 on > pci2 > Apr 15 13:33:56 notebook kernel: re0: turning off MSI enable bit. > Apr 15 13:33:56 notebook kernel: re0: Chip rev. 0x38000000 > Apr 15 13:33:56 notebook kernel: re0: MAC rev. 0x00000000 > Apr 15 13:33:56 notebook kernel: re0: Ethernet address: > 00:1a:92:ca:b3:bc > Apr 15 13:33:56 notebook kernel: re0: [FILTER] > Apr 15 13:33:56 notebook kernel: miibus0: on re0 > Apr 15 13:33:56 notebook kernel: rgephy0: interface> PHY 1 on miibus0 Apr 15 13:33:56 notebook kernel: rgephy0: > interface> 10baseT,10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > Apr 15 13:33:56 notebook kernel: re0: link state changed to DOWN > Apr 15 13:33:58 notebook kernel: re0: link state changed to UP > notebook# dhclient re0 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 > DHCPDISCOVER on re0 to 255.255.255.255 port 67 interval 7 > DHCPOFFER from 192.168.9.1 > DHCPREQUEST on re0 to 255.255.255.255 port 67 > DHCPACK from 192.168.9.1 > bound to 192.168.9.103 -- renewal in 7200 seconds. > Ok, I think you've have to live without MSI. I'll rearrange re(4) to disable MSI on RTL8168 SPIN2 device. Thanks for testing! From oleg at opentransfer.com Wed Apr 15 05:03:08 2009 From: oleg at opentransfer.com (Oleg V. Nauman) Date: Wed Apr 15 05:47:54 2009 Subject: 7.2-PRERELEASE: make process waiting indefinitely In-Reply-To: References: <20090414160411.042472seockg0css@webmail.opentransfer.com> Message-ID: <20090415150249.19ecof1i8gkos8kg@webmail.opentransfer.com> Quoting Ronald Klop : > On Tue, 14 Apr 2009 15:04:11 +0200, Oleg V. Nauman > wrote: > >> >> Have experienced today strange issue with my fresh RELENG_7 ( >> sources from yesterday April 13, userland and kernel in sync ) - >> sometimes some processes stop running without any visible reason. >> Have seen it twice today during KDE compilation - make process just >> waiting for something while nothing else compiles or some other >> way prevents this process from running ( no SIGSTOP performed, no >> Ctrl-S performed on console). Well it possible related to ( or >> triggered by ) new ports compilation feature for SMP machines ( >> most of KDE port marked as MAKE_JOBS_SAFE=yes ) but anyway this >> stuck process behavior is strange. kill -SIGCONT not helps, but it >> killable ( Ctrl-C helps at least ) >> Well some info related to this process: >> procstat -t 63472 output: >> >> PID TID COMM TDNAME CPU PRI STATE WCHAN >> 63472 100059 make - 1 92 sleep wait >> >> procstat -kk 63472 output: >> >> PID TID COMM TDNAME KSTACK >> 63472 100059 make - mi_switch+0x2c8 >> sleepq_switch+0xd9 sleepq_catch_signals+0x239 sleepq_wait_sig+0x14 >> _sleep+0x307 kern_wait+0xa36 wait4+0x3b syscall+0x2b3 >> Xint0x80_syscall+0x20 >> >> Some related sysctls output: >> >> kern.smp.cpus: 2 >> kern.smp.disabled: 0 >> kern.smp.active: 1 >> >> uname -msr output: >> FreeBSD 7.2-PRERELEASE i386 > > It sounds like > http://www.mail-archive.com/freebsd-stable@freebsd.org/msg102628.html . > There are some tips in that mailthread about debugging it. Thank you. Looks like it was the same issue. > > Ronald. From petefrench at ticketswitch.com Wed Apr 15 09:39:07 2009 From: petefrench at ticketswitch.com (Pete French) Date: Wed Apr 15 10:23:44 2009 Subject: bce + lagg not working on STABLE Message-ID: Ok, I have now confirmed that the commit mentioned in this email: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=187270+0+archive/2009/freebsd-stable/20090405.freebsd-stable ss what breaks lagg using bce on my machines. I did submit a PR about this, but I can't find it yes (though I dont know how long such things take to show up, this was only ten minutes ago or so). Code before the commit works, code after doesn,t and it is only the bce files which have changed. I wrote "stable" in the subject line, but this is present in the 7.2 prerelease stuff, and is a regression from 7.1 (a fairly major one in my opinion, but I realise ever problem is importnat to the person it affects). cheers, -pete. From donotreply at fortunedouble.com Wed Apr 15 15:19:21 2009 From: donotreply at fortunedouble.com (Royal Vegas) Date: Wed Apr 15 15:39:52 2009 Subject: =?windows-1252?q?=801200_Welcome_Offer?= Message-ID: If you cannot see this email properly, follow this link: http://www.c-f-1.com/HTMLEmail.aspx?emailid=UE%3dAyGTB9dQoQdsbVX4CltF3X [http://www.c-f-1.com/d.aspx?e=UE%3dAyGTB9dQoQdsbVX4CltF3X&c=2&linkID=1301824] What could you do with EUR1,200? Royal Vegas is offering you this insane amount of cash, on the house, so join in and start enjoying one of the best gaming experiences around. Come and get your ?1,200 booster on the House. [http://www.c-f-1.com/d.aspx?e=UE%3dAyGTB9dQoQdsbVX4CltF3X&c=2&linkID=1301825] Want to know more about this offer? Find out more about our exciting games, promotions, tournaments and monster progressive jackpots by visiting this link [http://www.c-f-1.com/d.aspx?e=UE%3dAyGTB9dQoQdsbVX4CltF3X&c=2&linkID=1301826] Royal Vegas is a high-quality, award-winning online casino and is part of the Fortune Lounge Group of online gaming products. Players get to enjoy all the thrills, excitement and rewards of Vegas at the touch of a button. This communication was brought to you by a third party and not by Royal Vegas as advertised. Your privacy is important to us. If you feel you received this communication by mistake, or if you wish to alter your mail status, please visit this link [http://www.c-f-1.com/d.aspx?e=UE%3dAyGTB9dQoQdsbVX4CltF3X&c=2&linkID=1301827]. Report any mail abuse to flcc@mailcomplaint.com [mailto:flcc@mailcomplaint.com] From alexs at analytic.mv.ru Wed Apr 15 22:44:40 2009 From: alexs at analytic.mv.ru (=?utf-8?B?0JrQu9GO0YfQvdC40LrQvtCyINCQLtChLg==?=) Date: Wed Apr 15 23:27:58 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <20090416051720.GD71235@mail.analytic.mv.ru> * Danny Braniss [2009-04-08 15:54:25 +0300]: > > > Garance A Drosihn wrote: > > > Some friends of mine are looking at the new "DroboPro", which makes a > > > lot of disk space available via iSCSI (in addition to firewire 800), > > > and they were wondering how well iSCSI works with FreeBSD. I haven't > > > paid attention to iSCSI support. Is there anyone using it heavily > > > for disk-storage under FreeBSD? Has there been much changed for > > > iSCSI support in the 8.x branch, or is 7.x support working fine? > > > > I suppose you are interested in the "client" (initiator) side of iSCSI > > support. It hasn't changed much between 7.x and 8.x but there are > > apparently some announcements of a newer version: > > > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html > > > > I can't find any more information on it. > the latest is in: > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz I install this to freebsd 7.1 i386. Target from zfs solaris 10 sparc64 iscontrol -c /etc/iscsi.conf -n myiscsi Get loop creating da devices kill iscontrol don`t work, kill -9 don`t work too. kldunload -f iscsi_initiator.ko fail system after 10-15 second (celeron 2000) What can i do to get more info or solve problem? -- alexs From alexs at analytic.mv.ru Wed Apr 15 22:44:41 2009 From: alexs at analytic.mv.ru (=?utf-8?B?0JrQu9GO0YfQvdC40LrQvtCyINCQLtChLg==?=) Date: Wed Apr 15 23:28:01 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <20090411144222.GE83095@mail.analytic.mv.ru> * Danny Braniss [2009-04-08 15:54:25 +0300]: > > > Garance A Drosihn wrote: > > > Some friends of mine are looking at the new "DroboPro", which makes a > > > lot of disk space available via iSCSI (in addition to firewire 800), > > > and they were wondering how well iSCSI works with FreeBSD. I haven't > > > paid attention to iSCSI support. Is there anyone using it heavily > > > for disk-storage under FreeBSD? Has there been much changed for > > > iSCSI support in the 8.x branch, or is 7.x support working fine? > > > > I suppose you are interested in the "client" (initiator) side of iSCSI > > support. It hasn't changed much between 7.x and 8.x but there are > > apparently some announcements of a newer version: > > > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html > > > > I can't find any more information on it. > the latest is in: > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz I install this to freebsd 7.1 i386. Target from zfs solaris 10 sparc64 iscontrol -c /etc/iscsi.conf -n myiscsi Get loop creating ad devices kill iscontrol don`t work, kill -9 don`t work too. kldunload -f iscsi_initiator.ko fail system after 10-15 second (celeron 2000) What can i do to get more info or solve problem? -- alexs From alexs at analytic.mv.ru Wed Apr 15 22:44:43 2009 From: alexs at analytic.mv.ru (=?utf-8?B?0JrQu9GO0YfQvdC40LrQvtCyINCQLtChLg==?=) Date: Wed Apr 15 23:28:02 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: References: Message-ID: <20090411123456.GA81937@mail.analytic.mv.ru> * Danny Braniss [2009-04-08 15:54:25 +0300]: > > > Garance A Drosihn wrote: > > > Some friends of mine are looking at the new "DroboPro", which makes a > > > lot of disk space available via iSCSI (in addition to firewire 800), > > > and they were wondering how well iSCSI works with FreeBSD. I haven't > > > paid attention to iSCSI support. Is there anyone using it heavily > > > for disk-storage under FreeBSD? Has there been much changed for > > > iSCSI support in the 8.x branch, or is 7.x support working fine? > > > > I suppose you are interested in the "client" (initiator) side of iSCSI > > support. It hasn't changed much between 7.x and 8.x but there are > > apparently some announcements of a newer version: > > > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html > > > > I can't find any more information on it. > the latest is in: > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz I install this to freebsd 7.1 i386. Target from zfs solaris 10 sparc64 iscontrol -c /etc/iscsi.conf -n myiscsi Get loop creating ad devices kill iscontrol don`t work, kill -9 don`t work too. kldunload -f iscsi_initiator.ko fail system after 10-15 second (celeron 2000) What can i do to get more info or solve problem? -- alexs From sobomax at FreeBSD.org Thu Apr 16 00:45:53 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Thu Apr 16 01:15:23 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 Message-ID: <49E6DB39.8080103@FreeBSD.org> Sam, What is the reason to have this option in the kernel config if kernel compilation fails when this option is enabled? It also affects 7-stable. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' -Maxim From sobomax at sippysoft.com Thu Apr 16 00:45:54 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu Apr 16 01:15:35 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 Message-ID: <49E6DB25.2010601@sippysoft.com> Sam, What is the reason to have this option in the kernel config if kernel compilation fails when this option is enabled? It also affects 7-stable. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -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 -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 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has no member named 'rs_flags' /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has no member named 'rs_flags' -Maxim From sonic2000gr at gmail.com Thu Apr 16 01:41:10 2009 From: sonic2000gr at gmail.com (Manolis Kiagias) Date: Thu Apr 16 01:58:12 2009 Subject: problems with 7.2, vm_page_insert: page already inserted Message-ID: <49E6E786.6060504@gmail.com> (Sorry for not directly replying to the thread, just subscribed to the list) I've had this panic myself, on a system that would run 7.1 for weeks at a time. More importantly, this is a very standard desktop system with very simple apps for casual use: FreeBSD atlantis.dyndns.org 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #21: Sat Apr 4 08:30:04 EEST 2009 root@atlantis.dyndns.org:/usr/obj/usr/src/sys/ATLANTIS i386 As far as modules are concerned: Id Refs Address Size Name 1 13 0xc0400000 624a64 kernel 2 1 0xc0a25000 5464 vesa.ko 3 1 0xc0a2b000 6a45c acpi.ko 4 1 0xc55bc000 22000 linux.ko 5 1 0xc5f4d000 9000 i915.ko 6 1 0xc5f56000 13000 drm.ko sound, snd_hda and geom_journal are built into the kernel (I am journaling /usr and /var). There are no other differences (other than some removed drivers) from GENERIC The latest incident was this morning, while I was opening firefox. The system has 2G of memory and 1G swap and it never runs out of memory (it won't even touch swap most of the times) as it is just a standard desktop (XFCE). Unfortunately I don't have a dump at this point, but as the system runs 24/7 I'll make sure to get one if it happens next time. I've nuked and reinstalled all packages from scratch today. From dennis.melentyev at gmail.com Thu Apr 16 02:38:05 2009 From: dennis.melentyev at gmail.com (Dennis Melentyev) Date: Thu Apr 16 03:05:18 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49E6DB25.2010601@sippysoft.com> References: <49E6DB25.2010601@sippysoft.com> Message-ID: Hi Max, Also seen that. Fixed with careful merging on my kernel config with GENERIC one. There are additional strings involved: device ath device ath_rate_sample After adding the later one (and probably, the first one too (?)) compiled ok. Could be worth an entry in UPDATING and/or explicitly added to GENERIC. /dennis 2009/4/16 Maxim Sobolev : > Sam, > > What is the reason to have this option in the kernel config if kernel > compilation fails when this option is enabled? It also affects 7-stable. > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing ?-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 -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 -mcmodel=kernel -mno-red-zone > ?-mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow ?-msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -Werror > ?/usr/src/sys/dev/ath/if_ath.c -I/usr/src/sys/dev/ath > /usr/src/sys/dev/ath/if_ath.c: In function 'ath_rx_tap': > /usr/src/sys/dev/ath/if_ath.c:3414: error: 'const struct ath_rx_status' has > no member named 'rs_flags' > /usr/src/sys/dev/ath/if_ath.c:3416: error: 'const struct ath_rx_status' has > no member named 'rs_flags' > > -Maxim > _______________________________________________ > 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" > -- Dennis Melentyev From sobomax at sippysoft.com Thu Apr 16 02:51:35 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Thu Apr 16 03:08:39 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: References: <49E6DB25.2010601@sippysoft.com> Message-ID: <49E6FF8F.4070403@sippysoft.com> Dennis Melentyev wrote: > Could be worth an entry in UPDATING and/or explicitly added to GENERIC. My point is that if the option is mandatory for compiling ath(4) driver, then there is no point in having this option in the first place. -Maxim From dennis.melentyev at gmail.com Thu Apr 16 05:05:58 2009 From: dennis.melentyev at gmail.com (Dennis Melentyev) Date: Thu Apr 16 05:35:07 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49E6FF8F.4070403@sippysoft.com> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> Message-ID: 2009/4/16 Maxim Sobolev : > Dennis Melentyev wrote: >> >> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. > > My point is that if the option is mandatory for compiling ath(4) driver, > then there is no point in having this option in the first place. Well, fair. +1 from me :). -- Dennis Melentyev From sam at freebsd.org Thu Apr 16 09:46:27 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Apr 16 10:33:35 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49E6FF8F.4070403@sippysoft.com> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> Message-ID: <49E75992.7050106@freebsd.org> Maxim Sobolev wrote: > Dennis Melentyev wrote: >> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. > > My point is that if the option is mandatory for compiling ath(4) > driver, then there is no point in having this option in the first place. There is an entry in UPDATING and it is present in GENERIC (in HEAD, I didn't commit the changes to RELENG_7 so don't know). When the ath hal src code was imported the meaning of the ath_hal device changed because internal configuration done during binary builds was now exposed. Specifically, the need for AH_SUPPORT_5416 to enable support for the extended descriptor format used by the 11n parts. If you read ath_hal(4) this should be clear--if not please help improve the manual page. However, it so happens you can eliminate this option because config will generate a #define you can use instead to identify the configuration of "ath_hal" but this magic is undocumented and I didn't know about it until ru recently told me. I suggested he go ahead and fixup the code to use it but haven't seen anything. I don't have time right now. Sam From pmc at citylink.dinoex.sub.org Thu Apr 16 10:43:53 2009 From: pmc at citylink.dinoex.sub.org (Peter Much) Date: Thu Apr 16 11:13:45 2009 Subject: Rel 7 works better (was: "s/stable/broken/g") References: <200803261404.00508.fjwcash@gmail.com> Message-ID: Hi folks, hi Freddy, sorry, missed Your note last year this time. aka Freddie Cash schrieb mit Datum Wed, 26 Mar 2008 14:04:00 -0700 in m2n.fbsd.stable: |On March 22, 2008 01:01 pm Peter Much wrote: |> Both of them were running Release 5.5, and they were doing all that |> is needed, and I was perfectly happy with this. |> [...] |> So I upgraded the first computer to Release 6.3. The outcome was | |A safer (recommended?) upgrade process when crossing major versions (ie |5.x to 6.x) is to upgrade to the latest release of the "old" version, |then to the .0 release of the "new" version, then to the latest release |of the "new" version. | |So from 5.x to 5.5, then from 5.5 to 6.0, then from 6.0 to 6.3. | |The devs take great pains to make the transition from "latest X.x to Y.0" |simple and mostly fool-proof, and the transition from "Y.x to Y.z" simple |and mostly fool-proof. But there are no guarantees when going from X.x |to Y.z. Maybe its good idea to replay Your message just now, as it seems good advice. I'm just strolling by to tell that I went from 6.3 to 7.2 just now with my testmachine, and this time it was a really good experience so far. I have now only one strangeness, which I think not worth a bug report, but I would invite You to think about what that can be. I post a separate note with better subject for that. And yes, I did ignore the good advice again, but 7.2 isn't officially out for release yet, so there are no safety belts anyway. rgds, PMc From pmc at citylink.dinoex.sub.org Thu Apr 16 11:13:24 2009 From: pmc at citylink.dinoex.sub.org (Peter Much) Date: Thu Apr 16 11:53:39 2009 Subject: 7.2-PRE: switch virtual console drops crazy characters into X Message-ID: Hi all, to make a long story short, I got trapped in the Xorg upgrade problems (concerning HAL etc.) that were widely reported during January. After reading thru the material I figured out that there are not much chances that somebody would take effort and fix these things for a 6.3 Release. So I decided to give it a try with the 7.2-PRERELASE. And, well, after recompiling all the stuff, the problems seem gone so far. Only one strange thing has appeared: Every time I switch from X to a virtual console and back, I get some characters dropped into my command-line in the X window, and have to delete them with the backspace key. These characters read: ^[[20~ Now this is exactly the escape sequence on the F9 key (where the X runs), if it were pressed without Ctrl-Alt. That shouldn't happen. Now the funny thing is: this does only happen when booting the GENERIC kernel. When I boot my normal custom made kernel, it does not happen. Now this is strange. Usually the GENERIC kernel should show the least unexpected behaviour. Alright, there are lots and lots of devices left out of my custom kernel, but I do not see anything that could have to do with VT switching. I do not quite understand it. But I am also not so much bored that I would start trying out options and building kernels so to find what makes this happen. So, if anyone experiences the similar thing, and is enough annoyed to do something about it, I will happily send a diff from my kernel configs. rgds, PMc From piotr.smyrak at heron.pl Thu Apr 16 12:36:35 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Thu Apr 16 13:10:27 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <49E46AF6.30407@bullseye.andymac.org> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> <20090413104255.M2582@heron.pl> <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> <49E46AF6.30407@bullseye.andymac.org> Message-ID: <20090416193532.M10966@heron.pl> On Tue, 14 Apr 2009 20:52:38 +1000, Andrew MacIntyre wrote > Michal Varga wrote: > > 2009/4/13 : > >> Yes, I'm 100% positive I tried plugging mouse after the boot up had > >> finished. Honestly I am late asking here. I was struggling with > >> this and looking for cases online for more than 2 weeks at least. > >> And I came across your thread from 2007, too. > >> > > That's really bad. Though closest I can find to your board with > > freebsd people I know is AMD770+SB600, while your is AMD740G+SB700, > > all of them dating back to my first AMD690G/V (and maybe prior to > > that) so far exhibited the same symptoms and the late-plug approach > > always worked.. Yours would be then the first one that Gigabyte > > botched even more (congrats). I guess that's one more reason to push > > on USB guys to finally fix it. > > If it works with the OP's USB mouse, a USB -> PS/2 (male) > adapter might at least get him running provided that the > mobo has a PS/2 port... (I know at least some of the > Gigabyte 780G boards do, but I don't have any USB mice...) Yes, it has a PS/2 port but it is occupied by my keyboard. Anyway, I have found a workaround for my problems. To keep USB working in FreeBSD, all, even this built-in smallest hub in my keyboard, have to be disconnected. Then when boot finishes I can connect devices, and my mice are detected. Well, this is annoying since it means diving under the desk every time computer boots, but at least I can work now. -- Piotr Smyrak piotr.smyrak@heron.pl From bruce at cran.org.uk Thu Apr 16 14:14:23 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Thu Apr 16 14:38:46 2009 Subject: 7.2-PRE: switch virtual console drops crazy characters into X In-Reply-To: References: Message-ID: <20090416221414.2947e7ed@gluon.draftnet> On Thu, 16 Apr 2009 16:32:09 GMT pmc@citylink.dinoex.sub.org (Peter Much) wrote: > Every time I switch from X to a virtual console and back, I get > some characters dropped into my command-line in the X window, > and have to delete them with the backspace key. > These characters read: ^[[20~ > > Now this is exactly the escape sequence on the F9 key (where the X > runs), if it were pressed without Ctrl-Alt. That shouldn't happen. > > Now the funny thing is: this does only happen when booting the > GENERIC kernel. When I boot my normal custom made kernel, it > does not happen. > Now this is strange. Usually the GENERIC kernel should show the > least unexpected behaviour. > > Alright, there are lots and lots of devices left out of my custom > kernel, but I do not see anything that could have to do with > VT switching. I do not quite understand it. But I am also not > so much bored that I would start trying out options and building > kernels so to find what makes this happen. > > So, if anyone experiences the similar thing, and is enough annoyed > to do something about it, I will happily send a diff from my > kernel configs. I'm also seeing the same issue, but I'm running a custom kernel. I've attached a diff from GENERIC. -- Bruce Cran -------------- next part -------------- A non-text attachment was scrubbed... Name: GENERIC.diff Type: text/x-patch Size: 11564 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090416/e403fdee/GENERIC.bin From msch at snafu.de Thu Apr 16 14:43:25 2009 From: msch at snafu.de (Matthias Schuendehuette) Date: Thu Apr 16 15:29:17 2009 Subject: NFS-Locking problems Message-ID: Hello, I want to remind to the kern/132934-PR. Are we the only ones that have Problems with the NFS-Locking? I try every week the latest -STABLE code but nothing changed so far. Are there any chances to get NFS-locking working with HP-UX 11.11 machines again with 7.2-RELEASE? Greetings - Matthew -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) From db at danielbond.org Fri Apr 17 02:32:35 2009 From: db at danielbond.org (Daniel Bond) Date: Fri Apr 17 03:12:24 2009 Subject: PAM completeness and standardization Message-ID: <34B37CEC-AF7A-48EE-81F5-7B19291F99EF@danielbond.org> Hi, FreeBSD has excellent PAM-support, except for the passwd-command. The passwd-command gained PAM support quite a while ago, but there is a test preventing it from working with PAM. There have been outstanding PR's for this minor issue for years now, I think it's time this one got fixed. People find it frustrating that they can't change their passwords (LDAP etc), like they can in a normal PAM-based system. I'd be happy to fix whatever needs to be done, but I need to know why it's not been fixed / what needs to be done for it to be accepted by the community. -DB. From bsam at ipt.ru Fri Apr 17 04:18:09 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Fri Apr 17 04:56:47 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <20090416193532.M10966@heron.pl> (piotr smyrak's message of "Thu, 16 Apr 2009 21:36:30 +0200") References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> <20090413104255.M2582@heron.pl> <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> <49E46AF6.30407@bullseye.andymac.org> <20090416193532.M10966@heron.pl> Message-ID: <03599684@serv3.int.kfs.ru> On Thu, 16 Apr 2009 21:36:30 +0200 piotr.smyrak@heron.pl wrote: > On Tue, 14 Apr 2009 20:52:38 +1000, Andrew MacIntyre wrote > > Michal Varga wrote: > > > 2009/4/13 : > > >> Yes, I'm 100% positive I tried plugging mouse after the boot up had > > >> finished. Honestly I am late asking here. I was struggling with > > >> this and looking for cases online for more than 2 weeks at least. > > >> And I came across your thread from 2007, too. > > >> > > > That's really bad. Though closest I can find to your board with > > > freebsd people I know is AMD770+SB600, while your is AMD740G+SB700, > > > all of them dating back to my first AMD690G/V (and maybe prior to > > > that) so far exhibited the same symptoms and the late-plug approach > > > always worked.. Yours would be then the first one that Gigabyte > > > botched even more (congrats). I guess that's one more reason to push > > > on USB guys to finally fix it. > > > > If it works with the OP's USB mouse, a USB -> PS/2 (male) > > adapter might at least get him running provided that the > > mobo has a PS/2 port... (I know at least some of the > > Gigabyte 780G boards do, but I don't have any USB mice...) > Yes, it has a PS/2 port but it is occupied by my keyboard. Anyway, I have found a > workaround for my problems. To keep USB working in FreeBSD, all, even this > built-in smallest hub in my keyboard, have to be disconnected. Then when boot > finishes I can connect devices, and my mice are detected. Well, this is annoying > since it means diving under the desk every time computer boots, but at least I can > work now. I had similar problems until I played with USB options at BIOS. Something like "Legacy USB support", "Detect USB mouse at startup", etc. You may give it a try. HTH & WBR -- bsam From danny at cs.huji.ac.il Fri Apr 17 06:40:31 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Fri Apr 17 07:28:41 2009 Subject: FreeBSD and iSCSI for disks. In-Reply-To: Your message of Thu, 16 Apr 2009 09:17:20 +0400 . Message-ID: > * Danny Braniss [2009-04-08 15:54:25 +0300]: > > > > > > Garance A Drosihn wrote: > > > > Some friends of mine are looking at the new "DroboPro", which makes a > > > > lot of disk space available via iSCSI (in addition to firewire 800), > > > > and they were wondering how well iSCSI works with FreeBSD. I haven't > > > > paid attention to iSCSI support. Is there anyone using it heavily > > > > for disk-storage under FreeBSD? Has there been much changed for > > > > iSCSI support in the 8.x branch, or is 7.x support working fine? > > > > > > I suppose you are interested in the "client" (initiator) side of iSCSI > > > support. It hasn't changed much between 7.x and 8.x but there are > > > apparently some announcements of a newer version: > > > > > > http://lists.freebsd.org/pipermail/freebsd-scsi/2009-March/003834.html > > > > > > I can't find any more information on it. > > the latest is in: > > http://www.cs.huji.ac.il/~danny/ftp/freebsd/iscsi-2.1.1.tar.gz > > I install this to freebsd 7.1 i386. > Target from zfs solaris 10 sparc64 > > > iscontrol -c /etc/iscsi.conf -n myiscsi > Get loop creating da devices > kill iscontrol don`t work, kill -9 don`t work too. > kldunload -f iscsi_initiator.ko > fail system after 10-15 second (celeron 2000) > > What can i do to get more info or solve problem? there is a newer version at: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.1.2.tar.gz you will need to recompile iscontrol too. run tcpdump -s512 port 3260 -w iscsi.cap and send me the iscsi.cap. cheers, danny From kensmith at cse.Buffalo.EDU Fri Apr 17 10:15:09 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Fri Apr 17 10:40:50 2009 Subject: FreeBSD 7.2-RC1 Available Message-ID: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> The first of two planned Release Candidates for the FreeBSD 7.2-RELEASE cycle is now available. Testing of some of the recent work would be particularly appreciated. This includes: - bce(4) updated (there is a report that lagg(4) does not work after the update, fixing that may need to be done as an Errata Notice after the release) - testing of the threading libraries - amr(4) should be fixed A fix for the "vm_page_insert: page already inserted" panics has been committed to RELENG_7_1 this morning so it missed the 7.2-RC1 builds. If you wind up being hit by that you can try a normal source based update to the current state of RELENG_7_1 and that problem should go away. We have slipped by two days at this point but otherwise are on track with the target release schedule which is here: http://www.freebsd.org/releases/7.2R/schedule.html We continue to watch for problems both on the mailing lists and in Gnats but at this point we know of nothing we consider show-stopper calibre. Unless something that bad does surface as a result of 7.2-RC1 testing we should be sticking to the schedule. The ISO images and FTP install trees are available on the FreeBSD Mirror sites. Using the primary site as an example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.2/ where ${arch} is one of amd64 i386, ia64, pc98, or sparc64. The builds for powerpc are still in progress, it should become available in a day or two. Checksums for the ISO images are at the bottom of this message. The amd64 and i386 sets include a *preliminary* set of packages. If you would like to do a source-based update to 7.2-RC1 from an already installed machine you can update your tree to RELENG_7_1 using normal cvsup/csup methods. 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, or 7.2-BETA1 can upgrade as follows: # freebsd-update upgrade -r 7.2-RC1 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. # 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, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to upgrade to FreeBSD 7.2-RC1, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of "freebsd-update install", in order to handle differences in the system libraries between FreeBSD 6.x and FreeBSD 7.x. Checksums: MD5 (7.2-RC1-amd64-bootonly.iso) = 2e4474ca4924ac589adf600b1d7d7168 MD5 (7.2-RC1-amd64-disc1.iso) = 47e1a823636dec2e8a88e2d4794d87da MD5 (7.2-RC1-amd64-disc2.iso) = 6761b5cf2ac2d8399c28b58ccdddb2a5 MD5 (7.2-RC1-amd64-disc3.iso) = 02c798036ed43f4f346518d584783a72 MD5 (7.2-RC1-amd64-docs.iso) = ece13f382c308ce05f7dfc1aef4d0a62 MD5 (7.2-RC1-amd64-dvd1.iso) = 2a25cc807849fa2987c032c87053c8e9 MD5 (7.2-RC1-amd64-livefs.iso) = fbff690090c9cf3d5cf1b07b6c019b40 MD5 (7.2-RC1-i386-bootonly.iso) = 85783d47f3d03dcdd6859cbe94fa41e2 MD5 (7.2-RC1-i386-disc1.iso) = 4ef516f7fa88ab6a6f67f6fba3e9e86e MD5 (7.2-RC1-i386-disc2.iso) = f5bf94273f64f4e4f968322990bd32eb MD5 (7.2-RC1-i386-disc3.iso) = 634cce798ea17117a009f53e07dadda0 MD5 (7.2-RC1-i386-docs.iso) = 2b019c24576c03c382bd3748baeb473b MD5 (7.2-RC1-i386-dvd1.iso) = ed88046ecae36fd1dd12157534243106 MD5 (7.2-RC1-i386-livefs.iso) = 81637ca4b1668ff44047fe4b6fc71447 MD5 (7.2-RC1-ia64-bootonly.iso) = 414bf45bbbae757dff03acea5484635f MD5 (7.2-RC1-ia64-disc1.iso) = 0f26204eaa8c63a37b34ef0101dcb278 MD5 (7.2-RC1-ia64-disc2.iso) = cc206f814e5da015042485bfe5c30605 MD5 (7.2-RC1-ia64-disc3.iso) = 3888415a65514805546d8ad50cf0f650 MD5 (7.2-RC1-ia64-docs.iso) = 07c5c83f05248f7b7dec7e210e2cbf9e MD5 (7.2-RC1-ia64-livefs.iso) = df5ffb89ae0a5e9aea8cc12a75c0d14a MD5 (7.2-RC1-pc98-bootonly.iso) = b4b0b16bc0afa9ce734d1c4a303fc13c MD5 (7.2-RC1-pc98-disc1.iso) = 33dd272b30bab2f1ad2a3455a177c3b5 MD5 (7.2-RC1-pc98-livefs.iso) = 7ffda81d7d91bb91db202de7c30afadd MD5 (7.2-RC1-sparc64-bootonly.iso) = a220e5318eb10e4ff3b6c783d76a1b28 MD5 (7.2-RC1-sparc64-disc1.iso) = c23469659332723ce600073611497f52 MD5 (7.2-RC1-sparc64-docs.iso) = 96fc98f8ac071a5942fc25fa4ab940eb SHA256 (7.2-RC1-amd64-bootonly.iso) = 9e4786270b12f5fff34e063edbc05b995f2b539c2931a26020153d5e603da9cd SHA256 (7.2-RC1-amd64-disc1.iso) = a4c707c20dc3b0e33ab8bdd5408e03b31481115147643bcd65c49a322b956e68 SHA256 (7.2-RC1-amd64-disc2.iso) = 5fde245f11064c2033bfbf1c40f8c62a1c204a8e0cadc7be2f105823b3c1da16 SHA256 (7.2-RC1-amd64-disc3.iso) = 85858d70199b1705d3e8d8e1770a65c64da63089dc122462a900040833e66479 SHA256 (7.2-RC1-amd64-docs.iso) = 620b57e6db73097755aacf73a2746a2ef70a1bcc3f054813caf95c0a3d8865c2 SHA256 (7.2-RC1-amd64-dvd1.iso) = a24ce789c6f72d1189c70df4982bdc6eb79f5227a4706df0f784b001d30c68e1 SHA256 (7.2-RC1-amd64-livefs.iso) = b2145383bac00cf73a81242dc89ee5c68ccb00c2011e57724e9e786d429b8c23 SHA256 (7.2-RC1-i386-bootonly.iso) = 1b56aca9f0647b2f321524326240f17b05cc9a4f5e83adde7f71a09b9b9d01ab SHA256 (7.2-RC1-i386-disc1.iso) = d96d670172fbc7405e529e9c47f4aa72c96c704bbdf8fac9ac77662f17f49888 SHA256 (7.2-RC1-i386-disc2.iso) = b38cb7d48e8aae2fff142f8165c62fa61290d08e3fa75ce9c3fd035871f6e40c SHA256 (7.2-RC1-i386-disc3.iso) = bb4d39117210d9884fcef3c9936d1be72db06544ae696607ca9c082c6b4fdda7 SHA256 (7.2-RC1-i386-docs.iso) = 8b84fc57e727f7b085a909965c5d765bb23dea9828fff706e55068e997f8719c SHA256 (7.2-RC1-i386-dvd1.iso) = aca822e5b4dd096f4a7d51dc912cddca005ce0983853e99cf12506b40403289e SHA256 (7.2-RC1-i386-livefs.iso) = dddef3930777027de4b2faf09be83560266efe7b47e51ed62a630b683ca1acdb SHA256 (7.2-RC1-ia64-bootonly.iso) = 7187248fc225b020177301fdc435e52b73a41ee0ab145aa0249770a1386fa891 SHA256 (7.2-RC1-ia64-disc1.iso) = fac482f9bf93a0fac8f6ab89d8a89b047e4861a023b1f14d8067163560795c36 SHA256 (7.2-RC1-ia64-disc2.iso) = 95e182b4c0c6f7e8179e1fe568c0804a9f352c83beeea330a0664849071ff4d6 SHA256 (7.2-RC1-ia64-disc3.iso) = 2100105114f26421d90bf13d6d1f417b837835102635c8af5048baf3867b1da0 SHA256 (7.2-RC1-ia64-docs.iso) = 615cf4afdf30dbaa3fef58f0a15ff769502e1316b70c7657efd3d2af4d402385 SHA256 (7.2-RC1-ia64-livefs.iso) = 92f06a856143dd59108de23d23dcc49c04ee136d461630f1754d2455ebde0343 SHA256 (7.2-RC1-pc98-bootonly.iso) = 2dd4b6e61f7ed9d99cac26ed9ab3203d4ae7a2086cc4ac9efbe7260e8c94592e SHA256 (7.2-RC1-pc98-disc1.iso) = 31de5cc66e5df83668d54ef8a1bc28cc85f4763bb955a516fb214333b2182062 SHA256 (7.2-RC1-pc98-livefs.iso) = 256a80ae9b19b3c766f1200e2ef127c7d6be5b2064e24b882c239746147cf922 SHA256 (7.2-RC1-sparc64-bootonly.iso) = cd3575d870d85dce59a7c964798569c5b2b135a15697f914490260c90d854e25 SHA256 (7.2-RC1-sparc64-disc1.iso) = f6464477b96eb79cac87fab60a311af2b59d7d685247e44beef24b32b45ce761 SHA256 (7.2-RC1-sparc64-docs.iso) = 51c97434a16c30169083a6220f7b6493c1404cacf7abb412caba24e88b686a21 -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090417/0547e465/attachment.pgp From alan.l.cox at gmail.com Fri Apr 17 10:33:52 2009 From: alan.l.cox at gmail.com (Alan Cox) Date: Fri Apr 17 11:23:49 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <49E6E786.6060504@gmail.com> References: <49E6E786.6060504@gmail.com> Message-ID: I believe that this problem is now resolved. A recent MFC overlooked one critical change. That change was MFCed a few minutes ago. So, please update your kernel. Regards, Alan From sonic2000gr at gmail.com Fri Apr 17 10:48:17 2009 From: sonic2000gr at gmail.com (Manolis Kiagias) Date: Fri Apr 17 11:33:03 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: References: <49E6E786.6060504@gmail.com> Message-ID: <49E8C0DC.2020502@gmail.com> Alan Cox wrote: > I believe that this problem is now resolved. A recent MFC overlooked > one critical change. That change was MFCed a few minutes ago. So, > please update your kernel. > > Regards, > Alan > > I will csup and rebuild tonight, thanks for sharing! From jon at web-tricks.net Fri Apr 17 11:16:41 2009 From: jon at web-tricks.net (Jon Holstrom) Date: Fri Apr 17 11:41:20 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> Message-ID: Got it on Vista Home 64 & VMware server Two CPU's & two gigs of ram. Works grate so far. fast too On Fri, 17 Apr 2009 13:15:03 -0400 Ken Smith wrote: > > The first of two planned Release Candidates for the > FreeBSD 7.2-RELEASE > cycle is now available. Testing of some of the recent > work would be > particularly appreciated. This includes: > > - bce(4) updated (there is a report that lagg(4) does > not work after the update, fixing that may need to be > done as an Errata Notice after the release) > - testing of the threading libraries > - amr(4) should be fixed > > A fix for the "vm_page_insert: page already inserted" > panics has been > committed to RELENG_7_1 this morning so it missed the > 7.2-RC1 builds. > If you wind up being hit by that you can try a normal > source based > update to the current state of RELENG_7_1 and that > problem should go > away. > > We have slipped by two days at this point but otherwise > are on track > with the target release schedule which is here: > > http://www.freebsd.org/releases/7.2R/schedule.html > > We continue to watch for problems both on the mailing > lists and in Gnats > but at this point we know of nothing we consider > show-stopper calibre. > Unless something that bad does surface as a result of > 7.2-RC1 testing we > should be sticking to the schedule. > > The ISO images and FTP install trees are available on the > FreeBSD Mirror > sites. Using the primary site as an example: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.2/ > > where ${arch} is one of amd64 i386, ia64, pc98, or > sparc64. The > builds for powerpc are still in progress, it should > become available > in a day or two. > > Checksums for the ISO images are at the bottom of this > message. The > amd64 and i386 sets include a *preliminary* set of > packages. > > If you would like to do a source-based update to 7.2-RC1 > from an > already installed machine you can update your tree to > RELENG_7_1 using > normal cvsup/csup methods. > > 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, or 7.2-BETA1 can upgrade as follows: > > # freebsd-update upgrade -r 7.2-RC1 > > 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. > > # 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, and the system needs to be rebooted > again: > > # freebsd-update install > # shutdown -r now > > Users of earlier FreeBSD releases (FreeBSD 6.x) can also > use freebsd-update to > upgrade to FreeBSD 7.2-RC1, but will be prompted to > rebuild all third-party > applications (e.g., anything installed from the ports > tree) after the second > invocation of "freebsd-update install", in order to > handle differences in the > system libraries between FreeBSD 6.x and FreeBSD 7.x. > > > Checksums: > > MD5 (7.2-RC1-amd64-bootonly.iso) = > 2e4474ca4924ac589adf600b1d7d7168 > MD5 (7.2-RC1-amd64-disc1.iso) = > 47e1a823636dec2e8a88e2d4794d87da > MD5 (7.2-RC1-amd64-disc2.iso) = > 6761b5cf2ac2d8399c28b58ccdddb2a5 > MD5 (7.2-RC1-amd64-disc3.iso) = > 02c798036ed43f4f346518d584783a72 > MD5 (7.2-RC1-amd64-docs.iso) = > ece13f382c308ce05f7dfc1aef4d0a62 > MD5 (7.2-RC1-amd64-dvd1.iso) = > 2a25cc807849fa2987c032c87053c8e9 > MD5 (7.2-RC1-amd64-livefs.iso) = > fbff690090c9cf3d5cf1b07b6c019b40 > > MD5 (7.2-RC1-i386-bootonly.iso) = > 85783d47f3d03dcdd6859cbe94fa41e2 > MD5 (7.2-RC1-i386-disc1.iso) = > 4ef516f7fa88ab6a6f67f6fba3e9e86e > MD5 (7.2-RC1-i386-disc2.iso) = > f5bf94273f64f4e4f968322990bd32eb > MD5 (7.2-RC1-i386-disc3.iso) = > 634cce798ea17117a009f53e07dadda0 > MD5 (7.2-RC1-i386-docs.iso) = > 2b019c24576c03c382bd3748baeb473b > MD5 (7.2-RC1-i386-dvd1.iso) = > ed88046ecae36fd1dd12157534243106 > MD5 (7.2-RC1-i386-livefs.iso) = > 81637ca4b1668ff44047fe4b6fc71447 > > MD5 (7.2-RC1-ia64-bootonly.iso) = > 414bf45bbbae757dff03acea5484635f > MD5 (7.2-RC1-ia64-disc1.iso) = > 0f26204eaa8c63a37b34ef0101dcb278 > MD5 (7.2-RC1-ia64-disc2.iso) = > cc206f814e5da015042485bfe5c30605 > MD5 (7.2-RC1-ia64-disc3.iso) = > 3888415a65514805546d8ad50cf0f650 > MD5 (7.2-RC1-ia64-docs.iso) = > 07c5c83f05248f7b7dec7e210e2cbf9e > MD5 (7.2-RC1-ia64-livefs.iso) = > df5ffb89ae0a5e9aea8cc12a75c0d14a > > MD5 (7.2-RC1-pc98-bootonly.iso) = > b4b0b16bc0afa9ce734d1c4a303fc13c > MD5 (7.2-RC1-pc98-disc1.iso) = > 33dd272b30bab2f1ad2a3455a177c3b5 > MD5 (7.2-RC1-pc98-livefs.iso) = > 7ffda81d7d91bb91db202de7c30afadd > > MD5 (7.2-RC1-sparc64-bootonly.iso) = > a220e5318eb10e4ff3b6c783d76a1b28 > MD5 (7.2-RC1-sparc64-disc1.iso) = > c23469659332723ce600073611497f52 > MD5 (7.2-RC1-sparc64-docs.iso) = > 96fc98f8ac071a5942fc25fa4ab940eb > > SHA256 (7.2-RC1-amd64-bootonly.iso) = > 9e4786270b12f5fff34e063edbc05b995f2b539c2931a26020153d5e603da9cd > SHA256 (7.2-RC1-amd64-disc1.iso) = > a4c707c20dc3b0e33ab8bdd5408e03b31481115147643bcd65c49a322b956e68 > SHA256 (7.2-RC1-amd64-disc2.iso) = > 5fde245f11064c2033bfbf1c40f8c62a1c204a8e0cadc7be2f105823b3c1da16 > SHA256 (7.2-RC1-amd64-disc3.iso) = > 85858d70199b1705d3e8d8e1770a65c64da63089dc122462a900040833e66479 > SHA256 (7.2-RC1-amd64-docs.iso) = > 620b57e6db73097755aacf73a2746a2ef70a1bcc3f054813caf95c0a3d8865c2 > SHA256 (7.2-RC1-amd64-dvd1.iso) = > a24ce789c6f72d1189c70df4982bdc6eb79f5227a4706df0f784b001d30c68e1 > SHA256 (7.2-RC1-amd64-livefs.iso) = > b2145383bac00cf73a81242dc89ee5c68ccb00c2011e57724e9e786d429b8c23 > > SHA256 (7.2-RC1-i386-bootonly.iso) = > 1b56aca9f0647b2f321524326240f17b05cc9a4f5e83adde7f71a09b9b9d01ab > SHA256 (7.2-RC1-i386-disc1.iso) = > d96d670172fbc7405e529e9c47f4aa72c96c704bbdf8fac9ac77662f17f49888 > SHA256 (7.2-RC1-i386-disc2.iso) = > b38cb7d48e8aae2fff142f8165c62fa61290d08e3fa75ce9c3fd035871f6e40c > SHA256 (7.2-RC1-i386-disc3.iso) = > bb4d39117210d9884fcef3c9936d1be72db06544ae696607ca9c082c6b4fdda7 > SHA256 (7.2-RC1-i386-docs.iso) = > 8b84fc57e727f7b085a909965c5d765bb23dea9828fff706e55068e997f8719c > SHA256 (7.2-RC1-i386-dvd1.iso) = > aca822e5b4dd096f4a7d51dc912cddca005ce0983853e99cf12506b40403289e > SHA256 (7.2-RC1-i386-livefs.iso) = > dddef3930777027de4b2faf09be83560266efe7b47e51ed62a630b683ca1acdb > > SHA256 (7.2-RC1-ia64-bootonly.iso) = > 7187248fc225b020177301fdc435e52b73a41ee0ab145aa0249770a1386fa891 > SHA256 (7.2-RC1-ia64-disc1.iso) = > fac482f9bf93a0fac8f6ab89d8a89b047e4861a023b1f14d8067163560795c36 > SHA256 (7.2-RC1-ia64-disc2.iso) = > 95e182b4c0c6f7e8179e1fe568c0804a9f352c83beeea330a0664849071ff4d6 > SHA256 (7.2-RC1-ia64-disc3.iso) = > 2100105114f26421d90bf13d6d1f417b837835102635c8af5048baf3867b1da0 > SHA256 (7.2-RC1-ia64-docs.iso) = > 615cf4afdf30dbaa3fef58f0a15ff769502e1316b70c7657efd3d2af4d402385 > SHA256 (7.2-RC1-ia64-livefs.iso) = > 92f06a856143dd59108de23d23dcc49c04ee136d461630f1754d2455ebde0343 > > SHA256 (7.2-RC1-pc98-bootonly.iso) = > 2dd4b6e61f7ed9d99cac26ed9ab3203d4ae7a2086cc4ac9efbe7260e8c94592e > SHA256 (7.2-RC1-pc98-disc1.iso) = > 31de5cc66e5df83668d54ef8a1bc28cc85f4763bb955a516fb214333b2182062 > SHA256 (7.2-RC1-pc98-livefs.iso) = > 256a80ae9b19b3c766f1200e2ef127c7d6be5b2064e24b882c239746147cf922 > > SHA256 (7.2-RC1-sparc64-bootonly.iso) = > cd3575d870d85dce59a7c964798569c5b2b135a15697f914490260c90d854e25 > SHA256 (7.2-RC1-sparc64-disc1.iso) = > f6464477b96eb79cac87fab60a311af2b59d7d685247e44beef24b32b45ce761 > SHA256 (7.2-RC1-sparc64-docs.iso) = > 51c97434a16c30169083a6220f7b6493c1404cacf7abb412caba24e88b686a21 > > -- > Ken Smith > - From there to here, from here to | > kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > From ohartman at mail.zedat.fu-berlin.de Fri Apr 17 12:00:45 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Fri Apr 17 12:45:03 2009 Subject: PAM completeness and standardization In-Reply-To: <34B37CEC-AF7A-48EE-81F5-7B19291F99EF@danielbond.org> References: <34B37CEC-AF7A-48EE-81F5-7B19291F99EF@danielbond.org> Message-ID: <49E8CDD5.1020602@mail.zedat.fu-berlin.de> Daniel Bond wrote: > Hi, > > > FreeBSD has excellent PAM-support, except for the passwd-command. The > passwd-command gained PAM support quite a while ago, but there is a > test preventing it from working with PAM. > There have been outstanding PR's for this minor issue for years now, I > think it's time this one got fixed. People find it frustrating that > they can't change their passwords (LDAP etc), like they can in a > normal PAM-based system. > > > I'd be happy to fix whatever needs to be done, but I need to know why > it's not been fixed / what needs to be done for it to be accepted by > the community. > > > -DB. > _______________________________________________ > 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" Good luck. In this case I gave up. There are patches floating around the web and I suggest patching passw.c manually. For two years now, I do this to come along with our OpenLDAP environment. Regards, Oliver From smithi at nimnet.asn.au Fri Apr 17 12:21:49 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Fri Apr 17 12:52:29 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49DF7A1C.90009@root.org> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> Message-ID: <20090418043432.O34434@sola.nimnet.asn.au> On Fri, 10 Apr 2009, Nate Lawson wrote: > Andriy Gapon wrote: > > on 09/04/2009 23:24 Stephen Clark said the following: > >> Is there a reason it doesn't send and event like Linux that can be acted > >> upon by user space other > >> than signaling init? I like to have a message written in > >> /var/log/messages that someone pressed > >> the powerbutton. > > > > I think that for all suspend states except S5 userland is notified via > > devd mechanism and potentially can veto the suspend. S5 (soft-off) is > > coded to start shutdown immediately. You can try to hack on > > acpi_ReqSleepState in sys/dev/acpica/acpi.c. > > > > I am not sure what is the reason for this special behavior of S5. But I > > like it, because it sometimes allows me to perform semi-clean shutdown > > when X goes crazy. But I also see when it could be useful to have S5 > > request go through userland. So this could be configurable. > > The reason for userland getting into the loop in the first place was to > run programs to shut down devices and reinit them after resume. This > isn't necessary in the shutdown case because init already sends a > signal, as you mention. > > There's already a mechanism for timing out if userland is not > responding, so a suspend will ultimately happen whether or not it > answers. However, that waits for a while (1 minute?) and devd used to be > optional, so I thought it best to keep the existing S5 behavior > (immediate shutdown). > > It may be ok to enable this for S5 but I don't think it's very useful. Perhaps a silly question, but is it too late at this stage of the game to try logging S5 events to syslog before dying? I agree with Stephen, logging 'shutdown by powerbutton' surely beats what might otherwise resemble a spontaneous reboot? Or is something already logged here? cheers, Ian From nate at root.org Fri Apr 17 12:27:36 2009 From: nate at root.org (Nate Lawson) Date: Fri Apr 17 12:53:58 2009 Subject: 6.x acpi powerbutton In-Reply-To: <20090418043432.O34434@sola.nimnet.asn.au> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> Message-ID: <49E8D824.1000001@root.org> Ian Smith wrote: > On Fri, 10 Apr 2009, Nate Lawson wrote: > > Andriy Gapon wrote: > > > on 09/04/2009 23:24 Stephen Clark said the following: > > >> Is there a reason it doesn't send and event like Linux that can be acted > > >> upon by user space other > > >> than signaling init? I like to have a message written in > > >> /var/log/messages that someone pressed > > >> the powerbutton. > > > > > > I think that for all suspend states except S5 userland is notified via > > > devd mechanism and potentially can veto the suspend. S5 (soft-off) is > > > coded to start shutdown immediately. You can try to hack on > > > acpi_ReqSleepState in sys/dev/acpica/acpi.c. > > > > > > I am not sure what is the reason for this special behavior of S5. But I > > > like it, because it sometimes allows me to perform semi-clean shutdown > > > when X goes crazy. But I also see when it could be useful to have S5 > > > request go through userland. So this could be configurable. > > > > The reason for userland getting into the loop in the first place was to > > run programs to shut down devices and reinit them after resume. This > > isn't necessary in the shutdown case because init already sends a > > signal, as you mention. > > > > There's already a mechanism for timing out if userland is not > > responding, so a suspend will ultimately happen whether or not it > > answers. However, that waits for a while (1 minute?) and devd used to be > > optional, so I thought it best to keep the existing S5 behavior > > (immediate shutdown). > > > > It may be ok to enable this for S5 but I don't think it's very useful. > > Perhaps a silly question, but is it too late at this stage of the game > to try logging S5 events to syslog before dying? I agree with Stephen, > logging 'shutdown by powerbutton' surely beats what might otherwise > resemble a spontaneous reboot? Or is something already logged here? I'm not resisting this, but I'm having trouble seeing the importance. What happens differently than if someone hits CTRL-ALT-DEL on a virtual console? -- Nate From kensmith at cse.Buffalo.EDU Fri Apr 17 12:29:54 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Fri Apr 17 12:55:22 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> References: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> Message-ID: <1239996590.94812.34.camel@bauer.cse.buffalo.edu> On Fri, 2009-04-17 at 13:15 -0400, Ken Smith wrote: > A fix for the "vm_page_insert: page already inserted" panics has been > committed to RELENG_7_1 this morning so it missed the 7.2-RC1 builds. > If you wind up being hit by that you can try a normal source based > update to the current state of RELENG_7_1 and that problem should go > away. > If you would like to do a source-based update to 7.2-RC1 from an > already installed machine you can update your tree to RELENG_7_1 using > normal cvsup/csup methods. Sorry, I had "RC*1*" on the brain... The proper branch tag is RELENG_7_2. Sorry about that. -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090417/d0e6861f/attachment.pgp From ertr1013 at student.uu.se Fri Apr 17 12:58:44 2009 From: ertr1013 at student.uu.se (Erik Trulsson) Date: Fri Apr 17 13:38:12 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> References: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> Message-ID: <20090417195823.GA81376@owl.midgard.homeip.net> On Fri, Apr 17, 2009 at 01:15:03PM -0400, Ken Smith wrote: > > The first of two planned Release Candidates for the FreeBSD 7.2-RELEASE > cycle is now available. Testing of some of the recent work would be > particularly appreciated. This includes: > > - bce(4) updated (there is a report that lagg(4) does > not work after the update, fixing that may need to be > done as an Errata Notice after the release) > - testing of the threading libraries > - amr(4) should be fixed > > A fix for the "vm_page_insert: page already inserted" panics has been > committed to RELENG_7_1 this morning so it missed the 7.2-RC1 builds. > If you wind up being hit by that you can try a normal source based > update to the current state of RELENG_7_1 and that problem should go > away. I assume that you mean 'RELENG_7_2' rather than 'RELENG_7_1' in the above paragraph? (As well as further down.) > > We have slipped by two days at this point but otherwise are on track > with the target release schedule which is here: > > http://www.freebsd.org/releases/7.2R/schedule.html > > We continue to watch for problems both on the mailing lists and in Gnats > but at this point we know of nothing we consider show-stopper calibre. > Unless something that bad does surface as a result of 7.2-RC1 testing we > should be sticking to the schedule. > > The ISO images and FTP install trees are available on the FreeBSD Mirror > sites. Using the primary site as an example: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.2/ > > where ${arch} is one of amd64 i386, ia64, pc98, or sparc64. The > builds for powerpc are still in progress, it should become available > in a day or two. > > Checksums for the ISO images are at the bottom of this message. The > amd64 and i386 sets include a *preliminary* set of packages. > > If you would like to do a source-based update to 7.2-RC1 from an > already installed machine you can update your tree to RELENG_7_1 using > normal cvsup/csup methods. > > 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, or 7.2-BETA1 can upgrade as follows: > > # freebsd-update upgrade -r 7.2-RC1 > > 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. > > # 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, and the system needs to be rebooted again: > > # freebsd-update install > # shutdown -r now > > Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to > upgrade to FreeBSD 7.2-RC1, but will be prompted to rebuild all third-party > applications (e.g., anything installed from the ports tree) after the second > invocation of "freebsd-update install", in order to handle differences in the > system libraries between FreeBSD 6.x and FreeBSD 7.x. > -- Erik Trulsson ertr1013@student.uu.se From kostikbel at gmail.com Fri Apr 17 13:07:37 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Fri Apr 17 13:52:14 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49E8D824.1000001@root.org> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> Message-ID: <20090417200726.GG3014@deviant.kiev.zoral.com.ua> On Fri, Apr 17, 2009 at 12:27:32PM -0700, Nate Lawson wrote: > Ian Smith wrote: > > Perhaps a silly question, but is it too late at this stage of the game > > to try logging S5 events to syslog before dying? I agree with Stephen, > > logging 'shutdown by powerbutton' surely beats what might otherwise > > resemble a spontaneous reboot? Or is something already logged here? > > I'm not resisting this, but I'm having trouble seeing the importance. > What happens differently than if someone hits CTRL-ALT-DEL on a virtual > console? Actually, this is quite reasonable feature. Quite often, machines do not have physical consoles, or C-A-D is disabled. On the other hand, power button is quite easy to be pressed by mistake by passing staff. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090417/8604c3de/attachment.pgp From freebsd.stable at virtualhost.nl Fri Apr 17 13:08:19 2009 From: freebsd.stable at virtualhost.nl (Jeroen Hofstee) Date: Fri Apr 17 13:52:15 2009 Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy Message-ID: <49E8DB60.4080202@virtualhost.nl> Hello All, I encountered the same problem as reported to this list earlier, http://lists.freebsd.org/pipermail/freebsd-stable/2009-February/048305.html, but then with 7.1-RELEASE-p4. Interestingly enough, FreeBSD booted fine on the machine installed (updated from 7.0 to 7.1-RELEASE-p4). This machine is a PowerEdge 1850 bios A04 with Perc 43/Si bios H430 / fwVer 521S. When booting a drive from this machine in another PowerEdge 1850, bios A07 Perc 4e/Si bios H435 FwVer 5B2D it drops to the can mount root prompt, similar as reported originally, see http://omx.ch/om/stuff/pe1850bsd71error.jpg. By specifying the kern.cam.scsi_delay, as suggested in this thread, the problem is solved. So there is a workaround, but I would prefer to see this fixed instead. I can't find a problem report regarding this topic though so can't find the current status. Does anybody know the current status? I can test if this issue has been solved if needed. I need to know then what to test of course... 7.1-STABLE or 7.2 BETA1 etc... Regards, Jeroen From cswiger at mac.com Fri Apr 17 13:24:43 2009 From: cswiger at mac.com (Chuck Swiger) Date: Fri Apr 17 13:56:28 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49E8D824.1000001@root.org> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> Message-ID: <1F394E42-BB02-41AC-8A52-C47A76EC55C9@mac.com> On Apr 17, 2009, at 12:27 PM, Nate Lawson wrote: >> Perhaps a silly question, but is it too late at this stage of the >> game >> to try logging S5 events to syslog before dying? I agree with >> Stephen, >> logging 'shutdown by powerbutton' surely beats what might otherwise >> resemble a spontaneous reboot? Or is something already logged here? > > I'm not resisting this, but I'm having trouble seeing the importance. > What happens differently than if someone hits CTRL-ALT-DEL on a > virtual > console? Well, I'd like to get a one-line message saying "rebooted by CTRL-ALT- DEL" versus "shutdown by powerbutton". Other systems would log a one- liner like "system rebooted by /etc/shutdown -i 6: _MESSAGE_".... Regards, -- -Chuck From nate at root.org Fri Apr 17 13:30:30 2009 From: nate at root.org (Nate Lawson) Date: Fri Apr 17 13:59:18 2009 Subject: 6.x acpi powerbutton In-Reply-To: <20090417200726.GG3014@deviant.kiev.zoral.com.ua> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> <20090417200726.GG3014@deviant.kiev.zoral.com.ua> Message-ID: <49E8E6E3.40304@root.org> Kostik Belousov wrote: > On Fri, Apr 17, 2009 at 12:27:32PM -0700, Nate Lawson wrote: >> Ian Smith wrote: >>> Perhaps a silly question, but is it too late at this stage of the game >>> to try logging S5 events to syslog before dying? I agree with Stephen, >>> logging 'shutdown by powerbutton' surely beats what might otherwise >>> resemble a spontaneous reboot? Or is something already logged here? >> I'm not resisting this, but I'm having trouble seeing the importance. >> What happens differently than if someone hits CTRL-ALT-DEL on a virtual >> console? > > Actually, this is quite reasonable feature. Quite often, machines > do not have physical consoles, or C-A-D is disabled. On the other > hand, power button is quite easy to be pressed by mistake by passing > staff. Sure. Perhaps Andriy will pick up this task after reworking the suspend path code for S5? It seems related. -- Nate From grarpamp at gmail.com Fri Apr 17 13:40:28 2009 From: grarpamp at gmail.com (grarpamp) Date: Fri Apr 17 14:02:38 2009 Subject: CD install notes with 7.1R and 7.2RC1 Message-ID: I have a test machine. Nothing special except for the dell 2350 mobo. Everything works. Somehow I had 7.1-RELEASE on it already. I zeroed the disk to reinstall 7.1R from disc1. The install went fine. But when booting from disk I hit the loader skip_newlines issue: http://lists.freebsd.org/pipermail/freebsd-stable/2009-January/047996.html So I booted 7.1R disc1, set rootdev=disk1s1a, boot -sv, copied in the /boot/loader from the 7.2-RC1 base pkg and that worked to boot the freshly installed 7.1R from disk. So I figured to use 7.2-RC1 now, and zeroed the disk for that. However 7.2-RC1 disc1 won't boot on this hardware but does on an older system. It seems to try to access the disc but doesn't print anything on console and the BIOS passes and proceeds to onboard DHCP/PXE booting. Oh, and burncd burns discs with what looks like a bad offset into them. I've seen this before. Had to use cdrecord, and with that all the hashes for the cd's verify ok. All the firmwares are up to date and everything's plain vanilla. Sorry, three issues in one :) So this is just a report while I tinker more... in case anyone else is seeing these things. I'm guessing some strange CDROM speed or write quality issue, not showstoppers. From scottl at samsco.org Fri Apr 17 13:59:27 2009 From: scottl at samsco.org (Scott Long) Date: Fri Apr 17 14:20:15 2009 Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy In-Reply-To: <49E8DB60.4080202@virtualhost.nl> References: <49E8DB60.4080202@virtualhost.nl> Message-ID: <49E8EDAA.2060908@samsco.org> The just-released 7.2-RC2 should fix this problem. Please let me know ASAP if it works for you. Scott Jeroen Hofstee wrote: > Hello All, > > I encountered the same problem as reported to this list earlier, > http://lists.freebsd.org/pipermail/freebsd-stable/2009-February/048305.html, > but then with 7.1-RELEASE-p4. > > Interestingly enough, FreeBSD booted fine on the machine installed > (updated from 7.0 to 7.1-RELEASE-p4). > This machine is a PowerEdge 1850 bios A04 with Perc 43/Si bios H430 / > fwVer 521S. > > When booting a drive from this machine in another PowerEdge 1850, bios > A07 Perc 4e/Si bios H435 FwVer 5B2D > it drops to the can mount root prompt, similar as reported originally, > see http://omx.ch/om/stuff/pe1850bsd71error.jpg. > By specifying the kern.cam.scsi_delay, as suggested in this thread, the > problem is solved. > > So there is a workaround, but I would prefer to see this fixed instead. > I can't find a problem report regarding this topic though so can't find > the current status. > > Does anybody know the current status? > I can test if this issue has been solved if needed. I need to know then > what to test of course... 7.1-STABLE or 7.2 BETA1 etc... > > Regards, > Jeroen > > > > > > > > > > > _______________________________________________ > 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 freebsd.stable at virtualhost.nl Fri Apr 17 16:04:28 2009 From: freebsd.stable at virtualhost.nl (Jeroen Hofstee) Date: Fri Apr 17 16:24:31 2009 Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy Message-ID: <49E90AF8.3080408@virtualhost.nl> I did the following to verify: 1) Installed 7.2-RC2 on the Perc 4e/Si H430 machine (RAID1), this went fine. 2) Turned off, and placed one drive in the machine with Perc 4e/Si H435, boot went fine and no long delays after amr0.... So the problem as I encountered with 7.1-RELEASE-p4 is not present in 7.2-RC2. There are some messages about GEOM_LABEL and GEOM_LABEL: Label .... removed, which I haven't seen before. If they are of any interest let me know. Regards, Jeroen p.s. I copied the subject from the original thread. I haven't attempt to install 7.1-RELEASE myself. If it is of any additional value, I can try to install the 7.1- RELEASE directly to verify if it fails. Scott Long wrote: > The just-released 7.2-RC2 should fix this problem. Please let me > know ASAP if it works for you. > > Scott > >> Interestingly enough, FreeBSD booted fine on the machine installed >> (updated from 7.0 to 7.1-RELEASE-p4). >> This machine is a PowerEdge 1850 bios A04 with Perc 4*e*/Si bios H430 >> / fwVer 521S. >> >> When booting a drive from this machine in another PowerEdge 1850, >> bios A07 Perc 4e/Si bios H435 FwVer 5B2D >> it drops to the mount root prompt... From raul at b2n.org Fri Apr 17 16:08:23 2009 From: raul at b2n.org (Raul) Date: Fri Apr 17 16:25:00 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: References: <49E6E786.6060504@gmail.com> Message-ID: <49E90BE4.5080404@b2n.org> Alan Cox escribi?: > I believe that this problem is now resolved. A recent MFC overlooked one > critical change. That change was MFCed a few minutes ago. So, please > update your kernel. Rebuilding right now, thanks. Regards Raul From raul at b2n.org Fri Apr 17 16:31:24 2009 From: raul at b2n.org (Raul) Date: Sat Apr 18 04:44:00 2009 Subject: problems with 7.2, vm_page_insert: page already inserted In-Reply-To: <49E1323F.5040408@andric.com> References: <1239447330.7119.36.camel@ws.pinlabs.b2n.org> <1239494679.15226.23.camel@ws.pinlabs.b2n.org> <49E1323F.5040408@andric.com> Message-ID: <49E91149.7070202@b2n.org> Dimitry Andric escribi?: >> As a side note, isc-dhcp30-server port doesn't like the new jail stuff > Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=131515 for a > possible fix. Your patch builds cleanly and looks good (against today's sources), at least not using jails at all :). Let me see about jailed dhcp, even compiling support for it I've never tried before XD. Regards, Raul From petefrench at ticketswitch.com Fri Apr 17 16:40:35 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sat Apr 18 04:45:01 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> Message-ID: > - bce(4) updated (there is a report that lagg(4) does > not work after the update, fixing that may need to be > done as an Errata Notice after the release) [ this is http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133756 ] I just tested again with a csup of RELENG_7_2 and this still has the lagg problem. I know it most likely won't be fixed before release, so we do need a big warning in the release notes to tell people with this setup not to update, as it will just kill all network connectivity. -pete. From kensmith at cse.Buffalo.EDU Fri Apr 17 17:57:24 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Apr 18 04:49:09 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: References: Message-ID: <1240016235.27699.16.camel@neo.cse.buffalo.edu> On Sat, 2009-04-18 at 00:40 +0100, Pete French wrote: > > - bce(4) updated (there is a report that lagg(4) does > > not work after the update, fixing that may need to be > > done as an Errata Notice after the release) > > [ this is http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133756 ] > > I just tested again with a csup of RELENG_7_2 and this still has the > lagg problem. I know it most likely won't be fixed before release, so we > do need a big warning in the release notes to tell people with this setup > not to update, as it will just kill all network connectivity. > > -pete. We will, and if we do wind up shipping 7.2-REL with lagg(4) broken (there is still time for a fix if we find it fast enough so that's not definite yet...) apologies in advance. At least as things stand now it seems like the current driver is noticably better than the previous one in most regards so deciding whether to ship with this breakage versus reverting to the older driver isn't a particularly easy decision. -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090418/5785dd20/attachment.pgp From sclark46 at earthlink.net Fri Apr 17 20:11:43 2009 From: sclark46 at earthlink.net (Stephen Clark) Date: Sat Apr 18 04:56:04 2009 Subject: 6.x acpi powerbutton In-Reply-To: <49E8D824.1000001@root.org> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> Message-ID: <49E944DE.7080409@earthlink.net> Nate Lawson wrote: > Ian Smith wrote: >> On Fri, 10 Apr 2009, Nate Lawson wrote: >> > Andriy Gapon wrote: >> > > on 09/04/2009 23:24 Stephen Clark said the following: >> > >> Is there a reason it doesn't send and event like Linux that can be acted >> > >> upon by user space other >> > >> than signaling init? I like to have a message written in >> > >> /var/log/messages that someone pressed >> > >> the powerbutton. >> > > >> > > I think that for all suspend states except S5 userland is notified via >> > > devd mechanism and potentially can veto the suspend. S5 (soft-off) is >> > > coded to start shutdown immediately. You can try to hack on >> > > acpi_ReqSleepState in sys/dev/acpica/acpi.c. >> > > >> > > I am not sure what is the reason for this special behavior of S5. But I >> > > like it, because it sometimes allows me to perform semi-clean shutdown >> > > when X goes crazy. But I also see when it could be useful to have S5 >> > > request go through userland. So this could be configurable. >> > >> > The reason for userland getting into the loop in the first place was to >> > run programs to shut down devices and reinit them after resume. This >> > isn't necessary in the shutdown case because init already sends a >> > signal, as you mention. >> > >> > There's already a mechanism for timing out if userland is not >> > responding, so a suspend will ultimately happen whether or not it >> > answers. However, that waits for a while (1 minute?) and devd used to be >> > optional, so I thought it best to keep the existing S5 behavior >> > (immediate shutdown). >> > >> > It may be ok to enable this for S5 but I don't think it's very useful. >> >> Perhaps a silly question, but is it too late at this stage of the game >> to try logging S5 events to syslog before dying? I agree with Stephen, >> logging 'shutdown by powerbutton' surely beats what might otherwise >> resemble a spontaneous reboot? Or is something already logged here? > > I'm not resisting this, but I'm having trouble seeing the importance. > What happens differently than if someone hits CTRL-ALT-DEL on a virtual > console? > Hi Nate, We have over 500 units in the field that are used as firewall/vpn/routers. They have no console, but they do have a powerbutton. We have had customers say the machine turned itself off. It would be nice to know that someone pressed the power button. Thanks, Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) From smithi at nimnet.asn.au Sat Apr 18 01:28:18 2009 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Apr 18 05:17:05 2009 Subject: 6.x acpi powerbutton In-Reply-To: <1F394E42-BB02-41AC-8A52-C47A76EC55C9@mac.com> References: <49DE1F8B.2080400@earthlink.net> <49DE2E6D.5050001@icyb.net.ua> <49DE596E.2050406@earthlink.net> <49DEFF53.1040306@icyb.net.ua> <49DF7A1C.90009@root.org> <20090418043432.O34434@sola.nimnet.asn.au> <49E8D824.1000001@root.org> <1F394E42-BB02-41AC-8A52-C47A76EC55C9@mac.com> Message-ID: <20090418170826.T34434@sola.nimnet.asn.au> On Fri, 17 Apr 2009, Chuck Swiger wrote: > On Apr 17, 2009, at 12:27 PM, Nate Lawson wrote: > > > Perhaps a silly question, but is it too late at this stage of the game > > > to try logging S5 events to syslog before dying? I agree with Stephen, > > > logging 'shutdown by powerbutton' surely beats what might otherwise > > > resemble a spontaneous reboot? Or is something already logged here? > > > > I'm not resisting this, but I'm having trouble seeing the importance. > > What happens differently than if someone hits CTRL-ALT-DEL on a virtual > > console? > > Well, I'd like to get a one-line message saying "rebooted by CTRL-ALT-DEL" > versus "shutdown by powerbutton". Other systems would log a one-liner like > "system rebooted by /etc/shutdown -i 6: _MESSAGE_".... I don't know about C-A-D as I've always disabled it in my kernels - lest some 'windows expert' may be hoping to see a TaskList - but 'reboot' and 'shutdown -[rhp] ..' are already logged nicely: May 31 16:25:26 paqi reboot: rebooted by root May 31 16:25:26 paqi syslogd: exiting on signal 15 May 31 16:26:30 paqi syslogd: kernel boot file is /boot/kernel/kernel Mar 31 20:04:14 paqi shutdown: power-down by smithi: down after fixing localtime Sydney Mar 31 19:04:32 paqi named[16442]: stopping command channel on 127.0.0.1#953 Mar 31 19:04:33 paqi named[16442]: exiting Mar 31 19:04:33 paqi syslogd: exiting on signal 15 Mar 31 19:07:16 paqi syslogd: kernel boot file is /boot/kernel/kernel I suspect a 'windows expert' would have to break down doors to get to Nate's boxes, but for those of us condemned to being remote catherders, a powerbutton shutdown message would be helpful. cheers, Ian From grarpamp at gmail.com Sat Apr 18 01:46:43 2009 From: grarpamp at gmail.com (grarpamp) Date: Sat Apr 18 05:18:26 2009 Subject: Update ... CD install 7.2RC1 Message-ID: dell 2350 bluford mobo p4 non-htt ich4 award acpi bios pri master = 9GB of zeros pri slave = sec master = gcr-8481b sec slave = sh-s182d All firmwares are current. I'm able to boot 7.1R disc1 from sec master. I load 7.1R fixit livefs in the opposing drive, remove the 7.1R boot disc1 and insert 7.2RC-1 disc1. Then do dd | sha256 from fixit on the 7.2RC-1 disc1. Hashes match. I'm able to boot 7.1R disc1 from sec slave. I load 7.1R fixit livefs in the opposing drive, remove the 7.1R boot disc1 and insert 7.2RC-1 disc1. Then do dd | sha256 from fixit on the 7.2RC-1 disc1. Hashes match. So my drives boot 7.1R disc1 and read the raw iso's fine and something's up with 7.2RC-1 disc1 booting on this hardware. Unfortunately I get NO output on the console when booting this disc1 so I'm at a loss. The drive lights up, after the drive's insert disc tasting sequence is complete and the disc is still spun up, so the system does read and try to boot something off the drive for sure. Then it silently passes to the bios/onboard netboot. The discs were written on the above writer. So I'm stuck... with cdrecord, installing 7.1R, copying in 7.2RC-1's loader and building RELENG_7. No big deal right :) If I have time, I'll do a RELENG_7 make relase and see what that disc1 does for me. From petefrench at ticketswitch.com Sat Apr 18 02:36:23 2009 From: petefrench at ticketswitch.com (Pete French) Date: Sat Apr 18 05:21:04 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: <1240016235.27699.16.camel@neo.cse.buffalo.edu> Message-ID: > We will, and if we do wind up shipping 7.2-REL with lagg(4) broken > (there is still time for a fix if we find it fast enough so that's not > definite yet...) apologies in advance. At least as things stand now it Well, kind of my fault too for not getting aroiund to testing the driver for two weeks - I was out of the country so didn't get a chance. > seems like the current driver is noticably better than the previous one > in most regards so deciding whether to ship with this breakage versus > reverting to the older driver isn't a particularly easy decision. Yes, I can see that, and a better bce driver is very much a Good Thing. I have another identical box running 7.2-PRE without lagg and that works beautifuly. What surprises me is that nobody else has made any reports either way - neither a "me too" on the issure, nor a "it works ok here". Surely I cant be the only one using HP servers + Cisco switches and needing redundancy on the links ? Anyone else out there care to chip in ? Let me know if/wher there are things to test though - after the 7.1 relese routing problems I have now allocated a box for testing this kind of stuff, so it's fairly easy to do - I will be away from thursday for another a week though unfortunately which will make that hard :-( Sorry... -pete. From freebsd.stable at virtualhost.nl Sat Apr 18 02:54:20 2009 From: freebsd.stable at virtualhost.nl (Jeroen Hofstee) Date: Sat Apr 18 05:21:53 2009 Subject: poweredge 1850 won't boot 7.1? maybe LSI-related : amr0: adapter is busy In-Reply-To: <49E90AF8.3080408@virtualhost.nl> References: <49E90AF8.3080408@virtualhost.nl> Message-ID: <49E9A348.3050809@virtualhost.nl> I did some additional testing: 1) Installed 7.2-RC2 directly on the Perc 4e/Si H435 machine (RAID1) from a cd, this went fine. 2) Turned off, and placed one drive in the machine with Perc 4e/Si H430, boot went fine Checked install of 7.1-RELEASE from cd on the 4e/Si H435 machine, failed: no harddisk found. Checked install of 7.1-RELEASE from cd on the 4e/Si H430 machine, fine harddisk found. Jeroen Jeroen Hofstee schreef: > I did the following to verify: > > 1) Installed 7.2-RC2 on the Perc 4e/Si H430 machine (RAID1), this went > fine. > 2) Turned off, and placed one drive in the machine with Perc 4e/Si H435, > boot went fine and no long delays after amr0.... > > So the problem as I encountered with 7.1-RELEASE-p4 is not present in > 7.2-RC2. > > There are some messages about GEOM_LABEL and GEOM_LABEL: Label .... > removed, > which I haven't seen before. If they are of any interest let me know. > > Regards, > Jeroen > > p.s. I copied the subject from the original thread. I haven't attempt > to install 7.1-RELEASE myself. If it is of any additional value, I can > try to install the 7.1- RELEASE directly to verify if it fails. > > > Scott Long wrote: >> The just-released 7.2-RC2 should fix this problem. Please let me >> know ASAP if it works for you. >> >> Scott >> >>> Interestingly enough, FreeBSD booted fine on the machine installed >>> (updated from 7.0 to 7.1-RELEASE-p4). >>> This machine is a PowerEdge 1850 bios A04 with Perc 4*e*/Si bios >>> H430 / fwVer 521S. >>> >>> When booting a drive from this machine in another PowerEdge 1850, >>> bios A07 Perc 4e/Si bios H435 FwVer 5B2D >>> it drops to the mount root prompt... > > > _______________________________________________ > 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 cpghost at cordula.ws Sat Apr 18 17:13:26 2009 From: cpghost at cordula.ws (cpghost) Date: Sat Apr 18 17:13:33 2009 Subject: page fault in sis.ko / drm.ko Message-ID: <20090418171306.GA1983@phenom.cordula.ws> Could a drm guru please have a look at kern/133554? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From rnoland at FreeBSD.org Sat Apr 18 19:00:23 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Sat Apr 18 19:00:30 2009 Subject: page fault in sis.ko / drm.ko In-Reply-To: <20090418171306.GA1983@phenom.cordula.ws> References: <20090418171306.GA1983@phenom.cordula.ws> Message-ID: <1240081119.3525.5.camel@balrog.2hip.net> 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: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090418/241b4bdd/attachment.pgp From cpghost at cordula.ws Sat Apr 18 19:43:22 2009 From: cpghost at cordula.ws (cpghost) Date: Sat Apr 18 19:44:48 2009 Subject: page fault in sis.ko / drm.ko In-Reply-To: <1240081119.3525.5.camel@balrog.2hip.net> References: <20090418171306.GA1983@phenom.cordula.ws> <1240081119.3525.5.camel@balrog.2hip.net> Message-ID: <20090418192441.GB4441@phenom.cordula.ws> On Sat, Apr 18, 2009 at 01:58:39PM -0500, Robert Noland wrote: > On Sat, 2009-04-18 at 19:13 +0200, cpghost wrote: > > Could a drm guru please have a look at kern/133554? > > > > Thanks, > > -cpghost. > > Give this patch a try, it looks like the sis driver doesn't have irq's. Ah, thank you. I'll try this tomorrow as soon as I'm in front of this box again, and will report back. Kind regards, -cpghost. > robert. > > -- > Robert Noland > FreeBSD > Index: dev/drm/drm_drv.c > =================================================================== > --- dev/drm/drm_drv.c (revision 190987) > +++ dev/drm/drm_drv.c (working copy) > @@ -134,7 +134,7 @@ > .d_flags = D_TRACKCLOSE > }; > > -int drm_msi = 1; /* Enable by default. */ > +static int drm_msi = 1; /* Enable by default. */ > TUNABLE_INT("hw.drm.msi", &drm_msi); > > static struct drm_msi_blacklist_entry drm_msi_blacklist[] = { > @@ -228,28 +228,31 @@ > dev->pci_vendor = pci_get_vendor(dev->device); > dev->pci_device = pci_get_device(dev->device); > > - if (drm_msi && > - !drm_msi_is_blacklisted(dev->pci_vendor, dev->pci_device)) { > - msicount = pci_msi_count(dev->device); > - DRM_DEBUG("MSI count = %d\n", msicount); > - if (msicount > 1) > - msicount = 1; > + if (drm_core_check_feature(dev, DRIVER_HAVE_IRQ)) { > + if (drm_msi && > + !drm_msi_is_blacklisted(dev->pci_vendor, dev->pci_device)) { > + msicount = pci_msi_count(dev->device); > + DRM_DEBUG("MSI count = %d\n", msicount); > + if (msicount > 1) > + msicount = 1; > > - if (pci_alloc_msi(dev->device, &msicount) == 0) { > - DRM_INFO("MSI enabled %d message(s)\n", msicount); > - dev->msi_enabled = 1; > - dev->irqrid = 1; > + if (pci_alloc_msi(dev->device, &msicount) == 0) { > + DRM_INFO("MSI enabled %d message(s)\n", > + msicount); > + dev->msi_enabled = 1; > + dev->irqrid = 1; > + } > } > - } > > - dev->irqr = bus_alloc_resource_any(dev->device, SYS_RES_IRQ, > - &dev->irqrid, RF_SHAREABLE); > - if (!dev->irqr) { > - return ENOENT; > + dev->irqr = bus_alloc_resource_any(dev->device, SYS_RES_IRQ, > + &dev->irqrid, RF_SHAREABLE); > + if (!dev->irqr) { > + return ENOENT; > + } > + > + dev->irq = (int) rman_get_start(dev->irqr); > } > > - dev->irq = (int) rman_get_start(dev->irqr); > - > mtx_init(&dev->dev_lock, "drmdev", NULL, MTX_DEF); > mtx_init(&dev->irq_lock, "drmirq", NULL, MTX_DEF); > mtx_init(&dev->vbl_lock, "drmvbl", NULL, MTX_DEF); -- Cordula's Web. http://www.cordula.ws/ From bc979 at lafn.org Sat Apr 18 21:16:49 2009 From: bc979 at lafn.org (Doug Hardie) Date: Sat Apr 18 21:16:56 2009 Subject: FreeBSD 7.2-rc1 Message-ID: <84888337-9024-4DA0-BF29-06FF98A49F15@lafn.org> I have encountered a rather interesting issue trying to install rc1. The system boots and then says there is no disk in the CD drive. The rc1 disk1 downloaded fine and the checksums matched. The CD will mount fine in other systems and can easily be read. I then let 7.0 boot on the test system and mounted the 7.2 cd. It mounts fine and I can read all the files ( well a few that I tested). Looking through the 7.0 dmesg I find some rather unexpected entries for the CD drive. acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: cd present [287216 x 2048 byte records] ... acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 (cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0 (cd0:ata0:0:1:0): CAM Status: SCSI Status Error (cd0:ata0:0:1:0): SCSI Status: Check Condition (cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0 (cd0:ata0:0:1:0): No seek complete (cd0:ata0:0:1:0): Retrying Command (per Sense Data) acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 (cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0 (cd0:ata0:0:1:0): CAM Status: SCSI Status Error (cd0:ata0:0:1:0): SCSI Status: Check Condition (cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0 (cd0:ata0:0:1:0): No seek complete (cd0:ata0:0:1:0): Retrying Command (per Sense Data) acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 (cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0 (cd0:ata0:0:1:0): CAM Status: SCSI Status Error (cd0:ata0:0:1:0): SCSI Status: Check Condition (cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0 (cd0:ata0:0:1:0): No seek complete (cd0:ata0:0:1:0): Retrying Command (per Sense Data) acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 (cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0 (cd0:ata0:0:1:0): CAM Status: SCSI Status Error (cd0:ata0:0:1:0): SCSI Status: Check Condition (cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0 (cd0:ata0:0:1:0): No seek complete (cd0:ata0:0:1:0): Retrying Command (per Sense Data) acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00 (cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0 (cd0:ata0:0:1:0): CAM Status: SCSI Status Error (cd0:ata0:0:1:0): SCSI Status: Check Condition (cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0 (cd0:ata0:0:1:0): No seek complete (cd0:ata0:0:1:0): Retries Exhausted (cd0:ata0:0:1:0): cddone: got error 0x5 back The drive works under 7.0, although with error messages. I also am hearing some rather unusual clicks and whines occasionally from the computer. I can't tell if they are from the CD drive but I suspect so. Many of them stop temporarily when I read a file from the CD. Taking the CD out seems to have stopped the noise. It would appear that I have some kind of CD drive failure. I don't understand why 7.0 can read the drive and 7.2 doesn't even see the disk in it. From m.e.sanliturk at gmail.com Sat Apr 18 23:04:29 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sat Apr 18 23:05:05 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation Message-ID: Dear All , I have installed FreeBSD 7.2 amd64 RC1 from DVD .iso to test its installation issues . It detected hardware correctly and installed without any problems , but during installation of the packages the following errors occurred : Add of package ...name of package... aborted , error code 1 : apache-1.3.41 links-0.98,1 apache+mod_ssl-1.3.41+2.8.31 ghostscript7-nox11-7.07_20 emacs-22.3 Number of failed packages is significantly less than failed packages of Release 7.1 amd64 installation . Due to failed package installation , at the end Gnome in 7.1 Release and Stable was unusable , at least because terminal was not available in Gnome menus with nearly empty menus . Other points may be the following : (1) During user definition password confirmation is not asked but in root password definition it is asked . For the user , the same password entry box may be re-used for password confirmation without changing screen design because entered password is not plainly visible and during password confirmation it is not necessary to keep it there , and it does not require much work to include it . ( During installation of 7.1 , I carefully first recorded password on paper , entered it , later it did not worked . ) (2) CD/DVD drive is NOT released when the message ... ( be sure to remove any floppies/CDs/DVDs from the drives ) . (3) When shutdown is selected from Gnome menu either by the first user or the root , within displayed dialog box there is no a Shutdown item . It is necessary for the root open a terminal console , and enter shutdown -p now command . PC definition : Intel DG965WH main board with 2 GB memory , PS/2 mouse and keyboard . Installation Options : Starting FreeBSD menu : Default Standard installation Fresh install ( SATA II Disk cleared before start of installation and all of the disk allocated ) Standard boot Disk layout : Default All distributions selected All of the ports categories containing all of the packages selected with the following categories excluded : accessibility ( entries selected on dependency ) chinese , ipv6 , japanese , korean , palm . IPv6 : No DHCP : Yes , Ethernet to ADSL router : Yes , worked . Gateway : No iNetd and Network services : No SSH login : No FTP : No NFS Server : No NFS Client : No Console Settings : No Time zone setting : Yes Mouse : Tested , Worked Packages : Selected , Installed User : Defined Thank you very much Mehmet Erol Sanliturk From kensmith at cse.Buffalo.EDU Sat Apr 18 23:56:30 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Sat Apr 18 23:56:38 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: References: Message-ID: <1240098983.27699.44.camel@neo.cse.buffalo.edu> On Sat, 2009-04-18 at 19:04 -0400, Mehmet Erol Sanliturk wrote: Thanks for the testing and feedback. > I have installed FreeBSD 7.2 amd64 RC1 from DVD .iso to test its > installation issues . > > It detected hardware correctly and installed without any problems , but > during installation of the packages the following errors > occurred : > > Add of package ...name of package... aborted , error code 1 : > > apache-1.3.41 > links-0.98,1 > apache+mod_ssl-1.3.41+2.8.31 > ghostscript7-nox11-7.07_20 > emacs-22.3 > > Number of failed packages is significantly less than failed packages of > Release 7.1 amd64 installation . > Due to failed package installation , at the end Gnome in 7.1 Release and > Stable was unusable , at least because > terminal was not available in Gnome menus with nearly empty menus . To be honest it never occured to me that someone would attempt to install all of the packages (or at least as many as you indicated in your summary that you did). The package failures you mention were almost certainly caused by conflicts (e.g. apache-1.3.41 and apache +mod_ssl-1.3.41+2.8.31 failing because apache-2.2.11_4 got installed first). When deciding what packages to include on the media as of late I haven't been taking the issue of possible conflicts into mind. Like I said I'm afraid it just never occured to me someone would just select "virtually all of them" as you did. I'll take this into consideration moving forward but just so you know it likely won't be addressed as part of 7.2-REL. It's likely you would need to be at least a little more selective in what packages you install if you want to avoid these sorts of package install failures caused by conflicts. > Other points may be the following : > > (1) During user definition password confirmation is not asked but in root > password definition it is asked . > For the user , the same password entry box may be re-used for > password confirmation without changing > screen design because entered password is not plainly visible and > during password confirmation it is not necessary > to keep it there , and it does not require much work to include it . > > ( During installation of 7.1 , I carefully first recorded password on > paper , entered it , later it did not worked . ) > > (2) CD/DVD drive is NOT released when the message ... ( be sure to remove > any floppies/CDs/DVDs from the drives ) . Those are both fixed in head (what will become 8.0). I chose to not MFC those changes because they rearrange questions which might throw off people who are used to the older behavior, it's best to phase in that sort of thing as part of a new branch. > (3) When shutdown is selected from Gnome menu either by the first user or > the root , within displayed dialog box > there is no a Shutdown item . > It is necessary for the root open a terminal console , and enter > shutdown -p now command . That one is a question for the Gnome folks but I *think* that's the intended behavior unless you configure the machine to launch the graphical interface as part of booting up. :-) -- Ken Smith - From there to here, from here to | kensmith@cse.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/20090418/2ca0ed32/attachment.pgp From bruce at cran.org.uk Sun Apr 19 00:09:09 2009 From: bruce at cran.org.uk (Bruce Cran) Date: Sun Apr 19 00:09:16 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: References: Message-ID: <20090419010904.714c2dc2@gluon.draftnet> On Sat, 18 Apr 2009 19:04:26 -0400 Mehmet Erol Sanliturk wrote: > (3) When shutdown is selected from Gnome menu either by the first > user or the root , within displayed dialog box > there is no a Shutdown item . > It is necessary for the root open a terminal console , and enter > shutdown -p now command . Have you installed sudo? I think those options (suspend/shutdown/hibernate) only get displayed if HAL sees sudo is available. -- Bruce Cran From sonic2000gr at gmail.com Sun Apr 19 00:20:07 2009 From: sonic2000gr at gmail.com (Manolis Kiagias) Date: Sun Apr 19 00:20:14 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: <20090419010904.714c2dc2@gluon.draftnet> References: <20090419010904.714c2dc2@gluon.draftnet> Message-ID: <49EA6E33.1060906@gmail.com> Bruce Cran wrote: > On Sat, 18 Apr 2009 19:04:26 -0400 > Mehmet Erol Sanliturk wrote: > > > >> (3) When shutdown is selected from Gnome menu either by the first >> user or the root , within displayed dialog box >> there is no a Shutdown item . >> It is necessary for the root open a terminal console , and enter >> shutdown -p now command . >> > > Have you installed sudo? I think those options > (suspend/shutdown/hibernate) only get displayed if HAL sees sudo is > available. > > Fact is you will get these options either if you have sudo and your user account is authorized to shutdown / reboot (this is the fallback method though) or if PolicyKit is configured (see /usr/local/etc/PolicyKit/PolicyKit.conf) to allow shutdown/reboot. Entries will look similar to these: Have a look at http://www.freebsd.org/gnome/docs/halfaq.html for more HAL fun ;) From m.e.sanliturk at gmail.com Sun Apr 19 03:27:55 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sun Apr 19 03:28:02 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: <1240098983.27699.44.camel@neo.cse.buffalo.edu> References: <1240098983.27699.44.camel@neo.cse.buffalo.edu> Message-ID: On Sat, Apr 18, 2009 at 7:56 PM, Ken Smith wrote: > On Sat, 2009-04-18 at 19:04 -0400, Mehmet Erol Sanliturk wrote: > > To be honest it never occured to me that someone would attempt to > install all of the packages (or at least as many as you indicated in > your summary that you did). The package failures you mention were > almost certainly caused by conflicts (e.g. apache-1.3.41 and apache > +mod_ssl-1.3.41+2.8.31 failing because apache-2.2.11_4 got installed > first). When deciding what packages to include on the media as of late > I haven't been taking the issue of possible conflicts into mind. Like I > said I'm afraid it just never occured to me someone would just select > "virtually all of them" as you did. > > I'll take this into consideration moving forward but just so you know it > likely won't be addressed as part of 7.2-REL. It's likely you would > need to be at least a little more selective in what packages you install > if you want to avoid these sorts of package install failures caused by > conflicts. > > This is a test installation . Therefore installation of all the packages is a testing step . Such a test will show installability of packages and missing parts if any , and possible conflicts . Therefore package selection process rules may be adjusted accordingly . After marking selected packages I inspected every category list toward backward to see whether a last selection reverted a previously marked selection . Such a mark erasing did not occurred . Marking is able to select dependencies but at present it is not de-select conflicting selections . Another reason is that I am writing a multimedia information management system since 1986 and it is continuation of my PhD thesis subject . Concepts coverage is vast and I am studying every possible information sources one by one to learn at least their main ideas . This part is for me . > That one is a question for the Gnome folks but I *think* that's the > intended behavior unless you configure the machine to launch the > graphical interface as part of booting up. :-) > > -- > Ken Smith > - From there to here, from here to | kensmith@cse.buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > After installation , FreeBSD boots in terminal mode . In this first boot , I have included gnome_enable=?YES? into rc.conf and re-booted . Thank you very much Mehmet Erol Sanliturk From m.e.sanliturk at gmail.com Sun Apr 19 03:39:24 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sun Apr 19 03:39:31 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: <20090419010904.714c2dc2@gluon.draftnet> References: <20090419010904.714c2dc2@gluon.draftnet> Message-ID: On Sat, Apr 18, 2009 at 8:09 PM, Bruce Cran wrote: > On Sat, 18 Apr 2009 19:04:26 -0400 > Mehmet Erol Sanliturk wrote: > > > > (3) When shutdown is selected from Gnome menu either by the first > > user or the root , within displayed dialog box > > there is no a Shutdown item . > > It is necessary for the root open a terminal console , and enter > > shutdown -p now command . > > Have you installed sudo? I think those options > (suspend/shutdown/hibernate) only get displayed if HAL sees sudo is > available. > > -- > Bruce Cran It is very likely , because I had selected all of the packages . I do not know why HAL uses sudo for such a result . Actually I am using FreeBSD 7.1 i386 Stable again all of the packages installed but Gnome shut down menu is NOT affected by selection of sudo . Now I have checked my 7.1 i386 . sudo is installed and Gnome shutdown menu for the user ( not root ) included into operator group for USB mounts shows the menu item shudtdown . This means that there is a difference between i386 and amd64 shutdown rules in Gnome menus . Thank you very much Mehmet Erol Sanliturk From m.e.sanliturk at gmail.com Sun Apr 19 04:01:03 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sun Apr 19 04:01:10 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: <49EA6E33.1060906@gmail.com> References: <20090419010904.714c2dc2@gluon.draftnet> <49EA6E33.1060906@gmail.com> Message-ID: On Sat, Apr 18, 2009 at 8:20 PM, Manolis Kiagias wrote: > Bruce Cran wrote: > > On Sat, 18 Apr 2009 19:04:26 -0400 > > Mehmet Erol Sanliturk wrote: > > > > > > > >> (3) When shutdown is selected from Gnome menu either by the first > >> user or the root , within displayed dialog box > >> there is no a Shutdown item . > >> It is necessary for the root open a terminal console , and enter > >> shutdown -p now command . > >> > > > > Have you installed sudo? I think those options > > (suspend/shutdown/hibernate) only get displayed if HAL sees sudo is > > available. > > > > > Fact is you will get these options either if you have sudo and your user > account is authorized to shutdown / reboot (this is the fallback method > though) or if PolicyKit is configured (see > /usr/local/etc/PolicyKit/PolicyKit.conf) to allow shutdown/reboot. > > Entries will look similar to these: > > > > > > > > > > > > > Have a look at http://www.freebsd.org/gnome/docs/halfaq.html for more > HAL fun ;) > Nearly all of my expressed ideas about FreeBSD is not about my own requirements but especially newly beginning users . This point is utmost importance for me because my profession was the teaching of programming languages to the students in the University by starting from Introduction to computing . In those days computers were not available as they are today . I know how difficult is to make a start to learning to use a computing systems with respect to observations of the students . Then I want to emphasize the points that will be difficult for the new users to overcome at the beginning . If we do not reduce usage difficulty level of FreeBSD as much as possible it will prevent adoption of FreeBSD so much . Why FreeBSD so important for me is not a good question because FreeBSD is an excellent operating system with an immensely invested efforts by its very valuable developers and I think it is second to none . For my own difficulties : I wish - the Handbook includes more examples . - the man pages includes more examples for typical situations . In that respect my idea is that freebsd-questions and other lists contain excellent cases and solutions to them . In those days there is a concept of data mining . Actually these lists are containing very good sample cases and their solutions . By traversing the questions and problems and answers to them may be utilized to enhance the man pages and the handbook . This requires extensive knowledge about the Handbook and man pages which I do not have yet . Knowledgeable FreeBSD developers may contribute to this process . It is known that ideas expressed in mailing lists may be utilized for this process and my opinion is that no one will object to utilization of his/her ideas in such a utilization . Thank you very much . Mehmet Erol Sanliturk. From xernet at hotmail.it Sun Apr 19 08:02:27 2009 From: xernet at hotmail.it (xer) Date: Sun Apr 19 08:02:34 2009 Subject: 6.4-STABLE and PHP5 pcre and phpsysinfo In-Reply-To: <20090415120024.0E20A1065706@hub.freebsd.org> References: <20090415120024.0E20A1065706@hub.freebsd.org> Message-ID: Hello Mine 6.4-STABLE today has a strange problem regarding "phpsysinfo" that i use it. Ports are updated,but phpsysinfo (on browser) today show errors about pcre: ----------------------- Notice: Undefined offset: 3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.FreeBSD.inc.php on line 59 ^ a lots Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 126 ^ a lots Warning: asort() expects parameter 1 to be array, boolean given in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 174 ^ a lots Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 187 ^ a lots XPath error in XPath.class.php:3492 Expression failed to parse as PrimaryExpr because: Expression is not a PrimaryExpr XPath error in XPath.class.php:5903 The supplied xPath '/phpsysinfo/Vitals/Distro' does not *uniquely* describe a node in the xml document.Not unique xpath-query, matched 0-times. and more... -------------------- It seems that the FreeBSD patch does not work so well, someone use phpsysinfo? I did deinstalled php5 and 1.3 extension and reinstalled as expected.. but no resolve. Any help please? Thanx in advance. _________________________________________________________________ Quante ne sai? Scoprilo con CrossWire! http://clk.atdmt.com/GBL/go/140630367/direct/01/ From bc979 at lafn.org Sun Apr 19 09:10:03 2009 From: bc979 at lafn.org (Doug Hardie) Date: Sun Apr 19 09:10:10 2009 Subject: FreeBSD 7.2-rc1 In-Reply-To: <84888337-9024-4DA0-BF29-06FF98A49F15@lafn.org> References: <84888337-9024-4DA0-BF29-06FF98A49F15@lafn.org> Message-ID: <40A886C4-9202-48F8-B111-F4C7F4E3EA11@lafn.org> On Apr 18, 2009, at 14:05, Doug Hardie wrote: > I have encountered a rather interesting issue trying to install > rc1. The system boots and then says there is no disk in the CD > drive. The rc1 disk1 downloaded fine and the checksums matched. > The CD will mount fine in other systems and can easily be read. I > then let 7.0 boot on the test system and mounted the 7.2 cd. It > mounts fine and I can read all the files ( well a few that I > tested). Looking through the 7.0 dmesg I find some rather > unexpected entries for the CD drive. ... Since I can't boot the CD, I did a source update. Unfortunately I seem to have downloaded one of the kernel modules while it was being updated since it would not compile. Since it was for hardware I don't have, I just commented it out and everything then built just fine. #device ath # Atheros pci/cardbus NIC's #device ath_hal # Atheros HAL (Hardware Access Layer) #device ath_rate_sample # SampleRate tx rate control for ath I usually run a stress test on new releases. Basically I open a ftp to a server (local LAN) and download gigs of data - more than the available free space on the drive. With 7.1, the download would hang about 50% of the time. There was free space remaining on the drive. The NIC was basically useless at that point. The only way to restore it was to reboot. The particular machine I am using right now only has an old decrepit rl NIC: rl0: port 0xe000-0xe0ff mem 0xdd104000-0xdd1040ff irq 12 at device 13.0 on pci0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:d0:09:d8:8f:ff rl0: [ITHREAD] When running this test with 7.2-rc1 it always managed to make it to disk full and then terminate gracefully. Looks like the rl NICs are going to be usable. I had eliminated them from my production servers a long time ago. The only real issue I encountered was that the number of files you have to respond to in mergemaster continues to grow (perhaps exponentially). For my machine I maintain the source on thats no big issue. However, it does cause a lot of additional down time for the servers. I am going to have to dig through mergemaster to see if there is some way to tell it to automatically install the updates to specific directories (e.g., periodic, security, rc.d etc.). I never touch them and they contribute the majority of manual entries. From hlh at restart.be Sun Apr 19 09:39:29 2009 From: hlh at restart.be (Henri Hennebert) Date: Sun Apr 19 09:39:37 2009 Subject: 6.4-STABLE and PHP5 pcre and phpsysinfo In-Reply-To: References: <20090415120024.0E20A1065706@hub.freebsd.org> Message-ID: <49EAF14C.8030908@restart.be> xer wrote: > Hello > Mine 6.4-STABLE today has a strange problem regarding "phpsysinfo" that i use it. > > Ports are updated,but phpsysinfo (on browser) today show errors about pcre: > > > ----------------------- > Notice: Undefined offset: 3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.FreeBSD.inc.php on line 59 > > > ^ a lots > > Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 126 > > > ^ a lots > > Warning: asort() expects parameter 1 to be array, boolean given in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 174 > > > ^ a lots > > > Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 187 > > > ^ a lots > > XPath error in XPath.class.php:3492 Expression failed to parse as PrimaryExpr because: Expression is not a PrimaryExpr > XPath error in XPath.class.php:5903 The supplied xPath > '/phpsysinfo/Vitals/Distro' does not *uniquely* describe a node in the > xml document.Not unique xpath-query, matched 0-times. > > > and more... > -------------------- > It seems that the FreeBSD patch does not work so well, someone use phpsysinfo? > > I did deinstalled php5 and 1.3 extension and reinstalled as expected.. but no resolve. Contrary to /usr/ports/UPDATING - entry 20081211, base php5 (5.2.9) don't contains pcre. You simply have to add /usr/ports/devel/php5-pcre. All will be OK. Henri > Any help please? > Thanx in advance. > > _________________________________________________________________ > Quante ne sai? Scoprilo con CrossWire! > http://clk.atdmt.com/GBL/go/140630367/direct/01/_______________________________________________ > 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 xernet at hotmail.it Sun Apr 19 09:46:28 2009 From: xernet at hotmail.it (xer) Date: Sun Apr 19 09:46:35 2009 Subject: 6.4-STABLE and PHP5 pcre and phpsysinfo In-Reply-To: <49EAF14C.8030908@restart.be> References: <20090415120024.0E20A1065706@hub.freebsd.org> <49EAF14C.8030908@restart.be> Message-ID: Thanx Henri, but php5-pcre is already installed, phpsysinfo was working before (i don't understand what happened) So i did deinstalled pcre and also php5-pcre but the problem regarding phpsysinfo still alive.. -------------------------------------------------- From: "Henri Hennebert" Sent: Sunday, April 19, 2009 11:39 AM To: "xer" Cc: Subject: Re: 6.4-STABLE and PHP5 pcre and phpsysinfo > xer wrote: >> Hello >> Mine 6.4-STABLE today has a strange problem regarding "phpsysinfo" that i >> use it. >> >> Ports are updated,but phpsysinfo (on browser) today show errors about >> pcre: >> >> >> ----------------------- >> Notice: Undefined offset: 3 in >> /usr/local/www/data-dist/phpsysinfo/includes/os/class.FreeBSD.inc.php on >> line 59 >> >> >> ^ a lots >> >> Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() >> error -3 in >> /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php >> on line 126 >> >> >> ^ a lots >> >> Warning: asort() expects parameter 1 to be array, boolean given in >> /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php >> on line 174 >> >> >> ^ a lots >> >> >> Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() >> error -3 in >> /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php >> on line 187 >> >> >> ^ a lots >> >> XPath error in XPath.class.php:3492 Expression failed to parse as >> PrimaryExpr because: Expression is not a PrimaryExpr >> XPath error in XPath.class.php:5903 The supplied xPath >> '/phpsysinfo/Vitals/Distro' does not *uniquely* describe a node in the >> xml document.Not unique xpath-query, matched 0-times. >> >> >> and more... >> -------------------- >> It seems that the FreeBSD patch does not work so well, someone use >> phpsysinfo? >> >> I did deinstalled php5 and 1.3 extension and reinstalled as expected.. >> but no resolve. > > Contrary to /usr/ports/UPDATING - entry 20081211, base php5 (5.2.9) don't > contains pcre. You simply have to add /usr/ports/devel/php5-pcre. All will > be OK. > > Henri > >> Any help please? >> Thanx in advance. >> >> _________________________________________________________________ >> Quante ne sai? Scoprilo con CrossWire! >> http://clk.atdmt.com/GBL/go/140630367/direct/01/_______________________________________________ >> 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 xernet at hotmail.it Sun Apr 19 10:03:03 2009 From: xernet at hotmail.it (xer) Date: Sun Apr 19 10:03:10 2009 Subject: 6.4-STABLE and PHP5 pcre and phpsysinfo [SOLVED] Message-ID: Hello to any1 just solved my silly problem, php5-pcre (for php5.2.9) need to be build with BUNDLED_PCRE, for FreeBSD that have apache 2.0.x (as mine) so make config before install it.. anyway, my problem has been determinated, 'cause i did upgraded the port above (php5-pcre) without a make config before, so, i don't really remember if previous php5-pcre was prebuilt with pcre bundled action for apache 2.0.x thanx again to any1 -------------------------------------------------- From: "xer" Sent: Sunday, April 19, 2009 11:46 AM To: "Henri Hennebert" Cc: Subject: Re: 6.4-STABLE and PHP5 pcre and phpsysinfo > Thanx Henri, but php5-pcre is already installed, phpsysinfo was working > before (i don't understand what happened) > > So i did deinstalled pcre and also php5-pcre but the problem regarding > phpsysinfo still alive.. > > > -------------------------------------------------- > From: "Henri Hennebert" > Sent: Sunday, April 19, 2009 11:39 AM > To: "xer" > Cc: > Subject: Re: 6.4-STABLE and PHP5 pcre and phpsysinfo > >> xer wrote: >>> Hello >>> Mine 6.4-STABLE today has a strange problem regarding "phpsysinfo" that >>> i use it. >>> >>> Ports are updated,but phpsysinfo (on browser) today show errors about >>> pcre: >>> >>> >>> ----------------------- >>> Notice: Undefined offset: 3 in >>> /usr/local/www/data-dist/phpsysinfo/includes/os/class.FreeBSD.inc.php on >>> line 59 >>> >>> >>> ^ a lots >>> >>> Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() >>> error -3 in >>> /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php >>> on line 126 >>> >>> >>> ^ a lots >>> >>> Warning: asort() expects parameter 1 to be array, boolean given in >>> /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php >>> on line 174 >>> >>> >>> ^ a lots >>> >>> >>> Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() >>> error -3 in >>> /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php >>> on line 187 >>> >>> >>> ^ a lots >>> >>> XPath error in XPath.class.php:3492 Expression failed to parse as >>> PrimaryExpr because: Expression is not a PrimaryExpr >>> XPath error in XPath.class.php:5903 The supplied xPath >>> '/phpsysinfo/Vitals/Distro' does not *uniquely* describe a node in the >>> xml document.Not unique xpath-query, matched 0-times. >>> >>> >>> and more... >>> -------------------- >>> It seems that the FreeBSD patch does not work so well, someone use >>> phpsysinfo? >>> >>> I did deinstalled php5 and 1.3 extension and reinstalled as expected.. >>> but no resolve. >> >> Contrary to /usr/ports/UPDATING - entry 20081211, base php5 (5.2.9) don't >> contains pcre. You simply have to add /usr/ports/devel/php5-pcre. All >> will be OK. >> >> Henri >> >>> Any help please? >>> Thanx in advance. >>> >>> _________________________________________________________________ >>> Quante ne sai? Scoprilo con CrossWire! >>> http://clk.atdmt.com/GBL/go/140630367/direct/01/_______________________________________________ >>> 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 piotr.smyrak at heron.pl Sun Apr 19 15:25:23 2009 From: piotr.smyrak at heron.pl (piotr.smyrak@heron.pl) Date: Sun Apr 19 15:25:30 2009 Subject: no USB mice detected on GA-MA74GM-S2 In-Reply-To: <03599684@serv3.int.kfs.ru> References: <20090408190805.GA1368@smyrak.com> <20090408224925.3dd1f8ab@zelda.local> <20090409104532.M16424@heron.pl> <20090412151547.M42910@heron.pl> <3f1fd1ea0904121512m21cfb40crb2e16fa1841f3cb5@mail.gmail.com> <20090412224548.M53466@heron.pl> <3f1fd1ea0904121735t3220cf7dyfce5221a35d7944@mail.gmail.com> <20090413104255.M2582@heron.pl> <3f1fd1ea0904131217y375498c6y41afe7fc9d5c6466@mail.gmail.com> <49E46AF6.30407@bullseye.andymac.org> <20090416193532.M10966@heron.pl> <03599684@serv3.int.kfs.ru> Message-ID: <20090419152433.M84321@heron.pl> On Fri, 17 Apr 2009 14:58:19 +0400, Boris Samorodov wrote > On Thu, 16 Apr 2009 21:36:30 +0200 piotr.smyrak@heron.pl wrote: > > On Tue, 14 Apr 2009 20:52:38 +1000, Andrew MacIntyre wrote > > > Michal Varga wrote: > > > > 2009/4/13 : > > > >> Yes, I'm 100% positive I tried plugging mouse after the boot up had > > > >> finished. Honestly I am late asking here. I was struggling with > > > >> this and looking for cases online for more than 2 weeks at least. > > > >> And I came across your thread from 2007, too. > > > >> > > > > That's really bad. Though closest I can find to your board with > > > > freebsd people I know is AMD770+SB600, while your is AMD740G+SB700, > > > > all of them dating back to my first AMD690G/V (and maybe prior to > > > > that) so far exhibited the same symptoms and the late-plug approach > > > > always worked.. Yours would be then the first one that Gigabyte > > > > botched even more (congrats). I guess that's one more reason to push > > > > on USB guys to finally fix it. > > > > > > If it works with the OP's USB mouse, a USB -> PS/2 (male) > > > adapter might at least get him running provided that the > > > mobo has a PS/2 port... (I know at least some of the > > > Gigabyte 780G boards do, but I don't have any USB mice...) > > > Yes, it has a PS/2 port but it is occupied by my keyboard. Anyway, I have found a > > workaround for my problems. To keep USB working in FreeBSD, all, even this > > built-in smallest hub in my keyboard, have to be disconnected. Then when boot > > finishes I can connect devices, and my mice are detected. Well, this is annoying > > since it means diving under the desk every time computer boots, but at least I can > > work now. > > I had similar problems until I played with USB options at BIOS. > Something like "Legacy USB support", "Detect USB mouse at > startup", etc. You may give it a try. As I said in the beginning of the thread, it was of no use in my case. -- Piotr Smyrak piotr.smyrak@heron.pl From cpghost at cordula.ws Sun Apr 19 15:53:10 2009 From: cpghost at cordula.ws (cpghost) Date: Sun Apr 19 15:53:18 2009 Subject: page fault in sis.ko / drm.ko In-Reply-To: <1240081119.3525.5.camel@balrog.2hip.net> References: <20090418171306.GA1983@phenom.cordula.ws> <1240081119.3525.5.camel@balrog.2hip.net> Message-ID: <20090419155306.GA14114@phenom.cordula.ws> On Sat, Apr 18, 2009 at 01:58:39PM -0500, Robert Noland wrote: > On Sat, 2009-04-18 at 19:13 +0200, cpghost wrote: > > Could a drm guru please have a look at kern/133554? > > Give this patch a try, it looks like the sis driver doesn't have irq's. The patch solves kern/133554 here. sis is working again (including xv etc...), and no more panics. It would be nice if it could still be included in 7.2-RELEASE. ;-) Kind regards and many thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From pmc at citylink.dinoex.sub.org Sun Apr 19 16:43:56 2009 From: pmc at citylink.dinoex.sub.org (Peter Much) Date: Sun Apr 19 16:44:03 2009 Subject: 7.2-PRE: switch virtual console drops crazy characters into X In-Reply-To: <20090416221414.2947e7ed@gluon.draftnet> References: <20090416221414.2947e7ed@gluon.draftnet> Message-ID: <20090419154652.GA19498@gate.oper.dinoex.org> ! I'm also seeing the same issue, but I'm running a custom kernel. I've ! attached a diff from GENERIC. Okay, I send You my diff. Good luck with experimenting! Aeh, FYI: my graphics card identifies itself as Matrox Graphics, Inc. MGA G400/G450 rev 4 and the "device mgadrm" has something to do with that, I have forgotten what. That piece seems currently not to exist as a loadable module. rgds, PMc -------------- next part -------------- - cpu I486_CPU - cpu I586_CPU cpu I686_CPU - device aac - device aacp device adv - device adw - device age device agp - device aha - device ahb - device ahc - device ahd - device aic - device ale - device amd - device amr - device an device apic - device arcmsr - device asr device ata device atadisk device atapicd - device atapifd - device atapist - device ataraid - device ath - device ath_hal - device ath_rate_sample device atkbd device atkbdc - device aue - device awi - device axe - device bce - device bfe - device bge device bpf - device bt - device cardbus - device cbb device cd - device cdce device ch - device ciss device cpufreq - device cs - device cue device da - device dc - device dcons - device dcons_crom device de - device dpt + device drm device ed device ehci - device eisa - device em - device ep - device et device ether - device ex device faith device fdc - device fe - device firewire device firmware - device fwe - device fwip device fxp device gif - device hptiop - device hptmv - device hptrr - device ida - device ie - device igb - device iir - device ips device isp - device ixgb - device jme - device kbdmux - device kue - device le - device lge device loop device lpt device md - device mfi + device mgadrm device miibus - device mlx - device mly - device mpt - device msk - device ncv - device nfe - device nge + device nmdm - device nsp device ohci device pass - device pccard device pci - device pcn device plip device pmtimer device ppbus device ppc device ppi - device ppp - device psm - device pst device pty - device ral device random - device re device rl - device rue - device rum device sa - device sbp device sc device scbus device ses - device sf device sio - device sis - device sk - device sl - device sn + device snd_cmi + device snd_ess + device snd_sbc + device sound - device splash - device ste - device stg - device stge device sym - device ti - device tl - device trm device tun - device twa - device twe - device tx - device txp - device uark - device uart - device ubsa - device ubser device ucom - device uftdi device ugen device uhci device uhid - device uipaq device ukbd device ulpt device umass device ums device uplcom - device ural device urio device usb device uscanner - device uslcom - device uvisor - device uvscom device vga - device vge - device vr - device vx - device wb - device wi - device wlan - device wlan_amrr - device wlan_ccmp - device wlan_scan_ap - device wlan_scan_sta - device wlan_tkip - device wlan_wep - device xe device xl + ident D1R72V1 - ident GENERIC + machine i386 - makeoptions DEBUG=-g - options ADAPTIVE_GIANT - options AHC_REG_PRETTY_PRINT - options AHD_REG_PRETTY_PRINT - options AH_SUPPORT_AR5416 - options ATA_STATIC_ID - options AUDIT + options AUTO_EOI_1 options CD9660 options COMPAT_43TTY + options COMPAT_AOUT - options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 + options COMPAT_LINUX + options DDB + options DUMMYNET options FFS - options GEOM_LABEL - options GEOM_PART_GPT + options HZ=200 + options INCLUDE_CONFIG_FILE options INET options INET6 + options IPDIVERT + options IPFIREWALL + options IPFIREWALL_FORWARD options KBD_INSTALL_CDEV + options KDB options KTRACE + options LIBICONV + options LINPROCFS + options LINSYSFS - options MD_ROOT options MSDOSFS + options NETGRAPH options NFSCLIENT - options NFSLOCKD options NFSSERVER - options NFS_ROOT options PREEMPTION options PROCFS options PSEUDOFS options SCHED_ULE + options SCSI_DELAY=2000 - options SCSI_DELAY=5000 options SCTP options SMP options SOFTUPDATES options STACK options STOP_NMI + options SW_WATCHDOG + options SYM_MUSTEK_6000CX_ID=3 options SYSVMSG options SYSVSEM options SYSVSHM + options UDF + options UDF_ICONV options UFS_ACL options UFS_DIRHASH options UFS_GJOURNAL options _KPOSIX_PRIORITY_SCHEDULING From rabe at uugrn.org Sun Apr 19 17:08:11 2009 From: rabe at uugrn.org (Raphael Becker) Date: Sun Apr 19 17:08:18 2009 Subject: crash on 7.2-RC1 when inserting an empty DVD: supervisor write, page not present Message-ID: <20090419170742.GA2158@ma.sigsys.de> Hi there, from time to time my PC panics when I insert an empty DVD or CD-R. The kernel locks up instantly after the DVD writer's tray is closed. It seems burning the first DVD isn't critical but inserting the second one seems susceptible. I use k3b as software, which polls the hardware while the tray is open, maybe it's something with hald. Don't know, just use this. I don't think this is hardware related since I changed my mainboard recently and had exactly the same crashes with my 2002's model MSI-mainboard with P4/2.4 CPU running FreeBSD 7.x. It seems to be something about ata-code, see kgdb-outbut below. uname -a FreeBSD daemon.ma.sigsys.de 7.2-RC1 FreeBSD 7.2-RC1 #0: Sat Apr 18 14:57:37 CEST 2009 root@daemon.ma.sigsys.de:/usr/obj/usr/src/sys/DAEMON i386 I use atapicam as kernel module. DVD related lines from dmesg: pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib2: irq 17 at device 28.4 on pci0 pci2: on pcib2 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f irq 16 at device 0.0 on pci2 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] acd0: DVDR at ata2-master UDMA66 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata2 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.000MB/s transfers cd0: cd present [1 x 2048 byte records] acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - READ_TOC ILLEGAL REQUEST asc=0x24 ascq=0x00 rabe@daemon:~$ kldstat Id Refs Address Size Name 1 34 0xc0400000 9f73a4 kernel 2 1 0xc0df8000 111b8 geom_eli.ko 3 2 0xc0e0a000 25ff8 crypto.ko 4 2 0xc0e30000 ab40 zlib.ko 5 1 0xc0e3b000 164e8 geom_mirror.ko 6 1 0xc0e52000 78bc geom_stripe.ko 7 1 0xc0e5a000 1ae38 snd_hda.ko 8 2 0xc0e75000 4a64c sound.ko 9 1 0xc0ec0000 4d84 ichsmb.ko 10 2 0xc0ec5000 1be0 smbus.ko 11 1 0xc0ec7000 4dc0 atapicam.ko 12 1 0xc0ecc000 6a45c acpi.ko 13 1 0xc7277000 7000 linprocfs.ko 14 2 0xc727e000 22000 linux.ko 15 1 0xc72d3000 4000 nullfs.ko 16 1 0xc7825000 e000 fuse.ko 17 1 0xc79cc000 4000 fdescfs.ko 18 1 0xc7b37000 2000 rtc.ko 19 1 0xc7c15000 9000 i915.ko 20 1 0xc7c1e000 13000 drm.ko I don't know how to get more out of the crash dump, please tell me. root@daemon:/usr/obj/usr/src/sys/DAEMON# kgdb kernel.debug /var/crash/vmcore.5 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"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xbf5faee6 fault code = supervisor write, page not present instruction pointer = 0x20:0xc0519b00 stack pointer = 0x28:0xc6779c14 frame pointer = 0x28:0xc6779c44 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 = 27 (irq16: fwohci0+++) trap number = 12 panic: page fault cpuid = 1 Uptime: 5h10m20s Physical memory: 3306 MB Dumping 303 MB: 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/geom_eli.ko...Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_eli.ko Reading symbols from /boot/kernel/crypto.ko...Reading symbols from /boot/kernel/crypto.ko.symbols...done. done. Loaded symbols for /boot/kernel/crypto.ko Reading symbols from /boot/kernel/zlib.ko...Reading symbols from /boot/kernel/zlib.ko.symbols...done. done. Loaded symbols for /boot/kernel/zlib.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/geom_stripe.ko...Reading symbols from /boot/kernel/geom_stripe.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_stripe.ko Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichsmb.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:196 #1 0xc07df277 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc07df549 in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0ae0bac in trap_fatal (frame=0xc6779bd4, eva=3210718950) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc0ae0e30 in trap_pfault (frame=0xc6779bd4, usermode=0, eva=3210718950) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc0ae17dc in trap (frame=0xc6779bd4) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc0ac5eeb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0519b00 in ata_pio_read (request=0xc7bedd80, length=18) at cpufunc.h:229 #8 0xc051b195 in ata_end_transaction (request=0xc7bedd80) at /usr/src/sys/dev/ata/ata-lowlevel.c:386 #9 0xc05053f2 in ata_interrupt (data=0xc6a37c00) at /usr/src/sys/dev/ata/ata-all.c:343 #10 0xc0506225 in ata_generic_intr (data=0xc69b9b00) at /usr/src/sys/dev/ata/ata-chipset.c:230 #11 0xc07bd1db in ithread_loop (arg=0xc69f7a70) at /usr/src/sys/kern/kern_intr.c:1088 #12 0xc07b9d29 in fork_exit (callout=0xc07bd020 , arg=0xc69f7a70, frame=0xc6779d38) at /usr/src/sys/kern/kern_fork.c:810 #13 0xc0ac5f60 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:264 Regards Raphael -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- 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/20090419/0d9fd93b/attachment.pgp From rabe at uugrn.org Sun Apr 19 21:29:06 2009 From: rabe at uugrn.org (Raphael Becker) Date: Sun Apr 19 21:29:15 2009 Subject: Getting Logitech USB Receiver ("Cordless Desktop") auto-detected on boot Message-ID: <20090419212839.GA2054@ma.sigsys.de> Hi all, my Logitech USB Receiver isn't automatically detected by the kernel on system boot, not even a LED is glowing. The keyboard is detected and working perfectly by the system BIOS and is usable in BIOS and for the boot loader until the kernel is running. A workaround is disconnecting/reconnecting the USB connector to the PC, to get it detected by the kernel (after mounting root). ukbd0: on uhub2 kbd1 at ukbd0 ums1: on uhub2 ums1: 16 buttons and Z dir. My mainboard has PS/2 connectors for keyboard and mouse so I tried to workaround the USB-problems by disabling the devices in the kernel: nodevice atkbdc # AT keyboard controller nodevice atkbd # AT keyboard nodevice psm # PS/2 mouse But this makes no real difference for USB, just the kernel isn't detecting an "virtual" AT-Keyboard (which isn't really connected to ps/2): before: --- kernel with ps/2 and atkbd support now: +++ kernel without ps/2 and adkbd support --- HW_20090419220146/dmesg.boot 2009-04-19 22:01:46.000000000 +0200 +++ HW_20090419222851/dmesg.boot 2009-04-19 22:28:51.000000000 +0200 -FreeBSD 7.2-RC1 #0: Sat Apr 18 14:57:37 CEST 2009 +FreeBSD 7.2-RC1 #1: Sun Apr 19 22:19:26 CEST 2009 [...] -atkbdc0: port 0x60,0x64 irq 1 on acpi0 -atkbd0: irq 1 on atkbdc0 -kbd0 at atkbd0 -atkbd0: [GIANT-LOCKED] -atkbd0: [ITHREAD] [...] Trying to mount root from ufs:/dev/ufs/ROOT <------ !! ukbd0: on uhub2 -kbd2 at ukbd0 +kbd1 at ukbd0 ums1: on uhub2 ums1: 16 buttons and Z dir. I had to reconnect the USB (to type geli-passphrases), so before and now the ukbd0 is detected after mounting root. I guess most of you have USB keyboards and mouse. Is this problem very common? Is this related to mainboard / usb handling or related to the usb devices? Is this related to the usb connetor on the pc? (actually the receiver is connected to uhub2->usb2->uhci2) My board has about 4 different usb chips uhci0@pci0:0:26:0: class=0x0c0300 card=0x82771043 chip=0x29378086 rev=0x02 hdr=0x00 uhci1@pci0:0:26:1: class=0x0c0300 card=0x82771043 chip=0x29388086 rev=0x02 hdr=0x00 uhci2@pci0:0:26:2: class=0x0c0300 card=0x82771043 chip=0x29398086 rev=0x02 hdr=0x00 ehci0@pci0:0:26:7: class=0x0c0320 card=0x82771043 chip=0x293c8086 rev=0x02 hdr=0x00 All the USB stuff from dmesg: uhci0: port 0xc480-0xc49f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xc880-0xc89f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xfe7fbc00-0xfe7fbfff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered uhub4: on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered ums0: on uhub4 ums0: 3 buttons and Z dir. ulpt0: on uhub4 ulpt0: using bi-directional mode (ums0 is not the logitec mouse) Why doesn't the kernel detect the Logitech USB Receiver? Any suggestions? TIA and Regards Raphael -- Raphael Becker http://rabe.uugrn.org/ GnuPG: E7B2 1D66 3AF2 EDC7 9828 6D7A 9CDA 3E7B 10CA 9F2D .........|.........|.........|.........|.........|.........|.........|.. -------------- 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/20090419/19296bac/attachment.pgp From m.e.sanliturk at gmail.com Sun Apr 19 22:03:41 2009 From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk) Date: Sun Apr 19 22:03:48 2009 Subject: FreeBSD 7.2 RC1 amd64 Installation In-Reply-To: <1240098983.27699.44.camel@neo.cse.buffalo.edu> References: <1240098983.27699.44.camel@neo.cse.buffalo.edu> Message-ID: On Sat, Apr 18, 2009 at 7:56 PM, Ken Smith wrote: > On Sat, 2009-04-18 at 19:04 -0400, Mehmet Erol Sanliturk wrote: > > > I'll take this into consideration moving forward but just so you know it > likely won't be addressed as part of 7.2-REL. It's likely you would > need to be at least a little more selective in what packages you install > if you want to avoid these sorts of package install failures caused by > conflicts. > (1) During package selection if a conflict exits , the user may be warned with a message , for example : Selection of ... requires de-selection of previously selected package(s) ... ( list of packages ) In that way it is possible to make a suitable decision . At present it is necessary to know which packages are conflicting . During a learning process of FreeBSD this causes difficulty . (2) At present , only package names are listed . If it is easy and/or possible a short description of package may be displayed in a separate pane which would be very helpful for selection . All of the descriptions are present in port related FreeBSD web site pages . >From there short summaries may be copied . (3) During installation of packages a counter would be informative about progress . And listing of installed packages in a pane shows package dependencies and detailed progress . (4) For unattended installs , when an error occurs it may be listed in another pane and it may be appended to an error message file . At present it is waiting a user entry for enter key pressing . Therefore , at present package install part requires to wait there up to completion . (5) In .../Latest/package_name.tbz directory , only package names are listed . Persons knowing FreeBSD very well can understand attributes of packages but this is difficult at the beginning . Over time addition of short explanatory sentences at the side of package names increases their comprehensibility . (6) When a package is tried to be installed in Mandriva Linux , it is asking Mandriva DVD if it is present in it . Such a technique may be used for port package updates in FreeBSD . After an installation , later on when the user wants to install a new package , pkg_add may check the update web sites . If the package is updated there it installs it from the update site . If it is not updated yet and it is present in installation DVD or CD , pkg_add (and other update utilities also ) displays a message like , for example : install from DVD , enter D for it , install from CD numbered .. , enter C for it , install from update site , enter S for it . ( The user may not have DVD or CD at hand ) In that way , for many installs , FreeBSD web site traffic may be reduced for unnecessary re-downloads . (7) The above ideas may be utilized over time if they are found useful . I am not expecting that they will be implemented instantly because some of them require much work to be done ( this means time and resources ) . Thank you very much . Mehme Erol Sanliturk From exemys at exemys.com Mon Apr 20 07:18:05 2009 From: exemys at exemys.com (Exemys) Date: Mon Apr 20 07:18:13 2009 Subject: TCP/IP Sensors and Transducers Message-ID: <5c84f216f7b41674ae58806ab1cd07b7@www.hostmailing.com> 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 avg at icyb.net.ua Mon Apr 20 10:04:56 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 20 10:05:03 2009 Subject: panic: nfs sndunlock Message-ID: <49EC48C2.20402@icyb.net.ua> System is stable/7: 7.2-PRERELEASE r191214 i386 uni-processor. NFS mount options: ro,noauto,nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768 The panic occurred on client after losing and then restoring connectivity with NFS server. There may have been parallel access to NFS-mounted tree at the time of the accident. Kernel messages just before the panic: kernel: nfs server odyssey:/usr/ports: not responding kernel: nfs send error 57 for server odyssey:/usr/ports kgdb information: #0 doadump () at pcpu.h:196 #1 0xc0555a33 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc0555c7f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc064be63 in nfs_connect_unlock (rep=0x0) at /usr/src/sys/nfsclient/nfs_socket.c:1819 #4 0xc064da24 in nfs_reconnect (rep=0xc40a0c80) at /usr/src/sys/nfsclient/nfs_socket.c:581 #5 0xc064ff50 in nfs_request (vp=0xc4464450, mrest=0xc435a000, procnum=3, td=0xc398cd20, cred=0xc420b800, mrp=0xdac06a04, mdp=0xdac06a00, dposp=0xdac06a08) at /usr/src/sys/nfsclient/nfs_socket.c:737 #6 0xc065d3f2 in nfs_lookup (ap=0xdac06a84) at /usr/src/sys/nfsclient/nfs_vnops.c:922 #7 0xc0729cd6 in VOP_LOOKUP_APV (vop=0xc07a0fe0, a=0xdac06a84) at vnode_if.c:99 #8 0xc05cad71 in lookup (ndp=0xdac06ba8) at vnode_if.h:57 #9 0xc05cbab8 in namei (ndp=0xdac06ba8) at /usr/src/sys/kern/vfs_lookup.c:220 #10 0xc05db02d in kern_stat (td=0xc398cd20, path=0x2814d040
, pathseg=UIO_USERSPACE, sbp=0xdac06c18) at /usr/src/sys/kern/vfs_syscalls.c:2123 #11 0xc05db21f in stat (td=0xc398cd20, uap=0xdac06cfc) at /usr/src/sys/kern/vfs_syscalls.c:2107 #12 0xc0712055 in syscall (frame=0xdac06d38) at /usr/src/sys/i386/i386/trap.c:1090 #13 0xc06ff290 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 I am not sure why rep parameter shows up as NULL in nfs_connect_unlock call. In frame 4: (kgdb) p/x rep->r_nmp->nm_state $2 = 0x10100000 I am keeping the core file. -- Andriy Gapon From a.selivanov at createmedia.ru Mon Apr 20 12:22:51 2009 From: a.selivanov at createmedia.ru (Andrei Selivanov) Date: Mon Apr 20 12:22:59 2009 Subject: Gigabit cardbus re nic fails to attach Message-ID: <49EC650F.9010005@createmedia.ru> hi all Per Otterstr?m wrote: > Hi all. > > I'm running 7.1-RELEASE. > > When I plug in my D-Link DGE-660TD gigabit cardbus adapter I get: > > re0: port > 0x4000-0x40ff mem 0xd0201000-0xd02011ff irq 11 at device 0.0 on cardbus1 > re0: Chip rev. 0x10000000 > re0: MAC rev. 0x00000000 > re0: PHY write failed > re0: PHY write failed > re0: PHY read failed > re0: MII without any phy! > device_attach: re0 attach returned 6 > > Relevant part from pciconf -lv: > > r...@pci0:6:0:0: class=0x020000 card=0x43011186 chip=0x816910ec rev=0x10 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8110SB Single-Chip Gigabit LOM Ethernet Controller' > class = network > subclass = ethernet > > I've seen several patches for similar problems provided by Pyun YongHyeon, > but I don't think any one of them are applicable in my case. > > Any advice appreciated. > > regards, Pelle i got same error on my 7.1 i386 dmesg output with hw.cardbus.debug="1" and hw.cardbus.cis_debug="1" is here - http://pastebin.com/m63175351 i am ready to give shell access if anyone need it wbr Andrei From lehmann at ans-netz.de Mon Apr 20 13:53:02 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Mon Apr 20 13:53:10 2009 Subject: dri + ATI: dramatic performance slowdown Message-ID: <20090420152620.8f89edd5.lehmann@ans-netz.de> Hi, as I found out in the meantime - the following described problem can be only worked around when 'Load "dri"' is removed from the server section, and 'Option "DRI" "true"' is removed from the Device section. Otherwise: I've synced my pre-drm-changes 7-STABLE to the latest 7-STABLE. Now the grafic performance in xorg decreased dramatically. Moving a window or resizing a window makes me feel sent back 15 years ago ;). I can "see" the window resizing. The popup of an window is fast, but moving it around or scrolling... jesus that is what I call slow. Firefox is nearly not usable for example :( I wonder what is causing this. I'm using a ATI Radeon HD3850 in it's AGP version (probably kinda uncommon). olivleh1@kartoffel olivleh1> dmesg | grep drm drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd8000000 128MB info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV670 CP Microcode info: [drm] Loading RV670 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] olivleh1@kartoffel olivleh1> pkg_info | grep radeon xf86-video-radeonhd-1.2.5 X.Org ati RadeonHD display driver olivleh1@kartoffel olivleh1> >From my xorg.conf: Section "Module" Load "dbe" Load "freetype" Load "glx" Load "dri" EndSection Section "Device" Identifier "ATI1" BoardName "ATI Radeon" Driver "radeonhd" BusID "PCI:1:0:0" Option "Monitor-DVI-I_1/digital" "Syncmaster DVI1" Option "Monitor-DVI-I_2/digital" "Syncmaster DVI2" Option "DRI" "true" EndSection the whole xorg.conf can be found here: http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 Is this expected to happen with DRI enabled? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From rnoland at FreeBSD.org Mon Apr 20 14:35:04 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Apr 20 14:35:28 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090420152620.8f89edd5.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> Message-ID: <1240238090.3930.0.camel@balrog.2hip.net> On Mon, 2009-04-20 at 15:26 +0200, Oliver Lehmann wrote: > Hi, > > as I found out in the meantime - the following described problem can be > only worked around when 'Load "dri"' is removed from the server > section, and 'Option "DRI" "true"' is removed from the Device > section. Otherwise: > > I've synced my pre-drm-changes 7-STABLE to the latest 7-STABLE. Now the > grafic performance in xorg decreased dramatically. Moving a window or > resizing a window makes me feel sent back 15 years ago ;). I can "see" the > window resizing. The popup of an window is fast, but moving it around or > scrolling... jesus that is what I call slow. Firefox is nearly not usable > for example :( > > I wonder what is causing this. I'm using a ATI Radeon HD3850 in it's AGP > version (probably kinda uncommon). > > olivleh1@kartoffel olivleh1> dmesg | grep drm > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xd8000000 128MB Can you show me the output of memcontrol list, with drm enabled. robert. > info: [drm] Initialized radeon 1.29.0 20080528 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading RV670 CP Microcode > info: [drm] Loading RV670 PFP Microcode > info: [drm] Resetting GPU > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > olivleh1@kartoffel olivleh1> pkg_info | grep radeon > xf86-video-radeonhd-1.2.5 X.Org ati RadeonHD display driver > olivleh1@kartoffel olivleh1> > > >From my xorg.conf: > > Section "Module" > Load "dbe" > Load "freetype" > Load "glx" > Load "dri" > EndSection > Section "Device" > > Identifier "ATI1" > BoardName "ATI Radeon" > Driver "radeonhd" > BusID "PCI:1:0:0" > Option "Monitor-DVI-I_1/digital" "Syncmaster DVI1" > Option "Monitor-DVI-I_2/digital" "Syncmaster DVI2" > Option "DRI" "true" > EndSection > > the whole xorg.conf can be found here: > > http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 > > Is this expected to happen with DRI enabled? -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090420/2e462a72/attachment.pgp From hlh at restart.be Mon Apr 20 14:49:51 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Apr 20 14:49:58 2009 Subject: 7.2-RC1 - serial console / sio0 not working In-Reply-To: <49EC48C2.20402@icyb.net.ua> References: <49EC48C2.20402@icyb.net.ua> Message-ID: <49EC8B8B.8010101@restart.be> Hello, Experiencing some deadlock, I try to reenable my serial console on 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and -Dh or -Dh -S115200 in /boot.config). /var/log/message show: 'sio0: type 16550A, console' and from the vga point of view, console output from kernel is slow as if echoed on a serial and rc output is going somewhere. At the other end of the serial, minicom show nothing and is 'offline'. A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' has no effect. The cable is working fine (serial console mode) with another box in 8.0-CURRENT. If I disable serial console and try minicom on 7.2-RC1, status is offline but any key is recieved at the other end and any key type at the other end is displayed fine. Does anyone encounter such a problem ? Thanks in advance henri From olivas at new.digiflux.org Mon Apr 20 14:57:12 2009 From: olivas at new.digiflux.org (Stacy Olivas) Date: Mon Apr 20 14:57:20 2009 Subject: cardbus0 and Xircom X3201 10/100BaseTX problems Message-ID: <49EC8D3A.9070602@new.digiflux.org> Hello, Got a quick question about the Xircom X3201 PCMCIA card with FreeBSD 7.2-PRERELEASE. I recently upgraded from 6.2-STABLE to 7.2-PRERELEASE, and after the upgrade, I noticed that my Xircom card was not working. Here is what I get when the system boots or I remove and re-insert the card: cardbus0: Unable to allocate resource to read CIS. cardbus0: Unable to allocate resources for CIS dc0: port 0x1100-0x117f mem 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on cardbus0 dc0: No station address in CIS! device_attach: dc0 attach returned 6 Anyone else having this issue? I"ve found this patch that was supposed to fix the issue: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F115623&cat= Not sure if it was actually incorporated into 7.2-PRERELEASE though. Ideas? Thanks -Stacy From hlh at restart.be Mon Apr 20 15:07:22 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Apr 20 15:07:29 2009 Subject: 7.2-RC1 - serial console / sio0 not working Message-ID: <49EC8FA5.6080609@restart.be> Sorry for the previous wrong followup :-( Hello, Experiencing some deadlock, I try to reenable my serial console on 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and -Dh or -Dh -S115200 in /boot.config). /var/log/message show: 'sio0: type 16550A, console' and from the vga point of view, console output from kernel is slow as if echoed on a serial and rc output is going somewhere. At the other end of the serial, minicom show nothing and is 'offline'. A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' has no effect. The cable is working fine (serial console mode) with another box in 8.0-CURRENT. If I disable serial console and try minicom on 7.2-RC1, status is offline but any key is recieved at the other end and any key type at the other end is displayed fine. Does anyone encounter such a problem ? Thanks in advance henri From info at martenvijn.nl Mon Apr 20 15:25:01 2009 From: info at martenvijn.nl (Marten Vijn) Date: Mon Apr 20 15:25:08 2009 Subject: 7.2-RC1 - serial console / sio0 not working In-Reply-To: <49EC8B8B.8010101@restart.be> References: <49EC48C2.20402@icyb.net.ua> <49EC8B8B.8010101@restart.be> Message-ID: <1240240495.20308.10.camel@polaris> On Mon, 2009-04-20 at 16:49 +0200, Henri Hennebert wrote: > Hello, > > Experiencing some deadlock, I try to reenable my serial console on > 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and > -Dh or -Dh -S115200 in /boot.config). > > /var/log/message show: 'sio0: type 16550A, console' and from the vga > point of view, console output from kernel is slow as if echoed on a > serial and rc output is going somewhere. > > At the other end of the serial, minicom show nothing and is 'offline'. > A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' > has no effect. > > The cable is working fine (serial console mode) with another box in > 8.0-CURRENT. > > If I disable serial console and try minicom on 7.2-RC1, status is > offline but any key is recieved at the other end and any key type at the > other end is displayed fine. > > Does anyone encounter such a problem ? maybe diff /etc/ttys between 8.0 and 7.2 I had problems updrading a machine (over serial console) lately, (7.1.to Current) Marten > > Thanks in advance > > henri > _______________________________________________ > 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" -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From hlh at restart.be Mon Apr 20 15:47:31 2009 From: hlh at restart.be (Henri Hennebert) Date: Mon Apr 20 15:47:41 2009 Subject: 7.2-RC1 - serial console / sio0 not working In-Reply-To: <1240240495.20308.10.camel@polaris> References: <49EC48C2.20402@icyb.net.ua> <49EC8B8B.8010101@restart.be> <1240240495.20308.10.camel@polaris> Message-ID: <49EC990E.6010302@restart.be> Marten Vijn wrote: > On Mon, 2009-04-20 at 16:49 +0200, Henri Hennebert wrote: >> Hello, >> >> Experiencing some deadlock, I try to reenable my serial console on >> 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and >> -Dh or -Dh -S115200 in /boot.config). >> >> /var/log/message show: 'sio0: type 16550A, console' and from the vga >> point of view, console output from kernel is slow as if echoed on a >> serial and rc output is going somewhere. >> >> At the other end of the serial, minicom show nothing and is 'offline'. >> A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' >> has no effect. >> >> The cable is working fine (serial console mode) with another box in >> 8.0-CURRENT. >> >> If I disable serial console and try minicom on 7.2-RC1, status is >> offline but any key is recieved at the other end and any key type at the >> other end is displayed fine. >> >> Does anyone encounter such a problem ? > > maybe diff /etc/ttys > > between 8.0 and 7.2 I don't use the serial for login, so I believe it is not important in my case. Thank you for your time Henri > > I had problems updrading a machine (over serial console) > lately, (7.1.to Current) > > Marten > >> Thanks in advance >> >> henri >> _______________________________________________ >> 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 leslie at eskk.nu Mon Apr 20 15:48:53 2009 From: leslie at eskk.nu (Leslie Jensen) Date: Mon Apr 20 15:49:00 2009 Subject: ACPI Errors in 7.2-RC1 security run output Message-ID: <49EC94D6.2020709@eskk.nu> I don't know if this is useful to anyone but I'll post it for evaluation. /Leslie kernel log messages: +++ /tmp/security.rACT66f0 2009-04-19 18:02:16.000000000 +0200 +FreeBSD 7.2-RC1 #0: Wed Apr 15 19:47:40 UTC 2009 +CPU: Intel(R) Core(TM)2 Duo CPU P9500 @ 2.53GHz (2527.01-MHz K8-class CPU) +usable memory = 4268974080 (4071 MB) +avail memory = 4103565312 (3913 MB) +dcons_crom0: on firewire0 +dcons_crom0: bus_addr 0x1450000 +ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xffffff0001612d00 [20070320] +ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU0._OSC] (Node 0xffffff00015c4c40), AE_AML_INTERNAL +ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xffffff0001612800 [20070320] +ACPI Error (psparse-0626): Method parse/execution failed [\\_PR_.CPU1._OSC] (Node 0xffffff00015c4b60), AE_AML_INTERNAL +GEOM_LABEL: Label for provider ad4s3a is ufsid/49d89a583b1aab71. +GEOM_LABEL: Label for provider ad4s3d is ufsid/49d89a5ad56723d6. +GEOM_LABEL: Label for provider ad4s3e is ufsid/49d89a59e70514cb. +GEOM_LABEL: Label for provider ad4s3f is ufsid/49d89a59678efa0c. +GEOM_LABEL: Label for provider ad4s3g is ufsid/49d89a5868bc195a. +GEOM_LABEL: Label ufsid/49d89a583b1aab71 removed. +GEOM_LABEL: Label for provider ad4s3a is ufsid/49d89a583b1aab71. +GEOM_LABEL: Label ufsid/49d89a5868bc195a removed. +GEOM_LABEL: Label for provider ad4s3g is ufsid/49d89a5868bc195a. +GEOM_LABEL: Label ufsid/49d89a59e70514cb removed. +GEOM_LABEL: Label for provider ad4s3e is ufsid/49d89a59e70514cb. +GEOM_LABEL: Label ufsid/49d89a59678efa0c removed. +GEOM_LABEL: Label for provider ad4s3f is ufsid/49d89a59678efa0c. +GEOM_LABEL: Label ufsid/49d89a5ad56723d6 removed. +GEOM_LABEL: Label for provider ad4s3d is ufsid/49d89a5ad56723d6. +GEOM_LABEL: Label ufsid/49d89a583b1aab71 removed. +GEOM_LABEL: Label ufsid/49d89a5868bc195a removed. +GEOM_LABEL: Label ufsid/49d89a59e70514cb removed. +GEOM_LABEL: Label ufsid/49d89a59678efa0c removed. +GEOM_LABEL: Label ufsid/49d89a5ad56723d6 removed. +em0: link state changed to UP From olivas at new.digiflux.org Mon Apr 20 16:17:19 2009 From: olivas at new.digiflux.org (Stacy Olivas) Date: Mon Apr 20 16:17:25 2009 Subject: cardbus0 and Xircom X3201 10/100BaseTX problems In-Reply-To: <49EC8D3A.9070602@new.digiflux.org> References: <49EC8D3A.9070602@new.digiflux.org> Message-ID: <49EC9FFF.5020706@new.digiflux.org> Stacy Olivas wrote: > it to -stable instead> > > Hello, > Got a quick question about the Xircom X3201 PCMCIA card with FreeBSD > 7.2-PRERELEASE. > I"ve found this patch that was supposed to fix the issue: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern%2F115623&cat= > > Not sure if it was actually incorporated into 7.2-PRERELEASE though. > Update: I had some time to look at the code in the patch and compare it against the cardbus_cis.c file on my system. The patch has not been added. I've patched my cardbus_cis.c file and recompiled the kernel. My Xircom card works now with no issues. This is the output now when the system boots: dc0: port 0x1100-0x117f mem 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on cardbus0 miibus0: on dc0 tdkphy0: PHY 0 on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:10:a4:b2:72:ef dc0: [ITHREAD] I've also submitted a follow-up PR with my results. Any ideas if the patch will ever be incorporated into the codebase? Thanks. -Stacy From jb000003 at mr-happy.com Mon Apr 20 20:46:43 2009 From: jb000003 at mr-happy.com (Jeff Blank) Date: Mon Apr 20 20:46:51 2009 Subject: bge problems under 7.2-PRERELEASE Message-ID: <20090420204637.GA1236@mr-happy.com> Hi, csup today around 13:00 UTC. 'make buildworld', 'make buildkernel', 'make installkernel', reboot to single-user. # ifconfig bge0 141.219.5.33/22 up # ping 141.219.4.1 PING 141.219.4.1 (141.219.4.1): 56 data bytes ^C --- 141.219.4.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # ifconfig bge0 bge0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1e:c9:44:30:14 inet6 fe80::21e:c9ff:fe44:3014%bge0 prefixlen 64 scopeid 0x1 inet 141.219.5.33 netmask 0xfffffc00 broadcast 141.219.7.255 media: Ethernet autoselect (100baseTX ) status: active I have no trouble with networking using a kernel from 20090115. This is a Dell Optiplex 740, about 9 months old. make.conf and src.conf are below. dmesg and pciconf output are attached. I ran 'tcpdump -i bge0 -nn' while pinging, and this captured no packets, not even this host's ARP broadcasts. I also encountered this problem in late March as well, just after RELENG_7 became 7.2-PRERELEASE, but couldn't find time to put this information together. If there's anything else I can run to troubleshoot this, please let me know. thank you, Jeff Blank /etc/make.conf: CPUTYPE ?= k8 WITHOUT_NLS=true [port-specific options elided for brevity] /etc/src.conf: WITHOUT_ATM=true WITHOUT_GPIB=true WITHOUT_I4B=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_LIB32=true WITHOUT_NCP=true WITHOUT_NDIS=true WITHOUT_PPP=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_SENDMAIL=true WITHOUT_SLIP=true WITHOUT_WIRELESS=true -------------- next part -------------- # 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-PRERELEASE #0: Mon Apr 20 12:27:26 EDT 2009 root@bender.tc.mtu.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2906.08-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant Cores per package: 2 usable memory = 4278718464 (4080 MB) avail memory = 4098314240 (3908 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0: Changing APIC ID to 4 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, bfdd0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 bge0: mem 0xfd8f0000-0xfd8fffff irq 16 at device 0.0 on pci2 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1e:c9:44:30:14 bge0: [ITHREAD] pcib3: at device 4.0 on pci0 pci3: on pcib3 vgapci0: port 0xbc00-0xbcff mem 0xd0000000-0xdfffffff,0xfddf0000-0xfddfffff irq 16 at device 0.0 on pci3 vgapci1: mem 0xfdde0000-0xfddeffff at device 0.1 on pci3 pci0: at device 9.0 (no driver attached) isab0: port 0x1d00-0x1dff at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 8 ports with 8 removable, self powered uhub2: on uhub1 uhub2: multiple transaction translators uhub2: 4 ports with 4 removable, self powered ums0: on uhub2 ums0: 5 buttons and Z dir. atapci0: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 23 at device 14.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] atapci1: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 20 at device 15.0 on pci0 atapci1: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] pcib4: at device 16.0 on pci0 pci4: on pcib4 hdac0: mem 0xfe024000-0xfe027fff irq 21 at device 16.1 on pci0 hdac0: HDA Driver Revision: 20090329_0131 hdac0: [ITHREAD] sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: [ITHREAD] plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 orm0: at iomem 0xc0000-0xcf7ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: on uhub0 kbd2 at ukbd0 ums1: on uhub0 ums1: 3 buttons and Z dir. WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 6 ZFS storage pool version 6 ad4: 152587MB at ata2-master SATA300 ad6: 152587MB at ata3-master SATA300 GEOM_MIRROR: Device mirror/gm0 launched (1/2). GEOM_MIRROR: Device gm0: rebuilding provider ad4. acd0: CDROM at ata4-master SATA150 acd1: CDRW at ata5-master SATA150 hdac0: HDA Codec #0: Sigmatel STAC9220 pcm0: at cad 0 nid 1 on hdac0 GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/4856c1053a1b8b74. acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe1:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe1:ata3:0:0:0): CAM Status: SCSI Status Error (probe1:ata3:0:0:0): SCSI Status: Check Condition (probe1:ata3:0:0:0): NOT READY asc:3a,1 (probe1:ata3:0:0:0): Medium not present - tray closed (probe1:ata3:0:0:0): Unretryable error acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata2:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata2:0:0:0): CAM Status: SCSI Status Error (probe0:ata2:0:0:0): SCSI Status: Check Condition (probe0:ata2:0:0:0): NOT READY asc:3a,0 (probe0:ata2:0:0:0): Medium not present (probe0:ata2:0:0:0): Unretryable error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd1 at ata3 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device ScMdP1:: 3A.P 3C0P0UM B#/s1 tLraaunnscfheerds! cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed cd0 at ata2 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from zfs:zgm0/root GEOM_LABEL: Label ufsid/4856c1053a1b8b74 removed. GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/4856c1053a1b8b74. GEOM_LABEL: Label ufsid/4856c1053a1b8b74 removed. # pciconf -lv none0@pci0:0:0:0: class=0x050000 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none1@pci0:0:0:1: class=0x050000 card=0x02fa10de chip=0x02fa10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 0' class = memory subclass = RAM none2@pci0:0:0:2: class=0x050000 card=0x02fe10de chip=0x02fe10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 1' class = memory subclass = RAM none3@pci0:0:0:3: class=0x050000 card=0x02f810de chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 5' class = memory subclass = RAM none4@pci0:0:0:4: class=0x050000 card=0x02f910de chip=0x02f910de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 4' class = memory subclass = RAM none5@pci0:0:0:5: class=0x050000 card=0x02ff10de chip=0x02ff10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none6@pci0:0:0:6: class=0x050000 card=0x027f10de chip=0x027f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 3' class = memory subclass = RAM none7@pci0:0:0:7: class=0x050000 card=0x027e10de chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 2' class = memory subclass = RAM pcib1@pci0:0:2:0: class=0x060400 card=0x000010de chip=0x02fc10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x000010de chip=0x02fd10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib3@pci0:0:4:0: class=0x060400 card=0x000010de chip=0x02fb10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI none8@pci0:0:9:0: class=0x050000 card=0xcb8410de chip=0x027010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Host Bridge' class = memory subclass = RAM isab0@pci0:0:10:0: class=0x060100 card=0x01ec1028 chip=0x026010de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 LPC Bridge' class = bridge subclass = PCI-ISA none9@pci0:0:10:1: class=0x0c0500 card=0x01ec1028 chip=0x026410de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI System Management' class = serial bus subclass = SMBus none10@pci0:0:10:2: class=0x050000 card=0x01ec1028 chip=0x027210de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Memory Controller 0' class = memory subclass = RAM ohci0@pci0:0:11:0: class=0x0c0310 card=0x01ec1028 chip=0x026d10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:11:1: class=0x0c0320 card=0x01ec1028 chip=0x026e10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:14:0: class=0x010185 card=0x01ec1028 chip=0x026610de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:15:0: class=0x010185 card=0x01ec1028 chip=0x026710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA pcib4@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'MCP51 PCI Bridge' class = bridge subclass = PCI-PCI hdac0@pci0:0:16:1: class=0x040300 card=0x1f901028 chip=0x026c10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 High Definition Audio' class = multimedia subclass = HDA hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI bge0@pci0:2:0:0: class=0x020000 card=0x01ec1028 chip=0x167a14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5754 Broadcom NetXtreme Gigabit Ethernet Controller' class = network subclass = ethernet vgapci0@pci0:3:0:0: class=0x030000 card=0x0920174b chip=0x71471002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X1550 64-bit (RV505)' class = display subclass = VGA vgapci1@pci0:3:0:1: class=0x038000 card=0x0921174b chip=0x71671002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon X1300 Series Secondary' class = display # From wblock at wonkity.com Tue Apr 21 00:29:30 2009 From: wblock at wonkity.com (Warren Block) Date: Tue Apr 21 00:29:37 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090420152620.8f89edd5.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> Message-ID: On Mon, 20 Apr 2009, Oliver Lehmann wrote: > as I found out in the meantime - the following described problem can be > only worked around when 'Load "dri"' is removed from the server > section, and 'Option "DRI" "true"' is removed from the Device > section. Otherwise: > the whole xorg.conf can be found here: > > http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 No DRI Section? Section "DRI" Group 0 Mode 0660 EndSection I suspect the DRI option in the driver is there to easily disable DRI, and Option "DRI" "On" does not replace the DRI section. But I don't know that for a fact. -Warren Block * Rapid City, South Dakota USA From pyunyh at gmail.com Tue Apr 21 00:48:30 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Apr 21 00:48:36 2009 Subject: watchdog timeout In-Reply-To: <20090410044340.GJ37714@michelle.cdnetworks.co.kr> References: <20090407120032.633E410656D5@hub.freebsd.org> <20090410044340.GJ37714@michelle.cdnetworks.co.kr> Message-ID: <20090421005209.GD93322@michelle.cdnetworks.co.kr> On Fri, Apr 10, 2009 at 01:43:40PM +0900, Pyun YongHyeon wrote: > On Wed, Apr 08, 2009 at 10:41:44AM +0200, xer wrote: > > Hello > > I have some problems with 3Com nics, after a upgrade from 5.5-STABLE to > > 6.4-STABLE. > > > > This machine has two 3com nics (one is LAN other is WAN) and i see too much > > "watchdog timeout" on both cards. > > This on/off up/down on cards, affect the interrupt to clients that are > > downloading from apache web server, especially on large files. > > > > -------------------------------------------- > > xer:/root# dmesg > > xl1: watchdog timeout > > xl1: link state changed to DOWN > > xl1: link state changed to UP > > xl1: watchdog timeout > > xl1: link state changed to DOWN > > xl1: link state changed to UP > > xl1: watchdog timeout > > xl1: link state changed to DOWN > > xl1: link state changed to UP > > --------------------------------------------- > > > > xer:/root# cat /var/run/dmesg.boot | grep xl > > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem > > 0xfceffc00-0xfceffc7f irq 23 at device 11.0 on pci2 > > miibus0: on xl0 > > xlphy0: <3c905C 10/100 internal PHY> on miibus0 > > xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > xl0: Ethernet address: 00:01:02:e0:04:1b > > xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0xe880-0xe8ff mem > > 0xfceff800-0xfceff87f irq 20 at device 12.0 on pci2 > > miibus1: on xl1 > > xlphy1: <3c905C 10/100 internal PHY> on miibus1 > > xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > xl1: Ethernet address: 00:01:02:df:fe:ed > > --------------------------------------------- > > Another doubt would be my kernel config, maybe there is something wrong > > that i cannot see, i'll post at the end of this post, 'cause is too long. > > > > As you can see, the cards are 3c905C-TX model. > > Someone told me to change drivers, but i cannot understand this advice. > > I got same errors with same cards but with another mainboard, same problem, > > watchdog appears after an upgrade from 5.4-STABLE to 6.4-STABLE. > > > > I don't think that to change nic's pci slots, will solve the problem, i > > think that maybe change the nics would resolve the matter, but i cannot > > access to both FreeBSD phisically, cause the boxes are too far from me > > (about 3500 km). > > > > I'm asking you some advices, and i can i fix this problem. > > p.s. with both 5.4 or 5.5 old kernel, the nics was fine. > > > > I vaguely remember there were a couple of reports on xl(4) watchdog > timeouts. I'm not sure this came from missing Tx interrupts but > would you try attached patch? > Note, it was generated against HEAD and you should experiment the > attached patch on local box prior to applying to your production > server. For the records, patch committed to HEAD(r191344, r191345). From mike at sentex.net Tue Apr 21 05:25:03 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Apr 21 05:25:09 2009 Subject: RELENG_7 crash Message-ID: <200904210524.n3L5O9YS086865@lava.sentex.ca> The box has a fairly heavy UDP load. Its RELENG_7 as of today and took 3hrs for it to dump core. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0637146 stack pointer = 0x28:0xe766eaac frame pointer = 0x28:0xe766eb54 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 = 761 (bsnmpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 3h47m43s Physical memory: 2036 MB Dumping 83 MB: 68 52 36 20 4 (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05964d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05967a9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc07f64ac in trap_fatal (frame=0xe766ea6c, eva=104) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc07f6730 in trap_pfault (frame=0xe766ea6c, usermode=0, eva=104) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc07f70dc in trap (frame=0xe766ea6c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc07db7eb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 #8 0xc059fd77 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1413 #9 0xc059ff14 in userland_sysctl (td=0xc5374460, name=0xe766ec14, namelen=6, old=0x0, oldlenp=0xbfbf8478, inkernel=0, new=0x0, newlen=0, retval=0xe766ec10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1506 #10 0xc05a0064 in __sysctl (td=0xc5374460, uap=0xe766ecfc) at /usr/src/sys/kern/kern_sysctl.c:1443 #11 0xc07f6a85 in syscall (frame=0xe766ed38) at /usr/src/sys/i386/i386/trap.c:1090 #12 0xc07db850 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -------------------------------------------------------------------- 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 bms at incunabulum.net Tue Apr 21 07:00:58 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Apr 21 07:01:06 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> Message-ID: <49ED6AD2.4010006@incunabulum.net> Hi, Looks like I'm late to the party. I was responsible for committing these ath(4) changes to RELENG_7. I can't remember if I tested the kernel compile without the AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. Dennis Melentyev wrote: > 2009/4/16 Maxim Sobolev : > >> Dennis Melentyev wrote: >> >>> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. >>> >> My point is that if the option is mandatory for compiling ath(4) driver, >> then there is no point in having this option in the first place. >> > > Well, fair. > +1 from me :). > > So is there a consensus that this seems to break the build for folk who do not need this option? If so I can see about committing the necessary changes to turn this option on by default. I needed the option for what I was trying to do. Of course if someone already has a patch for that, that will help, as I don't have a lot of free time at the moment but can certainly commit a quick fix if someone already has one. thanks, BMS From bms at incunabulum.net Tue Apr 21 07:35:59 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Tue Apr 21 07:36:06 2009 Subject: Anyone using func or certserver? Message-ID: <49ED7312.9070504@incunabulum.net> Is anyone out there using Fedora's Unified Network Controller (func) or certserver on FreeBSD? If so, I would really like to hear from you about your experience with it. thanks, BMS From ronald-freebsd8 at klop.yi.org Tue Apr 21 08:26:35 2009 From: ronald-freebsd8 at klop.yi.org (Ronald Klop) Date: Tue Apr 21 08:26:49 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090420152620.8f89edd5.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> Message-ID: On Mon, 20 Apr 2009 15:26:20 +0200, Oliver Lehmann wrote: > Hi, > > as I found out in the meantime - the following described problem can be > only worked around when 'Load "dri"' is removed from the server > section, and 'Option "DRI" "true"' is removed from the Device > section. Otherwise: > > I've synced my pre-drm-changes 7-STABLE to the latest 7-STABLE. Now the > grafic performance in xorg decreased dramatically. Moving a window or > resizing a window makes me feel sent back 15 years ago ;). I can "see" > the > window resizing. The popup of an window is fast, but moving it around or > scrolling... jesus that is what I call slow. Firefox is nearly not usable > for example :( > > I wonder what is causing this. I'm using a ATI Radeon HD3850 in it's AGP > version (probably kinda uncommon). > > olivleh1@kartoffel olivleh1> dmesg | grep drm > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] AGP at 0xd8000000 128MB > info: [drm] Initialized radeon 1.29.0 20080528 > info: [drm] Setting GART location based on new memory map > info: [drm] Loading RV670 CP Microcode > info: [drm] Loading RV670 PFP Microcode > info: [drm] Resetting GPU > info: [drm] writeback test succeeded in 1 usecs > drm0: [ITHREAD] > olivleh1@kartoffel olivleh1> pkg_info | grep radeon > xf86-video-radeonhd-1.2.5 X.Org ati RadeonHD display driver > olivleh1@kartoffel olivleh1> > >> From my xorg.conf: > > Section "Module" > Load "dbe" > Load "freetype" > Load "glx" > Load "dri" > EndSection > Section "Device" > > Identifier "ATI1" > BoardName "ATI Radeon" > Driver "radeonhd" > BusID "PCI:1:0:0" > Option "Monitor-DVI-I_1/digital" "Syncmaster DVI1" > Option "Monitor-DVI-I_2/digital" "Syncmaster DVI2" > Option "DRI" "true" > EndSection > > the whole xorg.conf can be found here: > > http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 > > Is this expected to happen with DRI enabled? > Hi, X.org is quite good in autodetecting your hardware and running without a config. It works for me out-of-the-box with my Radeon HD 2400 XT and Radeon HD 2600 XT. (But I'm not using agp.) You can also try the xf86-video-ati driver. It works very well with 2d accell. (I'm using it also.) Ronald. From alexs at analytic.mv.ru Tue Apr 21 09:51:28 2009 From: alexs at analytic.mv.ru (alexs@analytic.mv.ru) Date: Tue Apr 21 09:51:35 2009 Subject: diskless netmask problem Message-ID: <20090421095114.GA35757@mail.analytic.mv.ru> Setup diskless in ip/22 subnet dhcpd.conf subnet 192.168.0.0 netmask 255.255.252.0 { use-host-decl-names on; option subnet-mask 255.255.252.0; option broadcast-address 192.168.3.255; host bart { hardware ethernet 00:1c:c0:85:48:fe; fixed-address 192.168.0.72; filename "pxeboot"; option root-path "192.168.0.160:/export/diskless/freebsd71"; } } System starts ok, but netmask on interface is not 255.255.252.0, it gets 255.255.255.0 if put nfs server in 192.168.1.0-192.168.3.255, i have nfs_mountroot error. -- alexs From lehmann at ans-netz.de Tue Apr 21 14:04:54 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Tue Apr 21 14:05:03 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <1240238090.3930.0.camel@balrog.2hip.net> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <1240238090.3930.0.camel@balrog.2hip.net> Message-ID: <20090421160454.9f5bf40c.lehmann@ans-netz.de> Hi Robert, Robert Noland wrote: > Can you show me the output of memcontrol list, with drm enabled. here we go (with drm in the kernel, dri disabled in xorg): root@kartoffel olivleh1> memcontrol list 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x10000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x20000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x30000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x40000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x50000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x60000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x70000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x80000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x90000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc0000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd0000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdd000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xde000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdf000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe0000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe1000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe2000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe3000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe4000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe5000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe6000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe7000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe8000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe9000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xea000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xeb000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xec000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xed000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xee000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xef000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xf0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfa000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfe000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xff000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0x0/0x80000000 BIOS write-back set-by-firmware active 0xd8000000/0x8000000 drm write-combine active root@kartoffel olivleh1> -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From lehmann at ans-netz.de Tue Apr 21 14:08:11 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Tue Apr 21 14:08:17 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: References: <20090420152620.8f89edd5.lehmann@ans-netz.de> Message-ID: <20090421160813.6fad1ed3.lehmann@ans-netz.de> Hi, Warren Block wrote: > No DRI Section? >From what I understood in the past is, that this section is just optional. I had it once in the past but removed it and nothing changed so far without having it. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From lehmann at ans-netz.de Tue Apr 21 14:26:48 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Tue Apr 21 14:35:21 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: References: <20090420152620.8f89edd5.lehmann@ans-netz.de> Message-ID: <20090421162650.a0ef7477.lehmann@ans-netz.de> Ronald Klop wrote: > X.org is quite good in autodetecting your hardware and running without a > config. It works for me out-of-the-box with my Radeon HD 2400 XT and > Radeon HD 2600 XT. (But I'm not using agp.) > You can also try the xf86-video-ati driver. It works very well with 2d > accell. (I'm using it also.) When I tried xf86-video-ati in the past, it didn't deteced my ChipID so I was forced to use the radeonhd driver (I even have to manually patch the official generic AMD/ATI Windows XP driver to get support for my card ;)). I now retested the driver and my Xorg was left unresponsible after my loginmanager slim tried to fire up my windowmanager. I only could kill it from an other system, switching back to the console and back to X11 left my Xorg in an unkillable state while eating up all my CPU time. So for my xf86-video-ati is not an option :( I'm also not sure how the RV610 or RV630 chipsets are different to my RV670. -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From sam at freebsd.org Tue Apr 21 14:51:07 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Apr 21 14:51:38 2009 Subject: kernel compile fails without AH_SUPPORT_AR5416 In-Reply-To: <49ED6AD2.4010006@incunabulum.net> References: <49E6DB25.2010601@sippysoft.com> <49E6FF8F.4070403@sippysoft.com> <49ED6AD2.4010006@incunabulum.net> Message-ID: <49EDDD51.9040608@freebsd.org> Bruce Simpson wrote: > Hi, > > Looks like I'm late to the party. I was responsible for committing these > ath(4) changes to RELENG_7. > I can't remember if I tested the kernel compile without the > AH_SUPPORT_AR5416 option or not, I have been so incredibly busy. > > Dennis Melentyev wrote: >> 2009/4/16 Maxim Sobolev : >> >>> Dennis Melentyev wrote: >>> >>>> Could be worth an entry in UPDATING and/or explicitly added to GENERIC. >>>> >>> My point is that if the option is mandatory for compiling ath(4) driver, >>> then there is no point in having this option in the first place. >>> >> >> Well, fair. >> +1 from me :). >> >> > > So is there a consensus that this seems to break the build for folk who > do not need this option? > If so I can see about committing the necessary changes to turn this > option on by default. I needed the option for what I was trying to do. > > Of course if someone already has a patch for that, that will help, as I > don't have a lot of free time at the moment but can certainly commit a > quick fix if someone already has one. ru had a change to fix this but decided not to; can't say why. Otherwise there is a better way to fix this which I alluded to in previous mail--use the config-generated #define that is generated for the "ath_hal" device. As I said I've not had time to look at that won't probably for several weeks. Either way this requirement has been listed in UPDATING ever since the ath hal source code was imported into the tree. Sam From rnoland at FreeBSD.org Tue Apr 21 14:58:24 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 21 14:59:24 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: References: <20090420152620.8f89edd5.lehmann@ans-netz.de> Message-ID: <1240325885.14628.12.camel@balrog.2hip.net> On Tue, 2009-04-21 at 10:26 +0200, Ronald Klop wrote: > On Mon, 20 Apr 2009 15:26:20 +0200, Oliver Lehmann > wrote: > > > Hi, > > > > as I found out in the meantime - the following described problem can be > > only worked around when 'Load "dri"' is removed from the server > > section, and 'Option "DRI" "true"' is removed from the Device > > section. Otherwise: > > > > I've synced my pre-drm-changes 7-STABLE to the latest 7-STABLE. Now the > > grafic performance in xorg decreased dramatically. Moving a window or > > resizing a window makes me feel sent back 15 years ago ;). I can "see" > > the > > window resizing. The popup of an window is fast, but moving it around or > > scrolling... jesus that is what I call slow. Firefox is nearly not usable > > for example :( > > > > I wonder what is causing this. I'm using a ATI Radeon HD3850 in it's AGP > > version (probably kinda uncommon). > > > > olivleh1@kartoffel olivleh1> dmesg | grep drm > > drm0: on vgapci0 > > vgapci0: child drm0 requested pci_enable_busmaster > > info: [drm] AGP at 0xd8000000 128MB > > info: [drm] Initialized radeon 1.29.0 20080528 > > info: [drm] Setting GART location based on new memory map > > info: [drm] Loading RV670 CP Microcode > > info: [drm] Loading RV670 PFP Microcode > > info: [drm] Resetting GPU > > info: [drm] writeback test succeeded in 1 usecs > > drm0: [ITHREAD] > > olivleh1@kartoffel olivleh1> pkg_info | grep radeon > > xf86-video-radeonhd-1.2.5 X.Org ati RadeonHD display driver > > olivleh1@kartoffel olivleh1> > > > >> From my xorg.conf: > > > > Section "Module" > > Load "dbe" > > Load "freetype" > > Load "glx" > > Load "dri" > > EndSection > > Section "Device" > > > > Identifier "ATI1" > > BoardName "ATI Radeon" > > Driver "radeonhd" > > BusID "PCI:1:0:0" > > Option "Monitor-DVI-I_1/digital" "Syncmaster DVI1" > > Option "Monitor-DVI-I_2/digital" "Syncmaster DVI2" > > Option "DRI" "true" > > EndSection > > > > the whole xorg.conf can be found here: > > > > http://cvs.olli.homeip.net/index.html/configs/xorg.conf?rev=1.9 > > > > Is this expected to happen with DRI enabled? > > > > Hi, > > X.org is quite good in autodetecting your hardware and running without a > config. It works for me out-of-the-box with my Radeon HD 2400 XT and > Radeon HD 2600 XT. (But I'm not using agp.) > You can also try the xf86-video-ati driver. It works very well with 2d > accell. (I'm using it also.) If you don't have a config, you won't get drm as it defaults to off on r6/7xx hardware right now. robert. > Ronald. > _______________________________________________ > 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: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090421/b992caed/attachment.pgp From rnoland at FreeBSD.org Tue Apr 21 15:11:30 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 21 15:11:36 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090421162650.a0ef7477.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <20090421162650.a0ef7477.lehmann@ans-netz.de> Message-ID: <1240326672.14628.32.camel@balrog.2hip.net> On Tue, 2009-04-21 at 16:26 +0200, Oliver Lehmann wrote: > Ronald Klop wrote: > > > X.org is quite good in autodetecting your hardware and running without a > > config. It works for me out-of-the-box with my Radeon HD 2400 XT and > > Radeon HD 2600 XT. (But I'm not using agp.) > > You can also try the xf86-video-ati driver. It works very well with 2d > > accell. (I'm using it also.) > > When I tried xf86-video-ati in the past, it didn't deteced my ChipID so I > was forced to use the radeonhd driver (I even have to manually patch the > official generic AMD/ATI Windows XP driver to get support for my > card ;)). > I now retested the driver and my Xorg was left unresponsible after my > loginmanager slim tried to fire up my windowmanager. I only could kill it > from an other system, switching back to the console and back to X11 left > my Xorg in an unkillable state while eating up all my CPU time. So for my > xf86-video-ati is not an option :( > > I'm also not sure how the RV610 or RV630 chipsets are different to my > RV670. (--) PCI:*(0@1:0:0) ATI Technologies Inc RV670PRO [Radeon HD 3850] rev 0, Mem @ 0xd0000000/268435456, 0xfe8e0000/65536, I/O @ 0x0000b000/256, BIOS @ 0x????????/65536 I am running this right now... Though, it is PCI-E, not AGP... Works with both radeon and radeonhd drivers (current from ports). I expect the issue is with AGP, but you need to be setting Option "AccelMethod" "EXA" on your hardware as well. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090421/1c0b8a54/attachment.pgp From jhb at freebsd.org Tue Apr 21 15:12:06 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Apr 21 15:12:24 2009 Subject: RELENG_7 crash In-Reply-To: <200904210524.n3L5O9YS086865@lava.sentex.ca> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> Message-ID: <200904211111.57295.jhb@freebsd.org> On Tuesday 21 April 2009 1:25:06 am Mike Tancsa wrote: > The box has a fairly heavy UDP load. Its RELENG_7 as of today and > took 3hrs for it to dump core. > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x68 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0637146 > stack pointer = 0x28:0xe766eaac > frame pointer = 0x28:0xe766eb54 > 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 = 761 (bsnmpd) > trap number = 12 > panic: page fault > cpuid = 1 > Uptime: 3h47m43s > Physical memory: 2036 MB > Dumping 83 MB: 68 52 36 20 4 > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc05964d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc05967a9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc07f64ac in trap_fatal (frame=0xe766ea6c, eva=104) at > /usr/src/sys/i386/i386/trap.c:939 > #4 0xc07f6730 in trap_pfault (frame=0xe766ea6c, usermode=0, eva=104) > at /usr/src/sys/i386/i386/trap.c:852 > #5 0xc07f70dc in trap (frame=0xe766ea6c) at /usr/src/sys/i386/i386/trap.c:530 > #6 0xc07db7eb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 > #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, > arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 > #8 0xc059fd77 in sysctl_root (oidp=Variable "oidp" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1413 > #9 0xc059ff14 in userland_sysctl (td=0xc5374460, name=0xe766ec14, > namelen=6, old=0x0, oldlenp=0xbfbf8478, inkernel=0, new=0x0, > newlen=0, retval=0xe766ec10, flags=0) at > /usr/src/sys/kern/kern_sysctl.c:1506 > #10 0xc05a0064 in __sysctl (td=0xc5374460, uap=0xe766ecfc) at > /usr/src/sys/kern/kern_sysctl.c:1443 > #11 0xc07f6a85 in syscall (frame=0xe766ed38) at > /usr/src/sys/i386/i386/trap.c:1090 > #12 0xc07db850 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #13 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) Can you do 'frame 7' followed by 'l', 'p ifp', and 'p ifp->if_snd'? -- John Baldwin From rnoland at FreeBSD.org Tue Apr 21 15:12:06 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 21 15:12:25 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090421160454.9f5bf40c.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <1240238090.3930.0.camel@balrog.2hip.net> <20090421160454.9f5bf40c.lehmann@ans-netz.de> Message-ID: <1240326709.14628.33.camel@balrog.2hip.net> On Tue, 2009-04-21 at 16:04 +0200, Oliver Lehmann wrote: > 0xd8000000/0x8000000 drm write-combine active Ok, looks like MTRR is working for you, so that isn't it... robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090421/92cfa698/attachment.pgp From mike at sentex.net Tue Apr 21 15:20:09 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Apr 21 15:20:16 2009 Subject: RELENG_7 crash In-Reply-To: <200904211111.57295.jhb@freebsd.org> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <200904211111.57295.jhb@freebsd.org> Message-ID: <200904211519.n3LFJFsk090691@lava.sentex.ca> At 11:11 AM 4/21/2009, John Baldwin wrote: >Can you do 'frame 7' followed by 'l', 'p ifp', and 'p ifp->if_snd'? Hi, kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05964d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc05967a9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc07f64ac in trap_fatal (frame=0xe766ea6c, eva=104) at /usr/src/sys/i386/i386/trap.c:939 #4 0xc07f6730 in trap_pfault (frame=0xe766ea6c, usermode=0, eva=104) at /usr/src/sys/i386/i386/trap.c:852 #5 0xc07f70dc in trap (frame=0xe766ea6c) at /usr/src/sys/i386/i386/trap.c:530 #6 0xc07db7eb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 #8 0xc059fd77 in sysctl_root (oidp=Variable "oidp" is not available. ) at /usr/src/sys/kern/kern_sysctl.c:1413 #9 0xc059ff14 in userland_sysctl (td=0xc5374460, name=0xe766ec14, namelen=6, old=0x0, oldlenp=0xbfbf8478, inkernel=0, new=0x0, newlen=0, retval=0xe766ec10, flags=0) at /usr/src/sys/kern/kern_sysctl.c:1506 #10 0xc05a0064 in __sysctl (td=0xc5374460, uap=0xe766ecfc) at /usr/src/sys/kern/kern_sysctl.c:1443 #11 0xc07f6a85 in syscall (frame=0xe766ed38) at /usr/src/sys/i386/i386/trap.c:1090 #12 0xc07db850 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #13 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) frame 7 #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 127 ifp->if_snd.ifq_drops = ifmd.ifmd_snd_drops; (kgdb) l 122 DONTCOPY(baudrate); 123 #undef DONTCOPY 124 #define COPY(fld) ifp->if_##fld = ifmd.ifmd_##fld 125 COPY(data); 126 ifp->if_snd.ifq_maxlen = ifmd.ifmd_snd_maxlen; 127 ifp->if_snd.ifq_drops = ifmd.ifmd_snd_drops; 128 #undef COPY 129 break; 130 131 case IFDATA_LINKSPECIFIC: (kgdb) p ifp $1 = (struct ifnet *) 0x0 (kgdb) p ifp->if_snd Cannot access memory at address 0xf4 (kgdb) Is it possible I am running into some of the interface lock fixes rwatson has been working on ? This box has a lot of ng interfaces which come and go. Perhaps snmp asking about an interface that just went away caused the panic ? I disabled bsnmp since the reboot and the box has been up for 10hrs so far. ---Mike From ru at FreeBSD.org Tue Apr 21 16:00:44 2009 From: ru at FreeBSD.org (Ruslan Ermilov) Date: Tue Apr 21 16:00:55 2009 Subject: RELENG_7 crash In-Reply-To: <200904211519.n3LFJFsk090691@lava.sentex.ca> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <200904211111.57295.jhb@freebsd.org> <200904211519.n3LFJFsk090691@lava.sentex.ca> Message-ID: <20090421153112.GA47589@edoofus.dev.vega.ru> On Tue, Apr 21, 2009 at 11:20:13AM -0400, Mike Tancsa wrote: > At 11:11 AM 4/21/2009, John Baldwin wrote: > > >Can you do 'frame 7' followed by 'l', 'p ifp', and 'p ifp->if_snd'? > > Hi, > > > kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc05964d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc05967a9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc07f64ac in trap_fatal (frame=0xe766ea6c, eva=104) at > /usr/src/sys/i386/i386/trap.c:939 > #4 0xc07f6730 in trap_pfault (frame=0xe766ea6c, usermode=0, eva=104) > at /usr/src/sys/i386/i386/trap.c:852 > #5 0xc07f70dc in trap (frame=0xe766ea6c) at /usr/src/sys/i386/i386/trap.c:530 > #6 0xc07db7eb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 > #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, > arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 > #8 0xc059fd77 in sysctl_root (oidp=Variable "oidp" is not available. > ) at /usr/src/sys/kern/kern_sysctl.c:1413 > #9 0xc059ff14 in userland_sysctl (td=0xc5374460, name=0xe766ec14, > namelen=6, old=0x0, oldlenp=0xbfbf8478, inkernel=0, new=0x0, > newlen=0, retval=0xe766ec10, flags=0) at > /usr/src/sys/kern/kern_sysctl.c:1506 > #10 0xc05a0064 in __sysctl (td=0xc5374460, uap=0xe766ecfc) at > /usr/src/sys/kern/kern_sysctl.c:1443 > #11 0xc07f6a85 in syscall (frame=0xe766ed38) at > /usr/src/sys/i386/i386/trap.c:1090 > #12 0xc07db850 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 > #13 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) frame 7 > #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, > arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 > 127 ifp->if_snd.ifq_drops = ifmd.ifmd_snd_drops; > (kgdb) l > 122 DONTCOPY(baudrate); > 123 #undef DONTCOPY > 124 #define COPY(fld) ifp->if_##fld = ifmd.ifmd_##fld > 125 COPY(data); > 126 ifp->if_snd.ifq_maxlen = ifmd.ifmd_snd_maxlen; > 127 ifp->if_snd.ifq_drops = ifmd.ifmd_snd_drops; > 128 #undef COPY > 129 break; > 130 > 131 case IFDATA_LINKSPECIFIC: > (kgdb) p ifp > $1 = (struct ifnet *) 0x0 > (kgdb) p ifp->if_snd > Cannot access memory at address 0xf4 > (kgdb) > > > Is it possible I am running into some of the interface lock fixes > rwatson has been working on ? This box has a lot of ng interfaces > which come and go. Perhaps snmp asking about an interface that just > went away caused the panic ? I disabled bsnmp since the reboot and > the box has been up for 10hrs so far. > It's a documented bug: : revision 1.281 : date: 2008/06/26 23:05:28; author: rwatson; state: Exp; lines: +69 -12 : SVN rev 180042 on 2008-06-26 23:05:28Z by rwatson : : Introduce locking around use of ifindex_table, whose use was previously : unsynchronized. While races were extremely rare, we've now had a : couple of reports of panics in environments involving large numbers of : IPSEC tunnels being added very quickly on an active system. : : - Add accessor functions ifnet_byindex(), ifaddr_byindex(), : ifdev_byindex() to replace existing accessor macros. These functions : now acquire the ifnet lock before derefencing the table. : - Add IFNET_WLOCK_ASSERT(). : - Add static accessor functions ifnet_setbyindex(), ifdev_setbyindex(), : which set values in the table either asserting of acquiring the ifnet : lock. : - Use accessor functions throughout if.c to modify and read : ifindex_table. : - Rework ifnet attach/detach to lock around ifindex_table modification. : : Note that these changes simply close races around use of ifindex_table, : and make no attempt to solve the probem of disappearing ifnets. Further ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : refinement of this work, including with respect to ifindex_table : resizing, is still required. : : In a future change, the ifnet lock should be converted from a mutex to an : rwlock in order to reduce contention. : : Reviewed and tested by: brooks Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From mike at sentex.net Tue Apr 21 16:11:28 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Apr 21 16:11:34 2009 Subject: RELENG_7 crash In-Reply-To: <20090421153112.GA47589@edoofus.dev.vega.ru> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <200904211111.57295.jhb@freebsd.org> <200904211519.n3LFJFsk090691@lava.sentex.ca> <20090421153112.GA47589@edoofus.dev.vega.ru> Message-ID: <200904211610.n3LGAYll090970@lava.sentex.ca> At 11:31 AM 4/21/2009, Ruslan Ermilov wrote: >: >: Note that these changes simply close races around use of ifindex_table, >: and make no attempt to solve the probem of disappearing ifnets. Further > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >: refinement of this work, including with respect to ifindex_table >: resizing, is still required. >: >: In a future change, the ifnet lock should be converted from a mutex to an >: rwlock in order to reduce contention. Hi, Thanks for the info! In the mean, time, apart from disabling snmpwalking, is there anything I can do to mitigate triggering this bug ? The box runs ospf/zebra for routing daemons and mpd53 for l2tp LNS termination. ---Mike From lehmann at ans-netz.de Tue Apr 21 17:27:34 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Tue Apr 21 17:27:41 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <1240326672.14628.32.camel@balrog.2hip.net> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <20090421162650.a0ef7477.lehmann@ans-netz.de> <1240326672.14628.32.camel@balrog.2hip.net> Message-ID: <20090421192735.1a865848.lehmann@ans-netz.de> Robert Noland wrote: > but you need to be setting Option "AccelMethod" > "EXA" on your hardware as well. (**) RADEONHD(0): Option "DRI" "true" (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Unknown card detected: 0x9515:0x1787:0x0028. Great - this did the trick. Now the system works like it was before and I can enjoy DRI - resizing videos and so on works now like a charm - like some years ago with my old ATI2950 ;) Resizing windows, scrolling content is now fast. Is there a FAQ list where I could have found it by searching on my own? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From rnoland at FreeBSD.org Tue Apr 21 17:38:28 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Apr 21 17:38:35 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090421192735.1a865848.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <20090421162650.a0ef7477.lehmann@ans-netz.de> <1240326672.14628.32.camel@balrog.2hip.net> <20090421192735.1a865848.lehmann@ans-netz.de> Message-ID: <1240335490.14628.35.camel@balrog.2hip.net> On Tue, 2009-04-21 at 19:27 +0200, Oliver Lehmann wrote: > Robert Noland wrote: > > > but you need to be setting Option "AccelMethod" > > "EXA" on your hardware as well. > > (**) RADEONHD(0): Option "DRI" "true" > (**) RADEONHD(0): Selected EXA 2D acceleration. > (II) RADEONHD(0): Unknown card detected: 0x9515:0x1787:0x0028. > > Great - this did the trick. Now the system works like it was before and I > can enjoy DRI - resizing videos and so on works now like a charm - like > some years ago with my old ATI2950 ;) > Resizing windows, scrolling content is now fast. > > Is there a FAQ list where I could have found it by searching on my own? The r6/7xx drm support is new. Best place is freebsd-x11@ for late breaking details on currently supported graphics cards from all vendors. I am now working with new 3d bits that AMD has released for these cards. It isn't quite ready yet, but we are getting closer... robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090421/83cb8620/attachment.pgp From rwatson at FreeBSD.org Tue Apr 21 17:53:55 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Apr 21 17:54:02 2009 Subject: RELENG_7 crash In-Reply-To: <200904211610.n3LGAYll090970@lava.sentex.ca> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <200904211111.57295.jhb@freebsd.org> <200904211519.n3LFJFsk090691@lava.sentex.ca> <20090421153112.GA47589@edoofus.dev.vega.ru> <200904211610.n3LGAYll090970@lava.sentex.ca> Message-ID: On Tue, 21 Apr 2009, Mike Tancsa wrote: > At 11:31 AM 4/21/2009, Ruslan Ermilov wrote: >> : >> : Note that these changes simply close races around use of ifindex_table, >> : and make no attempt to solve the probem of disappearing ifnets. Further >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> : refinement of this work, including with respect to ifindex_table >> : resizing, is still required. >> : >> : In a future change, the ifnet lock should be converted from a mutex to an >> : rwlock in order to reduce contention. > > Thanks for the info! In the mean, time, apart from disabling > snmpwalking, is there anything I can do to mitigate triggering this bug ? > The box runs ospf/zebra for routing daemons and mpd53 for l2tp LNS > termination. There are several bugs here, one difficult to fix (lack of refcounting), but also stuff like ifp being derived from an interface number twice, but checked against NULL only the first time (line 85 checked for NULL, re-queried but no check line 88). Fixing the top bit of the function to only query the ifp once and check it for NULL then would be a good idea. More fundamentally, we do need to refcount ifnets when used from the management path, which is not all that hard a change, but preferably to try the easy way first given where we are in the release cycle. However, I wonder if your debugger is being totally honest with you. Line 127 is after several other dereferences of ifp, and there are calls to functions with locking, so the compiler really shouldn't have reordered the post-sysctl calls to be before the pre-sysctl calls that also dereference it. Could you try using addr2line and see if it gives you a different line number, and/or check source and object file dates? Robert N M Watson Computer Laboratory University of Cambridge From marius at alchemy.franken.de Tue Apr 21 18:49:27 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Apr 21 18:49:35 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090420204637.GA1236@mr-happy.com> References: <20090420204637.GA1236@mr-happy.com> Message-ID: <20090421184924.GA36542@alchemy.franken.de> On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: > Hi, > > csup today around 13:00 UTC. 'make buildworld', 'make buildkernel', > 'make installkernel', reboot to single-user. > > # ifconfig bge0 141.219.5.33/22 up > # ping 141.219.4.1 > PING 141.219.4.1 (141.219.4.1): 56 data bytes > ^C > --- 141.219.4.1 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > > # ifconfig bge0 > bge0: flags=8843 metric 0 mtu 1500 > options=9b > ether 00:1e:c9:44:30:14 > inet6 fe80::21e:c9ff:fe44:3014%bge0 prefixlen 64 scopeid 0x1 > inet 141.219.5.33 netmask 0xfffffc00 broadcast 141.219.7.255 > media: Ethernet autoselect (100baseTX ) > status: active > > I have no trouble with networking using a kernel from 20090115. This Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? If it predates it could you please check whether this is the change which breaks things for you? > is a Dell Optiplex 740, about 9 months old. make.conf and src.conf > are below. dmesg and pciconf output are attached. I ran 'tcpdump -i > bge0 -nn' while pinging, and this captured no packets, not even this > host's ARP broadcasts. > > I also encountered this problem in late March as well, just after > RELENG_7 became 7.2-PRERELEASE, but couldn't find time to put this > information together. > > If there's anything else I can run to troubleshoot this, please let me > know. > > thank you, > Jeff Blank > > /etc/make.conf: > CPUTYPE ?= k8 > WITHOUT_NLS=true > [port-specific options elided for brevity] > > /etc/src.conf: > WITHOUT_ATM=true > WITHOUT_GPIB=true > WITHOUT_I4B=true > WITHOUT_IPFILTER=true > WITHOUT_IPFW=true > WITHOUT_IPX=true > WITHOUT_LIB32=true > WITHOUT_NCP=true > WITHOUT_NDIS=true > WITHOUT_PPP=true > WITHOUT_QUOTAS=true > WITHOUT_RCMDS=true > WITHOUT_SENDMAIL=true > WITHOUT_SLIP=true > WITHOUT_WIRELESS=true > # 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-PRERELEASE #0: Mon Apr 20 12:27:26 EDT 2009 > root@bender.tc.mtu.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ (2906.08-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 > Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > TSC: P-state invariant > Cores per package: 2 > usable memory = 4278718464 (4080 MB) > avail memory = 4098314240 (3908 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ioapic0: Changing APIC ID to 4 > 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, bfdd0000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_hpet0: iomem 0xfeff0000-0xfeff03ff on acpi0 > Timecounter "HPET" frequency 25000000 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: at device 0.0 (no driver attached) > pci0: at device 0.1 (no driver attached) > pci0: at device 0.2 (no driver attached) > pci0: at device 0.3 (no driver attached) > pci0: at device 0.4 (no driver attached) > pci0: at device 0.5 (no driver attached) > pci0: at device 0.6 (no driver attached) > pci0: at device 0.7 (no driver attached) > pcib1: at device 2.0 on pci0 > pci1: on pcib1 > pcib2: at device 3.0 on pci0 > pci2: on pcib2 > bge0: mem 0xfd8f0000-0xfd8fffff irq 16 at device 0.0 on pci2 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > bge0: Ethernet address: 00:1e:c9:44:30:14 > bge0: [ITHREAD] > pcib3: at device 4.0 on pci0 > pci3: on pcib3 > vgapci0: port 0xbc00-0xbcff mem 0xd0000000-0xdfffffff,0xfddf0000-0xfddfffff irq 16 at device 0.0 on pci3 > vgapci1: mem 0xfdde0000-0xfddeffff at device 0.1 on pci3 > pci0: at device 9.0 (no driver attached) > isab0: port 0x1d00-0x1dff at device 10.0 on pci0 > isa0: on isab0 > pci0: at device 10.1 (no driver attached) > pci0: at device 10.2 (no driver attached) > ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 11.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 8 ports with 8 removable, self powered > ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb1: EHCI version 1.0 > usb1: companion controller, 8 ports each: usb0 > usb1: on ehci0 > usb1: USB revision 2.0 > uhub1: on usb1 > uhub1: 8 ports with 8 removable, self powered > uhub2: on uhub1 > uhub2: multiple transaction translators > uhub2: 4 ports with 4 removable, self powered > ums0: on uhub2 > ums0: 5 buttons and Z dir. > atapci0: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xe000-0xe00f mem 0xfe02d000-0xfe02dfff irq 23 at device 14.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > atapci1: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xcc00-0xcc0f mem 0xfe02c000-0xfe02cfff irq 20 at device 15.0 on pci0 > atapci1: [ITHREAD] > ata4: on atapci1 > ata4: [ITHREAD] > ata5: on atapci1 > ata5: [ITHREAD] > pcib4: at device 16.0 on pci0 > pci4: on pcib4 > hdac0: mem 0xfe024000-0xfe027fff irq 21 at device 16.1 on pci0 > hdac0: HDA Driver Revision: 20090329_0131 > hdac0: [ITHREAD] > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FILTER] > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppbus0: on ppc0 > ppbus0: [ITHREAD] > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > cpu0: on acpi0 > powernow0: on cpu0 > cpu1: on acpi0 > powernow1: on cpu1 > orm0: at iomem 0xc0000-0xcf7ff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ukbd0: on uhub0 > kbd2 at ukbd0 > ums1: on uhub0 > ums1: 3 buttons and Z dir. > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > Timecounters tick every 1.000 msec > ZFS filesystem version 6 > ZFS storage pool version 6 > ad4: 152587MB at ata2-master SATA300 > ad6: 152587MB at ata3-master SATA300 > GEOM_MIRROR: Device mirror/gm0 launched (1/2). > GEOM_MIRROR: Device gm0: rebuilding provider ad4. > acd0: CDROM at ata4-master SATA150 > acd1: CDRW at ata5-master SATA150 > hdac0: HDA Codec #0: Sigmatel STAC9220 > pcm0: at cad 0 nid 1 on hdac0 > GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/4856c1053a1b8b74. > acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > (probe1:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe1:ata3:0:0:0): CAM Status: SCSI Status Error > (probe1:ata3:0:0:0): SCSI Status: Check Condition > (probe1:ata3:0:0:0): NOT READY asc:3a,1 > (probe1:ata3:0:0:0): Medium not present - tray closed > (probe1:ata3:0:0:0): Unretryable error > acd1: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > (probe0:ata2:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (probe0:ata2:0:0:0): CAM Status: SCSI Status Error > (probe0:ata2:0:0:0): SCSI Status: Check Condition > (probe0:ata2:0:0:0): NOT READY asc:3a,0 > (probe0:ata2:0:0:0): Medium not present > (probe0:ata2:0:0:0): Unretryable error > acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 > cd1 at ata3 bus 0 target 0 lun 0 > cd1: Removable CD-ROM SCSI-0 device > ScMdP1:: 3A.P 3C0P0UM B#/s1 tLraaunnscfheerds! > > cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed > cd0 at ata2 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-0 device > cd0: 3.300MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > Trying to mount root from zfs:zgm0/root > GEOM_LABEL: Label ufsid/4856c1053a1b8b74 removed. > GEOM_LABEL: Label for provider mirror/gm0s1a is ufsid/4856c1053a1b8b74. > GEOM_LABEL: Label ufsid/4856c1053a1b8b74 removed. > # pciconf -lv > none0@pci0:0:0:0: class=0x050000 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Host Bridge' > class = memory > subclass = RAM > none1@pci0:0:0:1: class=0x050000 card=0x02fa10de chip=0x02fa10de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Memory Controller 0' > class = memory > subclass = RAM > none2@pci0:0:0:2: class=0x050000 card=0x02fe10de chip=0x02fe10de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Memory Controller 1' > class = memory > subclass = RAM > none3@pci0:0:0:3: class=0x050000 card=0x02f810de chip=0x02f810de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Memory Controller 5' > class = memory > subclass = RAM > none4@pci0:0:0:4: class=0x050000 card=0x02f910de chip=0x02f910de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Memory Controller 4' > class = memory > subclass = RAM > none5@pci0:0:0:5: class=0x050000 card=0x02ff10de chip=0x02ff10de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Host Bridge' > class = memory > subclass = RAM > none6@pci0:0:0:6: class=0x050000 card=0x027f10de chip=0x027f10de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Memory Controller 3' > class = memory > subclass = RAM > none7@pci0:0:0:7: class=0x050000 card=0x027e10de chip=0x027e10de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Memory Controller 2' > class = memory > subclass = RAM > pcib1@pci0:0:2:0: class=0x060400 card=0x000010de chip=0x02fc10de rev=0xa1 hdr=0x01 > vendor = 'Nvidia Corp' > device = 'C51 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib2@pci0:0:3:0: class=0x060400 card=0x000010de chip=0x02fd10de rev=0xa1 hdr=0x01 > vendor = 'Nvidia Corp' > device = 'C51 PCIe Bridge' > class = bridge > subclass = PCI-PCI > pcib3@pci0:0:4:0: class=0x060400 card=0x000010de chip=0x02fb10de rev=0xa1 hdr=0x01 > vendor = 'Nvidia Corp' > device = 'C51 PCIe Bridge' > class = bridge > subclass = PCI-PCI > none8@pci0:0:9:0: class=0x050000 card=0xcb8410de chip=0x027010de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 Host Bridge' > class = memory > subclass = RAM > isab0@pci0:0:10:0: class=0x060100 card=0x01ec1028 chip=0x026010de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 LPC Bridge' > class = bridge > subclass = PCI-ISA > none9@pci0:0:10:1: class=0x0c0500 card=0x01ec1028 chip=0x026410de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI System Management' > class = serial bus > subclass = SMBus > none10@pci0:0:10:2: class=0x050000 card=0x01ec1028 chip=0x027210de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 Memory Controller 0' > class = memory > subclass = RAM > ohci0@pci0:0:11:0: class=0x0c0310 card=0x01ec1028 chip=0x026d10de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 USB Controller' > class = serial bus > subclass = USB > ehci0@pci0:0:11:1: class=0x0c0320 card=0x01ec1028 chip=0x026e10de rev=0xa3 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 USB Controller' > class = serial bus > subclass = USB > atapci0@pci0:0:14:0: class=0x010185 card=0x01ec1028 chip=0x026610de rev=0xa1 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 Serial ATA Controller' > class = mass storage > subclass = ATA > atapci1@pci0:0:15:0: class=0x010185 card=0x01ec1028 chip=0x026710de rev=0xa1 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 Serial ATA Controller' > class = mass storage > subclass = ATA > pcib4@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de rev=0xa2 hdr=0x01 > vendor = 'Nvidia Corp' > device = 'MCP51 PCI Bridge' > class = bridge > subclass = PCI-PCI > hdac0@pci0:0:16:1: class=0x040300 card=0x1f901028 chip=0x026c10de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP51 High Definition Audio' > class = multimedia > subclass = HDA > hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' > class = bridge > subclass = HOST-PCI > hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron Address Map' > class = bridge > subclass = HOST-PCI > hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron DRAM Controller' > class = bridge > subclass = HOST-PCI > hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = '(K8) Athlon 64/Opteron Miscellaneous Control' > class = bridge > subclass = HOST-PCI > bge0@pci0:2:0:0: class=0x020000 card=0x01ec1028 chip=0x167a14e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM5754 Broadcom NetXtreme Gigabit Ethernet Controller' > class = network > subclass = ethernet > vgapci0@pci0:3:0:0: class=0x030000 card=0x0920174b chip=0x71471002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X1550 64-bit (RV505)' > class = display > subclass = VGA > vgapci1@pci0:3:0:1: class=0x038000 card=0x0921174b chip=0x71671002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Radeon X1300 Series Secondary' > class = display > # Marius From jb000003 at mr-happy.com Tue Apr 21 19:31:31 2009 From: jb000003 at mr-happy.com (Jeff Blank) Date: Tue Apr 21 19:31:38 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090421184924.GA36542@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> Message-ID: <20090421193129.GA4869@mr-happy.com> On Tue, Apr 21, 2009 at 08:49:24PM +0200, Marius Strobl wrote: > On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: > > I have no trouble with networking using a kernel from 20090115. This > Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? nope, 1.198.2.11. > If it predates it could you please check whether this is the change > which breaks things for you? what's the best way to go about this? I no longer have the source tree from the working kernel. should I plug 1.198.2.11 into the sources I have and then try .14? any other files I'd need previous revisions of? or is there a different, better way to go about it? (I don't know much about time-travelling through source.) thanks, Jeff From marius at alchemy.franken.de Tue Apr 21 19:55:13 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Tue Apr 21 19:55:19 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090421193129.GA4869@mr-happy.com> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> Message-ID: <20090421195510.GC33994@alchemy.franken.de> On Tue, Apr 21, 2009 at 03:31:29PM -0400, Jeff Blank wrote: > On Tue, Apr 21, 2009 at 08:49:24PM +0200, Marius Strobl wrote: > > On Mon, Apr 20, 2009 at 04:46:38PM -0400, Jeff Blank wrote: > > > I have no trouble with networking using a kernel from 20090115. This > > Does that working kernel include r187309 (if_bge.c rev 1.198.2.14)? > > nope, 1.198.2.11. > > > If it predates it could you please check whether this is the change > > which breaks things for you? > > what's the best way to go about this? I no longer have the source > tree from the working kernel. should I plug 1.198.2.11 into the > sources I have and then try .14? any other files I'd need previous > revisions of? or is there a different, better way to go about it? (I > don't know much about time-travelling through source.) > Use the sources you have but plug in sys/dev/bge/if_bge.c rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this combination should work. Then update if_bge.c to rev 1.198.2.14 and check whether things still work, if they do revert to pci.c rev 1.355.2.9 and check again. Marius From to.my.trociny at gmail.com Tue Apr 21 20:53:07 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Apr 21 20:53:16 2009 Subject: RELENG_7 crash In-Reply-To: <200904210524.n3L5O9YS086865@lava.sentex.ca> (Mike Tancsa's message of "Tue\, 21 Apr 2009 01\:25\:06 -0400") References: <200904210524.n3L5O9YS086865@lava.sentex.ca> Message-ID: <86vdox685s.fsf@kopusha.onet> On Tue, 21 Apr 2009 01:25:06 -0400 Mike Tancsa wrote: MT> The box has a fairly heavy UDP load. Its RELENG_7 as of today and MT> took 3hrs for it to dump core. MT> Fatal trap 12: page fault while in kernel mode MT> cpuid = 1; apic id = 01 MT> fault virtual address = 0x68 MT> fault code = supervisor read, page not present MT> instruction pointer = 0x20:0xc0637146 MT> stack pointer = 0x28:0xe766eaac MT> frame pointer = 0x28:0xe766eb54 MT> code segment = base 0x0, limit 0xfffff, type 0x1b MT> = DPL 0, pres 1, def32 1, gran 1 MT> processor eflags = interrupt enabled, resume, IOPL = 0 MT> current process = 761 (bsnmpd) MT> trap number = 12 MT> panic: page fault MT> cpuid = 1 MT> Uptime: 3h47m43s MT> Physical memory: 2036 MB MT> Dumping 83 MB: 68 52 36 20 4 MT> (kgdb) bt MT> #0 doadump () at pcpu.h:196 MT> #1 0xc05964d7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 MT> #2 0xc05967a9 in panic (fmt=Variable "fmt" is not available. MT> ) at /usr/src/sys/kern/kern_shutdown.c:574 MT> #3 0xc07f64ac in trap_fatal (frame=0xe766ea6c, eva=104) at MT> /usr/src/sys/i386/i386/trap.c:939 MT> #4 0xc07f6730 in trap_pfault (frame=0xe766ea6c, usermode=0, eva=104) MT> at /usr/src/sys/i386/i386/trap.c:852 MT> #5 0xc07f70dc in trap (frame=0xe766ea6c) at /usr/src/sys/i386/i386/trap.c:530 MT> #6 0xc07db7eb in calltrap () at /usr/src/sys/i386/i386/exception.s:159 MT> #7 0xc0637146 in sysctl_ifdata (oidp=0xc08816a0, arg1=0xe766ec24, MT> arg2=2, req=0xe766eba4) at /usr/src/sys/net/if_mib.c:127 MT> #8 0xc059fd77 in sysctl_root (oidp=Variable "oidp" is not available. MT> ) at /usr/src/sys/kern/kern_sysctl.c:1413 MT> #9 0xc059ff14 in userland_sysctl (td=0xc5374460, name=0xe766ec14, MT> namelen=6, old=0x0, oldlenp=0xbfbf8478, inkernel=0, new=0x0, MT> newlen=0, retval=0xe766ec10, flags=0) at MT> /usr/src/sys/kern/kern_sysctl.c:1506 MT> #10 0xc05a0064 in __sysctl (td=0xc5374460, uap=0xe766ecfc) at MT> /usr/src/sys/kern/kern_sysctl.c:1443 MT> #11 0xc07f6a85 in syscall (frame=0xe766ed38) at MT> /usr/src/sys/i386/i386/trap.c:1090 MT> #12 0xc07db850 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 MT> #13 0x00000033 in ?? () MT> Previous frame inner to this frame (corrupt stack?) MT> (kgdb) Just FYI, the same problem has already been registered in pr database as kern/132734. -- Mikolaj Golub From mike at sentex.net Tue Apr 21 20:57:58 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Apr 21 20:58:08 2009 Subject: RELENG_7 crash In-Reply-To: <86vdox685s.fsf@kopusha.onet> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <86vdox685s.fsf@kopusha.onet> Message-ID: <200904212057.n3LKv4i4092456@lava.sentex.ca> At 04:53 PM 4/21/2009, Mikolaj Golub wrote: >Just FYI, the same problem has already been registered in pr >database as kern/132734. Thanks, http://www.freebsd.org/cgi/query-pr.cgi?pr=132734 does look familiar :) If you disable the snmpwalk, is the box stable ? ---Mike From to.my.trociny at gmail.com Tue Apr 21 21:08:30 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Apr 21 21:08:36 2009 Subject: RELENG_7 crash In-Reply-To: (Robert Watson's message of "Tue\, 21 Apr 2009 18\:53\:54 +0100 \(BST\)") References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <200904211111.57295.jhb@freebsd.org> <200904211519.n3LFJFsk090691@lava.sentex.ca> <20090421153112.GA47589@edoofus.dev.vega.ru> <200904211610.n3LGAYll090970@lava.sentex.ca> Message-ID: <86k55demux.fsf@kopusha.onet> On Tue, 21 Apr 2009 18:53:54 +0100 (BST) Robert Watson wrote: RW> On Tue, 21 Apr 2009, Mike Tancsa wrote: >> At 11:31 AM 4/21/2009, Ruslan Ermilov wrote: >>> : >>> : Note that these changes simply close races around use of ifindex_table, >>> : and make no attempt to solve the probem of disappearing ifnets. Further >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> : refinement of this work, including with respect to ifindex_table >>> : resizing, is still required. >>> : >>> : In a future change, the ifnet lock should be converted from a mutex to an >>> : rwlock in order to reduce contention. >> >> Thanks for the info! In the mean, time, apart from disabling >> snmpwalking, is there anything I can do to mitigate triggering this >> bug ? The box runs ospf/zebra for routing daemons and mpd53 for l2tp >> LNS termination. RW> There are several bugs here, one difficult to fix (lack of RW> refcounting), but also stuff like ifp being derived from an interface RW> number twice, but checked against NULL only the first time (line 85 RW> checked for NULL, re-queried but no check line 88). Fixing the top RW> bit of the function to only query the ifp once and check it for NULL RW> then would be a good idea. More fundamentally, we do need to refcount RW> ifnets when used from the management path, which is not all that hard RW> a change, but preferably to try the easy way first given where we are RW> in the release cycle. I was thinking a bit on this problem (the same issue was reported in kern/132734) and eliminating double call of ifnet_byindex() was the first thing I did. But I decided then that the proper fix would be to wrap all critical code in sysctl_ifdata in IFNET_RLOCK/IFNET_RUNLOCK (the patch is attached). It looks like I am wrong and my idea about how the kernel works is oversimplified? :-) Unfortunately, I didn't manage to reproduce the panic in my environment so I was not able to do some experiments and tests. -- Mikolaj Golub -------------- next part -------------- A non-text attachment was scrubbed... Name: if_mib.c.patch Type: text/x-diff Size: 2280 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090421/7195e76b/if_mib.c.bin From to.my.trociny at gmail.com Tue Apr 21 21:14:56 2009 From: to.my.trociny at gmail.com (Mikolaj Golub) Date: Tue Apr 21 21:15:04 2009 Subject: RELENG_7 crash In-Reply-To: <200904212057.n3LKv4i4092456@lava.sentex.ca> (Mike Tancsa's message of "Tue\, 21 Apr 2009 16\:58\:02 -0400") References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <86vdox685s.fsf@kopusha.onet> <200904212057.n3LKv4i4092456@lava.sentex.ca> Message-ID: <86fxg1emk3.fsf@kopusha.onet> On Tue, 21 Apr 2009 16:58:02 -0400 Mike Tancsa wrote: MT> At 04:53 PM 4/21/2009, Mikolaj Golub wrote: >> Just FYI, the same problem has already been registered in pr >> database as kern/132734. MT> Thanks, MT> http://www.freebsd.org/cgi/query-pr.cgi?pr=132734 does look MT> familiar :) If you disable the snmpwalk, is the box stable ? It was not me who reported the problem. Unfortunately, I was not able to reproduce the panic on my host. I tried the simple script, which just created/deleted many tun interfaces and was running snmpwalk at the same time). -- Mikolaj Golub From rwatson at FreeBSD.org Tue Apr 21 22:25:41 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Apr 21 22:25:48 2009 Subject: RELENG_7 crash In-Reply-To: <86k55demux.fsf@kopusha.onet> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <200904211111.57295.jhb@freebsd.org> <200904211519.n3LFJFsk090691@lava.sentex.ca> <20090421153112.GA47589@edoofus.dev.vega.ru> <200904211610.n3LGAYll090970@lava.sentex.ca> <86k55demux.fsf@kopusha.onet> Message-ID: On Wed, 22 Apr 2009, Mikolaj Golub wrote: > RW> There are several bugs here, one difficult to fix (lack of > RW> refcounting), but also stuff like ifp being derived from an interface > RW> number twice, but checked against NULL only the first time (line 85 > RW> checked for NULL, re-queried but no check line 88). Fixing the top > RW> bit of the function to only query the ifp once and check it for NULL > RW> then would be a good idea. More fundamentally, we do need to refcount > RW> ifnets when used from the management path, which is not all that hard > RW> a change, but preferably to try the easy way first given where we are > RW> in the release cycle. > > I was thinking a bit on this problem (the same issue was reported in > kern/132734) and eliminating double call of ifnet_byindex() was the first > thing I did. But I decided then that the proper fix would be to wrap all > critical code in sysctl_ifdata in IFNET_RLOCK/IFNET_RUNLOCK (the patch is > attached). It looks like I am wrong and my idea about how the kernel works > is oversimplified? :-) Unfortunately, I didn't manage to reproduce the panic > in my environment so I was not able to do some experiments and tests. The problem is that you can't hold IFNET_RLOCK() over the sysctl copyouts. I'm preparing a patch for 8-CURRENT that will add a refcount to struct ifnet to handle this case, but that isn't an MFC candidate for 7.2. If fixing the return value checks for ifnet_byindex() avoids the insta-panic Mike's running into, it's a better 7.2 change at this point. We can target the ifnet refcount changes for 7.3. Robert N M Watson Computer Laboratory University of Cambridge From 000.fbsd at quip.cz Tue Apr 21 22:40:49 2009 From: 000.fbsd at quip.cz (Miroslav Lachman) Date: Tue Apr 21 22:40:56 2009 Subject: changing cpuset of jail from inside of jail - is it feature? Message-ID: <49EE4B6B.5020005@quip.cz> I am running system FreeBSD 7.1-STABLE amd64 GENERIC (Wed Feb 11 09:56:08 CET 2009) hosting few jails. The machine has dual core CPU and some jails are set to run only on one core (core 0 in this example): host# cpuset -l 0 -j 25 As I tested today, root user inside the jail can change this by the same command as I am doing it from the host system: injail# cpuset -l 0,1 -j 25 And from now, jail with JID 25 is running on both cores. Is it expected behavior of cpuset to allow user inside the jail change cpuset of the jail itself or is it a bug? It seems to me as undesirable. Miroslav Lachman From alexs at analytic.mv.ru Wed Apr 22 05:47:44 2009 From: alexs at analytic.mv.ru (alexs@analytic.mv.ru) Date: Wed Apr 22 05:47:55 2009 Subject: diskless netmask problem In-Reply-To: <20090421095114.GA35757@mail.analytic.mv.ru> References: <20090421095114.GA35757@mail.analytic.mv.ru> Message-ID: <20090422054740.GA49349@mail.analytic.mv.ru> * alexs@analytic.mv.ru [2009-04-21 13:51:14 +0400]: > Setup diskless in ip/22 subnet > > dhcpd.conf > subnet 192.168.0.0 netmask 255.255.252.0 { > use-host-decl-names on; > option subnet-mask 255.255.252.0; > option broadcast-address 192.168.3.255; > > host bart { > hardware ethernet 00:1c:c0:85:48:fe; > fixed-address 192.168.0.72; > filename "pxeboot"; > option root-path "192.168.0.160:/export/diskless/freebsd71"; > } > } > > System starts ok, but netmask on interface is not 255.255.252.0, > it gets 255.255.255.0 > > if put nfs server in 192.168.1.0-192.168.3.255, i have nfs_mountroot error. Solved by place in /export/diskless/freebsd71/boot/loader.conf boot.netif.netmask="255.255.252.0" But it is dirty. netmask must taken from dhcp.. > > -- > alexs > _______________________________________________ > 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" -- alexs From avg at icyb.net.ua Wed Apr 22 06:51:09 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 22 06:51:16 2009 Subject: panic: nfs sndunlock In-Reply-To: <49EC48C2.20402@icyb.net.ua> References: <49EC48C2.20402@icyb.net.ua> Message-ID: <49EEBE58.2090809@icyb.net.ua> Any ideas, interest? I still have the core file. on 20/04/2009 13:04 Andriy Gapon said the following: > System is stable/7: 7.2-PRERELEASE r191214 i386 uni-processor. > > NFS mount options: ro,noauto,nfsv3,tcp,intr,rdirplus,-r=32768,-w=32768 > > The panic occurred on client after losing and then restoring > connectivity with NFS server. There may have been parallel access to > NFS-mounted tree at the time of the accident. > > Kernel messages just before the panic: > kernel: nfs server odyssey:/usr/ports: not responding > kernel: nfs send error 57 for server odyssey:/usr/ports > > kgdb information: > #0 doadump () at pcpu.h:196 > #1 0xc0555a33 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc0555c7f in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc064be63 in nfs_connect_unlock (rep=0x0) at > /usr/src/sys/nfsclient/nfs_socket.c:1819 > #4 0xc064da24 in nfs_reconnect (rep=0xc40a0c80) at > /usr/src/sys/nfsclient/nfs_socket.c:581 > #5 0xc064ff50 in nfs_request (vp=0xc4464450, mrest=0xc435a000, > procnum=3, td=0xc398cd20, cred=0xc420b800, mrp=0xdac06a04, > mdp=0xdac06a00, dposp=0xdac06a08) > at /usr/src/sys/nfsclient/nfs_socket.c:737 > #6 0xc065d3f2 in nfs_lookup (ap=0xdac06a84) at > /usr/src/sys/nfsclient/nfs_vnops.c:922 > #7 0xc0729cd6 in VOP_LOOKUP_APV (vop=0xc07a0fe0, a=0xdac06a84) at > vnode_if.c:99 > #8 0xc05cad71 in lookup (ndp=0xdac06ba8) at vnode_if.h:57 > #9 0xc05cbab8 in namei (ndp=0xdac06ba8) at > /usr/src/sys/kern/vfs_lookup.c:220 > #10 0xc05db02d in kern_stat (td=0xc398cd20, path=0x2814d040
0x2814d040 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xdac06c18) > at /usr/src/sys/kern/vfs_syscalls.c:2123 > #11 0xc05db21f in stat (td=0xc398cd20, uap=0xdac06cfc) at > /usr/src/sys/kern/vfs_syscalls.c:2107 > #12 0xc0712055 in syscall (frame=0xdac06d38) at > /usr/src/sys/i386/i386/trap.c:1090 > #13 0xc06ff290 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:255 > > I am not sure why rep parameter shows up as NULL in nfs_connect_unlock > call. In frame 4: > (kgdb) p/x rep->r_nmp->nm_state > $2 = 0x10100000 > > I am keeping the core file. > -- Andriy Gapon From bzeeb-lists at lists.zabbadoz.net Wed Apr 22 09:50:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Apr 22 09:50:22 2009 Subject: changing cpuset of jail from inside of jail - is it feature? In-Reply-To: <49EE4B6B.5020005@quip.cz> References: <49EE4B6B.5020005@quip.cz> Message-ID: <20090422094447.A15361@maildrop.int.zabbadoz.net> On Wed, 22 Apr 2009, Miroslav Lachman wrote: Hi, > I am running system FreeBSD 7.1-STABLE amd64 GENERIC (Wed Feb 11 09:56:08 CET > 2009) hosting few jails. > The machine has dual core CPU and some jails are set to run only on one core > (core 0 in this example): > > host# cpuset -l 0 -j 25 > > As I tested today, root user inside the jail can change this by the same > command as I am doing it from the host system: > > injail# cpuset -l 0,1 -j 25 > > And from now, jail with JID 25 is running on both cores. > > Is it expected behavior of cpuset to allow user inside the jail change cpuset > of the jail itself or is it a bug? > > It seems to me as undesirable. it is (undesirable) and it seems to be a bug as even if you do host# cpuset -l 0 -r -j 25 you can get back to 0,1 from within the jail. I'll check how/why this is possible. /bz PS: moving this to freebsd-jail@ -- Bjoern A. Zeeb The greatest risk is not taking one. From jb000003 at mr-happy.com Wed Apr 22 15:06:27 2009 From: jb000003 at mr-happy.com (Jeff Blank) Date: Wed Apr 22 15:06:34 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090421195510.GC33994@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> Message-ID: <20090422150612.GA1231@mr-happy.com> On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: > Use the sources you have but plug in sys/dev/bge/if_bge.c > rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this > combination should work. correct. > Then update if_bge.c to rev > 1.198.2.14 and check whether things still work, this causes the problem to resurface. Jeff From stefan.lambrev at moneybookers.com Wed Apr 22 15:25:57 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Wed Apr 22 15:26:05 2009 Subject: HEADS UP: multi-IPv4/v6/no-IP jails now in 7-STABLE In-Reply-To: <20090207174104.Y93725@maildrop.int.zabbadoz.net> References: <20090207174104.Y93725@maildrop.int.zabbadoz.net> Message-ID: Hi, Does this allow multiple network interfaces to be used by a single jail instance? On Feb 7, 2009, at 8:18 PM, Bjoern A. Zeeb wrote: > Hi, > > what has started a long time ago with patches from various people, was > started, abandoned, resumed finally found an end. > > I am happy to hereby announce that the multi-IPv4/v6/no-IP jails work > has been merged to 7-STABLE and thus can be used in FreeBSD 7 without > the need to maintain or apply patches from now on. > > This also means that the updated jails will be included in 7.2 > release. > > This update gives you (short selection): > - zero, one or multi-IP jails. > - IPv4 and IPv6 support. > - cpuset support for jails. > - jail names and states to ease administration. - 32bit compat on > 64bit, jail v1 compat, .. > > You'll find a longer summary about all the new features and how to use > them in a posting from December (you should really read it): > http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html > > Since the above posting, multiple PRs had been addressed and fixes > include > - SIOCGIFADDR ioctl handling which fixes the "samba inside jails > problem" > - no more arp and ndp information disclosure > - updated rc.conf framework (fully backward compatible in 7), see > man 5 rc.conf and /etc/defaults/rc.conf. > - various documentation/man page updates > - ... > > > I'd like to thank everyone who had helped to make this possible! > > > If you like the work, mayhap even use it for your business, or just > want > to support FreeBSD, you may want to visit > http://www.freebsdfoundation.org/ > and help donating some money. > > > Enjoy your new jails! > (and don't try to escape - you sure won't succeed;) > > /bz > > -- > Bjoern A. Zeeb The greatest risk is not taking > one. > _______________________________________________ > 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 Wishes, Stefan Lambrev ICQ# 24134177 From news at streetsoul.lv Wed Apr 22 19:00:46 2009 From: news at streetsoul.lv (Streetsoul) Date: Wed Apr 22 19:00:54 2009 Subject: New Creative Recreation & 9five sunglasses Message-ID: <601a52cb1ae544c7521dac319df0bdb4@www.streetsoul.dk> Hello Ya all!!! New Arrivals from Creative Recreation with the freshest sneakers and new brand - 9five with coolest sunglasses on streetsoul.eu!!! Press here to view new arrivals from Creative Recreation! or copy the link in a browser: http://www.streetsoul.dk/zoom_brand/15 Press here to view new arrivals from 9five eyewear or copy the link in a browser: http://www.streetsoul.dk/zoom_brand/38 Go and check streetsoul internet store now! Peace! streetsoul.eu ----------------------------------------------------------------------------------------------------------------------------------------------------------- streetsoul brands: 667 | 9five | Adidas Originals | Airbag Craftworks | ALAKAZAM! | Alprausch | Amos | Analog Clothing | BICO | Creative Recreation | Cross Colours | DVS Shoes | Electric | Emily The Strange | Five Four | Goorin Brothers | gsus | Irie Daily | Kanabeach | King Apparel | Levi's Engineered Jeans? | Levi's? | Matix | Mazine | My Zoo | Nike | OAKLEY | pa:nuu | Reebok | Schlepp | Streetsoul | Stussy | Sweet & Toxic | T.U.K. | Ucon From marius at alchemy.franken.de Wed Apr 22 19:26:49 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Apr 22 19:26:56 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090422150612.GA1231@mr-happy.com> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> Message-ID: <20090422192644.GA52151@alchemy.franken.de> On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: > On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: > > Use the sources you have but plug in sys/dev/bge/if_bge.c > > rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this > > combination should work. > > correct. > > > Then update if_bge.c to rev > > 1.198.2.14 and check whether things still work, > > this causes the problem to resurface. > David, this is the second report that using MSI with a BCM5754/ chip=0x167a14e4 results in no interrupts, is there any errata about this? Thanks, Marius From marius at alchemy.franken.de Wed Apr 22 20:32:37 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Wed Apr 22 20:32:44 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819339D9F5A64D@IRVEXCHCCR01.corp.ad.broadcom.com> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090422192644.GA52151@alchemy.franken.de> <5D267A3F22FD854F8F48B3D2B523819339D9F5A64D@IRVEXCHCCR01.corp.ad.broadcom.com> Message-ID: <20090422203232.GC50221@alchemy.franken.de> On Wed, Apr 22, 2009 at 01:21:58PM -0700, David Christensen wrote: > > > > Then update if_bge.c to rev > > > > 1.198.2.14 and check whether things still work, > > > > > > this causes the problem to resurface. > > > > > > > David, > > > > this is the second report that using MSI with a BCM5754/ > > chip=0x167a14e4 results in no interrupts, is there any errata > > about this? > > Nope, no errata for MSI on the 5754, nor can I recall any > MSI problems on any of the PCIe based devices. Do the > systems share a common root complex that might be the source > of the issue? > This one useses a: none0@pci0:0:0:0: class=0x050000 card=0x02f010de chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM At least Linux doesn't seem to avoid using MSI with these. I didn't get any further regarding the other report so far. Marius From davidch at broadcom.com Wed Apr 22 20:36:22 2009 From: davidch at broadcom.com (David Christensen) Date: Wed Apr 22 20:36:29 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090422192644.GA52151@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090422192644.GA52151@alchemy.franken.de> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339D9F5A64D@IRVEXCHCCR01.corp.ad.broadcom.com> > > > Then update if_bge.c to rev > > > 1.198.2.14 and check whether things still work, > > > > this causes the problem to resurface. > > > > David, > > this is the second report that using MSI with a BCM5754/ > chip=0x167a14e4 results in no interrupts, is there any errata > about this? Nope, no errata for MSI on the 5754, nor can I recall any MSI problems on any of the PCIe based devices. Do the systems share a common root complex that might be the source of the issue? Dave From davidch at broadcom.com Wed Apr 22 23:34:36 2009 From: davidch at broadcom.com (David Christensen) Date: Wed Apr 22 23:34:43 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090422203232.GC50221@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090422192644.GA52151@alchemy.franken.de> <5D267A3F22FD854F8F48B3D2B523819339D9F5A64D@IRVEXCHCCR01.corp.ad.broadcom.com> <20090422203232.GC50221@alchemy.franken.de> Message-ID: <5D267A3F22FD854F8F48B3D2B523819339DA0429DB@IRVEXCHCCR01.corp.ad.broadcom.com> > > > this is the second report that using MSI with a BCM5754/ > > > chip=0x167a14e4 results in no interrupts, is there any > errata about > > > this? > > > > Nope, no errata for MSI on the 5754, nor can I recall any > MSI problems > > on any of the PCIe based devices. Do the systems share a > common root > > complex that might be the source of the issue? > > > > This one useses a: > none0@pci0:0:0:0: class=0x050000 card=0x02f010de > chip=0x02f010de rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'C51 Host Bridge' > class = memory > subclass = RAM > > At least Linux doesn't seem to avoid using MSI with these. > I didn't get any further regarding the other report so far. Are there any other errors reported by the 5754 such as a PCIe completion timeout in the Advanced Error Uncorrectable Status Register? I recall an issue with another Nvidia chipset and the 5754 where the system BIOS incorrectly configured the Hypertransport unitID field to a value of 0x20 which would prevent our diagnostics from running. PCI configuration and memory-mapped I/O worked correctly but DMA operations such as sending RX'd frames would fail. MSI might fall into this latter category and could be causing this error. The important thing would be to check for a Completion Timeout in the 5754. Dave From npapke at acm.org Thu Apr 23 00:39:27 2009 From: npapke at acm.org (Norbert Papke) Date: Thu Apr 23 00:39:34 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <1240326709.14628.33.camel@balrog.2hip.net> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <20090421160454.9f5bf40c.lehmann@ans-netz.de> <1240326709.14628.33.camel@balrog.2hip.net> Message-ID: <200904221739.25097.npapke@acm.org> On April 21, 2009, Robert Noland wrote: > On Tue, 2009-04-21 at 16:04 +0200, Oliver Lehmann wrote: > > 0xd8000000/0x8000000 drm write-combine active > > Ok, looks like MTRR is working for you, so that isn't it... > > robert. Hi Robert, Should there be a write-combined range present for all (ATI) cards? I don't see such an entry (please see below). My 2D performance seems reasonable. I have no complaints, just wondering. Cheers, -- Norbert Papke. npapke@acm.org # dmesg | grep drm drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 info: [drm] Setting GART location based on new memory map info: [drm] Loading RV635 CP Microcode info: [drm] Loading RV635 PFP Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs # memcontrol list 0x0/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x10000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x20000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x30000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x40000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x50000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x60000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x70000/0x10000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x80000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x84000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x88000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x8c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x90000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x94000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x98000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0x9c000/0x4000 BIOS write-back fixed-base fixed-length set-by-firmware active 0xa0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xa8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xac000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb0000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb4000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xb8000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xbc000/0x4000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xc0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xc9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xca000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xce000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xcf000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xd0000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd1000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd2000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd3000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd4000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd5000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd6000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd7000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd8000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xd9000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xda000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdb000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdc000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdd000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xde000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xdf000/0x1000 BIOS uncacheable fixed-base fixed-length set-by-firmware active 0xe0000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe1000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe2000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe3000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe4000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe5000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe6000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe7000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe8000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xe9000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xea000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xeb000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xec000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xed000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xee000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xef000/0x1000 BIOS write-through fixed-base fixed-length set-by-firmware active 0xf0000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf1000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf2000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf3000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf4000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf5000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf6000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf7000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf8000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xf9000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfa000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfb000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfc000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfd000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xfe000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0xff000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware active 0x0/0x100000000 BIOS write-back set-by-firmware active 0x100000000/0x40000000 BIOS write-back set-by-firmware active 0xc0000000/0x40000000 BIOS uncacheable set-by-firmware active From rnoland at FreeBSD.org Thu Apr 23 00:55:35 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Apr 23 00:55:42 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <200904221739.25097.npapke@acm.org> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <20090421160454.9f5bf40c.lehmann@ans-netz.de> <1240326709.14628.33.camel@balrog.2hip.net> <200904221739.25097.npapke@acm.org> Message-ID: <1240448113.2142.11.camel@balrog.2hip.net> On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote: > 0x0/0x100000000 BIOS write-back set-by-firmware active > 0x100000000/0x40000000 BIOS write-back set-by-firmware active > 0xc0000000/0x40000000 BIOS uncacheable set-by-firmware active MTRR is failing in many cases... It seems that your BIOS is doing what both of my newer machines are doing and setting a global range to write-back. I'm also guessing that 0xc0000000 is your framebuffer. We aren't allowed to overlap either of these ranges with a write combined region according to the specs. We would have to handle splitting/merging regions which we don't currently do. I looked at this just the other day, but it is reasonably complex to make that work right and accommodate all of the merging/splitting of regions. We are allowed to use PAT on either of these types of regions to enable write-combining. The drm code already does this for some allocations that are not mapped to user space. The problem with PAT is that all mappings of a given region need to have the same type and we don't currently have any way to specify that for user space mappings. This is fwiw, the last of Nvidia's feature requests as well. I've started looking at it, but I have a lot of learning to do on the vm system still. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090423/8233cffa/attachment.pgp From npapke at acm.org Thu Apr 23 02:38:15 2009 From: npapke at acm.org (Norbert Papke) Date: Thu Apr 23 02:38:22 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <1240448113.2142.11.camel@balrog.2hip.net> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> Message-ID: <200904221938.12129.npapke@acm.org> On April 22, 2009, Robert Noland wrote: > On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote: > > 0x0/0x100000000 BIOS write-back set-by-firmware active > > 0x100000000/0x40000000 BIOS write-back set-by-firmware active > > 0xc0000000/0x40000000 BIOS uncacheable set-by-firmware active > > MTRR is failing in many cases... It seems that your BIOS is doing what > both of my newer machines are doing and setting a global range to > write-back. I'm also guessing that 0xc0000000 is your framebuffer. Correct. The framebuffer starts at 0xd0000000, still covered by that last range. > We > aren't allowed to overlap either of these ranges with a write combined > region according to the specs. We would have to handle > splitting/merging regions which we don't currently do. I looked at this > just the other day, but it is reasonably complex to make that work right > and accommodate all of the merging/splitting of regions. > > We are allowed to use PAT on either of these types of regions to enable > write-combining. The drm code already does this for some allocations > that are not mapped to user space. The problem with PAT is that all > mappings of a given region need to have the same type and we don't > currently have any way to specify that for user space mappings. This is > fwiw, the last of Nvidia's feature requests as well. I've started > looking at it, but I have a lot of learning to do on the vm system > still. Thanks for taking the time to explain. Your posts are always very informative. I am learning quite a lot about the complexities involved. There is yet another thing I don't understand. With other graphics cards, including my G45 internal graphics adaptor, the /dev/agpgart device is created. I don't see this device with the Radeon card. Is this expected because it is not needed for PCIe? Cheers, -- Norbert Papke. npapke@acm.org From rnoland at FreeBSD.org Thu Apr 23 05:11:40 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Apr 23 05:11:46 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <200904221938.12129.npapke@acm.org> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> <200904221938.12129.npapke@acm.org> Message-ID: <1240463479.2142.21.camel@balrog.2hip.net> On Wed, 2009-04-22 at 19:38 -0700, Norbert Papke wrote: > On April 22, 2009, Robert Noland wrote: > > On Wed, 2009-04-22 at 17:39 -0700, Norbert Papke wrote: > > > 0x0/0x100000000 BIOS write-back set-by-firmware active > > > 0x100000000/0x40000000 BIOS write-back set-by-firmware active > > > 0xc0000000/0x40000000 BIOS uncacheable set-by-firmware active > > > > MTRR is failing in many cases... It seems that your BIOS is doing what > > both of my newer machines are doing and setting a global range to > > write-back. I'm also guessing that 0xc0000000 is your framebuffer. > > Correct. The framebuffer starts at 0xd0000000, still covered by that last > range. > > > We > > aren't allowed to overlap either of these ranges with a write combined > > region according to the specs. We would have to handle > > splitting/merging regions which we don't currently do. I looked at this > > just the other day, but it is reasonably complex to make that work right > > and accommodate all of the merging/splitting of regions. > > > > We are allowed to use PAT on either of these types of regions to enable > > write-combining. The drm code already does this for some allocations > > that are not mapped to user space. The problem with PAT is that all > > mappings of a given region need to have the same type and we don't > > currently have any way to specify that for user space mappings. This is > > fwiw, the last of Nvidia's feature requests as well. I've started > > looking at it, but I have a lot of learning to do on the vm system > > still. > > Thanks for taking the time to explain. Your posts are always very > informative. I am learning quite a lot about the complexities involved. > > There is yet another thing I don't understand. With other graphics cards, > including my G45 internal graphics adaptor, the /dev/agpgart device is > created. I don't see this device with the Radeon card. Is this expected > because it is not needed for PCIe? That is correct. If you have an agp based chipset, then the agp wriver will attach to your chipset and give you an agpgart device. All Intel graphics chips emulate AGP, so you will always have an agpgart device. With PCI-E based cards such as ATI or Nvidia, they don't use AGP. In those situations, we use a PCI GART (ati_pcigart.c) and map scatter gather memory into the GART. Nouveau is very similar in that respect. robert. > Cheers, > > -- Norbert Papke. > npapke@acm.org -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090423/c1c014c6/attachment.pgp From andrsn at andrsn.stanford.edu Thu Apr 23 07:48:32 2009 From: andrsn at andrsn.stanford.edu (Annelise Anderson) Date: Thu Apr 23 07:48:39 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090422192644.GA52151@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090422192644.GA52151@alchemy.franken.de> Message-ID: On Wed, 22 Apr 2009, Marius Strobl wrote: > On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: >> On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: >>> Use the sources you have but plug in sys/dev/bge/if_bge.c >>> rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this >>> combination should work. >> >> correct. >> >>> Then update if_bge.c to rev >>> 1.198.2.14 and check whether things still work, >> >> this causes the problem to resurface. >> > > David, > > this is the second report that using MSI with a BCM5754/ > chip=0x167a14e4 results in no interrupts, is there any > errata about this? > > Thanks, > Marius I wanted to upgrade my stable and but now am afraid to reboot with the new kernel as I've got one of these bge0 cards. dmesg reveals: brgphy0: PHY 1 on miibus0 a different version of BCM, not BCM 5754 and the log of cvsup shows: Edit src/sys/dev/bge/if_bge.c Add delta 1.198.2.12 2009.01.15.20.13.22 marius Add delta 1.198.2.13 2009.01.15.20.19.53 marius Add delta 1.198.2.14 2009.01.15.20.23.38 marius Add delta 1.198.2.15 2009.03.19.16.44.37 marius Add delta 1.198.2.16 2009.03.23.20.53.38 marius Add delta 1.198.2.17 2009.03.27.21.21.22 marius Would you advise using the old kernel? Should I have posted to -questions? Annelise From jb000003 at mr-happy.com Thu Apr 23 15:01:52 2009 From: jb000003 at mr-happy.com (Jeff Blank) Date: Thu Apr 23 15:01:59 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090422192644.GA52151@alchemy.franken.de> Message-ID: <20090423150147.GF1231@mr-happy.com> On Thu, Apr 23, 2009 at 12:41:36AM -0700, Annelise Anderson wrote: > I wanted to upgrade my stable and but now am afraid to > reboot with the new kernel as I've got one of these bge0 cards. You should be able to back out fairly easily in case of most problems. When you reboot to single-user mode with the new kernel, you can test whatever you think you need to (device presence/functionality, networking, etc) before installing world. If you don't like the results, just rename or delete /boot/kernel, rename /boot/kernel.old to /boot/kernel, and reboot, no damage done (usually). > dmesg reveals: > > brgphy0: PHY 1 on miibus0 > > a different version of BCM, not BCM 5754 I can't speak authoritatively, but I expect you're fine. My problem appears to have a very narrow scope. Jeff From rwatson at FreeBSD.org Thu Apr 23 16:52:55 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Apr 23 16:53:02 2009 Subject: RELENG_7 crash In-Reply-To: <200904212057.n3LKv4i4092456@lava.sentex.ca> References: <200904210524.n3L5O9YS086865@lava.sentex.ca> <86vdox685s.fsf@kopusha.onet> <200904212057.n3LKv4i4092456@lava.sentex.ca> Message-ID: On Tue, 21 Apr 2009, Mike Tancsa wrote: > At 04:53 PM 4/21/2009, Mikolaj Golub wrote: > >> Just FYI, the same problem has already been registered in pr database as >> kern/132734. > > Thanks, > http://www.freebsd.org/cgi/query-pr.cgi?pr=132734 does look familiar > :) If you disable the snmpwalk, is the box stable ? It would be interesting to know if this tweak at least eliminates the instant panic: Index: if_mib.c =================================================================== --- if_mib.c (revision 191424) +++ if_mib.c (working copy) @@ -82,11 +82,9 @@ return EINVAL; if (name[0] <= 0 || name[0] > if_index || - ifnet_byindex(name[0]) == NULL) + (ifp = ifnet_byindex(name[0])) == NULL) return ENOENT; - ifp = ifnet_byindex(name[0]); - switch(name[1]) { default: return ENOENT; Robert N M Watson Computer Laboratory University of Cambridge From marius at alchemy.franken.de Thu Apr 23 17:19:52 2009 From: marius at alchemy.franken.de (Marius Strobl) Date: Thu Apr 23 17:19:59 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090422150612.GA1231@mr-happy.com> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> Message-ID: <20090423171949.GE50221@alchemy.franken.de> On Wed, Apr 22, 2009 at 11:06:12AM -0400, Jeff Blank wrote: > On Tue, Apr 21, 2009 at 09:55:10PM +0200, Marius Strobl wrote: > > Use the sources you have but plug in sys/dev/bge/if_bge.c > > rev 1.198.2.13 and sys/dev/pci/pci.c rev 1.355.2.6, this > > combination should work. > > correct. > > > Then update if_bge.c to rev > > 1.198.2.14 and check whether things still work, > > this causes the problem to resurface. > FYI, I've found a notebook equipped with the exact same Broadcom chip and ASIC revision but which works without problems with current sources. So in combination with the low number of problem reports this really doesn't look like a generic problem of this Broadcom hardware or bge(4) and I just can suggest to disable MSI by setting the hw.pci.enable_msi tuneable to 0 for now. As David pointed out this might be a problem with the Nvidia chipset. Linux seems to have a workaround related to this but I still need to check that in detail. Marius From michel.dicroci at gmail.com Thu Apr 23 18:35:13 2009 From: michel.dicroci at gmail.com (Michel Di Croci) Date: Thu Apr 23 18:35:20 2009 Subject: Evaluating the performance of a single FreeBSD server Message-ID: Hello, One of my ex colleague wanna startup a web project. I'm still unsure about the possibility of expansion of the project so I prefer to start slowly. One of my idea was to use a FreeBSD server (a rack one which I will put in a colocation environment) and use it as a starting server and runs an Apache + PHP + PostgreSQL (for a long run stable and expandable DB). If it starts to respond slowly after the "initial release of the service"... I would add more servers (one new for the DB and another one for a webserver and a load balancer) with the profit from the service. You know where I'm heading... adding as needs grows. However what I want to know here is how much could handle this server as a standalone? How many requests at the same time ? If it's a good way to present as a startup? If we should go indead to a managed server. My idea here is that if it's going too slow, we might just buy new instead of going with a all managed solution where we would be more like renting a server. He doesn't have a lot of money, especially at the beginning but I wish to be in a middle solution. Responding for a lot of requests (if it's starting well) without the drawback of having just one server. We cannot afford a full rack of server if it would even be better. Michel PS: If you have suggestion for better hardware, just let me know. I never venture in this direction but I know FreeBSD is running quite well here in my house ;) But I know that's not the same story if I want a server being accessible. I don't think we'll be slashdotted however.... ;) From jb000003 at mr-happy.com Thu Apr 23 20:05:09 2009 From: jb000003 at mr-happy.com (Jeff Blank) Date: Thu Apr 23 20:05:15 2009 Subject: bge problems under 7.2-PRERELEASE In-Reply-To: <20090423171949.GE50221@alchemy.franken.de> References: <20090420204637.GA1236@mr-happy.com> <20090421184924.GA36542@alchemy.franken.de> <20090421193129.GA4869@mr-happy.com> <20090421195510.GC33994@alchemy.franken.de> <20090422150612.GA1231@mr-happy.com> <20090423171949.GE50221@alchemy.franken.de> Message-ID: <20090423200507.GA1246@mr-happy.com> On Thu, Apr 23, 2009 at 07:19:49PM +0200, Marius Strobl wrote: > So in combination with > the low number of problem reports this really doesn't > look like a generic problem of this Broadcom hardware > or bge(4) and I just can suggest to disable MSI by > setting the hw.pci.enable_msi tuneable to 0 for now. Great, this does the trick, and I'm now running today's RELENG_7. Thanks for your help, and let me know if ever you'd like me to help test possible fixes. Jeff From zbeeble at gmail.com Thu Apr 23 20:39:08 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Thu Apr 23 20:39:15 2009 Subject: Evaluating the performance of a single FreeBSD server In-Reply-To: References: Message-ID: <5f67a8c40904231339i3335cb22sa2b72f52ec0766ec@mail.gmail.com> On Thu, Apr 23, 2009 at 2:04 PM, Michel Di Croci wrote: > Hello, > > One of my ex colleague wanna startup a web project. I'm still unsure about > [...] > However what I want to know here is how much could handle this server as a > standalone? How many requests at the same time ? If it's a good way to > present as a startup? If we should go indead to a managed server. My idea > here is that if it's going too slow, we might just buy new instead of going > with a all managed solution where we would be more like renting a server. System performance is a moving target that is insanely difficult to hit without usage data. Is your application going to be processor bound (unlikely these days), memory bound, network bound, disk bound? The cost of a baisc server from a large vendor is around $1k (dell, hp, sun, etc) that you can load FreeBSD on. If you purchace carefully, you'll get a nice quad core with decently fast memory and two disks (RAID 1). It will also likely have two or more gigabit nics. Is this optimal in any way? No. The nic chipsets will suck a bit, the drives will be small-ish... and so on. But compared to a few years ago when you had to care about the performance of a server for a small company, the system will be a monster. My sincere advice is to buy the basic server, build your app and then test it. Test what gets busy first. This depends a little on the hardware, but it depends a lot on how you build your app. It may be cheaper to optimize the app rather than buy more hardware. As an example, moving the database server to another machine may not help at all. If you're not CPU bound, you simply move the bottlenecked I/O to another machine --- still bottlenecked. But as a baseline to answer your question, without running anything serverside (just serving files) FreeBSD can fill multiple gigE nics with content (large-ish files) or perform many millions of hits an hour (small files) on this configuration. Making the broad brush assumption that your Apache+PHP+PostgreSQL is going to run a moderate content manager (a moderately onerous application), you'll still probably pass a million hits an hour if you can push that much content over your network connection and your disks are fast enough (and you can display your page with one or two database hits). In fact number of databse hits per pageview is likely one of your larger limitations. From army.of.root at googlemail.com Thu Apr 23 22:22:38 2009 From: army.of.root at googlemail.com (army.of.root) Date: Thu Apr 23 22:22:46 2009 Subject: Evaluating the performance of a single FreeBSD server In-Reply-To: References: Message-ID: <49F0E264.4020904@googlemail.com> Michel Di Croci wrote: > He doesn't have a lot of money, especially at the beginning but I wish to be > in a middle solution. Responding for a lot of requests (if it's starting > well) without the drawback of having just one server. We cannot afford a > full rack of server if it would even be better. Hi, maybe Amazon's AWS or similar services are helpful here. I'm not getting paid to say that, but you don't have to invest a whole lot to get startet. regards From matthias.andree at gmx.de Fri Apr 24 08:31:09 2009 From: matthias.andree at gmx.de (Matthias Andree) Date: Fri Apr 24 08:31:16 2009 Subject: FreeBSD 7.2-RC1 Available In-Reply-To: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> References: <1239988503.94812.26.camel@bauer.cse.buffalo.edu> Message-ID: Am 17.04.2009, 19:15 Uhr, schrieb Ken Smith : > The first of two planned Release Candidates for the FreeBSD 7.2-RELEASE > cycle is now available. Testing of some of the recent work would be > particularly appreciated. This includes: Can one peek at the release notes already? The /relnotes.html main links point to empty documents, the snapshots point to 7.0 release notes. Particularly, can FreeBSD 7.2 support 256-byte inodes in ext2fs? -- Matthias Andree From lehmann at ans-netz.de Fri Apr 24 13:11:05 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Fri Apr 24 13:11:13 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <1240463479.2142.21.camel@balrog.2hip.net> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> <200904221938.12129.npapke@acm.org> <1240463479.2142.21.camel@balrog.2hip.net> Message-ID: <20090424151102.970570fa.lehmann@ans-netz.de> Hi Robert, there is one problem left here. When changing from inside X11 to the console (Ctrl+F1), and then changing back to X11 (Alt+F9), the the monitor keeps being black. From a remote login I can see, that Xorg is now unkillable and eats all my CPU. dmesg shows: info: [drm] wait idle failed status : 0xA0003030 0x00000003 over and over (looks like the buffer can only keep 1090 lines ;)) All I'm left with is rebooting the system :( -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From cperciva at freebsd.org Fri Apr 24 15:11:48 2009 From: cperciva at freebsd.org (Colin Percival) Date: Fri Apr 24 15:11:55 2009 Subject: Looking for FreeBSD Update mirrors for 7.2-RELEASE Message-ID: <49F1D6A5.7070400@freebsd.org> Hi all, When 7.1-RELEASE came out, FreeBSD Update was overwhelmed by the burst of traffic as thousands of people tried to upgrade at once. I'd like to make sure this doesn't happen again, so I'm looking for some extra temporary mirror capacity. If you can provide me with (a) 40 GB of disk space, (b) 1 TB of bandwidth (I expect 10+ Mbps for the first few days after the release announcement), (c) an HTTP server (or root/jail access so that I can install one myself), and (d) a firewall rule which blocks outgoing RST packets, for the month of May (depending on when the release happens, I might not need these extra mirrors beyond the middle of the month), please contact me. Extra points if you have a fast disk subsystem, since FreeBSD Update involves serving up lots of small files, and it has been disk seek limited in the past. The requirement (d) results from a bug in phttpget which (I think) caused a lot of failed attempts to upgrade systems to 7.1-RELEASE; I've fixed this bug now, but people upgrading from old releases will still have the buggy phttpget, so for now it's necessary to work around the bug by making sure that RSTs don't get sent (the buggy phttpget dies if a connection is reset instead of retrying it properly). Since I'm sure people will ask: I'm not looking for extra permanent mirrors at the moment. The FreeBSD Update mirroring code currently consists of "Colin sshes into servers and copies bits around from the shell", so until I've made some improvements to that I don't really want to have any more mirrors than necessary. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From pluknet at gmail.com Fri Apr 24 15:42:42 2009 From: pluknet at gmail.com (pluknet) Date: Fri Apr 24 15:42:49 2009 Subject: policy for dumpdev in -stable Message-ID: Hi. I noticed that dumpdev in defaults/rc.conf was initially to be set to "AUTO" in -current only, and to be switched back to "NO" after creating a new stable branch (to be "NO" in .0 release). Nevertheless it was set to "NO" only just before 6.1 was out, and is currently "AUTO" before 7.2. -- wbr, pluknet From rnoland at FreeBSD.org Fri Apr 24 17:22:08 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 24 17:22:40 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090424151102.970570fa.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> <200904221938.12129.npapke@acm.org> <1240463479.2142.21.camel@balrog.2hip.net> <20090424151102.970570fa.lehmann@ans-netz.de> Message-ID: <1240593706.2142.38.camel@balrog.2hip.net> On Fri, 2009-04-24 at 15:11 +0200, Oliver Lehmann wrote: > Hi Robert, > > there is one problem left here. When changing from inside X11 to the > console (Ctrl+F1), and then changing back to X11 (Alt+F9), the the > monitor keeps being black. From a remote login I can see, that Xorg is > now unkillable and eats all my CPU. dmesg shows: > > info: [drm] wait idle failed status : 0xA0003030 0x00000003 > > over and over (looks like the buffer can only keep 1090 lines ;)) > > All I'm left with is rebooting the system :( Which chip is this with? Vt switching seems fine for me on x1650 and HD 3850. I don't think that I have anything substantial in my tree that isn't in -STABLE for ATI. robert. -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090424/c6cbe617/attachment.pgp From lehmann at ans-netz.de Fri Apr 24 17:52:10 2009 From: lehmann at ans-netz.de (Oliver Lehmann) Date: Fri Apr 24 17:52:18 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <1240593706.2142.38.camel@balrog.2hip.net> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> <200904221938.12129.npapke@acm.org> <1240463479.2142.21.camel@balrog.2hip.net> <20090424151102.970570fa.lehmann@ans-netz.de> <1240593706.2142.38.camel@balrog.2hip.net> Message-ID: <20090424195205.73a2cf44.lehmann@ans-netz.de> Hi Robert, Robert Noland wrote: > On Fri, 2009-04-24 at 15:11 +0200, Oliver Lehmann wrote: > > > > info: [drm] wait idle failed status : 0xA0003030 0x00000003 > > Which chip is this with? vgapci0@pci0:1:0:0: class=0x030000 card=0x00281787 chip=0x95151002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' class = display subclass = VGA -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From horst at sxemacs.org Fri Apr 24 17:58:30 2009 From: horst at sxemacs.org (Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III) Date: Fri Apr 24 17:58:36 2009 Subject: magic disappearing coredumps Message-ID: <1240586478.2433.2004.camel@horst-tla> I'm trying to debug a piece of software. It dumps a core file which mysteriously vanishes. it's not in the program directory, nor my $HOME, nor /var/crash nor /var/core ... Deliberately crashing /bin/sh also results in a core file which turns up nowhere on my filesystem. Crossposting to -stable and -ppc because i'm uncertain whether this is a ppc issue or a bsd issue or simple operator incompetence. I apologise if the answer is something that was a google away. -- Horst -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090424/d4aaca7c/attachment.pgp From rnoland at FreeBSD.org Fri Apr 24 18:06:41 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Apr 24 18:06:48 2009 Subject: dri + ATI: dramatic performance slowdown In-Reply-To: <20090424195205.73a2cf44.lehmann@ans-netz.de> References: <20090420152620.8f89edd5.lehmann@ans-netz.de> <200904221739.25097.npapke@acm.org> <1240448113.2142.11.camel@balrog.2hip.net> <200904221938.12129.npapke@acm.org> <1240463479.2142.21.camel@balrog.2hip.net> <20090424151102.970570fa.lehmann@ans-netz.de> <1240593706.2142.38.camel@balrog.2hip.net> <20090424195205.73a2cf44.lehmann@ans-netz.de> Message-ID: <1240596378.2142.45.camel@balrog.2hip.net> On Fri, 2009-04-24 at 19:52 +0200, Oliver Lehmann wrote: > Hi Robert, > > Robert Noland wrote: > > > On Fri, 2009-04-24 at 15:11 +0200, Oliver Lehmann wrote: > > > > > > info: [drm] wait idle failed status : 0xA0003030 0x00000003 > > > > Which chip is this with? > > vgapci0@pci0:1:0:0: class=0x030000 card=0x00281787 chip=0x95151002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc' > class = display > subclass = VGA Hrm, that is an HD 3850... Same as I am running now... Do you have to remain on console for a period of time, or does just switching back and forth crash the gpu? robert. > -- Robert Noland FreeBSD -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090424/9d9f0a43/attachment.pgp From gpalmer at freebsd.org Fri Apr 24 18:07:34 2009 From: gpalmer at freebsd.org (Gary Palmer) Date: Fri Apr 24 18:07:46 2009 Subject: magic disappearing coredumps In-Reply-To: <1240586478.2433.2004.camel@horst-tla> References: <1240586478.2433.2004.camel@horst-tla> Message-ID: <20090424180729.GA79909@in-addr.com> On Sat, Apr 25, 2009 at 01:21:18AM +1000, Horst G?nther Burkhardt III wrote: > I'm trying to debug a piece of software. It dumps a core file which > mysteriously vanishes. it's not in the program directory, nor my $HOME, > nor /var/crash nor /var/core ... > > Deliberately crashing /bin/sh also results in a core file which turns up > nowhere on my filesystem. > > Crossposting to -stable and -ppc because i'm uncertain whether this is a > ppc issue or a bsd issue or simple operator incompetence. > > I apologise if the answer is something that was a google away. Did you check your ulimit limits to see if your login session actually allows for coredumps to be created? Regards, Gary From josh.carroll at gmail.com Fri Apr 24 18:30:10 2009 From: josh.carroll at gmail.com (Josh Carroll) Date: Fri Apr 24 18:30:21 2009 Subject: magic disappearing coredumps In-Reply-To: <1240586478.2433.2004.camel@horst-tla> References: <1240586478.2433.2004.camel@horst-tla> Message-ID: <8cb6106e0904241104n74d4739fi89c9ed05da001053@mail.gmail.com> On Fri, Apr 24, 2009 at 11:21 AM, Horst G?nther Burkhardt III wrote: > I'm trying to debug a piece of software. It dumps a core file which > mysteriously vanishes. it's not in the program directory, nor my $HOME, > nor /var/crash nor /var/core ... > > Deliberately crashing /bin/sh also results in a core file which turns up > nowhere on my filesystem. > > Crossposting to -stable and -ppc because i'm uncertain whether this is a > ppc issue or a bsd issue or simple operator incompetence. > > I apologise if the answer is something that was a google away. > > -- Horst > Have you limited the coredumpsize to 0 by chance? What output do you get from: limits | grep core or perhaps: ulimit -a | grep core Regards, Josh From glen.j.barber at gmail.com Fri Apr 24 18:32:01 2009 From: glen.j.barber at gmail.com (Glen Barber) Date: Fri Apr 24 18:32:09 2009 Subject: magic disappearing coredumps In-Reply-To: <1240586478.2433.2004.camel@horst-tla> References: <1240586478.2433.2004.camel@horst-tla> Message-ID: <4ad871310904241109qbf37b44pa414db7ec2f32c0c@mail.gmail.com> On Fri, Apr 24, 2009 at 11:21 AM, Horst G?nther Burkhardt III wrote: > I'm trying to debug a piece of software. It dumps a core file which > mysteriously vanishes. it's not in the program directory, nor my $HOME, > nor /var/crash nor /var/core ... > > Deliberately crashing /bin/sh also results in a core file which turns up > nowhere on my filesystem. > > Crossposting to -stable and -ppc because i'm uncertain whether this is a > ppc issue or a bsd issue or simple operator incompetence. > > I apologise if the answer is something that was a google away. > Do you disable coredumps in /boot/loader.conf? The following would enable them: kern.coredump=1 -- Glen Barber From ivoras at freebsd.org Fri Apr 24 18:47:03 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Apr 24 18:47:09 2009 Subject: Looking for FreeBSD Update mirrors for 7.2-RELEASE In-Reply-To: <49F1D6A5.7070400@freebsd.org> References: <49F1D6A5.7070400@freebsd.org> Message-ID: Colin Percival wrote: > Hi all, > > When 7.1-RELEASE came out, FreeBSD Update was overwhelmed by the burst of > traffic as thousands of people tried to upgrade at once. I'd like to > make sure > this doesn't happen again, so I'm looking for some extra temporary mirror > capacity. How are the servers chosen by freebsd-update? The same question for portsnap. What I'm hinting at is: is there some geography involved? I could provide you with a server in Eastern Europe but it's very badly connected with USA. > Since I'm sure people will ask: I'm not looking for extra permanent > mirrors at > the moment. The FreeBSD Update mirroring code currently consists of "Colin > sshes into servers and copies bits around from the shell", so until I've > made > some improvements to that I don't really want to have any more mirrors than > necessary. Hmm, if requests such as these are going to happen often, you probably should. If the front-end needs only HTTP, could you modify the backend so the updates are propagated with rsync and a self-maintained web of update servers can emerge similar to "normal" mirrors? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090424/d49d8b60/signature.pgp From ivoras at freebsd.org Fri Apr 24 18:56:18 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Apr 24 18:56:25 2009 Subject: Evaluating the performance of a single FreeBSD server In-Reply-To: References: Message-ID: Michel Di Croci wrote: > colocation environment) and use it as a starting server and runs an Apache + > PHP + PostgreSQL (for a long run stable and expandable DB). If it starts to Even if we forget everything else you said, "Apache + PHP + PostgreSQL" means you have at least ... BOTE calculation ... at least 24 different combinations of how these components interact with each other and each has different performance characteristics. You need to give us much more information before something meaningful can be concluded. In general, 90% of your performance issues will be in the application (PHP code, not PHP itself) and the database (structure, indexes, etc.). Assuming you have a decent application architecture, database schema and enough bandwidth, can you think of a similar already existing web application so people can have a baseline when giving you advice? (Don't think "Google" ... think of a smaller application which can be compared in size to yours). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090424/b29b6966/signature.pgp From martisch at uos.de Fri Apr 24 19:01:53 2009 From: martisch at uos.de (Martin Schmidt) Date: Fri Apr 24 19:02:02 2009 Subject: 7.1-STABLE Sun Mar 29 01:06:46 ADT 2009 Locks up ... Message-ID: Hi Marc and List, i had similar issues with FreeBSD 7.2-PRERELEASE. Server (zfs,nfs) seems to hang in intervals of about 8 hours. kernel is still there but no connections can be made to nfs/ssh and login on local console doesn't seem to work due to incredible slowness. breaking to the debugger takes a moment but works. (compiling kernel with WITNESS didnt help) the server had been solid before with 7 stable kernel from around 19 October 2008. I now added these lines to /boot/loader.conf hw.pci.enable_msi=0 hw.pci.enable_msix=0 to disable Message Signaled Interrupts. Which are used by the 3ware twa driver and igb network driver on our server. With this the server had run 3 days with no hangs. I then enabled msi again and had a hang within 24 hours. Disabled again and now the server is online without an issue for 6 days. Im not 100% sure yet if this really is the sole source of the problems (e.g. workload might be another factor). But i guess its worth a try to check if it might help you too. If this is a known problem or there are any other hints to solve this problem or if the server configuration just seems wrong, i appreciate the feedback. regards, Martin pciconf (with msi): hostb0@pci0:0:0:0: class=0x060000 card=0xa28015d9 chip=0x40038086 rev=0x20 hdr=0x00 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port pcib1@pci0:0:1:0: class=0x060400 card=0xa28015d9 chip=0x40218086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pcib2@pci0:0:3:0: class=0x060400 card=0xa28015d9 chip=0x40238086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pcib3@pci0:0:5:0: class=0x060400 card=0xa28015d9 chip=0x40258086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pcib4@pci0:0:7:0: class=0x060400 card=0xa28015d9 chip=0x40278086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 pcib8@pci0:0:9:0: class=0x060400 card=0xa28015d9 chip=0x40298086 rev=0x20 hdr=0x01 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[58] = MSI supports 2 messages cap 10[6c] = PCI-Express 2 root port cap 0d[b0] = PCI Bridge card=0xa28015d9 none0@pci0:0:15:0: class=0x088000 card=0xa28015d9 chip=0x402f8086 rev=0x20 hdr=0x00 cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 11[58] = MSI-X supports 4 messages in map 0x10 cap 10[6c] = PCI-Express 2 type 0 hostb1@pci0:0:16:0: class=0x060000 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb2@pci0:0:16:1: class=0x060000 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb3@pci0:0:16:2: class=0x060000 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb4@pci0:0:16:3: class=0x060000 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb5@pci0:0:16:4: class=0x060000 card=0xa28015d9 chip=0x40308086 rev=0x20 hdr=0x00 hostb6@pci0:0:17:0: class=0x060000 card=0xa28015d9 chip=0x40318086 rev=0x20 hdr=0x00 hostb7@pci0:0:21:0: class=0x060000 card=0xa28015d9 chip=0x40358086 rev=0x20 hdr=0x00 hostb8@pci0:0:21:1: class=0x060000 card=0xa28015d9 chip=0x40358086 rev=0x20 hdr=0x00 hostb9@pci0:0:22:0: class=0x060000 card=0xa28015d9 chip=0x40368086 rev=0x20 hdr=0x00 hostb10@pci0:0:22:1: class=0x060000 card=0xa28015d9 chip=0x40368086 rev=0x20 hdr=0x00 pcib9@pci0:0:28:0: class=0x060400 card=0xa28015d9 chip=0x26908086 rev=0x09 hdr=0x01 cap 10[40] = PCI-Express 1 root port cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0xa28015d9 cap 01[a0] = powerspec 2 supports D0 D3 current D0 uhci0@pci0:0:29:0: class=0x0c0300 card=0xa28015d9 chip=0x26888086 rev=0x09 hdr=0x00 uhci1@pci0:0:29:1: class=0x0c0300 card=0xa28015d9 chip=0x26898086 rev=0x09 hdr=0x00 uhci2@pci0:0:29:2: class=0x0c0300 card=0xa28015d9 chip=0x268a8086 rev=0x09 hdr=0x00 ehci0@pci0:0:29:7: class=0x0c0320 card=0xa28015d9 chip=0x268c8086 rev=0x09 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pcib10@pci0:0:30:0: class=0x060401 card=0xa28015d9 chip=0x244e8086 rev=0xd9 hdr=0x01 cap 0d[50] = PCI Bridge card=0xa28015d9 isab0@pci0:0:31:0: class=0x060100 card=0xa28015d9 chip=0x26708086 rev=0x09 hdr=0x00 atapci0@pci0:0:31:1: class=0x01018a card=0xa28015d9 chip=0x269e8086 rev=0x09 hdr=0x00 atapci1@pci0:0:31:2: class=0x010601 card=0xa28015d9 chip=0x26818086 rev=0x09 hdr=0x00 cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 12[a8] = unknown none1@pci0:0:31:3: class=0x0c0500 card=0xa28015d9 chip=0x269b8086 rev=0x09 hdr=0x00 twa0@pci0:1:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint pcib5@pci0:4:0:0: class=0x060400 card=0xa28015d9 chip=0x35008086 rev=0x01 hdr=0x01 cap 10[44] = PCI-Express 1 upstream port cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 0d[80] = PCI Bridge card=0xa28015d9 pcib7@pci0:4:0:3: class=0x060400 card=0xa28015d9 chip=0x350c8086 rev=0x01 hdr=0x01 cap 10[44] = PCI-Express 1 PCI bridge cap 01[6c] = powerspec 2 supports D0 D3 current D0 cap 0d[80] = PCI Bridge card=0xa28015d9 cap 07[d8] = PCI-X bridge supports pcib6@pci0:5:0:0: class=0x060400 card=0xa28015d9 chip=0x35108086 rev=0x01 hdr=0x01 cap 10[44] = PCI-Express 1 downstream port cap 05[60] = MSI supports 1 message, 64 bit cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 0d[80] = PCI Bridge card=0xa28015d9 twa1@pci0:6:0:0: class=0x010400 card=0x100413c1 chip=0x100413c1 rev=0x01 hdr=0x00 cap 01[40] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 32 messages, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint igb0@pci0:8:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint igb1@pci0:8:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint vgapci0@pci0:10:1:0: class=0x030000 card=0xa28015d9 chip=0x515e1002 rev=0x02 hdr=0x00 cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 vmstat -i (with msi): mstat -i interrupt total rate irq1: atkbd0 2 0 irq14: ata0 216 0 irq17: atapci1 172855 200 irq23: ehci0 12 0 irq48: twa0 1472 1 irq54: twa1 1895 2 cpu0: timer 1722548 1998 irq256: igb0 772 0 irq257: igb0 2673 3 irq258: igb0 485 0 irq259: igb0 2121 2 irq260: igb0 1319 1 irq261: igb0 2 0 cpu1: timer 1714417 1988 cpu2: timer 1713997 1988 cpu3: timer 1714220 1988 Total 7049006 8177 vmstat -i (without msi): interrupt total rate irq1: atkbd0 2 0 irq14: ata0 216 0 irq17: atapci1 210359 536 irq23: ehci0 11 0 irq48: twa0 1331 3 irq54: twa1 1751 4 irq56: igb0 3733 9 cpu0: timer 783575 1998 cpu1: timer 775435 1978 cpu2: timer 775251 1977 cpu3: timer 775364 1977 Total 3327028 8487 dmesg (without msi): 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-PRERELEASE #6: Mon Apr 13 13:30:07 CEST 2009 adm...@space.neurobiopsychologie.Uni-Osnabrueck.DE:/usr/obj/usr/ src/sys/SPACE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (2327.51-MHz K8- class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features = 0xbfebfbff < FPU ,VME ,DE ,PSE ,TSC ,MSR ,PAE ,MCE ,CX8 ,APIC ,SEP ,MTRR ,PGE ,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2 = 0xce3bd > AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 4 usable memory = 4280475648 (4082 MB) avail memory = 4107509760 (3917 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 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) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 48 at device 1.0 on pci0 pci1: on pcib1 3ware device driver for 9000 series storage controllers, version: 3.70.05.001 twa0: <3ware 9000 series Storage Controller> port 0x2000-0x20ff mem 0xd8000000-0xd9ffffff,0xdc100000-0xdc100fff irq 48 at device 0.0 on pci1 twa0: [ITHREAD] twa0: INFO: (0x04: 0x0001): Controller reset occurred: resets=3 twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 4.06.00.004, BIOS BE9X 4.05.00.015 pcib2: irq 50 at device 3.0 on pci0 pci2: on pcib2 pcib3: irq 52 at device 5.0 on pci0 pci3: on pcib3 pcib4: irq 54 at device 7.0 on pci0 pci4: on pcib4 pcib5: irq 54 at device 0.0 on pci4 pci5: on pcib5 pcib6: irq 54 at device 0.0 on pci5 pci6: on pcib6 twa1: <3ware 9000 series Storage Controller> port 0x3000-0x30ff mem 0xda000000-0xdbffffff,0xdc400000-0xdc400fff irq 54 at device 0.0 on pci6 twa1: [ITHREAD] twa1: INFO: (0x04: 0x0001): Controller reset occurred: resets=3 twa1: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-8LPML, 8 ports, Firmware FE9X 4.06.00.004, BIOS BE9X 4.05.00.015 pcib7: at device 0.3 on pci4 pci7: on pcib7 pcib8: irq 56 at device 9.0 on pci0 pci8: on pcib8 igb0: port 0x4000-0x401f mem 0xdc020000-0xdc03ffff,0xdc000000-0xdc01ffff, 0xdc080000-0xdc083fff irq 56 at device 0.0 on pci8 igb0: [FILTER] igb0: Ethernet address: 00:30:48:c2:35:76 igb1: port 0x4020-0x403f mem 0xdc060000-0xdc07ffff,0xdc040000-0xdc05ffff, 0xdc084000-0xdc087fff irq 70 at device 0.1 on pci8 igb1: [FILTER] igb1: Ethernet address: 00:30:48:c2:35:77 pci0: at device 15.0 (no driver attached) pcib9: irq 16 at device 28.0 on pci0 pci9: on pcib9 uhci0: port 0x1800-0x181f irq 20 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 0x1820-0x183f irq 21 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 0x1840-0x185f irq 22 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 0xdc704000-0xdc7043ff 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 ums0: on uhub3 ums0: 3 buttons and Z dir. ukbd0: on uhub3 kbd2 at ukbd0 pcib10: at device 30.0 on pci0 pci10: on pcib10 vgapci0: port 0x5000-0x50ff mem 0xd0000000-0xd7ffffff,0xdc200000-0xdc20ffff irq 18 at device 1.0 on pci10 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] atapci1: port 0x18b0-0x18b7,0x18a8-0x18ab, 0x18a0-0x18a7,0x1874-0x1877,0x1880-0x189f mem 0xdc704400-0xdc7047ff irq 17 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.10 controller with 6 ports detected ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 cpu0: on acpi0 ACPI Error (psargs-0459): [\\_SB_.BCMD] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0626): Method parse/execution failed [\ \_PR_.CPU0._OSC] (Node 0xffffff0001608c20), AE_NOT_FOUND ACPI Error (psparse-0626): Method parse/execution failed [\ \_PR_.CPU0._PDC] (Node 0xffffff0001608c40), AE_NOT_FOUND ACPI Error (psargs-0459): [\\_SB_.BCMD] Namespace lookup failure, AE_NOT_FOUND ACPI Error (psparse-0626): Method parse/execution failed [\ \_PR_.CPU0._OSC] (Node 0xffffff0001608c20), AE_NOT_FOUND coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 ipmi0: on isa0 ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcd7ff, 0xcd800-0xcf7ff,0xcf800-0xcffff on isa0 ppc0: cannot reserve I/O port range 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: DVDROM at ata0-slave UDMA33 ad4: 238475MB at ata2-master SATA150 ad6: 238475MB at ata3-master SATA300 ipmi0: IPMI device rev. 1, firmware rev. 1.2, version 2.0 ipmi0: Number of channels 8 ipmi0: Attached watchdog da0 at twa0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 100.000MB/s transfers da0: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da1 at twa0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 100.000MB/s transfers da1: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da2 at twa0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-5 device da2: 100.000MB/s transfers da2: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da3 at twa0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-5 device da3: 100.000MB/s transfers da3: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da4 at twa0 bus 0 target 4 lun 0 da4: Fixed Direct Access SCSI-5 device da4: 100.000MB/s transfers da4: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da5 at twa0 bus 0 target 5 lun 0 da5: Fixed Direct Access SCSI-5 device da5: 100.000MB/s transfers da5: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da6 at twa0 bus 0 target 6 lun 0 da6: Fixed Direct Access SCSI-5 device da6: 100.000MB/s transfers da6: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da7 at twa0 bus 0 target 7 lun 0 da7: Fixed Direct Access SCSI-5 device da7: 100.000MB/s transfers da7: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da8 at twa1 bus 0 target 0 lun 0 da8: Fixed Direct Access SCSI-5 device da8: 100.000MB/s transfers da8: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da9 at twa1 bus 0 target 1 lun 0 da9: Fixed Direct Access SCSI-5 device da9: 100.000MB/s transfers da9: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da10 at twa1 bus 0 target 2 lun 0 da10: Fixed Direct Access SCSI-5 device da10: 100.000MB/s transfers da10: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da11 at twa1 bus 0 target 3 lun 0 da11: Fixed Direct Access SCSI-5 device da11: 100.000MB/s transfers da11: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da12 at twa1 bus 0 target 4 lun 0 da12: Fixed Direct Access SCSI-5 device da12: 100.000MB/s transfers da12: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da13 at twa1 bus 0 target 5 lun 0 da13: Fixed Direct Access SCSI-5 device da13: 100.000MB/s transfers da13: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da14 at twa1 bus 0 target 6 lun 0 da14: Fixed Direct Access SCSI-5 device da14: 100.000MB/s transfers da14: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) da15 at twa1 bus 0 target 7 lun 0 da15: Fixed Direct Access SCSI-5 device da15: 100.000MB/s transfers da15: 715245MB (1464821760 512 byte sectors: 255H 63S/T 91180C) SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! On Apr 15, 5:15 am, free...@hub.org ("Marc G. Fournier") wrote: > --==========FBEC849F7CF9A3F6439C========== > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > Hi ... > Over the past little while, two of my servers have suddenly started to hang > ... servers that up until this started, have been reasonably rock solid ... > they are generally within a day of each other for source code, and the hardware > on both are pretty much identical (HP Proliant DL360 Servers) ... > I have serial console configured on both so that I can do CR ~ ^b to get to > DDB ... except, when it hangs, all I get is: > "KDB: enter: Break sequence on console" > And it hangs there, no prompt. > I setup a simple script (see attached) to run every 5 minutes that gathers > various pieces of info that I think are pertinent, but most likely don't cover > everything ... > Whenever this happens, on either machine, vmstat show data *like* (notice the > high procs -> w values?): > procs memory page disks faults cpu > r b w avm fre flt re pi