From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 00:33:17 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED5231065670; Sun, 5 Jul 2009 00:33:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id C1BEC8FC13; Sun, 5 Jul 2009 00:33:16 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n650UkEu028408; Sat, 4 Jul 2009 20:30:46 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907050030.n650UkEu028408@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Jul 2009 20:33:06 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 00:33:17 -0000 At 05:30 PM 7/3/2009, Mike Tancsa wrote: >At 03:31 PM 7/3/2009, Alexander Motin wrote: >>It would be more interesting to investigate benefits on NCQ >>suitable workload, as that are new for us. Something like unpacking >>a lot of small files to normal or async-mounted or gjournalled FS, >>or some multi-threaded read, or something else. Would be nice to >>understand on which types of workload NCQ could give us visible effects. >> >>You can track real requests parallelism by looking on dev_active >>field of `camcontrol tags ada0 -v`. > > >We dont have too many disk I/O bound apps here. Where we do, we >typically have used raid controllers in RAID10. But I will >experiment a little more over the weekend. For us, we are >interested in large amounts of storage for backup purposes. Having >things like port multiplier features are very nice to have. But I >will try some random io tests to see if I can measure a difference. I hooked up a Vantec eSata enclosure using a SATA to eSATA cable off the main motherboard. One small difference I noticed is that camcontrol does not get the info from the drive like it does on other devices. Perhaps thats the enclosure messing things up ? 0(ich10)# camcontrol identify ada2 pass2: < > ATA/ATAPI-0 device Protocol ATA/ATAPI revision 0 device model serial number firmware revision cylinders 0 heads 0 sectors/track 0 lba not supported lba48 not supported dma not supported overlap not supported Feature Support Enable Value Vendor write cache no no read ahead no no Tagged Command Queuing (TCQ) no no 0/0x00 SMART no no microcode download no no security no no power management no no advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 0/0x00 0(ich10)# 0(ich10)# camcontrol identify ada1 pass1: ATA/ATAPI-7 SATA 2.x device Protocol SATA revision 2.x device model ST380811AS serial number 6PS03G9Z firmware revision 3.AAE cylinders 16383 heads 16 sectors/track 63 lba supported 156301488 sectors lba48 supported 156301488 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management no no 0/0x00 208/0xD0 0(ich10)# camcontrol identify ada0 pass0: ATA/ATAPI-8 SATA 2.x device Protocol SATA revision 2.x device model ST3500410AS serial number 5VM0X6FG firmware revision CC34 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 976773168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes yes 0/0x00 254/0xFE 0(ich10)# There was a previous drive connected. We powered off the external drive, disconnected the cable, hooked up the new drive, powered up the enclosure and then I did a camcontrol rescan all Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): lost device Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): removing device entry Jul 4 20:19:37 ich10 kernel: (probe0:ahcich2:0:0:0): SIGNATURE: 0000 Jul 4 20:19:37 ich10 kernel: ada2 at ahcich2 bus 0 target 0 lun 0 Jul 4 20:19:37 ich10 kernel: ada2: ATA/ATAPI-8 SATA 1.x device Jul 4 20:19:37 ich10 kernel: ada2: 150.000MB/s transfers Jul 4 20:19:37 ich10 kernel: ada2: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) Jul 4 20:19:37 ich10 kernel: ada2: Native Command Queueing Enabled The drive we connected has some bad sectors, so I wanted to try a secure wipe as much as possible before RMAing the drive. I also thought it would be useful to test with the new driver how it handles bad disks Is this such an error ? Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is 40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 01:02:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE878106567A; Sun, 5 Jul 2009 01:02:56 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from tritus.poildetroll.net (tritus.poildetroll.net [81.93.245.19]) by mx1.freebsd.org (Postfix) with ESMTP id 55C908FC0C; Sun, 5 Jul 2009 01:02:56 +0000 (UTC) (envelope-from geekounet@poildetroll.net) Received: from korriban.poildetroll.net (kashyyyk.poildetroll.net [88.162.190.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tritus.poildetroll.net (Postfix) with ESMTPSA id 50C10C20; Sun, 5 Jul 2009 03:02:54 +0200 (CEST) Message-ID: <4A4FFBB0.5050903@poildetroll.net> Date: Sun, 05 Jul 2009 03:02:40 +0200 From: Pierre Guinoiseau Organization: Poil de Troll User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: Attilio Rao References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> <4A353E21.1080001@poildetroll.net> <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> <3bbf2fe10906281051k1da8d1edwc49388e30d3df492@mail.gmail.com> In-Reply-To: <3bbf2fe10906281051k1da8d1edwc49388e30d3df492@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig407E6E38B31ABA6210EAFC43" Cc: bf , "O. Hartmann" , freebsd-current@freebsd.org, Randall Stewart , Kip Macy Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 01:02:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig407E6E38B31ABA6210EAFC43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have some good news: the problem seems to be solved (at least for me) since I updated to r195011 about 2 weeks ago. I think it may be related to the MSI fixes (and the drm module may have been the cause, even if not used?), but I might be wrong. After this update, the permanent slowdown issue disappeared, but I still had some slowdown on high CPU load (but it was back to normal soon after coming back to a low load). I then figured out that it was due to an overheat problem on my laptop, slowing down the wall machine in some way... I've cleaned it up (there was a 5mm wall of dust in the fan!), and no more overheat nor slowdown since then. I'm sorry I can't reproduce it anymore now. ;) And I hope Randall's problem is fixed as well. :) Thanks for your help anyway! Pierre Guinoiseau Attilio Rao wrote: > 2009/6/24 Randall Stewart : >> One thing I have noticed for a while.. and have not >> been able to track down.. >> >> If one runs >> >> /usr/src/tools/tools/syscall_timing/syscall_timing >> >> On a 7.2 kernel and compare it on the same machine to an 8.0 kernel >> you will see almost a 3x slow down in 8. >=20 > So, as long as I think that for the pressing, next release, it is very > important to track such regressions down, I hope both Pierre and > Randall want to lend an hand. >=20 > First thing, Randall, could you recompile your kernel with > HWPMC_HOOKS, device hwpmc, and do some pmcstat runs in order to see > where/how the slowdown happens? > For example you could check if the number of cache misses increases, or= similar. >=20 > Both could provide, instead, once the slowdown takes place, verbose > top, ps and possibly vmstat, just to be sure in case. >=20 > If you are unable to reproduce the slowdown or give an hand, please let= me know. >=20 > Thanks, > Attilio >=20 >=20 --------------enig407E6E38B31ABA6210EAFC43 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpP+7wACgkQJikNJSAyef8VjQCeIOdL3rVydVE6pJekA5thp1LP m/EAoM7qSx1uBMHid4la5EJy1Wcrtv34 =O73o -----END PGP SIGNATURE----- --------------enig407E6E38B31ABA6210EAFC43-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 03:02:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E2551065670; Sun, 5 Jul 2009 03:02:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D6A8D8FC08; Sun, 5 Jul 2009 03:02:51 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from [10.251.87.223] (166-205-131-101.mobile.mymmode.com [166.205.131.101] (may be forged)) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n6532Zs4078915; Sat, 4 Jul 2009 21:02:44 -0600 (MDT) (envelope-from scottl@samsco.org) References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4F3B18.5010905@FreeBSD.org> Message-Id: <6E8AB140-4BF4-4CBC-BC96-D620F7A7CDFE@samsco.org> From: Scott Long To: Alexander Motin In-Reply-To: <4A4F3B18.5010905@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A341) Mime-Version: 1.0 (iPhone Mail 7A341) Date: Sat, 4 Jul 2009 21:02:25 -0600 X-Spam-Status: No, score=-2.6 required=3.8 tests=BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD-Current , "scottl@FreeBSD.org" , Mike Tancsa Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 03:02:52 -0000 On Jul 4, 2009, at 5:20 AM, Alexander Motin wrote: > Mike Tancsa wrote: >> On the ich10 board, its trying to boot up now, but I am getting >> uhub8: 4 ports with 4 removable, self powered >> (probe2:ahcich2:0:0:0): SIGNATURE: eb14 >> run_interrupt_driven_hooks: still waiting after 60 seconds for >> xpt_config >> ahcich2: Timeout on slot 4 >> run_interrupt_driven_hooks: still waiting after 120 seconds for >> xpt_config >> ahcich2: Timeout on slot 5 >> run_interrupt_driven_hooks: still waiting after 180 seconds for >> xpt_config >> ahcich2: Timeout on slot 6 >> run_interrupt_driven_hooks: still waiting after 240 seconds for >> xpt_config >> ahcich2: Timeout on slot 7 >> run_interrupt_driven_hooks: still waiting after 300 seconds for >> xpt_config >> ahcich2: Timeout on slot 8 >> ada0 at ahcich1 bus 0 target 0 lun 0 >> ada0: ATA/ATAPI-8 SATA 2.x device >> ada0: 300.000MB/s transfers >> ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada0: Native Command Queueing Enabled > > I've found how to make this DVD work. It refused to process PACKET > command until I have explicitly set it's PATA-legacy transfer mode > to the maximal supported. > > %camcontrol devlist > at scbus0 target 0 lun 0 > (pass0,ada0) > at scbus2 target 0 lun 0 > (cd0,pass1) > > Patch committed to P4. > > -- > Alexander Motin I mentioned this a few months ago. Both atapi and ata devices need a state machine to set their max transfer parameters, regardless if they are sata or pata. Newer sata devices might not need it, but older ones definitely do. IMHO, it's easiest to just do the negotiation for all sata devices instead of trying to be selective about it. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 06:41:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDA3106564A; Sun, 5 Jul 2009 06:41:32 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id B08758FC0A; Sun, 5 Jul 2009 06:41:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247669716; Sun, 05 Jul 2009 09:41:28 +0300 Message-ID: <4A504B0C.2060406@FreeBSD.org> Date: Sun, 05 Jul 2009 09:41:16 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> In-Reply-To: <200907050030.n650UkEu028408@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 06:41:32 -0000 Mike Tancsa wrote: > I hooked up a Vantec eSata enclosure using a SATA to eSATA cable off the > main motherboard. One small difference I noticed is that camcontrol > does not get the info from the drive like it does on other devices. > Perhaps thats the enclosure messing things up ? > > 0(ich10)# camcontrol identify ada2 > pass2: < > ATA/ATAPI-0 device That's strange. IDENTIFY is a basic ATA command, which must work always. > There was a previous drive connected. We powered off the external > drive, disconnected the cable, hooked up the new drive, powered up the > enclosure and then I did a camcontrol rescan all > > Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): lost device > Jul 4 20:19:22 ich10 kernel: (ada2:ahcich2:0:0:0): removing device entry > Jul 4 20:19:37 ich10 kernel: (probe0:ahcich2:0:0:0): SIGNATURE: 0000 > Jul 4 20:19:37 ich10 kernel: ada2 at ahcich2 bus 0 target 0 lun 0 > Jul 4 20:19:37 ich10 kernel: ada2: ATA/ATAPI-8 SATA > 1.x device > Jul 4 20:19:37 ich10 kernel: ada2: 150.000MB/s transfers > Jul 4 20:19:37 ich10 kernel: ada2: 715404MB (1465149168 512 byte > sectors: 16H 63S/T 16383C) > Jul 4 20:19:37 ich10 kernel: ada2: Native Command Queueing Enabled Looking to this, it was working. > The drive we connected has some bad sectors, so I wanted to try a secure > wipe as much as possible before RMAing the drive. I also thought it > would be useful to test with the new driver how it handles bad disks > > Is this such an error ? > > Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is 40000001 cs > 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 This is AHCI driver debugging. I've removed it in latest patch. In this case it means that drive signals some command error. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 07:18:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB01F106564A; Sun, 5 Jul 2009 07:18:16 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3E3588FC12; Sun, 5 Jul 2009 07:18:15 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247671153; Sun, 05 Jul 2009 10:18:12 +0300 Message-ID: <4A5053A8.2060902@FreeBSD.org> Date: Sun, 05 Jul 2009 10:18:00 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> In-Reply-To: <4A4FEBBC.30203@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 07:18:17 -0000 Harald Schmalzbauer wrote: > Late, but now I'd like to jump in. It's never late. I have just uploaded fresh patch: http://people.freebsd.org/~mav/cam-ata.20090704.patch > I have a gournaled FS whoch lists it's consumer as ad12p6 You mean gjournal has provider names hardcoded to it's meta data? It could be a problem. If it detects it's parts freely, then it should not notice the change. > Otherwise I only use labels (ufs) for quiet some time, so I thought > testing would be painless... > Can I safely remove glabel from the unmounted fs and relabel the new > device? I don't very understand whet you mean by "safe"? Safe for what? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 07:29:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0832D106564A for ; Sun, 5 Jul 2009 07:29:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 9220A8FC14 for ; Sun, 5 Jul 2009 07:29:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=rYzuquTPueXLEwDh6fUA:9 a=MGnlHCXEQf-HhHHV3ZUA:7 a=J8nZXcrQNjddW4vBWZWwvTFb9OUA:4 a=9aOQ2cSd83gA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 530246821; Sun, 05 Jul 2009 09:29:31 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 5 Jul 2009 09:29:07 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> In-Reply-To: <20090704164341.0acd0271@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907050929.07784.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 07:29:33 -0000 On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote: > Le Sat, 4 Jul 2009 09:45:40 +0200, > > Hans Petter Selasky a =E9crit : > > > ulpt_write_callback:220: state=3D0x1 actlen=3D2889 > > > ulpt_write_callback:220: state=3D0x1 actlen=3D3023 > > > > These two lines are interesting. Are these printed when doing the > > same job? > > Yes. > > > If the actlen is not a factor of 64 in your case, the printer will > > think that the document has ended. Could you verify that, that cups > > is feeding too little data into the ULPT port? > > Sometime cups writes only a litle amount of datas: > > [Job 40] Read 161 bytes of print data... > [Job 40] Wrote 161 bytes of print data... > [Job 40] Read 251 bytes of print data... > [Job 40] Wrote 251 bytes of print data... > [Job 40] Read 162 bytes of print data... > [Job 40] Wrote 162 bytes of print data... > [Job 40] Read 86 bytes of print data... > [Job 40] Wrote 86 bytes of print data... > [Job 40] Read 3292 bytes of print data... > [Job 40] Wrote 3292 bytes of print data... > [Job 40] Read 43 bytes of print data... > [Job 40] Wrote 43 bytes of print data... > [Job 40] Read 4096 bytes of print data... > [Job 40] Wrote 4096 bytes of print data... > > Cups uses a select() on the input file to print, reads the datas and > writes them to the usb port until the input file is empty. > > There is no warranty that the amount of datas will be a factor of 64 > bytes. It is not right to defragment the data in /dev/ulpt either. Maybe I can mak= e a=20 variant device, /dev/udlpt, that will automatically defrag the data. What happens if you dd if=3Dmyjob.pcl.or.ps of=3D/dev/ulpt bs=3D1024 =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 08:17:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B228B1065673; Sun, 5 Jul 2009 08:17:19 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3028FC13; Sun, 5 Jul 2009 08:17:19 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:35339 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MNMuC-0000OC-3k; Sun, 05 Jul 2009 10:17:01 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id D82BA3E0D; Sun, 5 Jul 2009 10:16:56 +0200 (CEST) Message-Id: <31D779DF-EFD0-4255-9177-0F88CA7067CC@exscape.org> From: Thomas Backman To: bug-followup@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 5 Jul 2009 10:16:54 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MNMuC-0000OC-3k. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MNMuC-0000OC-3k 9805ad6bd6ac4f177c89082cb12f064c Cc: FreeBSD current , re@freebsd.org Subject: Re: kern/127441: [dtrace] Dtrace timestamp variable is wrapping as if define as uint32_t X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 08:17:19 -0000 Could we have this patch merged in time for 8.0? I don't know if the problems in the PR followups are big enough, but considering that the current implementation is horribly broken for everyone, and the patch fixes it for a large number of people, I don't really see the downside in merging it for the time being. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 08:39:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89DA61065672 for ; Sun, 5 Jul 2009 08:39:45 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id D52998FC15 for ; Sun, 5 Jul 2009 08:39:44 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=q_pyG5KHjDeSI5tZlpUA:9 a=Hs_6fdvUTFY2Eg46FMaXpuLqehUA:4 a=9aOQ2cSd83gA:10 a=Apmh3L7rKdBIR0ouH8wA:9 a=0GkuctUUkaA5_SiZaQ8A:7 a=bz3TkzYc18S27zjSIMw4rX9E9JIA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1271944512; Sun, 05 Jul 2009 10:39:43 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 5 Jul 2009 10:39:18 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> In-Reply-To: <20090704164341.0acd0271@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_3aGUKFo9aO8ZqtK" Message-Id: <200907051039.19584.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 08:39:45 -0000 --Boundary-00=_3aGUKFo9aO8ZqtK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 July 2009 16:43:41 Patrick Lamaiziere wrote: > Le Sat, 4 Jul 2009 09:45:40 +0200, > > Hans Petter Selasky a =E9crit : > > > ulpt_write_callback:220: state=3D0x1 actlen=3D2889 > > > ulpt_write_callback:220: state=3D0x1 actlen=3D3023 > > > > These two lines are interesting. Are these printed when doing the > > same job? > > Yes. > Can you try the attached patch for 8-current. Please provide ulpt debug pri= nts=20 in either failing or succeeding case. cd /sys/dev/usb cat ulpt.diff | patch Build a new kernel and modules. =2D-HPS --Boundary-00=_3aGUKFo9aO8ZqtK Content-Type: text/x-patch; charset="iso-8859-1"; name="ulpt.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ulpt.diff" diff -u ./serial/ulpt.c ./serial/ulpt.c --- ./serial/ulpt.c 2009-06-24 12:59:19.000000000 +0200 +++ ./serial/ulpt.c 2009-07-05 10:19:31.000000000 +0200 @@ -110,6 +110,7 @@ struct ulpt_softc { struct usb_fifo_sc sc_fifo; struct usb_fifo_sc sc_fifo_noreset; + struct usb_fifo_sc sc_fifo_raw; struct mtx sc_mtx; struct usb_callout sc_watchdog; @@ -147,6 +148,7 @@ static usb_fifo_ioctl_t ulpt_ioctl; static usb_fifo_open_t ulpt_open; static usb_fifo_open_t unlpt_open; +static usb_fifo_open_t urlpt_open; static struct usb_fifo_methods ulpt_fifo_methods = { .f_close = &ulpt_close, @@ -170,6 +172,17 @@ .basename[0] = "unlpt", }; +static struct usb_fifo_methods urlpt_fifo_methods = { + .f_close = &ulpt_close, + .f_ioctl = &ulpt_ioctl, + .f_open = &urlpt_open, + .f_start_read = &ulpt_start_read, + .f_start_write = &ulpt_start_write, + .f_stop_read = &ulpt_stop_read, + .f_stop_write = &ulpt_stop_write, + .basename[0] = "urlpt", +}; + static void ulpt_reset(struct ulpt_softc *sc) { @@ -419,6 +432,28 @@ } static int +urlpt_open(struct usb_fifo *fifo, int fflags) +{ + struct ulpt_softc *sc = usb_fifo_softc(fifo); + + /* we assume that open is a serial process */ + + if (sc->sc_fflags == 0) { + + /* reset USB paralell port */ + + ulpt_reset(sc); + + /* set raw write mode */ + + if (fflags & FWRITE) { + usb_fifo_set_write_defrag(fifo, 0); + } + } + return (unlpt_open(fifo, fflags)); +} + +static int ulpt_open(struct usb_fifo *fifo, int fflags) { struct ulpt_softc *sc = usb_fifo_softc(fifo); @@ -426,7 +461,16 @@ /* we assume that open is a serial process */ if (sc->sc_fflags == 0) { + + /* reset USB paralell port */ + ulpt_reset(sc); + + /* set defrag write mode */ + + if (fflags & FWRITE) { + usb_fifo_set_write_defrag(fifo, 1); + } } return (unlpt_open(fifo, fflags)); } @@ -633,6 +677,13 @@ if (error) { goto detach; } + error = usb_fifo_attach(uaa->device, sc, &sc->sc_mtx, + &urlpt_fifo_methods, &sc->sc_fifo_raw, + unit, 0 - 1, uaa->info.bIfaceIndex, + UID_ROOT, GID_OPERATOR, 0644); + if (error) { + goto detach; + } /* start reading of status */ mtx_lock(&sc->sc_mtx); @@ -654,6 +705,7 @@ usb_fifo_detach(&sc->sc_fifo); usb_fifo_detach(&sc->sc_fifo_noreset); + usb_fifo_detach(&sc->sc_fifo_raw); mtx_lock(&sc->sc_mtx); usb_callout_stop(&sc->sc_watchdog); diff -u ./usb_busdma.c ./usb_busdma.c --- ./usb_busdma.c 2009-06-23 04:19:59.000000000 +0200 +++ ./usb_busdma.c 2009-06-29 13:10:45.000000000 +0200 @@ -359,7 +359,8 @@ if (bus_dma_tag_create ( /* parent */ udt->tag_parent->tag, /* alignment */ align, - /* boundary */ USB_PAGE_SIZE, + /* boundary */ (align == 1) ? + USB_PAGE_SIZE : 0, /* lowaddr */ (2ULL << (udt->tag_parent->dma_bits - 1)) - 1, /* highaddr */ BUS_SPACE_MAXADDR, /* filter */ NULL, diff -u ./usb_dev.c ./usb_dev.c --- ./usb_dev.c 2009-06-24 12:59:19.000000000 +0200 +++ ./usb_dev.c 2009-07-05 10:05:59.000000000 +0200 @@ -740,6 +740,8 @@ break; } } + /* reset have fragment flag */ + f->flag_have_fragment = 0; } /*------------------------------------------------------------------------* @@ -783,6 +785,16 @@ /* set flushing flag */ f->flag_flushing = 1; + /* get the last packet in */ + if (f->flag_have_fragment) { + struct usb_mbuf *m; + f->flag_have_fragment = 0; + USB_IF_DEQUEUE(&f->free_q, m); + if (m) { + USB_IF_ENQUEUE(&f->used_q, m); + } + } + /* start write transfer, if not already started */ (f->methods->f_start_write) (f); @@ -1303,6 +1315,7 @@ struct usb_cdev_privdata* cpd; struct usb_fifo *f; struct usb_mbuf *m; + uint8_t *pdata; int fflags; int resid; int io_len; @@ -1373,33 +1386,59 @@ } tr_data = 1; - USB_MBUF_RESET(m); - - io_len = MIN(m->cur_data_len, uio->uio_resid); - - m->cur_data_len = io_len; + if (f->flag_have_fragment == 0) { + USB_MBUF_RESET(m); + io_len = m->cur_data_len; + pdata = m->cur_data_ptr; + if (io_len > uio->uio_resid) + io_len = uio->uio_resid; + m->cur_data_len = io_len; + } else { + io_len = m->max_data_len - m->cur_data_len; + pdata = m->cur_data_ptr + io_len; + if (io_len > uio->uio_resid) + io_len = uio->uio_resid; + m->cur_data_len += io_len; + } DPRINTFN(2, "transfer %d bytes to %p\n", - io_len, m->cur_data_ptr); + io_len, pdata); - err = usb_fifo_uiomove(f, - m->cur_data_ptr, io_len, uio); + err = usb_fifo_uiomove(f, pdata, io_len, uio); if (err) { + f->flag_have_fragment = 0; USB_IF_ENQUEUE(&f->free_q, m); break; } - if (f->methods->f_filter_write) { + + /* check if the buffer is ready to be transmitted */ + + if ((f->flag_write_defrag == 0) || + (m->cur_data_len == m->max_data_len)) { + f->flag_have_fragment = 0; + /* - * Sometimes it is convenient to process data at the - * expense of a userland process instead of a kernel - * process. + * Check for write filter: + * + * Sometimes it is convenient to process data + * at the expense of a userland process + * instead of a kernel process. */ - (f->methods->f_filter_write) (f, m); - } - USB_IF_ENQUEUE(&f->used_q, m); + if (f->methods->f_filter_write) { + (f->methods->f_filter_write) (f, m); + } - (f->methods->f_start_write) (f); + /* Put USB mbuf in the used queue */ + USB_IF_ENQUEUE(&f->used_q, m); + + /* Start writing data, if not already started */ + (f->methods->f_start_write) (f); + } else { + /* Wait for more data or close */ + f->flag_have_fragment = 1; + USB_IF_PREPEND(&f->free_q, m); + } } while (uio->uio_resid > 0); done: @@ -2220,6 +2259,18 @@ f->flag_short = onoff; } +void +usb_fifo_set_write_defrag(struct usb_fifo *f, uint8_t onoff) +{ + if (f == NULL) + return; + + /* defrag written data */ + f->flag_write_defrag = onoff; + /* reset defrag state */ + f->flag_have_fragment = 0; +} + void * usb_fifo_softc(struct usb_fifo *f) { diff -u ./usb_dev.h ./usb_dev.h --- ./usb_dev.h 2009-06-24 12:59:19.000000000 +0200 +++ ./usb_dev.h 2009-07-05 10:36:50.000000000 +0200 @@ -130,6 +130,8 @@ uint8_t flag_short; /* set if short_ok or force_short * transfer flags should be set */ uint8_t flag_stall; /* set if clear stall should be run */ + uint8_t flag_write_defrag; /* set to defrag written data */ + uint8_t flag_have_fragment; /* set if defragging */ uint8_t iface_index; /* set to the interface we belong to */ uint8_t fifo_index; /* set to the FIFO index in "struct * usb_device" */ @@ -144,11 +146,9 @@ int usb_fifo_wait(struct usb_fifo *fifo); void usb_fifo_signal(struct usb_fifo *fifo); uint8_t usb_fifo_opened(struct usb_fifo *fifo); -void usb_fifo_free(struct usb_fifo *f); struct usb_symlink *usb_alloc_symlink(const char *target); void usb_free_symlink(struct usb_symlink *ps); int usb_read_symlink(uint8_t *user_ptr, uint32_t startentry, uint32_t user_len); -void usb_fifo_set_close_zlp(struct usb_fifo *, uint8_t); #endif /* _USB_DEV_H_ */ diff -u ./usbdi.h ./usbdi.h --- ./usbdi.h 2009-06-28 08:48:04.000000000 +0200 +++ ./usbdi.h 2009-07-05 10:36:50.000000000 +0200 @@ -531,5 +531,8 @@ void usb_fifo_wakeup(struct usb_fifo *f); void usb_fifo_get_data_error(struct usb_fifo *fifo); void *usb_fifo_softc(struct usb_fifo *fifo); +void usb_fifo_set_close_zlp(struct usb_fifo *, uint8_t); +void usb_fifo_set_write_defrag(struct usb_fifo *, uint8_t); +void usb_fifo_free(struct usb_fifo *f); #endif /* _KERNEL */ #endif /* _USB_USBDI_H_ */ --Boundary-00=_3aGUKFo9aO8ZqtK-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 10:07:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE8D106564A for ; Sun, 5 Jul 2009 10:07:24 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id EBD018FC08 for ; Sun, 5 Jul 2009 10:07:23 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.145.103.163] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MNOcy-0006Hv-5i for current@freebsd.org; Sun, 05 Jul 2009 12:07:20 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNOcw-0001uh-K3 for current@freebsd.org; Sun, 05 Jul 2009 12:07:18 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Sun, 05 Jul 2009 12:07:18 +0200 Message-Id: Cc: Subject: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 10:07:25 -0000 Hi Due to not paying attention my ntp.conf on several of my time servers was updated (and broken) by mergemaster. I had the automatic update options set for files that I had not modified. My ntp.conf had no VCS id and the files differed, obviously. Was mergemaster correct in its assesment that this file was a candidate for automatic installation? -U Attempt to auto upgrade files that have not been user modified Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 10:47:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E7BE106566C; Sun, 5 Jul 2009 10:47:05 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 231ED8FC08; Sun, 5 Jul 2009 10:47:04 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 48C4678D6A; Sun, 5 Jul 2009 14:47:03 +0400 (MSD) Message-ID: <4A5084A9.8060607@haruhiism.net> Date: Sun, 05 Jul 2009 14:47:05 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lawrence Stewart References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4E77EA.7030803@freebsd.org> In-Reply-To: <4A4E77EA.7030803@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: silby@freebsd.org, freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 10:47:06 -0000 Lawrence Stewart wrote: > The SACK code puts a global cap on the amount of memory that can be > used for SACK accounting. The variable V_tcp_sack_globalholes tracks > how many SACK holes are currently allocated across all active TCP > connections. It gets incremented in tcp_sackhole_alloc() and > decremented in tcp_sackhole_free() in netinet/tcp_sack.c. > It turns out that there is currently no lock synchronising access to > the variable, and the incrementing/decrementing is not being done > atomically. In Kamigishi's case, the server had a traffic profile > consisting of a large number of clients simultaneously connecting over > cruddy links which was giving the SACK accounting a real workout. The > inevitable race would strike one or more times, leaving the count of > holes not in tune with reality, and eventually when traffic died down > the variable would decrement down below 0, triggering the panic. Note > that this panic only occurs if INVARIANTS is compiled into the kernel > so the issue has been around for some time but not noticed. > The attached patch makes use of the atomic(9) KPI to ensure > incrementing/decrementing the variable is done atomically, which > should fix the bug. > Reviews/testing would be good so that we can get this into 8.0. After applying the patch and rebuilding the kernel I've been getting (similar) kernel panics way too often. Two backtraces follow (note the uptime; it can vary from 4 minutes to 5-7 hours, but average time between traps is approximately 2 hours): Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1321288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058ac15 stack pointer = 0x28:0xffffff80403d45f0 frame pointer = 0x28:0xffffff80403d4620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 2350 (mysqld) trap number = 12 panic: page fault cpuid = 0 Uptime: 3h28m59s (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80599a63 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff80599ebc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff80861f8d in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff80862c25 in trap (frame=0xffffff80403d4540) at /usr/src/sys/amd64/amd64/trap.c:345 #5 0xffffffff80848f13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff8058ac15 in _mtx_lock_sleep (m=0xffffffff80e98863, tid=18446742975233083168, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #7 0xffffffff8058ad6e in _mtx_lock_flags (m=Variable "m" is not available. ) at /usr/src/sys/kern/kern_mutex.c:203 #8 0xffffffff80647125 in netisr_queue_internal (proto=1, m=0xffffff0004ed1e00, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:830 #9 0xffffffff80647209 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:860 #10 0xffffffff80643180 in if_simloop (ifp=0xffffff0004609800, m=0xffffff0004ed1e00, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #11 0xffffffff806432d6 in looutput (ifp=0xffffff0004609800, m=0xffffff0004ed1e00, dst=0xffffff80403d47a0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:296 #12 0xffffffff806a2237 in ip_output (m=0xffffff0004ed1e00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:624 #13 0xffffffff80707874 in tcp_output (tp=0xffffff00137292d8) at /usr/src/sys/netinet/tcp_output.c:1188 #14 0xffffffff80713f29 in tcp_usr_send (so=0xffffff002bc32550, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:269 #15 0xffffffff805fd197 in sosend_generic (so=0xffffff002bc32550, addr=0x0, uio=0xffffff80403d4b10, top=0xffffff0004efeb00, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1257 #16 0xffffffff805e18a7 in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #17 0xffffffff805dad25 in dofilewrite (td=0xffffff003db34720, fd=30, fp=0xffffff0013d35a50, auio=0xffffff80403d4b10, offset=Variable "offset" is not available. ) at file.h:239 #18 0xffffffff805dc300 in kern_writev (td=0xffffff003db34720, fd=30, auio=0xffffff80403d4b10) at /usr/src/sys/kern/sys_generic.c:445 #19 0xffffffff805dc405 in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:361 #20 0xffffffff808624cf in syscall (frame=0xffffff80403d4c90) at /usr/src/sys/amd64/amd64/trap.c:984 #21 0xffffffff808491a0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #22 0x00000008014d8efc in ?? () Previous frame inner to this frame (corrupt stack?) Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1321288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058ac15 stack pointer = 0x28:0xffffff8040145600 frame pointer = 0x28:0xffffff8040145630 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1932 (lighttpd) trap number = 12 panic: page fault cpuid = 1 Uptime: 1h0m9s (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80599a63 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff80599ebc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff80861f8d in trap_fatal (frame=0xc, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff80862c25 in trap (frame=0xffffff8040145550) at /usr/src/sys/amd64/amd64/trap.c:345 #5 0xffffffff80848f13 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff8058ac15 in _mtx_lock_sleep (m=0xffffffff80e98863, tid=18446742974276744992, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #7 0xffffffff8058ad6e in _mtx_lock_flags (m=Variable "m" is not available. ) at /usr/src/sys/kern/kern_mutex.c:203 #8 0xffffffff80647125 in netisr_queue_internal (proto=1, m=0xffffff002453d400, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:830 #9 0xffffffff80647209 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:860 #10 0xffffffff80643180 in if_simloop (ifp=0xffffff0004609800, m=0xffffff002453d400, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #11 0xffffffff806432d6 in looutput (ifp=0xffffff0004609800, m=0xffffff002453d400, dst=0xffffff80401457b0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:296 #12 0xffffffff806a2237 in ip_output (m=0xffffff002453d400, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:624 #13 0xffffffff80707874 in tcp_output (tp=0xffffff0014bb5b60) at /usr/src/sys/netinet/tcp_output.c:1188 #14 0xffffffff80713f29 in tcp_usr_send (so=0xffffff00047fb2a8, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:269 #15 0xffffffff805fd197 in sosend_generic (so=0xffffff00047fb2a8, addr=0x0, uio=0xffffff000f4d4100, top=0xffffff00236c5d00, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1257 #16 0xffffffff805e18a7 in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #17 0xffffffff805dad25 in dofilewrite (td=0xffffff0004b2b720, fd=10, fp=0xffffff0070f18a50, auio=0xffffff000f4d4100, offset=Variable "offset" is not available. ) at file.h:239 #18 0xffffffff805dc300 in kern_writev (td=0xffffff0004b2b720, fd=10, auio=0xffffff000f4d4100) at /usr/src/sys/kern/sys_generic.c:445 #19 0xffffffff805dc381 in writev (td=0xffffff0004b2b720, uap=0xffffff8040145c00) at /usr/src/sys/kern/sys_generic.c:431 #20 0xffffffff808624cf in syscall (frame=0xffffff8040145c90) at /usr/src/sys/amd64/amd64/trap.c:984 #21 0xffffffff808491a0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #22 0x0000000800c5aacc in ?? () Previous frame inner to this frame (corrupt stack?) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 11:05:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63EF4106567F for ; Sun, 5 Jul 2009 11:05:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mail.bsdforen.de (bsdforen.de [212.204.60.79]) by mx1.freebsd.org (Postfix) with ESMTP id 238918FC15 for ; Sun, 5 Jul 2009 11:05:04 +0000 (UTC) (envelope-from kamikaze@bsdforen.de) Received: from mobileKamikaze.norad (unknown [88.130.194.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bsdforen.de (Postfix) with ESMTP id 7E1AA8A0357; Sun, 5 Jul 2009 12:44:55 +0200 (CEST) Message-ID: <4A508426.3010100@bsdforen.de> Date: Sun, 05 Jul 2009 12:44:54 +0200 From: Dominic Fandrey User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: jos@catnook.com References: <20090703221810.GA31128@lizzy.catnook.local> In-Reply-To: <20090703221810.GA31128@lizzy.catnook.local> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Selection using mouse aborts unexpectedly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 11:05:04 -0000 Jos Backus wrote: > Hi, > > For a few weeks now, when I drag my mouse over some text with the left button > pressed down, the selection will reproducibly abort after a second or so and > start re-selecting even though I never let go of the mouse button. This used > to work fine and is very annoying, to say the least. Sounds like your mouse button is worn out. Did you verify this with a different mouse? From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 11:29:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0223106564A; Sun, 5 Jul 2009 11:29:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 835D78FC1B; Sun, 5 Jul 2009 11:29:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n65BQhie032549; Sun, 5 Jul 2009 07:26:43 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907051126.n65BQhie032549@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 05 Jul 2009 07:29:05 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A504B0C.2060406@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 11:29:15 -0000 At 02:41 AM 7/5/2009, Alexander Motin wrote: >>The drive we connected has some bad sectors, so I wanted to try a >>secure wipe as much as possible before RMAing the drive. I also >>thought it would be useful to test with the new driver how it handles bad disks >>Is this such an error ? >>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is >>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 > >This is AHCI driver debugging. I've removed it in latest patch. In >this case it means that drive signals some command error. Actually, looks like the box panic'd, but it seems to be elsewhere. After hitting the bad sectors for some time, g_vfs_done():ada2[WRITE(offset=6193152, length=14336)]error = 5 ahcich2: Timeout on slot 17 ahcich2: Timeout on slot 5 ahcich2: Timeout on slot 25 ahcich2: Timeout on slot 13 ahcich2: Timeout on slot 1 g_vfs_done():ada2[WRITE(offset=65536, length=2048)]error = 5 ahcich2: Timeout on slot 21 ahcich2: Timeout on slot 8 ahcich2: Timeout on slot 27 ahcich2: Timeout on slot 14 ahcich2: Timeout on slot 1 g_vfs_done():ada2[WRITE(offset=98304, length=16384)]error = 5 panic: softdep_move_dependencies: need merge code cpuid = 0 Uptime: 2h25m8s (ada2:ahcich2:0:0:0): Synchronize cache failed Physical memory: 3560 MB Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc0812787 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc0812a79 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc0a354d4 in softdep_move_dependencies (oldbp=0xdaede7f0, newbp=0xdaec2c50) at /usr/src/sys/ufs/ffs/ffs_softdep.c:991 #4 0xc0a3d48e in ffs_backgroundwritedone (bp=0xdaede7f0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1756 #5 0xc08854d7 in bufdone (bp=0xdaede7f0) at /usr/src/sys/kern/vfs_bio.c:3254 #6 0xc07b3765 in g_vfs_done (bip=0xc7d68c94) at /usr/src/sys/geom/geom_vfs.c:97 #7 0xc087faa9 in biodone (bp=0xc7d68c94) at /usr/src/sys/kern/vfs_bio.c:3095 #8 0xc07b0c0f in g_io_schedule_up (tp=0xc6e8f240) at /usr/src/sys/geom/geom_io.c:669 #9 0xc07b0fc8 in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #10 0xc07e8421 in fork_exit (callout=0xc07b0f60 , arg=0x0, frame=0xc6937d38) at /usr/src/sys/kern/kern_fork.c:842 #11 0xc0b180a0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 09:15:03 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 222F7106564A for ; Sun, 5 Jul 2009 09:15:03 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id AB3DF8FC0A for ; Sun, 5 Jul 2009 09:15:02 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: by fxm18 with SMTP id 18so2706311fxm.43 for ; Sun, 05 Jul 2009 02:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=kQ0LbLccaqs/7akl+qOqXAa0ZtwsNuI1OjZJoUSNjvg=; b=uuRFcmCOxmA+ro1jvNC2/5qqJOgBizxQMFhpVgm23xfvyfAX7rdDitBys+Uneh+024 hG5s7FUd0A/WDGjOEFYdq7A9WEOWldCFCuWD08olotWQR6C7VU4dGl/xMYd4SuV9RLfg h4z9NBU0y7FCQTlfH8gsiAy6dlYHUgYUaTrqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=NeAkKT8R+9t/qK9ReX7gWcp8jtnnB2BAKyjIHQ12lDRNWADVvMe+ZaWHXk1xqoIKKV 44RT7AouSw8ojMcYDpgQPlDNaUT7zw0tMgsO9h6IxLuIibrQfTanW9QuynJ05F4QPD7B Pc3Rt31Z/S+iQsqofJKuVYRWe3yaqmIDgS2CM= MIME-Version: 1.0 Received: by 10.239.137.84 with SMTP id k20mr262668hbk.21.1246783712798; Sun, 05 Jul 2009 01:48:32 -0700 (PDT) Date: Sun, 5 Jul 2009 08:48:32 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 05 Jul 2009 12:29:54 +0000 Cc: Subject: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 09:15:03 -0000 Alexander Motin wrote: >Harald Schmalzbauer wrote: >> I have a gournaled FS whoch lists it's consumer as ad12p6 >You mean gjournal has provider names hardcoded to it's meta data? It >could be a problem. If it detects it's parts freely, then it should not >notice the change. I just changed provider names for a gjournal'ed disk when my disks were reordered, and with the proper corresponding changes to fstab, there were no problems -- everything was mounted and loaded upon reboot without me having to make any other changes. However, if you used the "-h" option with "gjournal label" you may have to manually relabel. >> Otherwise I only use labels (ufs) for quiet some time, so I thought >> testing would be painless... >> Can I safely remove glabel from the unmounted fs and relabel the new >> device? >I don't very understand whet you mean by "safe"? Safe for what? He means, can he relabel the disks without losing any data on them? I think that the answer is yes, provided he doesn't do anything foolish -- like relabel an existing file system with journal and data on the same provider, while increasing the size of the journal, which would cause all data on the space allocated to the new journal to be lost. He may have to use the "-f" flag with "gjournal label", or issue "gjournal clear" before relabeling, and he may lose the last sector of the file system and anything on the journal, but that usually isn't of any consequence. In any event, unless he hardcoded his provider names, this probably isn't necessary. If it does prove to be necessary, it would be wise to back up any data just to be safe, and to experiment on a test provider first, before trying to relabel. b. From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 14:29:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5366E1065672; Sun, 5 Jul 2009 14:29:18 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by mx1.freebsd.org (Postfix) with ESMTP id E56488FC12; Sun, 5 Jul 2009 14:29:17 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by pzk31 with SMTP id 31so1658243pzk.3 for ; Sun, 05 Jul 2009 07:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=6aH2MAGquB2i66jKpZIpFGuv/u7CaYFBXs6fQy7WK5U=; b=nIDfrNQ0PnoRDQ9EAsF2LGD7zC3DkHI7BnyWX2B0nDemp/ZxoDwBfd4dK0tDNpC9Kq 9aNbCLZQVaRuTGrRb6SG03WsGCDFjpN6ncyWlD3WTqkTSTlEU2JXBI1NHIRgWJNJjmp4 A5nr575F7jl/XQMwS1gnJsqFaRZ8TFn5JrrSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jDzNPBSNbDDRUdVnUcHuACcpGUqyl9IJglqieniM+zA9ljUPLqbD0+KOd8uf5Mrw7u BytQ9xIKY5FN2TXJYaOF0y4GNEvhruqOvsVllceJwbZiBihhroanianfkxrL4hTuJbXS O+xf3uUppOsaB4UXcU/PUlZDqAPY+8NBidjSs= MIME-Version: 1.0 Received: by 10.142.164.10 with SMTP id m10mr1042706wfe.140.1246804157660; Sun, 05 Jul 2009 07:29:17 -0700 (PDT) In-Reply-To: <4A5053A8.2060902@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> Date: Sun, 5 Jul 2009 16:29:17 +0200 Message-ID: <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> From: Lucius Windschuh To: Alexander Motin , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 14:29:18 -0000 Hi Alexander. 2009/7/5 Alexander Motin : > It's never late. I have just uploaded fresh patch: > http://people.freebsd.org/~mav/cam-ata.20090704.patch "make buildworld" with this patch stops in my configuration with: (cd /usr/src/rescue/rescue/../../usr.sbin/chown && /usr/obj/usr/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ depend && /usr/obj/usr/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o) `chown.o' is up to date. cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo sconfig.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lm /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In function `ata_max_mode': : undefined reference to `min' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Simply adding #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif in ata_all.c helps, obviously. Regards, Lucius From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 15:14:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D60E1065679 for ; Sun, 5 Jul 2009 15:14:03 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 034BA8FC16 for ; Sun, 5 Jul 2009 15:14:02 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247687764; Sun, 05 Jul 2009 18:13:59 +0300 Message-ID: <4A50C331.3040505@FreeBSD.org> Date: Sun, 05 Jul 2009 18:13:53 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Lucius Windschuh References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> In-Reply-To: <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 15:14:03 -0000 Lucius Windschuh wrote: > Hi Alexander. > > 2009/7/5 Alexander Motin : >> It's never late. I have just uploaded fresh patch: >> http://people.freebsd.org/~mav/cam-ata.20090704.patch > > "make buildworld" with this patch stops in my configuration with: > > /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In > function `ata_max_mode': > : undefined reference to `min' > > Simply adding > #ifndef min > #define min(a,b) (((a)<(b))?(a):(b)) > #endif > in ata_all.c helps, obviously. Thanks. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 16:24:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC40B1065680; Sun, 5 Jul 2009 16:24:54 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id AEC278FC08; Sun, 5 Jul 2009 16:24:54 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n65GMNWh034062; Sun, 5 Jul 2009 12:22:23 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907051622.n65GMNWh034062@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 05 Jul 2009 12:24:45 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <7.1.0.9.0.20090705072517.1b1f2338@sentex.net> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <7.1.0.9.0.20090705072517.1b1f2338@sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 16:24:55 -0000 At 07:29 AM 7/5/2009, Mike Tancsa wrote: >At 02:41 AM 7/5/2009, Alexander Motin wrote: > >>>The drive we connected has some bad sectors, so I wanted to try a >>>secure wipe as much as possible before RMAing the drive. I also >>>thought it would be useful to test with the new driver how it handles bad disks >>>Is this such an error ? >>>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is >>>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 >> >>This is AHCI driver debugging. I've removed it in latest patch. In >>this case it means that drive signals some command error. > > >Actually, looks like the box panic'd, but it seems to be >elsewhere. After hitting the bad sectors for some time, Here is another with invariants compiled in. Again, this is writing to a disk that has bad sectors and is failing, so not sure if this is a case of "dont do that" ---Mike Synchronize cache failed Physical memory: 3556 MB Dumping 223 MB:ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00010000 rs 00010000 tfd 441 serr 00000000 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xb68dc371 fault code = supervisor read, page not present ahcich2: Error while READ LOG EXT ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00000400 rs 00000400 tfd 441 serr 00000000 ahcich2: ahci_ch_intr ERROR is 40000001 cs 00000800 ss 00000000 rs 00000800 tfd 471 serr 00000000 ahcich2: Error while READ LOG EXT ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00001000 rs 00001000 tfd 441 serr 00000000 ahcich2: ahci_ch_intr ERROR is 40000001 cs 00002000 ss 00000000 rs 00002000 tfd 471 serr 00000000 ahcich2: Error while READ LOG EXT ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00004000 rs 00004000 tfd 441 serr 00000000 panic: initiate_write_inodeblock_ufs2: already started cpuid = 6 Uptime: 1h13m8s ahcich2: ahci_ch_intr ERROR is 40000001 cs 00008000 ss 00000000 rs 00008000 tfd 471 serr 00000000 ahcich2: Error while READ LOG EXT (ada2:g_vfs_done():ahcich2:0:ada2[READ(offset=56068767744, length=16384)]0:error = 50): Synchronize cache failed Physical memory: 3556 MB Dumping 223 MB:ahcich2: ahci_ch_intr ERROR is 40000008 cs 00000000 ss 00010000 rs 00010000 tfd 441 serr 00000000 Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xb68dc371 fault code = supervisor read, page not present instruction pointer = 0x20:0xc047f02b stack pointer = 0x28:0xc6e69bf0 frame pointer = 0x28:0xc6e69c08 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 = 12 (irq257: ahci0) trap number = 12 208 192 176 160 144 128 112 96 80 64 48 32 16 Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from /boot/kernel/ichwd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ichwd.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc086c59e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc086c839 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc0a87a1e in softdep_disk_io_initiation (bp=0xdb115fe0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4056 #4 0xc0a8b98c in ffs_geom_strategy (bo=0xc810fc2c, bp=0xdb115fe0) at buf.h:404 #5 0xc08e1b79 in bufwrite (bp=0xdb115fe0) at buf.h:397 #6 0xc0a8b0bb in ffs_bufwrite (bp=0xdb115fe0) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1893 #7 0xc08ded28 in vfs_bio_awrite (bp=0xdb115fe0) at buf.h:385 #8 0xc08e851b in vop_stdfsync (ap=0xe77a8c7c) at /usr/src/sys/kern/vfs_default.c:608 #9 0xc07f31cc in devfs_fsync (ap=0xe77a8c7c) at /usr/src/sys/fs/devfs/devfs_vnops.c:556 #10 0xc0b8fb95 in VOP_FSYNC_APV (vop=0xc0d1a020, a=0xe77a8c7c) at vnode_if.c:1267 #11 0xc08f8308 in sync_vnode (slp=0xc76a27e4, bo=0xe77a8ce8, td=0xc78ad6c0) at vnode_if.h:549 #12 0xc08f8653 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 #13 0xc0843f78 in fork_exit (callout=0xc08f83e0 , arg=0x0, frame=0xe77a8d38) at /usr/src/sys/kern/kern_fork.c:842 #14 0xc0b677b0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 17:02:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C9E9106564A for ; Sun, 5 Jul 2009 17:02:03 +0000 (UTC) (envelope-from jos@catnook.com) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by mx1.freebsd.org (Postfix) with ESMTP id 372208FC1B for ; Sun, 5 Jul 2009 17:02:02 +0000 (UTC) (envelope-from jos@catnook.com) Received: from lizzy.dyndns.org (209-204-188-132.dsl.static.sonic.net [209.204.188.132]) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id n65H21Oj002524 for ; Sun, 5 Jul 2009 10:02:02 -0700 Received: (qmail 28063 invoked by uid 1000); 5 Jul 2009 17:02:25 -0000 Date: Sun, 5 Jul 2009 10:02:25 -0700 From: Jos Backus To: Dominic Fandrey Message-ID: <20090705170225.GA24253@lizzy.catnook.local> References: <20090703221810.GA31128@lizzy.catnook.local> <4A508426.3010100@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A508426.3010100@bsdforen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: Selection using mouse aborts unexpectedly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 17:02:03 -0000 On Sun, Jul 05, 2009 at 12:44:54PM +0200, Dominic Fandrey wrote: > Sounds like your mouse button is worn out. Did you verify this with a different > mouse? No, but I don't think I need to because selection works okay in an xterm. I.e. when I click-drag the left mouse button inside an xterm the selection stays active just fine as long as I hold down the mouse button. But when I go to some webpage inside Opera and try to select text, the selection aborts and starts reselecting right away. Same on the console. I could swear this used to work before. -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 20:24:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DC57106564A for ; Sun, 5 Jul 2009 20:24:45 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id F12AB8FC12 for ; Sun, 5 Jul 2009 20:24:44 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 5 Jul 2009 21:24:43 +0100 (BST) Date: Sun, 5 Jul 2009 21:24:41 +0100 From: David Malone To: Kevin Oberman Message-ID: <20090705202441.GA4644@walton.maths.tcd.ie> References: <4A4E6EB4.9000000@phat.za.net> <20090704232317.2D0991CC09@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090704232317.2D0991CC09@ptavv.es.net> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: Aragon Gouveia , Anton Shterenlikht , freebsd-current@freebsd.org Subject: Re: nice work on ntp.conf! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 20:24:45 -0000 On Sat, Jul 04, 2009 at 04:23:17PM -0700, Kevin Oberman wrote: > Really nice, although I feel uncomfortable about the use of LOCAL. It is > a great opportunity for foot shooting and, since most systems running > NTP are not used as serves, I think that it should be left commented > out in the default case. We're currently talking about this on -net. We'll probably also change the way we're using the pool, as the current file breaks the pool's advice to vendors. David. From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 20:27:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3F3106564A; Sun, 5 Jul 2009 20:27:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6DE8FC1C; Sun, 5 Jul 2009 20:27:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n65KRKfx071925; Sun, 5 Jul 2009 16:27:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n65KRKoE063483; Sun, 5 Jul 2009 16:27:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 963057302F; Sun, 5 Jul 2009 16:27:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090705202720.963057302F@freebsd-current.sentex.ca> Date: Sun, 5 Jul 2009 16:27:20 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 20:27:24 -0000 TB --- 2009-07-05 18:43:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-05 18:43:25 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-07-05 18:43:25 - cleaning the object tree TB --- 2009-07-05 18:43:57 - cvsupping the source tree TB --- 2009-07-05 18:43:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-07-05 18:44:05 - building world TB --- 2009-07-05 18:44:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 18:44:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 18:44:05 - TARGET=powerpc TB --- 2009-07-05 18:44:05 - TARGET_ARCH=powerpc TB --- 2009-07-05 18:44:05 - TZ=UTC TB --- 2009-07-05 18:44:05 - __MAKE_CONF=/dev/null TB --- 2009-07-05 18:44:05 - cd /src TB --- 2009-07-05 18:44:05 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 5 18:44:09 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 5 20:10:29 UTC 2009 TB --- 2009-07-05 20:10:29 - generating LINT kernel config TB --- 2009-07-05 20:10:29 - cd /src/sys/powerpc/conf TB --- 2009-07-05 20:10:29 - /usr/bin/make -B LINT TB --- 2009-07-05 20:10:30 - building LINT kernel TB --- 2009-07-05 20:10:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 20:10:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 20:10:30 - TARGET=powerpc TB --- 2009-07-05 20:10:30 - TARGET_ARCH=powerpc TB --- 2009-07-05 20:10:30 - TZ=UTC TB --- 2009-07-05 20:10:30 - __MAKE_CONF=/dev/null TB --- 2009-07-05 20:10:30 - cd /src TB --- 2009-07-05 20:10:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 5 20:10:30 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ieee80211_node.o(.text+0x38f0): In function `ieee80211_node_attach': : undefined reference to `ieee80211_ageq_init' ieee80211_node.o(.text+0x3bf4): In function `node_cleanup': : undefined reference to `ieee80211_ageq_drain_node' ieee80211_wds.o(.text+0x138): In function `ieee80211_dwds_discover': : undefined reference to `ieee80211_ageq_append' ieee80211_wds.o(.text+0x8a4): In function `wds_newstate': : undefined reference to `ieee80211_ageq_remove' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-05 20:27:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-05 20:27:20 - ERROR: failed to build lint kernel TB --- 2009-07-05 20:27:20 - 4969.61 user 438.16 system 6234.77 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 20:39:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6766B10656D7; Sun, 5 Jul 2009 20:39:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 26D5B8FC14; Sun, 5 Jul 2009 20:39:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n65KdXUQ028215; Sun, 5 Jul 2009 16:39:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n65KdXLc069367; Sun, 5 Jul 2009 16:39:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D62DB7302F; Sun, 5 Jul 2009 16:39:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090705203932.D62DB7302F@freebsd-current.sentex.ca> Date: Sun, 5 Jul 2009 16:39:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 20:39:37 -0000 TB --- 2009-07-05 18:59:07 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-05 18:59:07 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-07-05 18:59:07 - cleaning the object tree TB --- 2009-07-05 18:59:50 - cvsupping the source tree TB --- 2009-07-05 18:59:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-07-05 18:59:58 - building world TB --- 2009-07-05 18:59:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 18:59:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 18:59:58 - TARGET=sparc64 TB --- 2009-07-05 18:59:58 - TARGET_ARCH=sparc64 TB --- 2009-07-05 18:59:58 - TZ=UTC TB --- 2009-07-05 18:59:58 - __MAKE_CONF=/dev/null TB --- 2009-07-05 18:59:58 - cd /src TB --- 2009-07-05 18:59:58 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 5 18:59:59 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 5 20:22:15 UTC 2009 TB --- 2009-07-05 20:22:15 - generating LINT kernel config TB --- 2009-07-05 20:22:15 - cd /src/sys/sparc64/conf TB --- 2009-07-05 20:22:15 - /usr/bin/make -B LINT TB --- 2009-07-05 20:22:15 - building LINT kernel TB --- 2009-07-05 20:22:15 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 20:22:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 20:22:15 - TARGET=sparc64 TB --- 2009-07-05 20:22:15 - TARGET_ARCH=sparc64 TB --- 2009-07-05 20:22:15 - TZ=UTC TB --- 2009-07-05 20:22:15 - __MAKE_CONF=/dev/null TB --- 2009-07-05 20:22:15 - cd /src TB --- 2009-07-05 20:22:15 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 5 20:22:16 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ieee80211_node.o(.text+0x3db8): In function `ieee80211_node_attach': : undefined reference to `ieee80211_ageq_init' ieee80211_node.o(.text+0x4214): In function `node_cleanup': : undefined reference to `ieee80211_ageq_drain_node' ieee80211_wds.o(.text+0x16c): In function `ieee80211_dwds_discover': : undefined reference to `ieee80211_ageq_append' ieee80211_wds.o(.text+0x8a8): In function `wds_newstate': : undefined reference to `ieee80211_ageq_remove' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-05 20:39:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-05 20:39:32 - ERROR: failed to build lint kernel TB --- 2009-07-05 20:39:32 - 4755.13 user 434.60 system 6024.88 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 21:30:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77B8C1065670; Sun, 5 Jul 2009 21:30:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.tele2.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id ACD7D8FC1A; Sun, 5 Jul 2009 21:30:35 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=eJ57vKNmtyAA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=kctU5lBUWTds1dXsgIkA:9 a=IDspSqL6dOovD2ZrJlIA:7 a=zm9i5RoucayZCjo48cATZLmc46QA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 527435834; Sun, 05 Jul 2009 23:30:30 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Date: Sun, 5 Jul 2009 23:30:06 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <9072a4470907051118o6c14e19cs670981a500fc6375@mail.gmail.com> In-Reply-To: <9072a4470907051118o6c14e19cs670981a500fc6375@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907052330.07792.hselasky@c2i.net> Cc: Robert Jameson Subject: Re: FreeBSD Kernel Panic during backup to USB external drive. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 21:30:36 -0000 On Sunday 05 July 2009 20:18:24 Robert Jameson wrote: > Hello everyone, recently i've been experience kernel panics whenever > attempting to run my backup to my usb external drive. > Here is the information i have, whatever else is needed please reply, thank > you. Hi, This issue doesn't look directly related to USB. I'm forwarding it to the freebsd-current e-mail list! Thanks for testing FreeBSD 8-current. --HPS > > > (02:11 PM):(root@cube)/var/crash$ kgdb /boot/kernel/kernel > /var/crash/vmcore.1 > 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: ffs_clusteralloc: map mismatch > cpuid = 1 > Uptime: 4d10h42m10s > Physical memory: 2546 MB > Dumping 249 MB: 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 > > 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/pflog.ko...Reading symbols from > /boot/kernel/pflog.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/pflog.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 > #0 doadump () at pcpu.h:196 > 196 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) quit > > > my backup script: > > #!/usr/local/bin/bash -x > # > # creates backups of essential files > # > DATA="/usr/home /root" > CONFIG="/etc /usr/local/etc /var/lib /etc/namedb" > LIST="/tmp/backlist_$$.txt" > # > mount /backup > set $(date) > # > if test "$1" = "Sun" ; then > # weekly a full backup of all data and config. settings: > # > tar cfz "/backup/data/data_full_$6-$2-$3.tgz" $DATA > rm -f /backup/data/data_diff* > # > tar cfz "/backup/config/config_full_$6-$2-$3.tgz" $CONFIG > rm -f /backup/config/config_diff* > else > # incremental backup: > # > find $DATA -depth -type f \( -ctime -1 -o -mtime -1 \) -print > > $LIST > tar cfzT "/backup/data/data_diff_$6-$2-$3.tgz" "$LIST" > rm -f "$LIST" > # > find $CONFIG -depth -type f \( -ctime -1 -o -mtime -1 \) -print > > $LIST > tar cfzT "/backup/config/config_diff_$6-$2-$3.tgz" "$LIST" > rm -f "$LIST" > fi > # > # create sql dump of databases: > mysqldump -u root --password=XXXXXXXXX --opt information_schema > > "/backup/database/information_schema_$6-$2-$3.sql" > gzip "/backup/database/information_schema_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt denora > > "/backup/database/denora_$6-$2-$3.sql" > gzip "/backup/database/denora_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt evilnet > > "/backup/database/evilnet_$6-$2-$3.sql" > gzip "/backup/database/evilnet_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt mysql > > "/backup/database/mysql_$6-$2-$3.sql" > gzip "/backup/database/mysql_$6-$2-$3.sql" > mysqldump -u root --password=XXXXXXXXX --opt quotes_db > > "/backup/database/quotes_db_$6-$2-$3.sql" > gzip "/backup/database/quotes_db_$6-$2-$3.sql" > > # > umount /backup > > > fstab: > > # Device Mountpoint FStype Options Dump > Pass# > /dev/ad0s1b none swap sw 0 0 > /dev/ad0s1a / ufs rw 1 1 > /dev/ad1s1d /usr/home ufs rw 1 1 > /dev/acd0 /cdrom cd9660 ro,noauto 0 0 > /dev/da0s1d /backup ufs rw,noauto 1 1 From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 21:57:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2BC21065670; Sun, 5 Jul 2009 21:57:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 939538FC12; Sun, 5 Jul 2009 21:57:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n65Lv81D032335; Sun, 5 Jul 2009 17:57:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n65Lv8Hb082574; Sun, 5 Jul 2009 17:57:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1AB1C7302F; Sun, 5 Jul 2009 17:57:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090705215708.1AB1C7302F@freebsd-current.sentex.ca> Date: Sun, 5 Jul 2009 17:57:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 21:57:11 -0000 TB --- 2009-07-05 20:27:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-05 20:27:20 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-07-05 20:27:20 - cleaning the object tree TB --- 2009-07-05 20:27:48 - cvsupping the source tree TB --- 2009-07-05 20:27:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-07-05 20:27:57 - building world TB --- 2009-07-05 20:27:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 20:27:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 20:27:57 - TARGET=sun4v TB --- 2009-07-05 20:27:57 - TARGET_ARCH=sparc64 TB --- 2009-07-05 20:27:57 - TZ=UTC TB --- 2009-07-05 20:27:57 - __MAKE_CONF=/dev/null TB --- 2009-07-05 20:27:57 - cd /src TB --- 2009-07-05 20:27:57 - /usr/bin/make -B buildworld >>> World build started on Sun Jul 5 20:27:58 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sun Jul 5 21:41:32 UTC 2009 TB --- 2009-07-05 21:41:32 - generating LINT kernel config TB --- 2009-07-05 21:41:32 - cd /src/sys/sun4v/conf TB --- 2009-07-05 21:41:32 - /usr/bin/make -B LINT TB --- 2009-07-05 21:41:32 - building LINT kernel TB --- 2009-07-05 21:41:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-05 21:41:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-05 21:41:32 - TARGET=sun4v TB --- 2009-07-05 21:41:32 - TARGET_ARCH=sparc64 TB --- 2009-07-05 21:41:32 - TZ=UTC TB --- 2009-07-05 21:41:32 - __MAKE_CONF=/dev/null TB --- 2009-07-05 21:41:32 - cd /src TB --- 2009-07-05 21:41:32 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jul 5 21:41:33 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ieee80211_node.o(.text+0x3db8): In function `ieee80211_node_attach': : undefined reference to `ieee80211_ageq_init' ieee80211_node.o(.text+0x4214): In function `node_cleanup': : undefined reference to `ieee80211_ageq_drain_node' ieee80211_wds.o(.text+0x16c): In function `ieee80211_dwds_discover': : undefined reference to `ieee80211_ageq_append' ieee80211_wds.o(.text+0x8a8): In function `wds_newstate': : undefined reference to `ieee80211_ageq_remove' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-05 21:57:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-05 21:57:08 - ERROR: failed to build lint kernel TB --- 2009-07-05 21:57:08 - 4695.66 user 428.96 system 5387.30 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 23:33:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C7091065676 for ; Sun, 5 Jul 2009 23:33:50 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from misery.daemoninthecloset.org (misery.daemoninthecloset.org [216.66.9.70]) by mx1.freebsd.org (Postfix) with ESMTP id 318DA8FC12 for ; Sun, 5 Jul 2009 23:33:50 +0000 (UTC) (envelope-from bryanv@daemoninthecloset.org) Received: from bayleaf.daemoninthecloset.org (bayleaf.daemoninthecloset.org [24.206.126.92]) by misery.daemoninthecloset.org (Postfix) with ESMTP id DFC34438105; Sun, 5 Jul 2009 16:30:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by bayleaf.daemoninthecloset.org (Postfix) with ESMTP id EBC924802D; Sun, 5 Jul 2009 18:16:56 -0500 (CDT) X-Virus-Scanned: amavisd-new at daemoninthecloset.org Received: from bayleaf.daemoninthecloset.org ([127.0.0.1]) by localhost (bayleaf.daemoninthecloset.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zURQll9n8-j; Sun, 5 Jul 2009 18:16:52 -0500 (CDT) Received: from bayleaf.daemoninthecloset.org (bayleaf.daemoninthecloset.org [192.168.10.13]) by bayleaf.daemoninthecloset.org (Postfix) with ESMTP id 1BAAC4802C; Sun, 5 Jul 2009 18:16:52 -0500 (CDT) Date: Sun, 5 Jul 2009 18:16:51 -0500 (CDT) From: Bryan Venteicher To: jos@catnook.com Message-ID: <1590020694.171246835811926.JavaMail.root@bayleaf> In-Reply-To: <1028722209.151246835679099.JavaMail.root@bayleaf> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.10.20] X-Mailer: Zimbra 5.0.16_GA_2921.UBUNTU8_64 (ZimbraWebClient - FF3.0 ([unknown])/5.0.16_GA_2921.UBUNTU8_64) Cc: current@freebsd.org Subject: Re: Selection using mouse aborts unexpectedly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 23:33:50 -0000 ----- "Jos Backus" wrote: > On Sun, Jul 05, 2009 at 12:44:54PM +0200, Dominic Fandrey wrote: > > Sounds like your mouse button is worn out. Did you verify this with > a different > > mouse? > > No, but I don't think I need to because selection works okay in an > xterm. I.e. > when I click-drag the left mouse button inside an xterm the selection > stays > active just fine as long as I hold down the mouse button. But when I > go to > some webpage inside Opera and try to select text, the selection aborts > and > starts reselecting right away. Same on the console. I could swear this > used to > work before. A Microsoft mouse of mine had similar behavior. The mouse is probably sending spurious up events. There's a flag for this in the ums driver: UMS_FLAG_SBU. Try or'ing that to sc_flag at attach time. > -- > Jos Backus > jos at catnook.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jul 5 23:42:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BC881065672 for ; Sun, 5 Jul 2009 23:42:16 +0000 (UTC) (envelope-from jos@catnook.com) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id EDCFB8FC12 for ; Sun, 5 Jul 2009 23:42:15 +0000 (UTC) (envelope-from jos@catnook.com) Received: from lizzy.dyndns.org (209-204-188-132.dsl.static.sonic.net [209.204.188.132]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id n65NgFUZ011042 for ; Sun, 5 Jul 2009 16:42:15 -0700 Received: (qmail 1467 invoked by uid 1000); 5 Jul 2009 23:42:38 -0000 Date: Sun, 5 Jul 2009 16:42:38 -0700 From: Jos Backus To: Bryan Venteicher Message-ID: <20090705234238.GA1448@lizzy.catnook.local> References: <1028722209.151246835679099.JavaMail.root@bayleaf> <1590020694.171246835811926.JavaMail.root@bayleaf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1590020694.171246835811926.JavaMail.root@bayleaf> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: current@freebsd.org Subject: Re: Selection using mouse aborts unexpectedly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jul 2009 23:42:16 -0000 On Sun, Jul 05, 2009 at 06:16:51PM -0500, Bryan Venteicher wrote: > A Microsoft mouse of mine had similar behavior. The mouse is probably > sending spurious up events. There's a flag for this in the ums driver: > UMS_FLAG_SBU. Try or'ing that to sc_flag at attach time. Thanks Bryan, that change makes it mostly usable again. So basically it's time to go look for a new mouse? Or does it make sense to add a quirk for this mouse? -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 07:23:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB3E9106564A for ; Mon, 6 Jul 2009 07:23:00 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from magic3.magicbooks.org (cl-190.dus-01.de.sixxs.net [IPv6:2a01:198:200:bd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 53C818FC14 for ; Mon, 6 Jul 2009 07:23:00 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from mail.magicbooks.org (localhost [127.0.0.1]) by magic3.magicbooks.org (8.14.3/8.14.3) with ESMTP id n667MkDW069340 for ; Mon, 6 Jul 2009 09:22:58 +0200 (CEST) (envelope-from cavac@magicbooks.org) Received: from 213.150.228.38 (SquirrelMail authenticated user cavac) by mail.magicbooks.org with HTTP; Mon, 6 Jul 2009 09:22:58 +0200 (CEST) Message-ID: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Date: Mon, 6 Jul 2009 09:22:58 +0200 (CEST) From: "Rene Schickbauer" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 07:23:01 -0000 Hi! Yesterday i submitted a patch for powerd to set maximum allowed CPU speed for adaptive modes (to keep the system cool and using less power). PR: 136354 Would it also make sense to have powerd run an (optional) user configureable script on ac state change? I'm thinking about things like dimming TFT backlight, on EEE PC turning of the webcam and so on. Another option that could make sense in powerd is checking the battery state and running a user configureable script when ac-state is set to battery and battery falls below a configured threshold. The script could do a number of things like warning the user, scheduling a shutdown and so on in order to give the user a fair chance to save his/her work and do a clean shutdown (or just plugin the ac adapter). powerd currently only adjusts CPU speed, but having a *second* programm monitor the same kernel variables to work on another part of the same problem does not seem to make sense. BTW, i'm also thinking of having the option to have powerd log the battery status (ac mode + load + charge level) every 5 Minutes or so to syslog. That way, a second script (log parser) may be able to determine information about the battery - like how long does it take to charge, rough capacity estimation and possible degradation of battery. Just throwing ideas... LLAP & LG Rene -- Hackerkey: http://tinyurl.com/pof37z From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 08:18:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E9F01065673 for ; Mon, 6 Jul 2009 08:18:47 +0000 (UTC) (envelope-from phoemix@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id B649D8FC25 for ; Mon, 6 Jul 2009 08:18:45 +0000 (UTC) (envelope-from phoemix@harmless.hu) Received: from [217.150.130.134] (helo=unknown) by marvin.harmless.hu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNjDA-000Kpy-FZ; Mon, 06 Jul 2009 10:06:04 +0200 Date: Mon, 6 Jul 2009 10:06:02 +0200 From: Gergely CZUCZY To: "Rene Schickbauer" Message-ID: <20090706100602.00003969@unknown> In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Organization: Harmless Digital Bt X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: Czuczy Gergely Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:18:47 -0000 Hello, I think this is a very nice idea, especially the TFT backlight part. It also might be useful to adjust the WiFi transmit power level according to battery state. That can also save some power, especially on portables. On Mon, 6 Jul 2009 09:22:58 +0200 (CEST) "Rene Schickbauer" wrote: > Hi! > > Yesterday i submitted a patch for powerd to set maximum allowed CPU > speed for adaptive modes (to keep the system cool and using less > power). > > PR: 136354 > > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about things > like dimming TFT backlight, on EEE PC turning of the webcam and so on. > > Another option that could make sense in powerd is checking the > battery state and running a user configureable script when ac-state > is set to battery and battery falls below a configured threshold. The > script could do a number of things like warning the user, scheduling > a shutdown and so on in order to give the user a fair chance to save > his/her work and do a clean shutdown (or just plugin the ac adapter). > > powerd currently only adjusts CPU speed, but having a *second* > programm monitor the same kernel variables to work on another part of > the same problem does not seem to make sense. > > BTW, i'm also thinking of having the option to have powerd log the > battery status (ac mode + load + charge level) every 5 Minutes or so > to syslog. That way, a second script (log parser) may be able to > determine information about the battery - like how long does it take > to charge, rough capacity estimation and possible degradation of > battery. > > Just throwing ideas... > > LLAP & LG > Rene -- Sincerely, Gergely CZUCZY Harmless Digital Bt +36-30-9702963 From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 08:36:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07E521065691 for ; Mon, 6 Jul 2009 08:36:06 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id BF21B8FC2B for ; Mon, 6 Jul 2009 08:36:05 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 2872C63353A; Mon, 6 Jul 2009 10:36:04 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id C8D08B918; Mon, 6 Jul 2009 10:36:03 +0200 (CEST) Date: Mon, 6 Jul 2009 10:36:02 +0200 From: Patrick Lamaiziere To: "Rene Schickbauer" Message-ID: <20090706103602.394c463a@baby-jane.lamaiziere.net> In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:36:06 -0000 Le Mon, 6 Jul 2009 09:22:58 +0200 (CEST), "Rene Schickbauer" a =E9crit : > Hi! Hello, > Yesterday i submitted a patch for powerd to set maximum allowed CPU > speed for adaptive modes (to keep the system cool and using less > power). >=20 > PR: 136354 I would like an option to set the minimum allowed CPU speed, instead the use of the sysctl debug.cpufreq.lowest.=20 > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about things > like dimming TFT backlight, on EEE PC turning of the webcam and so on. We can do this with devd. (my 0.42 euro) From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 08:56:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDACB10656E0 for ; Mon, 6 Jul 2009 08:56:19 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from magic3.magicbooks.org (cl-190.dus-01.de.sixxs.net [IPv6:2a01:198:200:bd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 1AF448FC1A for ; Mon, 6 Jul 2009 08:56:18 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from mail.magicbooks.org (localhost [127.0.0.1]) by magic3.magicbooks.org (8.14.3/8.14.3) with ESMTP id n668uH5B071105; Mon, 6 Jul 2009 10:56:17 +0200 (CEST) (envelope-from cavac@magicbooks.org) Received: from 213.150.228.38 (SquirrelMail authenticated user cavac) by mail.magicbooks.org with HTTP; Mon, 6 Jul 2009 10:56:17 +0200 (CEST) Message-ID: <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> In-Reply-To: <20090706100602.00003969@unknown> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706100602.00003969@unknown> Date: Mon, 6 Jul 2009 10:56:17 +0200 (CEST) From: "Rene Schickbauer" To: "Gergely CZUCZY" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 08:56:20 -0000 Hi! > I think this is a very nice idea, especially the TFT backlight part. It > also might be useful to adjust the WiFi transmit power level according > to battery state. That can also save some power, especially on > portables. Yes, changing the transmit power would be possible. Although adjusting the transmit power via script on a *mobile* computer is likely to get the user offline rather quickly. On the other hand, powerd would just run a script. This script could start a user-written daemon to continually adjust power level.. and when ac is plugged in again, the script kills that daemon. I sincerely doubt that would save you any amount of power worth mentioning, though but may give you additional troubles. But maybe you could restrict an a/b/g card to b/g or a and thus save some power. Some laptops let you power down the normal (cabled) network adapter. When your out of reach for AC power, you're very unlikely lugging a network cable around the building. Also, you may power down/unload inbuild audio, webcam, bluetooth, modem, serial port etc. If you're desperate, disallowing CDROM and SWAP operation may save you a ton of power, too. As i said, with user scripting triggered by powerd state changes, you could get *really* creative (like temporarly halting any mencoder and ffmpeg process while on battery power ;-). LLAP & LG Rene Schickbauer -- Hackerkey: http://tinyurl.com/pof37z From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 09:03:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF25310656DF for ; Mon, 6 Jul 2009 09:03:31 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from magic3.magicbooks.org (cl-190.dus-01.de.sixxs.net [IPv6:2a01:198:200:bd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 542948FC1A for ; Mon, 6 Jul 2009 09:03:30 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from mail.magicbooks.org (localhost [127.0.0.1]) by magic3.magicbooks.org (8.14.3/8.14.3) with ESMTP id n6693DDD071234; Mon, 6 Jul 2009 11:03:25 +0200 (CEST) (envelope-from cavac@magicbooks.org) Received: from 213.150.228.38 (SquirrelMail authenticated user cavac) by mail.magicbooks.org with HTTP; Mon, 6 Jul 2009 11:03:25 +0200 (CEST) Message-ID: <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> In-Reply-To: <20090706103602.394c463a@baby-jane.lamaiziere.net> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> Date: Mon, 6 Jul 2009 11:03:25 +0200 (CEST) From: "Rene Schickbauer" To: "Patrick Lamaiziere" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:03:32 -0000 Hi! >> Yesterday i submitted a patch for powerd to set maximum allowed CPU >> speed for adaptive modes (to keep the system cool and using less >> power). >> >> PR: 136354 > > I would like an option to set the minimum allowed CPU speed, instead > the use of the sysctl debug.cpufreq.lowest. This is so that powerd doesn't take so long to spin up power in the adaptive modes? Never thought of that, but makes sense to me. i will adapt the patch. >> Would it also make sense to have powerd run an (optional) user >> configureable script on ac state change? I'm thinking about things >> like dimming TFT backlight, on EEE PC turning of the webcam and so on. > > We can do this with devd. I'm not really familiar with devd. Could you give me a pointer how that would work? LLAP & LG Rene Schickbauer -- Hackerkey: http://tinyurl.com/pof37z From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 09:39:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5FFB106566C for ; Mon, 6 Jul 2009 09:39:30 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 90CE88FC12 for ; Mon, 6 Jul 2009 09:39:30 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 31B14C4021; Mon, 6 Jul 2009 11:19:24 +0200 (CEST) Message-Id: From: Rafal Jaworowski To: Kostik Belousov In-Reply-To: <20090703082040.GN2884@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 11:20:30 +0200 References: <200907030204.51415.max@love2party.net> <20090703082040.GN2884@deviant.kiev.zoral.com.ua> X-Mailer: Apple Mail (2.935.3) Cc: Max Laier , freebsd-current@freebsd.org, Jeff Roberson Subject: Re: MD5 test slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:39:31 -0000 On 2009-07-03, at 10:20, Kostik Belousov wrote: > On Fri, Jul 03, 2009 at 02:04:50AM +0200, Max Laier wrote: >> On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote: >>> I'm observing some heavy slowdown seen with md5 test on PowerPC: >>> >>> 1. On the MPC8572 machine with today's HEAD I'm getting: >>> >>> # md5 -t >>> MD5 time trial. Digesting 100000 10000-byte blocks ... done >>> Digest = 766a2bb5d24bddae466c572bcabca3ee >>> Time = 36.930565 seconds >>> Speed = 27077842.000000 bytes/second >>> >>> 2. While a couple of months back it yielded 6x shorter times on this >>> very same hardware, like this one: >>> >>> # md5 -t >>> MD5 time trial. Digesting 100000 10000-byte blocks ... done >>> Digest = 766a2bb5d24bddae466c572bcabca3ee >>> Time = 6.027277 seconds >>> Speed = 165912400.000000 bytes/second >>> >>> Timers work fine, the slowdown is real. I don't know if this is >>> PowerPC related, and was wondering if anybody observed something >>> similar on other archs perhaps? Any suggestions what could be >>> causing >>> this or where to look? I cannot see immediate suspects in the arch/ >>> platform code. >> >> "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this >> mailing list >> reports something that might be related. It seems there is a patch >> available, but not committed yet. Though I'm not sure about the >> nature of >> the problem exactly. Jeff? > > I want to make some points clear to avoid a confusion and spread of > FUD. > It seems we have at least three issues, all different: > 1. Syscalls slowdown on amd64. To see this, you need to microbenchmark > syscall enter/leave sequence. I doubt that it can be seen on any > load except while (1) {getpid();} loops or such. The issue is valid > _only_ for amd64. > I developed the patch with the input from Jeff who confirmed that > this slowdown is solved by the change. > 2. There are enough independent reports of i/o slowdown to believe > that > some problem is real; but we have not seen numbers or detailed > configurations or (most desirable) the revision after which the > slowdown started. Note the i/o part. > > This report is for PPC (right ?) and for workload that is purely > CPU-bounded. After additional testing my slowdown looks more like a PowerPC (E500 only) issue: nwhitehorn@ checked his G4 (AIM) system and could not observe this, so it seems something local to E500. Rafal From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 09:43:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACEF1106567F; Mon, 6 Jul 2009 09:43:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 5718A8FC08; Mon, 6 Jul 2009 09:43:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=M8ya5sss3rqR1TTGgThYf3/n4AjnemZ5pfAji8IqA+InrrtaJKOQ2j59TVYXP4HSHUdQIkRf2BpKSAJd+gbx5JoO2rn3RmFCS5lMTI7hhqtwrffPeJDVDIpCS1w6oOONpI/bpO3VHvFB9TZ8ZtB9UpwRrvfThqrq1ueLu1P47C0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MNkj4-0005nZ-Rc; Mon, 06 Jul 2009 13:43:06 +0400 Date: Mon, 6 Jul 2009 13:43:04 +0400 From: Eygene Ryabinkin To: Ian Freislich , dougb@freebsd.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: current@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:43:10 -0000 Ian, Doug, *, good day. Sun, Jul 05, 2009 at 12:07:18PM +0200, Ian Freislich wrote: > Due to not paying attention my ntp.conf on several of my time servers > was updated (and broken) by mergemaster. I had the automatic update > options set for files that I had not modified. My ntp.conf had no > VCS id and the files differed, obviously. What happened is the following: when mergemaster does automated upgrades, it consults the existing mtree database in /var/db/mergemaster.mtree that carries information about the state of the files created when the temproot was populated. When you start mergemaster, it will use the saved database from the previous run, so when you was hit the ntp.conf issue, that file was not in the mtree database yet. When mergemaster determines the list of changed files for auto-upgrade ($CHANGED), it just runs mtree against the current contents of the DESTDIR and looks for the 'changed' lines. Mtree is invoked with '-e', so it won't pay attention to the files that are present in the file hierarchy (your own /etc/ntp.conf), but not in the specification (remember, mtree database is from the previous run, so ntp.conf isn't there yet). And when a decision on the file's auto-upgrade is done, the following sequence is invoked: - mm checks that both source and destination files are present (your case); - mm checks that the destination file name isn't in the ${CHANGED} list (it isn't, as explained in the previous paragraph). So, it's how your ntp.conf ended up overwritten (if I am catching mm's logics well). > Was mergemaster correct in its assesment that this file was a > candidate for automatic installation? I'd say, "No it was mistaken". Basically, there should be a way to determine new files that were added to the tree since the last mergemaster run. And there is a way: ----- mtree -f ${MTREENEW} -f ${MTREEFILE} | \ awk '/^[^[:space:]]/ && $2 == "file" { print $1; }' ----- So, we should additionally check if the auto-installed files are present in the list produced by the latter command and refuse to copy them over. Doug, I am going to implement this stuff. May be I am overseeing something and there are another ways to overcome this problem? Will you commit such an extension to the mergemaster? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 09:47:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79E361065679 for ; Mon, 6 Jul 2009 09:47:45 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB3C8FC08 for ; Mon, 6 Jul 2009 09:47:44 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 3240763353A; Mon, 6 Jul 2009 11:47:44 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id E7F56BB9E; Mon, 6 Jul 2009 11:47:43 +0200 (CEST) Date: Mon, 6 Jul 2009 11:47:42 +0200 From: Patrick Lamaiziere To: "Rene Schickbauer" Message-ID: <20090706114742.4bd52252@baby-jane.lamaiziere.net> In-Reply-To: <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 09:47:45 -0000 Le Mon, 6 Jul 2009 11:03:25 +0200 (CEST), "Rene Schickbauer" a =E9crit : > Hi! >=20 > >> Yesterday i submitted a patch for powerd to set maximum allowed CPU > >> speed for adaptive modes (to keep the system cool and using less > >> power). > >> > >> PR: 136354 > > > > I would like an option to set the minimum allowed CPU speed, instead > > the use of the sysctl debug.cpufreq.lowest. >=20 > This is so that powerd doesn't take so long to spin up power in the > adaptive modes? If the speed is too low, my machine is not very interactive here (running KDE and all...). And with ndis if the speed is to low, my laptop hangs (on FreeBSD 7.2) > Never thought of that, but makes sense to me. i will adapt the patch. >=20 > >> Would it also make sense to have powerd run an (optional) user > >> configureable script on ac state change? I'm thinking about things > >> like dimming TFT backlight, on EEE PC turning of the webcam and so > >> on. > > > > We can do this with devd. >=20 > I'm not really familiar with devd. Could you give me a pointer how > that would work? See devd.conf, On ac state change a script is called (power_profile). # cat /var/run/devd.pipe (unplug) !system=3DACPI subsystem=3DACAD type=3D\_SB_.ADP1 notify=3D0x00 !system=3DACPI subsystem=3DCMBAT type=3D\_SB_.BAT0 notify=3D0x80 (plug) !system=3DACPI subsystem=3DACAD type=3D\_SB_.ADP1 notify=3D0x01 !system=3DACPI subsystem=3DCMBAT type=3D\_SB_.BAT0 notify=3D0x80 From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 10:01:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD16E106566C for ; Mon, 6 Jul 2009 10:01:11 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 92EDA8FC15 for ; Mon, 6 Jul 2009 10:01:11 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 113AF805F for ; Mon, 6 Jul 2009 12:01:09 +0200 (CEST) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id C6C478053; Mon, 6 Jul 2009 12:01:08 +0200 (CEST) From: Alban Hertroys To: Rene Schickbauer In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> X-Priority: 3 (Normal) References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Message-Id: <2A58225C-B4F9-40E5-8AFE-D169F391B4C2@solfertje.student.utwente.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 6 Jul 2009 12:01:08 +0200 X-Mailer: Apple Mail (2.935.3) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jul 6 12:01:09 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 909,4a51cb65759151706116102 X-DSPAM-Factors: 27, could, 0.40000, That, 0.40000, From*Alban, 0.40000, to+determine, 0.40000, to+determine, 0.40000, (provided+the, 0.40000, AM, 0.40000, Mime-Version*Message, 0.40000, AM+Rene, 0.40000, 5+Minutes, 0.40000, or, 0.40000, >+status, 0.40000, an, 0.40000, an, 0.40000, estimation, 0.40000, read+(programmatically), 0.40000, trees, 0.40000, trees, 0.40000, To*magicbooks.org>, 0.40000, easier, 0.40000, Date*12, 0.40000, rough, 0.40000, cut, 0.40000, of, 0.40000, of, 0.40000, syslog, 0.40000, Received*ESMTP, 0.40000 Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:01:12 -0000 On Jul 6, 2009, at 9:22 AM, Rene Schickbauer wrote: > BTW, i'm also thinking of having the option to have powerd log the > battery > status (ac mode + load + charge level) every 5 Minutes or so to > syslog. That > way, a second script (log parser) may be able to determine > information about > the battery - like how long does it take to charge, rough capacity > estimation and possible degradation of battery. Currently some similar information is available through sysctl's (cpu load + temperature for example). To me that seems to be a bit more flexible as a means of providing such information about battery status (you don't depend on a 5 minute interval in a log-file) and probably easier to read (programmatically) than parsing a file. And it doesn't need writing to a file-system that's trying to safe power while being carried around with the system off AC. OTOH, a sysctl doesn't keep a history of past events while a log-file does; you could write something that parsed an existing log-file to determine battery life expectations immediately (provided the log-file wasn't rotated too recent) while reading sysctl's would need some time to collect enough statistics. Just an idea. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:909,4a51cb65759151706116102! From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 10:56:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73E631065673 for ; Mon, 6 Jul 2009 10:56:33 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from magic3.magicbooks.org (cl-190.dus-01.de.sixxs.net [IPv6:2a01:198:200:bd::2]) by mx1.freebsd.org (Postfix) with ESMTP id E9CDC8FC20 for ; Mon, 6 Jul 2009 10:56:32 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from mail.magicbooks.org (localhost [127.0.0.1]) by magic3.magicbooks.org (8.14.3/8.14.3) with ESMTP id n66Au9cg073361; Mon, 6 Jul 2009 12:56:19 +0200 (CEST) (envelope-from cavac@magicbooks.org) Received: from 213.150.228.38 (SquirrelMail authenticated user cavac) by mail.magicbooks.org with HTTP; Mon, 6 Jul 2009 12:56:31 +0200 (CEST) Message-ID: <34809.213.150.228.38.1246877791.squirrel@mail.magicbooks.org> In-Reply-To: <2A58225C-B4F9-40E5-8AFE-D169F391B4C2@solfertje.student.utwente.nl> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <2A58225C-B4F9-40E5-8AFE-D169F391B4C2@solfertje.student.utwente.nl> Date: Mon, 6 Jul 2009 12:56:31 +0200 (CEST) From: "Rene Schickbauer" To: "Alban Hertroys" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 10:56:33 -0000 Hi! > And it doesn't need writing to a file-system that's trying to > safe power while being carried around with the system off AC. You're right, that would be a bit stupid. Heisenberg at work, it seems. Point taken. LLAP & LG Rene Schickbauer -- Hackerkey: http://tinyurl.com/pof37z From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:08:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F40F7106568D; Mon, 6 Jul 2009 11:08:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 9455D8FC2F; Mon, 6 Jul 2009 11:08:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 096CF1CECA; Mon, 6 Jul 2009 13:08:53 +0200 (CEST) Date: Mon, 6 Jul 2009 13:08:52 +0200 From: Ed Schouten To: Eygene Ryabinkin Message-ID: <20090706110852.GD48776@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FVcNYgCArjuDqTR+" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Ian Freislich , current@freebsd.org, dougb@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:08:54 -0000 --FVcNYgCArjuDqTR+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Eygene, * Eygene Ryabinkin wrote: > Doug, I am going to implement this stuff. May be I am overseeing > something and there are another ways to overcome this problem? Will > you commit such an extension to the mergemaster? While you're hacking on mergemaster, could you please change mergemaster to install files when the files are exactly the same, except for the $FreeBSD$ string? It makes switching to different CVS/SVN branches of the FreeBSD source tree a lot harder. ;-) --=20 Ed Schouten WWW: http://80386.nl/ --FVcNYgCArjuDqTR+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpR20QACgkQ52SDGA2eCwWjmACcDSHYDDCijgYYAID3sQAkGAQD ciAAniLOynFvxSFklacHYtC6ntOjc6bA =RbW5 -----END PGP SIGNATURE----- --FVcNYgCArjuDqTR+-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:12:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2145B1065A5C; Mon, 6 Jul 2009 11:12:39 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id ABAB88FC20; Mon, 6 Jul 2009 11:12:36 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 550559CB0ED; Mon, 6 Jul 2009 13:11:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0OExcczTefi; Mon, 6 Jul 2009 13:11:09 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 188599CB12D; Mon, 6 Jul 2009 13:11:09 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n66BB7Wb019857; Mon, 6 Jul 2009 13:11:07 +0200 (CEST) (envelope-from rdivacky) Date: Mon, 6 Jul 2009 13:11:07 +0200 From: Roman Divacky To: Ed Schouten Message-ID: <20090706111107.GA19818@freebsd.org> References: <20090706110852.GD48776@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090706110852.GD48776@hoeg.nl> User-Agent: Mutt/1.4.2.3i Cc: Ian Freislich , Eygene Ryabinkin , current@freebsd.org, dougb@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:12:52 -0000 On Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > Hi Eygene, > > * Eygene Ryabinkin wrote: > > Doug, I am going to implement this stuff. May be I am overseeing > > something and there are another ways to overcome this problem? Will > > you commit such an extension to the mergemaster? > > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) there's mergemaster -F From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:14:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFB9F10658B8; Mon, 6 Jul 2009 11:14:03 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A84BB8FC20; Mon, 6 Jul 2009 11:14:03 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1A0BA1CD00; Mon, 6 Jul 2009 13:14:03 +0200 (CEST) Date: Mon, 6 Jul 2009 13:14:03 +0200 From: Ed Schouten To: Roman Divacky Message-ID: <20090706111403.GE48776@hoeg.nl> References: <20090706110852.GD48776@hoeg.nl> <20090706111107.GA19818@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hiPWKCa83HsfYqhC" Content-Disposition: inline In-Reply-To: <20090706111107.GA19818@freebsd.org> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Ian Freislich , Eygene Ryabinkin , current@freebsd.org, dougb@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:14:13 -0000 --hiPWKCa83HsfYqhC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Roman Divacky wrote: > On Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > > Hi Eygene, > >=20 > > * Eygene Ryabinkin wrote: > > > Doug, I am going to implement this stuff. May be I am overseeing > > > something and there are another ways to overcome this problem? Will > > > you commit such an extension to the mergemaster? > >=20 > > While you're hacking on mergemaster, could you please change mergemaster > > to install files when the files are exactly the same, except for the > > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > > the FreeBSD source tree a lot harder. ;-) >=20 > there's mergemaster -F Ooh. Thanks! I just ran `mergemaster -U' and hoped it would do the right thing. I think it would be expected behaviour if -U implied -F... --=20 Ed Schouten WWW: http://80386.nl/ --hiPWKCa83HsfYqhC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpR3HsACgkQ52SDGA2eCwXiuwCfX8GzPnl6VZE4Tf2XOT5wOsO+ pzAAn1fKdyhSjldh7CXzZFyRFmjVH35r =Cmfn -----END PGP SIGNATURE----- --hiPWKCa83HsfYqhC-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:18:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03EBD10656AC; Mon, 6 Jul 2009 11:18:08 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 83D848FC0C; Mon, 6 Jul 2009 11:18:07 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.145.103.163] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MNmCy-00058z-VD; Mon, 06 Jul 2009 13:18:05 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MNmCx-0001PO-Fv; Mon, 06 Jul 2009 13:18:03 +0200 To: Ed Schouten From: Ian FREISLICH In-Reply-To: <20090706110852.GD48776@hoeg.nl> References: <20090706110852.GD48776@hoeg.nl> X-Attribution: BOFH Date: Mon, 06 Jul 2009 13:18:03 +0200 Message-Id: Cc: dougb@freebsd.org, Eygene Ryabinkin , current@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:18:08 -0000 Ed Schouten wrote: > * Eygene Ryabinkin wrote: > > Doug, I am going to implement this stuff. May be I am overseeing > > something and there are another ways to overcome this problem? Will > > you commit such an extension to the mergemaster? > > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) I believe that the '-F' option does this. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:31:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49531106566C; Mon, 6 Jul 2009 11:31:08 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E99ED8FC14; Mon, 6 Jul 2009 11:31:07 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=JZkyKKjTQPA7nvyOy+uZJ2+wGg4HMxfyI3HycQNJoIR3GQdctgvz50ACyb5qeBIBsIvMMWIeGF14Y/CuLpCp1HdNM9GEMfhxcW81AjdeOp+asZAG2d3HzLBWTY0xSc/uImjP8FKQJmdfe29KaDEaDrYJFIN9GmmeKW8dNBk6ubc=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MNmPa-000HB7-Ct; Mon, 06 Jul 2009 15:31:06 +0400 Date: Mon, 6 Jul 2009 15:31:04 +0400 From: Eygene Ryabinkin To: Ed Schouten Message-ID: References: <20090706110852.GD48776@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090706110852.GD48776@hoeg.nl> Sender: rea-fbsd@codelabs.ru Cc: Ian Freislich , current@freebsd.org, dougb@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:31:08 -0000 Ed, good day. Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) It's 'mergemaster -F'. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:36:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD7971065690 for ; Mon, 6 Jul 2009 11:36:31 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 2F7AF8FC15 for ; Mon, 6 Jul 2009 11:36:30 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (130.48.233.220.static.exetel.com.au [220.233.48.130]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n66BaO7v055164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 Jul 2009 21:06:26 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Mon, 6 Jul 2009 21:37:51 +1000 User-Agent: KMail/1.9.10 References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9377106.N4SKKcU5Jh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907062137.52621.doconnor@gsoft.com.au> X-Spam-Score: -1.819 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Rene Schickbauer Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:36:32 -0000 --nextPart9377106.N4SKKcU5Jh Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 6 Jul 2009, Rene Schickbauer wrote: > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about things > like dimming TFT backlight, on EEE PC turning of the webcam and so > on. devd can already do this.. Create a file for /usr/local/etc/devd (doesn't matter what it's called) with this in it.. notify 10 { match "system" "ACPI"; action "/usr/local/bin/acpi-ev $system $subsystem $type $notify"; }; The script will be called with "ACPI ACAD _SB_.AC__ 0x00" on power failure= =20 and "ACPI ACAD _SB_.AC__ 0x01" when connected. (It is easy to call logger $0 $* in your script to check various events out= =2E. =2D-=20 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 --nextPart9377106.N4SKKcU5Jh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKUeIQ5ZPcIHs/zowRAt5PAJ4zX3xRuL2m8t0ceXz4xg1LL0ZjxgCfYB0A Qc+ZS3Xzkx4xEkhOCb7I48E= =5B/p -----END PGP SIGNATURE----- --nextPart9377106.N4SKKcU5Jh-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 11:38:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852B51065687 for ; Mon, 6 Jul 2009 11:38:32 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp02.sth.basefarm.net (ch-smtp02.sth.basefarm.net [80.76.149.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3D64C8FC19 for ; Mon, 6 Jul 2009 11:38:32 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:50110 helo=falcon.midgard.homeip.net) by ch-smtp02.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MNmGW-0008HA-8A for current@freebsd.org; Mon, 06 Jul 2009 13:21:44 +0200 Received: (qmail 93301 invoked from network); 6 Jul 2009 13:15:01 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 6 Jul 2009 13:15:01 +0200 Received: (qmail 60021 invoked by uid 1001); 6 Jul 2009 13:15:01 +0200 Date: Mon, 6 Jul 2009 13:15:01 +0200 From: Erik Trulsson To: Ed Schouten Message-ID: <20090706111501.GA59991@owl.midgard.homeip.net> References: <20090706110852.GD48776@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090706110852.GD48776@hoeg.nl> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1MNmGW-0008HA-8A. X-Scan-Signature: ch-smtp02.sth.basefarm.net 1MNmGW-0008HA-8A f1469babca4feae03296d726a5022538 Cc: Ian Freislich , Eygene Ryabinkin , current@freebsd.org, dougb@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 11:38:32 -0000 On Mon, Jul 06, 2009 at 01:08:52PM +0200, Ed Schouten wrote: > Hi Eygene, > > * Eygene Ryabinkin wrote: > > Doug, I am going to implement this stuff. May be I am overseeing > > something and there are another ways to overcome this problem? Will > > you commit such an extension to the mergemaster? > > While you're hacking on mergemaster, could you please change mergemaster > to install files when the files are exactly the same, except for the > $FreeBSD$ string? It makes switching to different CVS/SVN branches of > the FreeBSD source tree a lot harder. ;-) Isn't that exactly what the '-F' flag for mergemaster already does? -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 12:11:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 930AB1065672 for ; Mon, 6 Jul 2009 12:11:16 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from magic3.magicbooks.org (cl-190.dus-01.de.sixxs.net [IPv6:2a01:198:200:bd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 26DF18FC16 for ; Mon, 6 Jul 2009 12:11:15 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from mail.magicbooks.org (localhost [127.0.0.1]) by magic3.magicbooks.org (8.14.3/8.14.3) with ESMTP id n66CAaOL074798; Mon, 6 Jul 2009 14:11:02 +0200 (CEST) (envelope-from cavac@magicbooks.org) Received: from 213.150.228.38 (SquirrelMail authenticated user cavac) by mail.magicbooks.org with HTTP; Mon, 6 Jul 2009 14:11:14 +0200 (CEST) Message-ID: <34960.213.150.228.38.1246882274.squirrel@mail.magicbooks.org> In-Reply-To: <200907062137.52621.doconnor@gsoft.com.au> References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <200907062137.52621.doconnor@gsoft.com.au> Date: Mon, 6 Jul 2009 14:11:14 +0200 (CEST) From: "Rene Schickbauer" To: "Daniel O'Connor" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:11:17 -0000 Hi! >> Would it also make sense to have powerd run an (optional) user >> configureable script on ac state change? I'm thinking about things >> like dimming TFT backlight, on EEE PC turning of the webcam and so >> on. > > devd can already do this.. [...] Wow, thanks. You just made my day! Its really astonishing what FreeBSD is capable of. Maybe it's finally time to kill OSX on my MacMini and install FreeBSD... uh, still need to get my DisplayLink adapter supported - one Monitor is *not* enough ;-) LLAP & LG Rene -- Hackerkey: http://tinyurl.com/pof37z From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 12:53:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E282A1065676 for ; Mon, 6 Jul 2009 12:53:45 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 79ED18FC23 for ; Mon, 6 Jul 2009 12:53:45 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 810B73A465; Mon, 6 Jul 2009 14:53:43 +0200 (SAST) Message-ID: <4A51F3D3.5000304@phat.za.net> Date: Mon, 06 Jul 2009 14:53:39 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Rene Schickbauer References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:53:46 -0000 Hi, Rene Schickbauer wrote: > Yesterday i submitted a patch for powerd to set maximum allowed CPU speed > for adaptive modes (to keep the system cool and using less power). Thank you for your work. > Would it also make sense to have powerd run an (optional) user configureable > script on ac state change? I'm thinking about things like dimming TFT > backlight, on EEE PC turning of the webcam and so on. No. As pointed out, devd(8) does this already. > Another option that could make sense in powerd is checking the battery state > and running a user configureable script when ac-state is set to battery and > battery falls below a configured threshold. The script could do a number of > things like warning the user, scheduling a shutdown and so on in order to > give the user a fair chance to save his/her work and do a clean shutdown (or > just plugin the ac adapter). As for the notification script at low capacity, in theory devd(8) should be able to do this as well. A notebook ought to generate a battery event when capacity hits its factory set "warning" and "low" marks. Of course I say this without having tested it on mine. :) > powerd currently only adjusts CPU speed, but having a *second* programm > monitor the same kernel variables to work on another part of the same > problem does not seem to make sense. > > BTW, i'm also thinking of having the option to have powerd log the battery > status (ac mode + load + charge level) every 5 Minutes or so to syslog. That > way, a second script (log parser) may be able to determine information about > the battery - like how long does it take to charge, rough capacity > estimation and possible degradation of battery. Seems unnecessary. That information is already available with acpiconf(8) and via sysctl(8) (see hw.acpi.acline, hw.acpi.battery), so someone is able to write their own logger if they wish. IMHO, I think powerd should be kept doing only work that's most useful. As I've experienced with power saving, the moment you start doing more and more work to save power, you also end up consuming more power. Keep it simple. Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 12:55:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD7121065675 for ; Mon, 6 Jul 2009 12:55:38 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 661E08FC08 for ; Mon, 6 Jul 2009 12:55:38 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id E3ADA3A465; Mon, 6 Jul 2009 14:55:36 +0200 (SAST) Message-ID: <4A51F444.7050803@phat.za.net> Date: Mon, 06 Jul 2009 14:55:32 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Rene Schickbauer References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706100602.00003969@unknown> <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> In-Reply-To: <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Gergely CZUCZY Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 12:55:39 -0000 Rene Schickbauer wrote: > Hi! > >> I think this is a very nice idea, especially the TFT backlight part. It >> also might be useful to adjust the WiFi transmit power level according >> to battery state. That can also save some power, especially on >> portables. > > Yes, changing the transmit power would be possible. Although adjusting the > transmit power via script on a *mobile* computer is likely to get the user > offline rather quickly. > > On the other hand, powerd would just run a script. This script could start a > user-written daemon to continually adjust power level.. and when ac is > plugged in again, the script kills that daemon. I sincerely doubt that would > save you any amount of power worth mentioning, though but may give you > additional troubles. But maybe you could restrict an a/b/g card to b/g or a > and thus save some power. FWIW, changing transmit power on my Intel 4965 based system made zero difference to overall power consumption. Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 13:04:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E0521065672 for ; Mon, 6 Jul 2009 13:04:57 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 17B228FC26 for ; Mon, 6 Jul 2009 13:04:56 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 4C0753982F; Mon, 6 Jul 2009 15:04:55 +0200 (SAST) Message-ID: <4A51F673.5010007@phat.za.net> Date: Mon, 06 Jul 2009 15:04:51 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Patrick Lamaiziere References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> <37078.213.150.228.38.1246871005.squirrel@mail.magicbooks.org> <20090706114742.4bd52252@baby-jane.lamaiziere.net> In-Reply-To: <20090706114742.4bd52252@baby-jane.lamaiziere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rene Schickbauer , freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 13:04:57 -0000 Hi, Patrick Lamaiziere wrote: >>> I would like an option to set the minimum allowed CPU speed, instead >>> the use of the sysctl debug.cpufreq.lowest. >> This is so that powerd doesn't take so long to spin up power in the >> adaptive modes? > > If the speed is too low, my machine is not very interactive here > (running KDE and all...). Have you tried disabling throttling (P4TCC)? Add these to your loader.conf: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 When you reboot you'll notice a lot of frequencies missing from dev.cpu.0.freq_levels. The remaining ones are those affected by EIST only. The difference? EIST controls CPU frequency *and* voltage. Throttling controls only frequency, and is much less effective at saving power (while being very effective at slowing your system down). If you disable throttling and use just EIST, your system will be much more responsive at a very small power cost. The power cost above can be made up by setting C-state to C2 or even C3. If you're running FreeBSD 8, another way of saving a lot of power on a notebook is to power down USB devices. Most notebooks' webcams and fingerprint readers are internally connected to the USB bus. Alexander Motin did a lot of testing a while ago. Take a look at this thread: http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006436.html Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 07:12:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E80D106564A for ; Mon, 6 Jul 2009 07:12:02 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) Received: from pdc.mands.hu (mail.mands.hu [194.143.229.130]) by mx1.freebsd.org (Postfix) with ESMTP id BFEAD8FC16 for ; Mon, 6 Jul 2009 07:12:01 +0000 (UTC) (envelope-from Krasznai.Andras@mands.hu) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Jul 2009 08:59:54 +0200 Message-ID: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: k3b and mkisofs problems on freebsd-current Thread-Index: Acn+B118DZZaEHnuRQOuDXIWNtsLIg== From: =?ISO-8859-1?Q?M=26S_-_Krasznai_Andr=E1s?= To: X-Mailman-Approved-At: Mon, 06 Jul 2009 14:11:12 +0000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: k3b and mkisofs problems on freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 07:12:02 -0000 Good morning! Since I upgraded my laptop to freebsd-8 k3b freezes after displaying the = splash screen. Earlier I used freebsd-7.2 stable. If I start k3b from a terminal window it gives back the terminal prompt = after the splash screen is displayed, and the GUI does not start. The = k3b process remains in memory, together with mkisofs. There are as many = mkisofs processes as many times I started k3b. k3b can be killed with = pkill k3b, but the mkisofs can not. Starting mkisofs from the command = line works perfectly.=20 If I move mkisofs out of the search path then k3b can be started, and I = could copy a CD with it.=20 I reinstalled k3b, cdrtools, I recompiled k3b with all its dependencies, = but there was no success.=20 I refreshed the sources last time on Friday, and recompiled k3b and = cdrtools again but it is still not working correctly. Did anybody experience such problems with k3b?=20 rgds Krasznai Andras From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 14:11:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310431065836 for ; Mon, 6 Jul 2009 14:11:59 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id A92CA8FC2F for ; Mon, 6 Jul 2009 14:11:58 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 55BD963352C; Mon, 6 Jul 2009 16:11:57 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id BF939B933; Mon, 6 Jul 2009 16:11:55 +0200 (CEST) Date: Mon, 6 Jul 2009 16:11:54 +0200 From: Patrick Lamaiziere To: Hans Petter Selasky Message-ID: <20090706161154.06abb3cd@baby-jane.lamaiziere.net> In-Reply-To: <200907051039.19584.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> <20090704164341.0acd0271@baby-jane.lamaiziere.net> <200907051039.19584.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 14:12:02 -0000 Le Sun, 5 Jul 2009 10:39:18 +0200, Hans Petter Selasky a =E9crit : > Can you try the attached patch for 8-current.=20 > Please provide ulpt > debug prints in either failing or succeeding case. Thanks a lot. I've commented the ulpt_reset(sc) in urlpt_open() because it does not work at all with it and I have to use unlpt. But no luck. I'm still using cups because I have to figure how I can get th= e PCL file sent to the printer. I'm using /dev/urlpt. ulpt0: on = usbus0 ulpt_attach:610: setting alternate config number: 0 ulpt0: using bi-directional mode ulpt_write_callback:237: state=3D0x0 actlen=3D0 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 12 times ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8173 ulpt_write_callback:237: state=3D0x0 actlen=3D8173 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x0 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D8192 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_status_callback:369: error=3DUSB_ERR_STALLED ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D14989 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x0 actlen=3D14989 ulpt_write_callback:237: state=3D0x1 actlen=3D8192=20 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D1563=20 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x0 actlen=3D1563=20 ulpt_write_callback:237: state=3D0x1 actlen=3D8192=20 ulpt_write_callback:237: state=3D0x0 actlen=3D8192=20 ulpt_write_callback:237: state=3D0x1 actlen=3D8192=20 ulpt_write_callback:237: state=3D0x0 actlen=3D8192=20 ulpt_write_callback:237: state=3D0x1 actlen=3D8192=20 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D8192=20 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 2 times =20 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 2 times =20 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 2 times =20 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 2 times ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 5 times ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 last message repeated 2 times ulpt_status_callback:369: error=3DUSB_ERR_IOERROR ulpt_write_callback:237: state=3D0x1 actlen=3D16384 ulpt_write_callback:237: state=3D0x1 actlen=3D4836 ulpt_status_callback:369: error=3DUSB_ERR_IOERROR last message repeated 31 times last message repeated 121 times last message repeated 544 times ... Shall I setup another box with current to be sure that's a problem with the printer and not with the hardware? Regards. From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 15:51:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96918106564A for ; Mon, 6 Jul 2009 15:51:04 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id D9BFC8FC19 for ; Mon, 6 Jul 2009 15:51:03 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=3Z1HSK4m8mWhRrFR_0EA:9 a=CtcdaOUG9Wt6lt26yf8A:7 a=a-aXMgJu9itIvJdfkB4L8J98DjgA:4 a=9aOQ2cSd83gA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1269572606; Mon, 06 Jul 2009 17:51:02 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 6 Jul 2009 17:50:37 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907051039.19584.hselasky@c2i.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> In-Reply-To: <20090706161154.06abb3cd@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907061750.39084.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 15:51:04 -0000 On Monday 06 July 2009 16:11:54 Patrick Lamaiziere wrote: > Le Sun, 5 Jul 2009 10:39:18 +0200, > > Hans Petter Selasky a =E9crit : > > Can you try the attached patch for 8-current. > > Please provide ulpt > > debug prints in either failing or succeeding case. > > Thanks a lot. > I've commented the ulpt_reset(sc) in urlpt_open() because it does not work > at all with it and I have to use unlpt. > > But no luck. I'm still using cups because I have to figure how I can get > the PCL file sent to the printer. I'm using /dev/urlpt. > > ulpt0: on > usbus0 ulpt_attach:610: setting alternate config number: 0 > ulpt0: using bi-directional mode > ulpt_write_callback:237: state=3D0x0 actlen=3D0 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 12 times > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8173 > ulpt_write_callback:237: state=3D0x0 actlen=3D8173 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_status_callback:369: error=3DUSB_ERR_STALLED > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D14989 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x0 actlen=3D14989 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D1563 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x0 actlen=3D1563 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x0 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D8192 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 2 times > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 2 times > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 2 times > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 2 times > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 5 times > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > last message repeated 2 times > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > ulpt_write_callback:237: state=3D0x1 actlen=3D16384 > ulpt_write_callback:237: state=3D0x1 actlen=3D4836 > ulpt_status_callback:369: error=3DUSB_ERR_IOERROR > last message repeated 31 times > last message repeated 121 times > last message repeated 544 times > ... > > Shall I setup another box with current to be sure that's a problem > with the printer and not with the hardware? Hi, urlpt was just for backwards compatibility. Could you try printing using /dev/unlpt0 ? And send me resulting dmesg? Power cycle your printer before testing. =2D-HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 17:27:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B29201065672 for ; Mon, 6 Jul 2009 17:27:37 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 3FB158FC08 for ; Mon, 6 Jul 2009 17:27:37 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MNryY-00063h-TG; Mon, 06 Jul 2009 19:27:34 +0200 Received: from tc1fe.t.pppool.de ([89.55.193.254]:19607 helo=ernst.jennejohn.org) by 5.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MNryY-0003Ls-Iy; Mon, 06 Jul 2009 19:27:34 +0200 Date: Mon, 6 Jul 2009 19:27:32 +0200 From: Gary Jennejohn To: M&S - Krasznai =?ISO-8859-1?Q?Andr=E1s?= Message-ID: <20090706192732.4e23f53a@ernst.jennejohn.org> In-Reply-To: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> References: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: 149285::1246901254-000052E9-FC6B7A60/0-0/0-0 Cc: freebsd-current@freebsd.org Subject: Re: k3b and mkisofs problems on freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:27:37 -0000 On Mon, 6 Jul 2009 08:59:54 +0200 M&S - Krasznai Andr__s wrote: > Good morning! > > Since I upgraded my laptop to freebsd-8 k3b freezes after displaying the splash screen. Earlier I used freebsd-7.2 stable. > > If I start k3b from a terminal window it gives back the terminal prompt after the splash screen is displayed, and the GUI does not start. The k3b process remains in memory, together with mkisofs. There are as many mkisofs processes as many times I started k3b. k3b can be killed with pkill k3b, but the mkisofs can not. Starting mkisofs from the command line works perfectly. > > If I move mkisofs out of the search path then k3b can be started, and I could copy a CD with it. > > I reinstalled k3b, cdrtools, I recompiled k3b with all its dependencies, but there was no success. > > > I refreshed the sources last time on Friday, and recompiled k3b and cdrtools again but it is still not working correctly. > > > Did anybody experience such problems with k3b? > Yes, I've been seeing this for months. I ditched k3b and started using tkdvd. Much smaller and doesn't require all that KDE stuff. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 17:31:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA758106570F for ; Mon, 6 Jul 2009 17:31:20 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7068FC16 for ; Mon, 6 Jul 2009 17:31:20 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n66HVILQ012961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 10:31:19 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A5234E6.2000900@freebsd.org> Date: Mon, 06 Jul 2009 10:31:18 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090705) MIME-Version: 1.0 To: Aragon Gouveia References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706100602.00003969@unknown> <12908.213.150.228.38.1246870577.squirrel@mail.magicbooks.org> <4A51F444.7050803@phat.za.net> In-Reply-To: <4A51F444.7050803@phat.za.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: Rene Schickbauer , Gergely CZUCZY , freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes [wifi tx power] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 17:31:21 -0000 Aragon Gouveia wrote: > Rene Schickbauer wrote: >> Hi! >> >>> I think this is a very nice idea, especially the TFT backlight part. It >>> also might be useful to adjust the WiFi transmit power level according >>> to battery state. That can also save some power, especially on >>> portables. >> >> Yes, changing the transmit power would be possible. Although >> adjusting the >> transmit power via script on a *mobile* computer is likely to get the >> user >> offline rather quickly. >> >> On the other hand, powerd would just run a script. This script could >> start a >> user-written daemon to continually adjust power level.. and when ac is >> plugged in again, the script kills that daemon. I sincerely doubt >> that would >> save you any amount of power worth mentioning, though but may give you >> additional troubles. But maybe you could restrict an a/b/g card to >> b/g or a >> and thus save some power. > > FWIW, changing transmit power on my Intel 4965 based system made zero > difference to overall power consumption. Changing the tx power is unlikely to save you much. What you want to do is switch between sta mode power save when you switch between AC and battery and/or change the PS parameters depending on the power config and battery level. I don't recall if iwn is hooked up properly to ifconfig to control power save operation. FWIW wifi tx power control (TPC) is best used to avoid saturating the rx radio when in close proximity. It's also good to reduce the power so you don't splatter adjacent channels (mostly in 2.4GHz). Some devices do this automatically. Sam From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 18:21:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A8101065673; Mon, 6 Jul 2009 18:21:05 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0B36B8FC1A; Mon, 6 Jul 2009 18:21:04 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n66IL9EG092488; Mon, 6 Jul 2009 13:21:09 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: content-type:content-transfer-encoding; b=sMOVOpuEOZzO8JMoMlQKTkGVfkWwUd64uhjmb2QCpCCEqAeruFtcfbr6PldPdAAac 0Xbrm9EjSjzR9/2K89et/dc0uWZSkef1SSiEWweX65A8LE3x/oi4SuuvZKMSyR8ZJ+N bVz9YBr5ua5Ykehe6VDoDGoR0GulD+24pKJjDKw= Message-ID: <4A52407B.1040009@jrv.org> Date: Mon, 06 Jul 2009 13:20:43 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: ahci: wait for !BSY fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:21:05 -0000 Quick synopsis: 1. The CAM AHCI driver fails for me every time detecting disks waiting for !BSY. The ATA driver works every time in the same configuration. The option ROM for the eSATA card ID's the drive correctly every time. 2. Both a WD 1TB and a Seagate 2TB fail/work the same way. 3. The system under test is a Via VB8001 with Via Nano (Isaiah) CPU in amd64 mode. 8.0-CURRENT svn 195136 June 28, 2009 with cam-ata.20090704.patch (other patch versions and -CURRENT revs tried too) 4. The AHCI adapter is a JMicron JMB363-based Syba SD-PEX-JM1A2E card: this one http://www.newegg.com/Product/Product.aspx?Item=N82E16816124022 The option ROM does not support RAID and there is no option ROM menu. 5, I've spent a couple of days looking at the code and putting in debugging to trace the I/Os and I can't find the problem. The old ATA and new CAM AHCI drivers are doing the same thing except for some timing differences, and eliminating those timing differences doesn't seem to help. Without the AHCI cam-ata.20090704.patch the disk is seen: atapci0: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c0f mem 0xdfbfe000-0xdfbfffff irq 24 at device 0.0 on pci2 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x9c00 ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xdfbfe000 atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000113 ata2: ready wait time=12ms ata2: software reset port 15... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ... ata2: Identifying devices: 00000001 ata2: New devices: 00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 953869MB at ata2-master SATA150 ad4: 1953525168 sectors [1938021C/16H/63S] 16 sectors/interrupt 1 depth queue uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered GEOM: new disk ad4 ad4: JMicron check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed But with the AHCI cam-ata.20090704.patch there is an error: (note that I increased the !BSY timeout to no avail here) ahci0: port 0xac00-0xac07,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9c00-0x9c0f mem 0xdfbfe000-0xdfbfffff irq 24 at device 0.0 on pci2 ahci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xdfbfe000 ioapic1: routing intpin 0 (PCI IRQ 24) to lapic 0 vector 49 ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported ahci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ... ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect time=0ms status=00000113 ahcich0: port is not ready (timeout 30000ms) tfd = 000000ff ahcich0: device ready timeout ahcich0: AHCI reset done: devices=00000001 ... ahcich0: Poll error on slot 1, TFD: 0077 (probe0:ahcich0:0:15:0): Request completed with CAM_ATA_STATUS_ERROR (probe0:ahcich0:0:15:0): error 5 (probe0:ahcich0:0:15:0): Retries Exhausted ahcich0: Poll error on slot 2, TFD: 0077 (probe0:ahcich0:0:0:0): Request completed with CAM_ATA_STATUS_ERROR (probe0:ahcich0:0:0:0): error 5 (probe0:ahcich0:0:0:0): Retries Exhausted From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 18:39:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14381065673 for ; Mon, 6 Jul 2009 18:39:33 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id A3B6A8FC12 for ; Mon, 6 Jul 2009 18:39:33 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 733FE63352C; Mon, 6 Jul 2009 20:39:32 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id B5CBCC594; Mon, 6 Jul 2009 20:39:30 +0200 (CEST) Date: Mon, 6 Jul 2009 20:39:30 +0200 From: Patrick Lamaiziere To: Hans Petter Selasky Message-ID: <20090706203930.7b0f1f20@baby-jane.lamaiziere.net> In-Reply-To: <200907061750.39084.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907051039.19584.hselasky@c2i.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> <200907061750.39084.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:39:34 -0000 Le Mon, 6 Jul 2009 17:50:37 +0200, Hans Petter Selasky a =E9crit : > urlpt was just for backwards compatibility. Ah ok! > Could you try printing using /dev/unlpt0 ? And send me resulting > dmesg? >=20 > Power cycle your printer before testing. It looks better, I still have some USB_ERR_IOERROR. But I was able to print 4 times the same document: It's long, please see http://user.lamaiziere.net/patrick/ulpt-debug1.txt I notice that there is always an error ulpt_status_callback:369: error=3DUSB_ERR_STALLED before an USB_ERR_IOERROR. Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 19:05:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D2A01065670 for ; Mon, 6 Jul 2009 19:05:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 374B98FC13 for ; Mon, 6 Jul 2009 19:05:38 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 8063 invoked by uid 399); 6 Jul 2009 19:05:30 -0000 Received: from localhost (HELO ?10.9.1.188?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 6 Jul 2009 19:05:30 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A524AE2.2020902@FreeBSD.org> Date: Mon, 06 Jul 2009 12:05:06 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian Freislich , current@freebsd.org Subject: Re: pebkac, but is it a mergemaster bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 19:05:39 -0000 Eygene Ryabinkin wrote: >> Was mergemaster correct in its assesment that this file was a >> candidate for automatic installation? > > I'd say, "No it was mistaken". Overall I tend to agree with you, however I'll use this as yet another reminder that my resistance to making mergemaster more "automatic" by default has a solid basis. > Basically, there should be a way to > determine new files that were added to the tree since the last > mergemaster run. And there is a way: > ----- > mtree -f ${MTREENEW} -f ${MTREEFILE} | \ > awk '/^[^[:space:]]/ && $2 == "file" { print $1; }' > ----- > So, we should additionally check if auto-installed files are present > in the list produced by the latter command and refuse to copy them > over. This situation with ntp.conf is the first time I remember that we've ever added an example config file to the base that the user is likely to have already in /etc (as opposed to /usr/local/etc which is where user-originated stuff usually goes). So I'm not sure that this feature as described is the most efficient way to solve the problem. We just had a thread on this topic recently where I suggested that the proper solution is to teach mtree to issue a list of files that have _not_ changed and have mergemaster depend on that list instead of getting the list of things that have changed and assuming that anything not on that list is safe to replace. Alternatively, if you really want to work on a patch that is for mergemaster only you could get the list of files that have changed, and parse the existing mtree db file against that list to generate a list of files that have not changed. > Doug, I am going to implement this stuff. Maybe I am overseeing > something and there are another ways to overcome this problem? Will > you commit such an extension to the mergemaster? I currently lack the time to do the mtree stuff, but I will gladly make the change to mergemaster if someone else can implement it. hth, Doug From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 21:20:02 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE18C106564A; Mon, 6 Jul 2009 21:20:02 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id C64548FC12; Mon, 6 Jul 2009 21:20:01 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id B2F051E002B1; Mon, 6 Jul 2009 23:20:00 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n66LGkBM013831; Mon, 6 Jul 2009 23:16:46 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n66LGk5t013830; Mon, 6 Jul 2009 23:16:46 +0200 (CEST) (envelope-from nox) Date: Mon, 6 Jul 2009 23:16:46 +0200 (CEST) From: Juergen Lock Message-Id: <200907062116.n66LGk5t013830@triton.kn-bremen.de> To: mav@FreeBSD.org X-Newsgroups: local.list.freebsd.current In-Reply-To: <4A50C331.3040505@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> Organization: home Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:20:03 -0000 In article <4A50C331.3040505@FreeBSD.org> you write: >Lucius Windschuh wrote: >> Hi Alexander. >> >> 2009/7/5 Alexander Motin : >>> It's never late. I have just uploaded fresh patch: >>> http://people.freebsd.org/~mav/cam-ata.20090704.patch >> >> "make buildworld" with this patch stops in my configuration with: >> >> /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In >> function `ata_max_mode': >> : undefined reference to `min' >> >> Simply adding >> #ifndef min >> #define min(a,b) (((a)<(b))?(a):(b)) >> #endif >> in ata_all.c helps, obviously. > >Thanks. I tried this on the box with that optical drive that head no longer likes (fails to be probed and generates an irq storm, see http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983 ), and with ahci.ko loaded by loader.conf I got timeouts followed by a panic: http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpg The panic seems to be in cam_periph_lock: (kgdb) l *(cdioctl+0x4e) 0xffffffff801a937e is in cdioctl (cam_periph.h:183). 178 u_int32_t sense_flags, union ccb *save_ccb); 179 180 static __inline void 181 cam_periph_lock(struct cam_periph *periph) 182 { 183 mtx_lock(periph->sim->mtx); 184 } 185 186 static __inline void 187 cam_periph_unlock(struct cam_periph *periph) (kgdb) Without ahci.ko loaded it boots, but the original problems remain, here is the dmesg from that boot: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #0: Mon Jul 6 21:22:05 CEST 2009 nox@triton.kn-bremen.de:/usr/obj/usr/home/nox/src8camata/src/sys/TRITON8 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81025000. module_register: module probe already exists! Module probe failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2812820279 Hz CPU: AMD Phenom(tm) II X4 920 Processor (2812.82-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB 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 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 9395240960 (8960 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x000000000104f000 - 0x00000000cfddffff, 3470331904 bytes (847249 pages) 0x0000000100000000 - 0x0000000220a2ffff, 4842520576 bytes (1182256 pages) avail memory = 8270852096 (7887 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf6fe0 00014 (v0 GBT ) ACPI: RSDT 0xcfde3000 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: FACP 0xcfde3040 00074 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: DSDT 0xcfde30c0 05E2B (v1 GBT GBTUACPI 00001000 MSFT 03000000) ACPI: FACS 0xcfde0000 00040 ACPI: SSDT 0xcfde8fc0 0088C (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xcfde9880 00038 (v1 GBT GBTUACPI 42302E31 GBTU 00000098) ACPI: MCFG 0xcfde98c0 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: TAMG 0xcfde9900 00302 (v1 GBT GBT B0 5455312E BG\^A\^A 53450101) ACPI: APIC 0xcfde8f00 00084 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) 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 lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high 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: 0x00000400 wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jul 6 2009 21:21:34) acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000012000 pa 0x4000 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, cfce0000 (3) failed ACPI timer: 1/2 1/2 1/1 1/2 1/1 1/1 1/1 1/2 1/2 1/1 -> 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=0x5957, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[1c]: type Memory, range 64, base 0xe0000000, size 29, enabled found-> vendor=0x1002, dev=0x5978, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x597d, revid=0x00 domain=0, bus=0, slot=7, 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) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x597f, revid=0x00 domain=0, bus=0, slot=10, 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) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4391, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-06-01, 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 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=0x0002, 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=11 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=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 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=5 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=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 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=0x0230, 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 1 message 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=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 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=0x1200, 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=0x1201, 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=0x1202, 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=0x1203, 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) found-> vendor=0x1022, dev=0x1204, revid=0x00 domain=0, bus=0, slot=24, func=4 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) pcib1: irq 18 at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfde00000-0xfdefffff pcib1: prefetched decode 0xd0000000-0xdfffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x9498, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfdee0000, size 16, enabled pcib1: requested memory range 0xfdee0000-0xfdeeffff: good map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled pcib1: requested I/O range 0xee00-0xeeff: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0xaa38, revid=0x00 domain=0, bus=1, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdefc000, size 14, enabled pcib1: requested memory range 0xfdefc000-0xfdefffff: good pcib1: matched entry for 1.0.INTB pcib1: slot 0 INTB hardwired to IRQ 19 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pcib2: irq 19 at device 7.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 0xfdc00000-0xfdcfffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x10b9, revid=0x06 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 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfdde0000, size 17, enabled pcib2: requested memory range 0xfdde0000-0xfddfffff: good map[14]: type Memory, range 32, base 0xfddc0000, size 17, enabled pcib2: requested memory range 0xfddc0000-0xfdddffff: good map[18]: type I/O Port, range 32, base 0xdf00, size 5, enabled pcib2: requested I/O range 0xdf00-0xdf1f: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 em0: port 0xdf00-0xdf1f mem 0xfdde0000-0xfddfffff,0xfddc0000-0xfdddffff irq 19 at device 0.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfdde0000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:34:ef:46 pcib3: irq 18 at device 10.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfda00000-0xfdafffff pcib3: prefetched decode 0xfdf00000-0xfdffffff pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=3, 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=5 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 0xce00, size 8, enabled pcib3: requested I/O range 0xce00-0xceff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, enabled pcib3: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdfe0000, size 16, enabled pcib3: requested memory range 0xfdfe0000-0xfdfeffff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 re0: port 0xce00-0xceff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at device 0.0 on pci3 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfdfff000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 50 re0: using IRQ 257 for MSI 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: bpf attached re0: Ethernet address: 00:1f:d0:d7:4c:1b re0: [MPSAFE] re0: [FILTER] 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 lapic 0 vector 51 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 6 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC 6ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000123 ata2: ready wait time=23ms ata2: software reset port 15... ata2: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: software reset port 0... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=10ms status=00000113 ata3: ready wait time=183ms ata3: software reset port 15... ata3: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata3: port is not ready (timeout 0ms) tfd = 00000180 ata3: software reset clear timeout ata3: software reset port 0... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: AHCI reset... ata4: hardware reset ... ata4: SATA connect time=0ms status=00000123 ata4: ready wait time=16ms ata4: software reset port 15... ata4: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata4: port is not ready (timeout 0ms) tfd = 000001d0 ata4: software reset clear timeout ata4: software reset port 0... ata4: ready wait time=0ms ata4: SIGNATURE: 00000101 ata4: AHCI reset done: devices=00000001 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci0 ata6: AHCI reset... ata6: hardware reset ... ata6: SATA connect timeout status=00000000 ata6: AHCI reset done: phy reset found no device ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci0 ata7: AHCI reset... ata7: hardware reset ... ata7: SATA connect timeout status=00000000 ata7: AHCI reset done: phy reset found no device ata7: [MPSAFE] ata7: [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 lapic 0 vector 52 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 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 lapic 0 vector 53 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 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 lapic 0 vector 54 ohci2: [MPSAFE] ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [MPSAFE] ohci3: [ITHREAD] usbus4: on ohci3 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 lapic 0 vector 55 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 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=7f 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=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 57 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xb000-0xbfff pcib4: memory decode 0xf8000000-0xfcffffff pcib4: prefetched decode 0xfdb00000-0xfdbfffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x14f1, dev=0x8800, revid=0x05 domain=0, bus=4, slot=6, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x37 (13750 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf9000000, size 24, enabled pcib4: requested memory range 0xf9000000-0xf9ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8811, revid=0x05 domain=0, bus=4, slot=6, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf8000000, size 24, enabled pcib4: requested memory range 0xf8000000-0xf8ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8802, revid=0x05 domain=0, bus=4, slot=6, func=2 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0x58 (22000 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb000000, size 24, enabled pcib4: requested memory range 0xfb000000-0xfbffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8804, revid=0x05 domain=0, bus=4, slot=6, func=4 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfa000000, size 24, enabled pcib4: requested memory range 0xfa000000-0xfaffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8024, revid=0x00 domain=0, bus=4, slot=14, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcfff000, size 11, enabled pcib4: requested memory range 0xfcfff000-0xfcfff7ff: good map[14]: type Memory, range 32, base 0xfcff8000, size 14, enabled pcib4: requested memory range 0xfcff8000-0xfcffbfff: good pcib4: matched entry for 4.14.INTA pcib4: slot 14 INTA hardwired to IRQ 22 pci4: at device 6.0 (no driver attached) pci4: at device 6.1 (no driver attached) pci4: at device 6.2 (no driver attached) pci4: at device 6.4 (no driver attached) fwohci0: mem 0xfcfff000-0xfcfff7ff,0xfcff8000-0xfcffbfff irq 22 at device 14.0 on pci4 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfcfff000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:ef:de:f8:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xcfdd8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:ef:de:00:1f:d0 fwe0: bpf attached fwe0: Ethernet address: 02:ef:de:00:1f:d0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:ef:de:f8:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [MPSAFE] ohci4: [ITHREAD] usbus6: on ohci4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 58 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: [FILTER] uart0: fast interrupt psmcpnp0: irq 12 on acpi0 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 lapic 0 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 61 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atrtc0: port 0x70-0x73 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) cpu0: on acpi0 cpu0: switching to generic Cx mode hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 513579 -> 100000 procfs registered lapic: Divisor 2, Frequency 100457873 hz Timecounter "TSC" frequency 2812820279 Hz quality -100 Timecounters tick every 1.000 msec pfsync0: bpf attached lo0: bpf attached pflog0: bpf attached ata5: CONNECT requested firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hptrr: no controller detected. ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ataata5: DISCONNECT requested 5: reinit done .. ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 953868MB at ata2-master SATA300 ad4: 1953523055 sectors [1938018C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: Silicon Image check3 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00010000 ata3: New devices: 00010000 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us acd0: DVDR drive at ata3 as master acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata4: Identifying devices: 00000001 ata4: New devices: 00000001 uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 953869MB at ata4-master SATA300 ad8: 1953525168 sectors [1938021C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Silicon Image check3 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5: Identifying devices: 00000000 ata5: New devices: 00000000 ata6: Identifying devices: 00000000 ata6: New devices: 00000000 ata7: Identifying devices: 00000000 ata7: New devices: 00000000 GEOM: new disk ad8 GEOM: ad8: partition 1 does not start on a track boundary. GEOM: ad8: partition 1 does not end on a track boundary. GEOM: ad8s3: geometry does not match label (255h,63s != 16h,63s). ugen1.2: at usbus1 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 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: 0x00000400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 1 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 2 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 3 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 2 vector 50 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 3 vector 50 msi: Assigning MSI IRQ 257 to local APIC 1 vector 51 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ufsid/49bca1defbad5bce ct_to_ts([2009-07-06 21:47:17]) = 1246916837.000000000 start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done ..ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... lock order reversal: 1st 0xffffffff80c0ffe0 pf task mtx (pf task mtx) @ /usr/home/nox/src8camata/src/sys/contrib/pf/net/pf_ioctl.c:1394 2nd 0xffffffff80e09240 ifnet (ifnet) @ /usr/home/nox/src8camata/src/sys/net/if.c:1887 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f ifunit() at ifunit+0x22 pfioctl() at pfioctl+0x1f6d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098798c, rsp = 0x7fffffffb568, rbp = 0x7fffffffb6c0 --- tun0: bpf attached altq: emulate 256000000Hz cpu clock WARNING: attempt to net_add_domain(netgraph) after domainfinalize() ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 21:20:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 833381065675; Mon, 6 Jul 2009 21:20:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 560B18FC24; Mon, 6 Jul 2009 21:20:48 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n66LIGRg043316; Mon, 6 Jul 2009 17:18:16 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907062118.n66LIGRg043316@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 06 Jul 2009 17:20:45 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A504B0C.2060406@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:20:49 -0000 At 02:41 AM 7/5/2009, Alexander Motin wrote: >>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is >>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 > >This is AHCI driver debugging. I've removed it in latest patch. In >this case it means that drive signals some command error. Hi, With the latest patch (cam-ata.20090704.patch), writing to the disk with physical errors looks like this now Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42003431424, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42196107264, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42388783104, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42581458944, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:17 ich10 last message repeated 4 times Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42774134784, length=16384)]error = 5 Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:18 ich10 last message repeated 4 times Jul 6 13:56:18 ich10 kernel: g_vfs_done():ada2[READ(offset=42966810624, length=16384)]error = 5 Jul 6 13:56:18 ich10 kernel: ahcich2: Error while READ LOG EXT Jul 6 13:56:18 ich10 last message repeated 4 times Still the box does a panic when writing to the disk that has bad sectors on it. (I do newfs it between reboots). Again, not sure if this is a "well, dont use a bad disk", but here is the panic again in case it shows something useful. Unread portion of the kernel message buffer: ahcich2: Error while READ LOG EXT ahcich2: Error while READ LOG EXT g_vfs_done():ada2s1d[READ(offset=36418928640, length=16384)]error = 5 ahcich2: Error while READ LOG EXT ahcich2: Error while READ LOG EXT ahcich2: Error while READ LOG EXT panic: initiate_write_inodeblock_ufs2: already started cpuid = 6 Uptime: 5m55s ahcich2: Error while READ LOG EXT (ada2:ahcich2:0:0:0): Synchronize cache failed Physical memory: 3556 MB Dumping 220 MB: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0xb0014 fault code = supervisor read, page not present instruction pointer = 0x20:0xc047f14b stack pointer = 0x28:0xc6e69c08 frame pointer = 0x28:0xc6e69c20 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 = 12 (irq257: ahci0) trap number = 12 205 189 173 157 141 125 109 93 77 61 45 29 13 Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc086ca3e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc086ccd9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc0a87ebe in softdep_disk_io_initiation (bp=0xdb2bbf60) at /usr/src/sys/ufs/ffs/ffs_softdep.c:4056 #4 0xc0a8be2c in ffs_geom_strategy (bo=0xc803c2c0, bp=0xdb2bbf60) at buf.h:404 #5 0xc08e2019 in bufwrite (bp=0xdb2bbf60) at buf.h:397 #6 0xc0a8b55b in ffs_bufwrite (bp=0xdb2bbf60) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1893 #7 0xc08df1c8 in vfs_bio_awrite (bp=0xdb2bbf60) at buf.h:385 #8 0xc08e89bb in vop_stdfsync (ap=0xe7798c7c) at /usr/src/sys/kern/vfs_default.c:608 #9 0xc07f366c in devfs_fsync (ap=0xe7798c7c) at /usr/src/sys/fs/devfs/devfs_vnops.c:556 #10 0xc0b90095 in VOP_FSYNC_APV (vop=0xc0d1a580, a=0xe7798c7c) at vnode_if.c:1267 #11 0xc08f87a8 in sync_vnode (slp=0xc76a27f4, bo=0xe7798ce8, td=0xc78ad6c0) at vnode_if.h:549 #12 0xc08f8af3 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 #13 0xc0844418 in fork_exit (callout=0xc08f8880 , arg=0x0, frame=0xe7798d38) at /usr/src/sys/kern/kern_fork.c:842 #14 0xc0b67cb0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) Unless you would like me to test some other features of the driver, I will just RMA the drive tomorrow. ---Mike From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 21:25:01 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A53C810656A3; Mon, 6 Jul 2009 21:25:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4F84B8FC14; Mon, 6 Jul 2009 21:25:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.home (pooker.samsco.home [192.168.254.1]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n66LOvUH088882; Mon, 6 Jul 2009 15:24:57 -0600 (MDT) (envelope-from scottl@samsco.org) Date: Mon, 6 Jul 2009 15:24:57 -0600 (MDT) From: Scott Long To: Mike Tancsa In-Reply-To: <200907062118.n66LIGRg043316@lava.sentex.ca> Message-ID: <20090706152351.S26418@pooker.samsco.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Alexander Motin , FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 21:25:02 -0000 On Mon, 6 Jul 2009, Mike Tancsa wrote: > At 02:41 AM 7/5/2009, Alexander Motin wrote: >>> Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is 40000001 cs >>> 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 >> >> This is AHCI driver debugging. I've removed it in latest patch. In this >> case it means that drive signals some command error. > > > Hi, > > With the latest patch (cam-ata.20090704.patch), writing to the disk with > physical errors looks like this now > > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42003431424, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42196107264, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42388783104, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42581458944, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: g_vfs_done():ada2[READ(offset=42774134784, > length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > Jul 6 13:56:18 ich10 kernel: g_vfs_done():ada2[READ(offset=42966810624, > length=16384)]error = 5 > Jul 6 13:56:18 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > > Still the box does a panic when writing to the disk that has bad sectors on > it. (I do newfs it between reboots). Again, not sure if this is a "well, > dont use a bad disk", but here is the panic again in case it shows something > useful. > This is a 'don't use a bad disk' panic; FreeBSD UFS and VM simply can't handle errors on reads or writes. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 22:11:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E7B106564A; Mon, 6 Jul 2009 22:11:23 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (unknown [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id D51FF8FC19; Mon, 6 Jul 2009 22:11:22 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p3185-ipbf514funabasi.chiba.ocn.ne.jp [123.225.96.185]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n66MBAaH084587; Tue, 7 Jul 2009 07:11:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n66MB2La027282; Tue, 7 Jul 2009 07:11:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 07 Jul 2009 07:05:45 +0900 (JST) Message-Id: <20090707.070545.02771440.hrs@allbsd.org> To: freebsd-rc@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Tue_Jul__7_07_05_45_2009_685)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93.3, clamav-milter version 0.93.3 on gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (mail.allbsd.org [133.31.130.32]); Tue, 07 Jul 2009 07:11:21 +0900 (JST) Cc: freebsd-current@FreeBSD.org Subject: RFC: set_rcvar in rc.subr X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 22:11:24 -0000 ----Security_Multipart0(Tue_Jul__7_07_05_45_2009_685)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Jul__7_07_05_45_2009_646)--" Content-Transfer-Encoding: 7bit ----Next_Part(Tue_Jul__7_07_05_45_2009_646)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like to propose an expansion of set_rcvar() in rc.subr. The motivation and the change are the following. The current rc.d scripts depend on variables defined in /etc/defaults/rc.conf. However, it is unclear that which variables are used in a script and assigning a default value to a variable is scattered and inconsistent. Also, it is difficult to detect definition of obsolete variables in /etc/rc.conf and /etc/defaults/rc.conf. The proposed changes are: 1. Add a functionality to declare a rc.conf variable and its default value to set_rcvar(). The syntax is: set_rcvar The declared variables are set by load_rc_config(). Note that this behavior of set_rcvar() is backward compatible. For example, a script for routed(8) will be something like this: ---- name="routed" rcvar=`set_rcvar` set_rcvar ${name}_enable NO set_rcvar ${name}_flags "-q" \ "Flags for ${name}(8)." set_rcvar ${name}_program "/usr/sbin/routed" \ "Program name for ${name}(8)." load_rc_config $name run_rc_command "$1" ---- 2. Display the declared variables by "rc.d/foo rcvar" with the default value and description like this: % /etc/rc.d/routed rcvar # routed : network RIP and router discovery routing daemon # routed_enable="NO" # (default: "NO") routed_flags="-q" # - Flags for routed(8). # (default: "-q") routed_program="/sbin/routed" # - Program name for routed(8). # (default: "/usr/sbin/routed") It should be easier to understand the variables than the current /etc/defaults/rc.conf and always consistent. To do this, all of rc.d scripts have to have run_rc_command() while currently some scripts which always run have no $rcvar and run_rc_command(). Adding run_rc_command() becomes no problem and rather good for consistency, IMHO. Also, $desc is added for description of the script displayed in above example. Entries for each rc.d script in /etc/defaults/rc.conf can be removed, and the equivalent contents can be generated by the following command: # for F in `rcorder /etc/rc.d/*`; do $F rcvar; done 3. Add a way to obsolete a variable. This is done by adding set_rcvar_obsolete() function. set_rcvar_obsolete If is defined, do newvar=$oldvar and display a warning in load_rc_config(). This makes easier to detect an obsolete variable in an old rc.conf file. The attached patch is a working example. If there is no strong objection I want to convert all of the current rc.d scripts in this way. Note that this patch include a change not directly related to the above; handling $_override_command in run_rc_command() looks wrong to me. When ${name}_program is defined and $command is not the former is used as the command, and if $command is defined directly it is used by priority. Comments or objections? -- Hiroki ----Next_Part(Tue_Jul__7_07_05_45_2009_646)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rc_set_rcvar.diff" Index: rc.subr =================================================================== --- rc.subr (revision 195284) +++ rc.subr (working copy) @@ -72,38 +72,64 @@ # functions # --------- +# set_rcvar [var] [defval] [desc] # -# set_rcvar base_var -# Set the variable name enabling a specific service. -# FreeBSD uses ${service}_enable, while NetBSD uses -# just the name of the service. For example: -# FreeBSD: sendmail_enable="YES" -# NetBSD : sendmail="YES" -# $1 - if $name is not the base to work of off, specify -# a different one +# Echo or define a rc.conf(5) variable name. Global variable +# $rcvars is used. # +# If no argument is specified, echo "${name}_enable". +# +# If only a var is specified, echo "${var}_enable". +# +# If var and defval are specified, the ${var} is defined as +# rc.conf(5) variable and the default value is ${defvar}. An +# optional argument $desc can also be specified to add a +# description for that. +# set_rcvar() { - if [ -z "$1" ]; then - base_var=${name} - else - base_var="$1" - fi - - case ${OSTYPE} in - FreeBSD) - echo ${base_var}_enable + case $# in + 0) + echo ${name}_enable ;; - NetBSD) - echo ${base_var} + 1) + echo ${1}_enable ;; *) - echo 'XXX' + debug "rcvar_define: \$$1=$2 is added" \ + " as a rc.conf(5) variable." + + local _var + _var=$1 + rcvars="${rcvars# } $_var" + eval ${_var}_defval=\"$2\" + shift 2 + # encode multiple lines of _desc + for l in "$@"; do + eval ${_var}_desc=\"\${${_var}_desc#^^}^^$l\" + done + eval ${_var}_desc=\"\${${_var}_desc#^^}\" ;; esac } +# set_rcvar_obsolete oldvar [newvar] [msg] +# Define obsolete variable. +# Global variable $rcvars_obsolete is used. # +set_rcvar_obsolete() +{ + local _var + _var=$1 + debug "rcvar_obsolete: \$$1(old) -> \$$2(new) is defined" + + rcvars_obsolete="${rcvars_obsolete# } $1" + eval ${1}_newvar=\"$2\" + shift 2 + eval ${_var}_obsolete_msg=\"$*\" +} + +# # force_depend script # Force a service to start. Intended for use by services # to resolve dependency issues. It is assumed the caller @@ -401,6 +427,8 @@ # command_interpreter n If not empty, command is interpreted, so # call check_{pidfile,process}() appropriately. # +# desc n Description of script. +# # extra_commands n List of extra commands supported. # # pidfile n If set, use check_pidfile $pidfile $command, @@ -574,7 +602,7 @@ esac eval _override_command=\$${name}_program - command=${command:+${_override_command:-$command}} + command=${command:-${_override_command}} _keywords="start stop restart rcvar $extra_commands" rc_pid= @@ -778,14 +806,49 @@ ;; rcvar) - echo "# $name" - if [ -n "$rcvar" ]; then - if checkyesno ${rcvar}; then - echo "${rcvar}=YES" - else - echo "${rcvar}=NO" + echo -n "# $name" + if [ -n "$desc" ]; then + echo " : $desc" + else + echo "" + fi + echo "#" + # Get unique vars in $rcvar $rcvars + for _v in $rcvar $rcvars; do + case $v in + $_v\ *|\ *$_v|*\ $_v\ *) ;; + *) v="${v# } $_v" ;; + esac + done + + # Display variables. + for _v in $v; do + if [ -z "$_v" ]; then + continue fi - fi + + eval _desc=\$${_v}_desc + eval _defval=\$${_v}_defval + _h="-" + + eval echo \"$_v=\\\"\$$_v\\\"\" + # decode multiple lines of _desc + while [ -n "$_desc" ]; do + case $_desc in + *^^*) + echo "# $_h ${_desc%%^^*}" + _desc=${_desc#*^^} + _h=" " + ;; + *) + echo "# $_h ${_desc}" + break + ;; + esac + done + echo "# (default: \"$_defval\")" + done + echo "" ;; *) @@ -896,7 +959,8 @@ unset name command command_args command_interpreter \ extra_commands pidfile procname \ - rcvar required_dirs required_files required_vars + rcvar rcvars rcvars_obsolete required_dirs required_files \ + required_vars eval unset ${_arg}_cmd ${_arg}_precmd ${_arg}_postcmd case "$_file" in @@ -927,6 +991,7 @@ # load_rc_config() { + local _name _var _defval _v _msg _new _name=$1 if [ -z "$_name" ]; then err 3 'USAGE: load_rc_config name' @@ -953,6 +1018,36 @@ # Old variable names support # [ -n "$enable_quotas" ] && quota_enable="$enable_quotas" + + # Set defaults if defined. + for _var in $rcvar $rcvars; do + _defval=`eval echo "\\\$${_var}_defval"` + if [ -n "$_defval" ]; then + eval : \${$_var:=\$${_var}_defval} + fi + done + + # check obsolete rc.conf variables + for _var in $rcvars_obsolete; do + _v=`eval echo \\$$_var` + _msg=`eval echo \\$${_var}_obsolete_msg` + _new=`eval echo \\$${_var}_newvar` + case $_v in + "") + ;; + *) + if [ -z "$_new" ]; then + _msg="Ignored." + else + eval $_new=\"\$$_var\" + if [ -z "$_msg" ]; then + _msg="Use \$$_new instead." + fi + fi + warn "\$$_var is obsolete. $_msg" + ;; + esac + done } # Index: rc.d/routed =================================================================== --- rc.d/routed (revision 195284) +++ rc.d/routed (working copy) @@ -10,13 +10,17 @@ . /etc/rc.subr name="routed" +desc="network RIP and router discovery routing daemon" +rcvar=`set_rcvar` -# XXX - Executable may be in a different location. The $name variable -# is different from the variable in rc.conf(5) so the -# subroutines in rc.subr won't catch it. -# +set_rcvar ${name}_enable NO +set_rcvar ${name}_flags "-q" \ + "Flags for ${name}(8)." +set_rcvar ${name}_program "/sbin/routed" \ + "Program name for ${name}(8)." +set_rcvar_obsolete router_enable routed_enable +set_rcvar_obsolete router routed_program +set_rcvar_obsolete router_flags routed_flags + load_rc_config $name -rcvar="router_enable" -command="${router:-/sbin/${name}}" -eval ${name}_flags=\"${router_flags}\" run_rc_command "$1" ----Next_Part(Tue_Jul__7_07_05_45_2009_646)---- ----Security_Multipart0(Tue_Jul__7_07_05_45_2009_685)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpSdTkACgkQTyzT2CeTzy3ZeACfTdSNAkynvEEwSXu9Y3/voeUb gdgAoJcBSN5Pljxqo0y/SCK2AkQjUlw0 =wRkO -----END PGP SIGNATURE----- ----Security_Multipart0(Tue_Jul__7_07_05_45_2009_685)---- From owner-freebsd-current@FreeBSD.ORG Mon Jul 6 23:36:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAB4B106564A for ; Mon, 6 Jul 2009 23:36:18 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id A01208FC0A for ; Mon, 6 Jul 2009 23:36:18 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n66NaE1e022233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Jul 2009 16:36:14 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 293AA1CC09; Mon, 6 Jul 2009 16:36:14 -0700 (PDT) To: Aragon Gouveia In-reply-to: Your message of "Mon, 06 Jul 2009 15:04:51 +0200." <4A51F673.5010007@phat.za.net> Date: Mon, 06 Jul 2009 16:36:14 -0700 From: "Kevin Oberman" Message-Id: <20090706233614.293AA1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-07-06_10:2009-07-03, 2009-07-06, 2009-07-06 signatures=0 Cc: Rene Schickbauer , Patrick Lamaiziere , freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:36:19 -0000 > Date: Mon, 06 Jul 2009 15:04:51 +0200 > From: Aragon Gouveia > Sender: owner-freebsd-current@freebsd.org > > Hi, > > Patrick Lamaiziere wrote: > >>> I would like an option to set the minimum allowed CPU speed, instead > >>> the use of the sysctl debug.cpufreq.lowest. > >> This is so that powerd doesn't take so long to spin up power in the > >> adaptive modes? > > > > If the speed is too low, my machine is not very interactive here > > (running KDE and all...). > > Have you tried disabling throttling (P4TCC)? Add these to your loader.conf: > > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > When you reboot you'll notice a lot of frequencies missing from > dev.cpu.0.freq_levels. The remaining ones are those affected by EIST only. > > The difference? EIST controls CPU frequency *and* voltage. Throttling > controls only frequency, and is much less effective at saving power > (while being very effective at slowing your system down). If you > disable throttling and use just EIST, your system will be much more > responsive at a very small power cost. It's really even worse than this. Throttling/TCC don't actually change clock speed. Thy simply "skip" N of every 8 clock cycles. The result is that power and performance under load are reduced by exactly the same amount and the effect of throttling drops with CPU load and is zero on an idle system. EST and C3 (or higher when available) are a much bigger wins. I see little value in the use of TCC or throttling. > The power cost above can be made up by setting C-state to C2 or even C3. > > If you're running FreeBSD 8, another way of saving a lot of power on a > notebook is to power down USB devices. Most notebooks' webcams and > fingerprint readers are internally connected to the USB bus. Note that even having the USB drivers loaded runs up battery use and blocks C3 even if no devices are connected to the USB. This is fixed in current by the new USB stack, but in v7, I build the kernel on my laptop without USB and load as needed. > > Alexander Motin did a lot of testing a while ago. Take a look at this > thread: > > http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006436.html -- 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 owner-freebsd-current@FreeBSD.ORG Tue Jul 7 00:51:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D6A1065679; Tue, 7 Jul 2009 00:51:12 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id B15508FC14; Tue, 7 Jul 2009 00:51:12 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n670X2Ns080408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 20:33:11 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-stable , freebsd-current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zDff1WUjPA5wALxM3eGB" Organization: U. Buffalo CSE Department Date: Mon, 06 Jul 2009 20:33:02 -0400 Message-Id: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1029; Body=0 Fuz1=0 Fuz2=0 Cc: Subject: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 00:51:13 -0000 --=-zDff1WUjPA5wALxM3eGB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The first public test build of the FreeBSD 8.0-RELEASE test cycle is now available, 8.0-BETA1. Through the next week or so more information about the release will be posted but here is the current target schedule for the other 'major events': BETA2: July 13, 2009 BETA3: July 20, 2009 RC1: July 27, 2009 RC2: August 17, 2009 RELEASE:August 31, 2009 People with the resources to do so (test machines...) are encouraged to give 8.0-BETA1 a try. At this point it is not quite ready for production systems but mostly because there is still some ongoing work in a few areas that may cause some changes in things like ABI/API. Debugging support (WITNESS, malloc debugging, etc.) are also still turned on and those tend to cause a performance hit. As far as we know there are no known issues that would cause data corruption or anything like that, just the issues with performance and potential for changes caused by ongoing work. If you find problems they can be reported through the normal Gnats based PR system or posted to the mailing lists. Note that for BETA1 no packages were included with any of the images. The amd64 and i386 architectures include a file named: 8.0-BETA1--memstick.img If you copy that to a USB memory stick newer machines should be able to boot from it and use it to install from. Note that you need to overwrite the contents of the memory stick completely, not copy it into an existing filesystem on the memory stick. Exactly how you do that depends on your machine but just to give you an example this works on the machine I tested it with: dd if=3D8.0-BETA1-amd64-memstick.img of=3D/dev/da0 bs=3D10240 conv=3Dsync Be careful if you have SCSI drives, more USB disks than just the memory stick, etc - make sure /dev/da0 (or whatever you use) is the memory stick. Using this image for livefs based rescue mode is known to not work, that is one of the things still being worked on. FreeBSD Update was not ready for updates to 8.0 at the point this message was sent but it is also being worked on. A separate message will be posted when it's ready. Checksums for the images: MD5 (8.0-BETA1-amd64-bootonly.iso) =3D e7cc0b3b022775f6be058044f171e3d2 MD5 (8.0-BETA1-amd64-disc1.iso) =3D ad259bc0d57e1a7ae1afdc04bbb87cfd MD5 (8.0-BETA1-amd64-dvd1.iso) =3D f240e48be3db47ed338bb157244b874d MD5 (8.0-BETA1-amd64-livefs.iso) =3D 2a0f06d61d2722efe68cf8c6a14de0c6 MD5 (8.0-BETA1-amd64-memstick.img) =3D 10bc42a388c213497f03aadad30e0486 MD5 (8.0-BETA1-i386-bootonly.iso) =3D cadcdb82377705061a0d464569ecfef7 MD5 (8.0-BETA1-i386-disc1.iso) =3D 9e19a4edcc3b2d7f594cbcdc7fcabace MD5 (8.0-BETA1-i386-dvd1.iso) =3D 98a2f5e05391eb4ab2b421443296cd7b MD5 (8.0-BETA1-i386-livefs.iso) =3D c1d35cd8a15434b2af0bc1f27ddb48a1 MD5 (8.0-BETA1-i386-memstick.img) =3D c6a0fbe8e31b2987b5da47c52705fa8e MD5 (8.0-BETA1-ia64-bootonly.iso) =3D d40385e657477566100ae66485a98bb3 MD5 (8.0-BETA1-ia64-disc1.iso) =3D 216b4e54536bb41c5a9543ce88f288bc MD5 (8.0-BETA1-ia64-disc2.iso) =3D 790eb3e163aee02c7c6dddcfa54cc167 MD5 (8.0-BETA1-ia64-disc3.iso) =3D b59510898c2ce1cfe594620cc2f9de97 MD5 (8.0-BETA1-ia64-dvd1.iso) =3D ce7d5abec2aaed9028b82c66445e2734 MD5 (8.0-BETA1-ia64-livefs.iso) =3D 5021774a2349d960e859082065c1bc86 MD5 (8.0-BETA1-pc98-bootonly.iso) =3D 9a421562167c5d6806784151c26694fe MD5 (8.0-BETA1-pc98-disc1.iso) =3D b5ca7555697677eb23057fffe2c47062 MD5 (8.0-BETA1-pc98-livefs.iso) =3D 0c8a405c394651ea61dee34d9637b47e MD5 (8.0-BETA1-powerpc-bootonly.iso) =3D e982f204c4024c544f88753b400007a5 MD5 (8.0-BETA1-powerpc-disc1.iso) =3D 0e59688100a8288e2bee87c4d0f9b0ee MD5 (8.0-BETA1-powerpc-disc2.iso) =3D 1426a523d1b2480c4f546422934d1cc4 MD5 (8.0-BETA1-powerpc-disc3.iso) =3D d6b7505441c756be547b4587331af6b9 MD5 (8.0-BETA1-powerpc-livefs.iso) =3D 2dbf7c3543fcd35c834fd19f64f240cf MD5 (8.0-BETA1-sparc64-bootonly.iso) =3D 24004c2014edcbafb68f09399db1b74d MD5 (8.0-BETA1-sparc64-disc1.iso) =3D 96e7a0b14581fac7ab845a4e9916d393 MD5 (8.0-BETA1-sparc64-dvd1.iso) =3D efcc5a4923f335cd483d76395333b639 SHA256 (8.0-BETA1-amd64-bootonly.iso) =3D d49e8651f71c1a4a4d2ad9b4e391e7dfe= a2fec159a716876c4c0a547b346d34d SHA256 (8.0-BETA1-amd64-disc1.iso) =3D 692eb89c0ba07dc161ad2ea366516a2210c5= d5e5cf90a48ed6316e67b7ebb5e4 SHA256 (8.0-BETA1-amd64-dvd1.iso) =3D eaf4a18c269589af516f6c96af164f918345a= 34e2fb1e5273762479a7779c4cd SHA256 (8.0-BETA1-amd64-livefs.iso) =3D b9e68d7944707f73f0894e0f610ff73ff5c= 5350e9dbc15d980a4d9413d61daf8 SHA256 (8.0-BETA1-amd64-memstick.img) =3D c3ece618be54d4c51400945d8922f6724= 547453a133c32450ac2ebbacaabaa65 SHA256 (8.0-BETA1-i386-bootonly.iso) =3D d82918557e595fdb76ae8d4158e0f5738a= 3879985d6c5109b944d382c9f767af SHA256 (8.0-BETA1-i386-disc1.iso) =3D 398a93e851088391fc1cca6c3ff50494afc4e= 5471791cff12204ef8673b81472 SHA256 (8.0-BETA1-i386-dvd1.iso) =3D b61e14733e498fe83e482010b036f3aabb8d7d= ace2ed5fb8b8dbe371141a2caa SHA256 (8.0-BETA1-i386-livefs.iso) =3D 6d47e830bea1a96d851490d41b4a47248a03= ec2a6c39df534ca407aba2daf58a SHA256 (8.0-BETA1-i386-memstick.img) =3D b7561c27ea789447e368a1e2398249282a= e46e8752a82bbb3614cb5db3d606e7 SHA256 (8.0-BETA1-ia64-bootonly.iso) =3D 6e9b9cc92a82b062cc5d9d51da7652a790= 97894b16e8c2cf8bcdb7b51c3aa576 SHA256 (8.0-BETA1-ia64-disc1.iso) =3D 52ca59f0129cda5651bf0aad3daa57a07a719= 580c3ece28be63178e40e6f0613 SHA256 (8.0-BETA1-ia64-disc2.iso) =3D f6e1bded3aec557e19ef0249b9c3b17ba3c5e= 0aca99d98ae697e6107c9bb3061 SHA256 (8.0-BETA1-ia64-disc3.iso) =3D b8b8e5ce0cca5eb3dd0dc8ea05b7de399cb93= 7ecc4b960eb092e621cda22bbd5 SHA256 (8.0-BETA1-ia64-dvd1.iso) =3D 29d5852bef2d09c73075242ea2e2d35072a51b= 30b624d5229ed8aec6737cfbc5 SHA256 (8.0-BETA1-ia64-livefs.iso) =3D 0a92eb0f09dfd4f4ab0694fd94482e4682ed= ed3425186737bd0e2440e957dd3b SHA256 (8.0-BETA1-pc98-bootonly.iso) =3D 5d77d1fb6a5d7e819b0d90d1848f7d029d= 64ce456ca550e3049d63eb5fc8891a SHA256 (8.0-BETA1-pc98-disc1.iso) =3D 5e11719fd24d8f8a9fd0fd4ce07c72509c197= e48b1e45060d931b0f8bcad9335 SHA256 (8.0-BETA1-pc98-livefs.iso) =3D 271056add63d5e82f85a482cfd0efcfaaacb= 1b5941337fc459782e97577f3e0e SHA256 (8.0-BETA1-powerpc-bootonly.iso) =3D 60c984e47d8e71eb87ae382cb1bc19a= 0abd982095b5906dafb539e799ad0a51e SHA256 (8.0-BETA1-powerpc-disc1.iso) =3D 647b51471e71a8de9ab4a0c42fa94d869f= ae33a2f5f3a0aaa07592bb9854a49f SHA256 (8.0-BETA1-powerpc-disc2.iso) =3D 9a46aecda07f6b6fa040bf7c852c3a99eb= 27e8db529c8f26974d5a9a2ecf0b8d SHA256 (8.0-BETA1-powerpc-disc3.iso) =3D efe792cb535ea2a6ee821cdcd5fd1e5306= e116e32b57e2f1e6d4309f672830ab SHA256 (8.0-BETA1-powerpc-livefs.iso) =3D 1b8e5c401bf5b14c0a14d91b21895ed22= 73287158e59a158313bcec43aead8ff SHA256 (8.0-BETA1-sparc64-bootonly.iso) =3D 2775ceec218f5fef0bc2d17ea80e149= 2f423307f27cec38df352b1e9ee6f96a4 SHA256 (8.0-BETA1-sparc64-disc1.iso) =3D 9eac5684c3c650e2cac01343c7933931ae= f0227bdb6e9a4931402ad0dd41b9c8 SHA256 (8.0-BETA1-sparc64-dvd1.iso) =3D 207268ec113811213d73b571c2322585c26= cf6beae88e27e5680e77c93e249b2 --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-zDff1WUjPA5wALxM3eGB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpSl7AACgkQ/G14VSmup/aqfQCePQYepsJ8Lr6x0SgzG2Mv/EVx EMYAn307W6Ad2Ib7oM52utK5RxRWsV3h =PyZW -----END PGP SIGNATURE----- --=-zDff1WUjPA5wALxM3eGB-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 02:15:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F5010656A3 for ; Tue, 7 Jul 2009 02:15:44 +0000 (UTC) (envelope-from erich@apsara.com.sg) Received: from babylon.webvis.net (babylon.webvis.net [202.157.163.226]) by mx1.freebsd.org (Postfix) with ESMTP id 192CF8FC19 for ; Tue, 7 Jul 2009 02:15:41 +0000 (UTC) (envelope-from erich@apsara.com.sg) Received: from [10.0.1.240] ([119.73.191.194]) by apsara.com.sg ; Tue, 07 Jul 2009 08:15:38 +0800 SGT From: Erich Dollansky Organization: apsara green technology pte ltd To: freebsd-current@freebsd.org Date: Tue, 7 Jul 2009 08:15:32 +0800 User-Agent: KMail/1.9.10 References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> In-Reply-To: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907070815.34876.erich@apsara.com.sg> X-Mailman-Approved-At: Tue, 07 Jul 2009 02:34:49 +0000 Cc: Rene Schickbauer Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 02:16:00 -0000 Hi, On 06 July 2009 pm 15:22:58 Rene Schickbauer wrote: > > Would it also make sense to have powerd run an (optional) user > configureable script on ac state change? I'm thinking about > things like dimming TFT backlight, on EEE PC turning of the > webcam and so on. > I did some work on powerd to regulate the speed better but never finished it. Let me share my experience. Yes, it makes sense that powerd is enabled to run external programs triggered by events powerd has to monitor. I would not limit it to AC/DC changes. powerd could also run external programs when falling below a certain speed and coming back above a certain speed again. This would allow also to dim the LCD when less power is used because notbody is using the screen. It might will not make sense for most uses but for some. powerd's main idea is to save energy. Allowing a second program to parse through a file is not what will save energy. Erich From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 03:58:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D73E3106564A for ; Tue, 7 Jul 2009 03:58:43 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 74CC98FC15 for ; Tue, 7 Jul 2009 03:58:43 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from fuzz.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 370313A6A5; Tue, 7 Jul 2009 05:58:41 +0200 (SAST) Message-ID: <4A52C7E3.4000304@phat.za.net> Date: Tue, 07 Jul 2009 05:58:27 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.22 (X11/20090628) MIME-Version: 1.0 To: Erich Dollansky References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <200907070815.34876.erich@apsara.com.sg> In-Reply-To: <200907070815.34876.erich@apsara.com.sg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Rene Schickbauer Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 03:58:44 -0000 Erich Dollansky wrote: > Yes, it makes sense that powerd is enabled to run external > programs triggered by events powerd has to monitor. > > I would not limit it to AC/DC changes. powerd could also run > external programs when falling below a certain speed and coming > back above a certain speed again. > > This would allow also to dim the LCD when less power is used > because notbody is using the screen. It might will not make sense > for most uses but for some. Can you think of a better example? LCD dimming can already by handled by Xorg's DPMS. And LCD dimming and CPU usage are not directly related. If I walk away from a port compiling, I don't want powerd to keep my LCD on because the CPU is at 100%. > powerd's main idea is to save energy. Allowing a second program to > parse through a file is not what will save energy. Neither will constant spawning of new processes. JMHO. Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 05:54:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50D6F106566C for ; Tue, 7 Jul 2009 05:54:52 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0CBAE8FC1D for ; Tue, 7 Jul 2009 05:54:51 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so6595017yxe.3 for ; Mon, 06 Jul 2009 22:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Y/wzcVMP8pdiXba4driWkQcal6K81kCZ2d+zgNZKYxo=; b=uPYBS0XbBNYRcyzwAhatSWT+46ZoPtI4lioXTAdisASSaXN+sRVjW1U9sXYLhn4n+I irz5vfjbwuLdsfIyOKmc40BCYkj9v3TixzEu4EbPcokQQMejfWbosvBd9Wmm0BN66Gz9 jacDwSNpqyrUnsl3PeYv4I8ARC8bq/AXIANiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=J14lW1XbMQ24rD+p5/NUFVLFID6TKbfnBpENNHW2JYHPgtjY9vUFV9CacDCMNRH1A7 K3SeeNHIYUd/WpWSDBbVC13IJE5mThqqw46qSOnjY0tXx9cuDohV76Gb/OuTtzeuE4WI gvD639ONF87ISqczi6fNWVeI2EVr3O0Rh1j9g= MIME-Version: 1.0 Received: by 10.100.152.12 with SMTP id z12mr9937677and.96.1246946091072; Mon, 06 Jul 2009 22:54:51 -0700 (PDT) Date: Tue, 7 Jul 2009 02:54:51 -0300 Message-ID: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 05:54:52 -0000 Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to boot "with ACPI disabled" or "Safe Mode": Fatal trap 9: general protection fault while in kernel mode cpuid = 0; acpic id = 00 instruction pointer = 0x70:0xbfe4 stack pointer = 0x28:0xfa4 frame pointer = 0x28:0xfd4 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 100000 ] Stopped at 0xbfe4: *** error reading from address bfe4 *** db> bt Tracing pid 0 tid 100000 td 0x0da9b50 uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 db> more info at http://forums.freebsd.org/showthread.php?t=4988 verbose boot: http://pastebin.com/f604c1399 Willing to do everything I can to solve it. Best regards Gonzalo From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 06:06:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 586DA1065670 for ; Tue, 7 Jul 2009 06:06:29 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.freebsd.org (Postfix) with ESMTP id 12D168FC1A for ; Tue, 7 Jul 2009 06:06:28 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2075873and.13 for ; Mon, 06 Jul 2009 23:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=kS34ZqNKIqShvV1MIYyturznZM3JsDN1lS+ka5kXYqM=; b=PM3wmjH35Yvi0T2OHOw9fMCAtwQ3k2lGAFk5Zf3gB2Eu4Ea72+KD76Fkvrd/47pe5Q arMd8F/42Xi+tUhnahZCdQFyPC4twc2HymWyn/oQQYY6BVK+SnA6hG6q+GSaT/7QcgaG i3tzZyHg8CspoVijteCtNFq317yJRPvPfNu0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aUeh/xkFhGeHiWdBf7+8sLxuauf+j7nP9ThWtcJTbKzGgyXbQ1eir9kXPqvfwzK017 vTS0XTSgYmdULSbvoCxiyC1KERG30hRaLcoc2Om9MOcFjrOIxXRWcfSyg0e2R09qj1Ei Xg5W70IqjWnUvkWKeskkkp+O7Wl9XRnI4Kvik= MIME-Version: 1.0 Received: by 10.100.12.17 with SMTP id 17mr10046585anl.2.1246945357640; Mon, 06 Jul 2009 22:42:37 -0700 (PDT) Date: Tue, 7 Jul 2009 02:42:37 -0300 Message-ID: <19e9a5dc0907062242qe6ec24br677c79996623c3e5@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: LOR on umount on -BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 06:06:29 -0000 LOR on -CURRENT and -BETA1. plug pen-drive: Jul 7 01:45:42 gargoyle root: Unknown USB device: vendor 0x08ec product 0x0008 bus uhub3 Jul 7 01:45:42 gargoyle kernel: ugen6.2: at usbus6 Jul 7 01:45:42 gargoyle kernel: umass0: on usbus6 Jul 7 01:45:42 gargoyle kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Jul 7 01:45:43 gargoyle kernel: umass0:1:0:-1: Attached to scbus1 Jul 7 01:45:43 gargoyle kernel: (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed Jul 7 01:45:45 gargoyle kernel: Retrying Command (per Sense Data) Jul 7 01:45:45 gargoyle kernel: (probe0:umass-sim0:0:0:0): Retrying Command Jul 7 01:45:45 gargoyle kernel: pass0 at umass-sim0 bus 0 target 0 lun 0 Jul 7 01:45:45 gargoyle kernel: pass0: Removable Direct Access SCSI-0 device Jul 7 01:45:45 gargoyle kernel: pass0: 40.000MB/s transfers Jul 7 01:45:45 gargoyle kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Jul 7 01:45:45 gargoyle kernel: da0: Removable Direct Access SCSI-0 device Jul 7 01:45:45 gargoyle kernel: da0: 40.000MB/s transfers Jul 7 01:45:45 gargoyle kernel: da0: 490MB (1003520 512 byte sectors: 64H 32S/T 490C) Jul 7 01:45:45 gargoyle kernel: GEOM: new disk da0 Jul 7 01:45:46 gargoyle kernel: GEOM: da0: partition 1 does not start on a track boundary. Jul 7 01:45:46 gargoyle kernel: GEOM: da0: partition 1 does not end on a track boundary. # mount_msdosfs /dev/da0s1 pen/, write and then # umount pen/: Jul 7 01:56:45 gargoyle kernel: lock order reversal: Jul 7 01:56:45 gargoyle kernel: 1st 0xc4e63bdc ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1199 Jul 7 01:56:45 gargoyle kernel: 2nd 0xc4e63ce8 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:944 Jul 7 01:56:45 gargoyle kernel: KDB: stack backtrace: Jul 7 01:56:45 gargoyle kernel: db_trace_self_wrapper(c0c5b564,e6da0a48,c08b5b35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 7 01:56:45 gargoyle kernel: kdb_backtrace(c08a68db,c0c5e3f9,c4530430,c4530360,e6da0aa4,...) at kdb_backtrace+0x29 Jul 7 01:56:45 gargoyle kernel: _witness_debugger(c0c5e3f9,c4e63ce8,c0c4d3c5,c4530360,c0c4dba9,...) at _witness_debugger+0x25 Jul 7 01:56:45 gargoyle kernel: witness_checkorder(c4e63ce8,9,c0c4dba9,3b0,c4e63d04,...) at witness_checkorder+0x839 Jul 7 01:56:45 gargoyle kernel: __lockmgr_args(c4e63ce8,80400,c4e63d04,0,0,...) at __lockmgr_args+0x7a7 Jul 7 01:56:45 gargoyle kernel: vop_stdlock(e6da0bac,c0ee9a48,c4afc9a4,80400,c4e63c90,...) at vop_stdlock+0x62 Jul 7 01:56:45 gargoyle kernel: VOP_LOCK1_APV(c0d38d00,e6da0bac,e6da0bcc,c0d75c00,c4e63c90,...) at VOP_LOCK1_APV+0xb5 Jul 7 01:56:45 gargoyle kernel: _vn_lock(c4e63c90,80400,c0c4dba9,3b0,c4add284,...) at _vn_lock+0x5e Jul 7 01:56:45 gargoyle kernel: msdosfs_sync(c4add284,1,c0c64e9d,4f4,80,...) at msdosfs_sync+0x29c Jul 7 01:56:45 gargoyle kernel: dounmount(c4add284,8000000,c4afc900,479,2,...) at dounmount+0x44e Jul 7 01:56:45 gargoyle kernel: unmount(c4afc900,e6da0cf8,8,c4afc900,c0d3c288,...) at unmount+0x30f Jul 7 01:56:45 gargoyle kernel: syscall(e6da0d38) at syscall+0x2a3 Jul 7 01:56:45 gargoyle kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 7 01:56:45 gargoyle kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d91ff, esp = 0xbfbfe52c, ebp = 0xbfbfe5f8 --- bervose boot: http://pastebin.com/f604c1399 some more info can be found at http://forums.freebsd.org/showthread.php?t=5025 Willing to try patches or solutions at your request. Best Regards. Gonzalo From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 06:10:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7E10106564A for ; Tue, 7 Jul 2009 06:10:02 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 75B3E8FC08 for ; Tue, 7 Jul 2009 06:10:02 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so6603958yxe.3 for ; Mon, 06 Jul 2009 23:10:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=+aTNvCxaZ3u8W7vX4DdqZIFxH+IqZyfEv2piHWPdv/w=; b=YRCwK+nxItiAYwovfH+MQ2PwwxjjzI15LEL2jN1yPDUOt5K6zveEo6hVhpfIO9iCjQ 8cIv2qFDU72H6n1h0b71yunu0+3kGHRKRLFdVEG4UDH0fm3KrAiD1qsvSNTWzXRDHusv dlpGsLHbdBebFHdZBfZYOeIrrXDd3qvBG9K0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aqGeCb8bJW6jSjEtCZEjhdLSbriVtNoSXAG8sFf5n/QgHz9RGXED1ALPBvHBqslsO5 ZVxqpVI76BSVuBKErpfkirAbUOv/M3vusZSRSb3cp+8yezvJqw1xVMkvSDu5a9OC44Hc f06qrNKFLjhd3iQsBE1g92pVICUrO9t9D3Pyo= MIME-Version: 1.0 Received: by 10.100.195.15 with SMTP id s15mr9992283anf.18.1246947001539; Mon, 06 Jul 2009 23:10:01 -0700 (PDT) Date: Tue, 7 Jul 2009 03:10:01 -0300 Message-ID: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> From: Gonzalo Nemmi To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 06:10:03 -0000 log in acpiconf -s 3 suspend works opened the lid and the screen doesn't come back (backlight never gets back) hard reset login again and checked /var/log/messages .. this is what I found: Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 (disconnected) Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 (disconnected) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: on usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 any hints on how to further debug or redirect this mail to the right list will be greatly appreciated. more info can be found in here: http://forums.freebsd.org/showthread.php?t=3886 Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 08:23:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9441065672 for ; Tue, 7 Jul 2009 08:23:58 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 678AD8FC0C for ; Tue, 7 Jul 2009 08:23:58 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz21 with SMTP id 21so891826bwz.43 for ; Tue, 07 Jul 2009 01:23:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dy9+d1KDgNqGYIl0LzHWbVBmSJNqiuzTlaSLxQMQE08=; b=MP2uE3mah9zMSwZW1VCSfATjvmy2zE9oIKN7AS1p2VKNlu0+Rc+NLUBlHrmvvXG95q +qaJ+EOXNTUDsGmHdCOrEq/BaVR21BLyFDeipG5f+G5INZ0lY3VEmAwXzvqT0Rhk7DgQ UnXsyuWOKCCl26P6NlZ+L2YP+On8vCV3pygCE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RQtQR4IOCO+mk1MGVi1HGEurCDST0t8T9taM9OO3Gea65UypHso+S57Q+vQZaRooyU foYqcbWRVKzGXoGeftPXRQB3M5QQdJW2NClLxm81PDVes0QW4o/0NUk7dwk26FpYheFG qdLl/PwznNzSFMgd9aAprq9wqcs2zazX8Ch6k= MIME-Version: 1.0 Received: by 10.204.118.134 with SMTP id v6mr5565205bkq.31.1246955037388; Tue, 07 Jul 2009 01:23:57 -0700 (PDT) In-Reply-To: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> Date: Tue, 7 Jul 2009 08:23:57 +0000 Message-ID: <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> From: "Paul B. Mahol" To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 08:23:59 -0000 On 7/7/09, Gonzalo Nemmi wrote: > log in > acpiconf -s 3 > suspend works > opened the lid and the screen doesn't come back (backlight never gets back) > hard reset > login again and checked /var/log/messages .. this is what I found: > > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > (disconnected) > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > (disconnected) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, > val 32768) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val > 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, > val 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, > val 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, > val 0) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, > val 0xffffffff) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, > val 0) > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, > val 18) > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init failed > Jul 7 00:33:18 gargoyle kernel: bge0: initialization failure > Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. > Jul 7 00:33:18 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > Jul 7 00:33:18 gargoyle kernel: fwohci0: Initiate bus reset > Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > Jul 7 00:33:18 gargoyle kernel: fwohci0: fwohci_intr_core: > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM > irm(0) (me) > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept 00:01:03) > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > Jul 7 00:33:18 gargoyle kernel: ums0: class 0/0, rev 2.00/0.10, addr 2> on usbus3 > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] coordinates ID=1 > Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 00:33:18 > Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > > any hints on how to further debug or redirect this mail to the right list > will be greatly appreciated. > > more info can be found in here: > http://forums.freebsd.org/showthread.php?t=3886 > > Best Regards > Gonzalo Nemmi i386 resume doesn't work with SMP kernel and SMP CPU. On amd64 make sure that you have right file loaded in kernel: for example i915.ko for intel cards. -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 09:16:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 195AF1065670 for ; Tue, 7 Jul 2009 09:16:35 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F3E68FC1A for ; Tue, 7 Jul 2009 09:16:34 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8C64819910F; Tue, 7 Jul 2009 11:16:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7F138199103; Tue, 7 Jul 2009 11:16:25 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5D3DF1990FC; Tue, 7 Jul 2009 11:16:25 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009070711162414-52608 ; Tue, 7 Jul 2009 11:16:24 +0200 Received: by wep4035 (sSMTP sendmail emulation); Tue, 7 Jul 2009 11:16:24 +0200 Date: Tue, 7 Jul 2009 11:16:24 +0200 From: Alexey Shuvaev To: Mike Tancsa Message-ID: <20090707091624.GA7770@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: Mike Tancsa , freebsd-current@freebsd.org References: <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> Mime-Version: 1.0 In-Reply-To: <200907062118.n66LIGRg043316@lava.sentex.ca> User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 07/07/2009 11:16:24 AM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 07/07/2009 11:16:25 AM, Serialize complete at 07/07/2009 11:16:25 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 09:16:35 -0000 On Mon, Jul 06, 2009 at 05:20:45PM -0400, Mike Tancsa wrote: > At 02:41 AM 7/5/2009, Alexander Motin wrote: > >>Jul 4 20:25:57 ich10 kernel: ahcich2: ahci_ch_intr ERROR is > >>40000001 cs 00000004 ss 00000000 rs 00000004 tfd 451 serr 00000000 > > > >This is AHCI driver debugging. I've removed it in latest patch. In > >this case it means that drive signals some command error. > > > Hi, > > With the latest patch (cam-ata.20090704.patch), writing to the disk > with physical errors looks like this now > > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42003431424, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42196107264, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42388783104, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42581458944, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:17 ich10 last message repeated 4 times > Jul 6 13:56:17 ich10 kernel: > g_vfs_done():ada2[READ(offset=42774134784, length=16384)]error = 5 > Jul 6 13:56:17 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > Jul 6 13:56:18 ich10 kernel: > g_vfs_done():ada2[READ(offset=42966810624, length=16384)]error = 5 > Jul 6 13:56:18 ich10 kernel: ahcich2: Error while READ LOG EXT > Jul 6 13:56:18 ich10 last message repeated 4 times > > Still the box does a panic when writing to the disk that has bad > sectors on it. (I do newfs it between reboots). Again, not sure if > this is a "well, dont use a bad disk", but here is the panic again in > case it shows something useful. > > > Unread portion of the kernel message buffer: > ahcich2: Error while READ LOG EXT > ahcich2: Error while READ LOG EXT > g_vfs_done():ada2s1d[READ(offset=36418928640, length=16384)]error = 5 > ahcich2: Error while READ LOG EXT > ahcich2: Error while READ LOG EXT > ahcich2: Error while READ LOG EXT > panic: initiate_write_inodeblock_ufs2: already started > cpuid = 6 > Uptime: 5m55s > ahcich2: Error while READ LOG EXT > (ada2:ahcich2:0:0:0): Synchronize cache failed > Physical memory: 3556 MB > Dumping 220 MB: > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0xb0014 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc047f14b > stack pointer = 0x28:0xc6e69c08 > frame pointer = 0x28:0xc6e69c20 > 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 = 12 (irq257: ahci0) > trap number = 12 > 205 189 173 157 141 125 109 93 77 61 45 29 13 > > Reading symbols from /boot/kernel/ahci.ko...Reading symbols from > /boot/kernel/ahci.ko.symbols...done. > done. > Loaded symbols for /boot/kernel/ahci.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:246 > #1 0xc086ca3e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xc086ccd9 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xc0a87ebe in softdep_disk_io_initiation (bp=0xdb2bbf60) > at /usr/src/sys/ufs/ffs/ffs_softdep.c:4056 > #4 0xc0a8be2c in ffs_geom_strategy (bo=0xc803c2c0, bp=0xdb2bbf60) > at buf.h:404 > #5 0xc08e2019 in bufwrite (bp=0xdb2bbf60) at buf.h:397 > #6 0xc0a8b55b in ffs_bufwrite (bp=0xdb2bbf60) > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1893 > #7 0xc08df1c8 in vfs_bio_awrite (bp=0xdb2bbf60) at buf.h:385 > #8 0xc08e89bb in vop_stdfsync (ap=0xe7798c7c) > at /usr/src/sys/kern/vfs_default.c:608 > #9 0xc07f366c in devfs_fsync (ap=0xe7798c7c) > at /usr/src/sys/fs/devfs/devfs_vnops.c:556 > #10 0xc0b90095 in VOP_FSYNC_APV (vop=0xc0d1a580, a=0xe7798c7c) > at vnode_if.c:1267 > #11 0xc08f87a8 in sync_vnode (slp=0xc76a27f4, bo=0xe7798ce8, td=0xc78ad6c0) > at vnode_if.h:549 > #12 0xc08f8af3 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1799 > #13 0xc0844418 in fork_exit (callout=0xc08f8880 , arg=0x0, > frame=0xe7798d38) at /usr/src/sys/kern/kern_fork.c:842 > #14 0xc0b67cb0 in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:270 > (kgdb) > > > Unless you would like me to test some other features of the driver, I > will just RMA the drive tomorrow. > It seems you are doing newfs and then mounting it. Why? If you want to remove the data do something like dd if=/dev/zero of=/dev/ada2 bs=1m or dd if=/dev/random of=/dev/ada2 bs=1m You could also try smaller block sizes (bs argument) near the bad blocks. Just 0.02$, Alexey. From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 09:48:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0117A106568A; Tue, 7 Jul 2009 09:48:14 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id B39228FC12; Tue, 7 Jul 2009 09:48:13 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MO7HW-0003BM-2r; Tue, 07 Jul 2009 10:48:12 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MO7HV-000119-Dv; Tue, 07 Jul 2009 10:48:09 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n679m8t2002935; Tue, 7 Jul 2009 10:48:08 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n679m8vX002934; Tue, 7 Jul 2009 10:48:08 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 7 Jul 2009 10:48:08 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Cc: Subject: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 09:48:14 -0000 this is FreeBSD 8.0-current 200906 snapshot on ia64. Updated src this morning, following the standard procedure, on make -j6 buildworld the process stops at: ===> gnu/usr.bin/cc/cc1 (all) cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-pa rser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbac kend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/o bj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/ob j/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy ../cc_tools/genchecksum cc1-dummy > cc1-checksum.c on the console I get: panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 cpuid = 0 KDB: enter: panic [thread pid 67078 tid 100097 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 10:06:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FDC7106566C for ; Tue, 7 Jul 2009 10:06:47 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 22D758FC0A for ; Tue, 7 Jul 2009 10:06:46 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 3207C6D423; Tue, 7 Jul 2009 11:51:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgH+91ifTaUP; Tue, 7 Jul 2009 11:50:58 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 76FE26D41E; Tue, 7 Jul 2009 11:50:58 +0200 (CEST) Date: Tue, 7 Jul 2009 11:50:58 +0200 From: Rink Springer To: Anton Shterenlikht Message-ID: <20090707095058.GC7827@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:06:47 -0000 On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > cpuid = 0 > KDB: enter: panic > [thread pid 67078 tid 100097 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; Do you have a backtrace ? Regards, -- Rink P.W. Springer - http://rink.nu "Doom, gloom and despair. I like it!" - Tiresias From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 10:12:46 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 088FB1065677; Tue, 7 Jul 2009 10:12:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CE7808FC1E; Tue, 7 Jul 2009 10:12:44 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA20082; Tue, 07 Jul 2009 13:12:30 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A531F8D.5040009@icyb.net.ua> Date: Tue, 07 Jul 2009 13:12:29 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Scott Long , Edward Tomasz Napierala References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> <20090706152351.S26418@pooker.samsco.org> In-Reply-To: <20090706152351.S26418@pooker.samsco.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD-Current , scottl@FreeBSD.org, Mike Tancsa Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:12:48 -0000 on 07/07/2009 00:24 Scott Long said the following: >> Still the box does a panic when writing to the disk that has bad >> sectors on it. (I do newfs it between reboots). Again, not sure if >> this is a "well, dont use a bad disk", but here is the panic again in >> case it shows something useful. >> > > This is a 'don't use a bad disk' panic; FreeBSD UFS and VM simply can't > handle errors on reads or writes. I think that this is not generally true, especially about reads. And wasn't there a FreeBSD Foundation sponsored project to fix panics caused by media going away? I think that panics on I/O errors are related to that. trasz might be interested in this particular one. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 10:35:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B68106564A for ; Tue, 7 Jul 2009 10:35:02 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 7BCE68FC1C for ; Tue, 7 Jul 2009 10:35:02 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n67AYq9w016636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 20:34:55 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A5324C1.5080203@freebsd.org> Date: Tue, 07 Jul 2009 11:34:41 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kostik Belousov References: <4A48942A.7030307@freebsd.org> <20090629114516.GY2884@deviant.kiev.zoral.com.ua> In-Reply-To: <20090629114516.GY2884@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_20,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: "filesystem goof: vop_panic[vop_revoke]" panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:35:03 -0000 Kostik Belousov wrote: > On Mon, Jun 29, 2009 at 11:15:06AM +0100, Lawrence Stewart wrote: >> Hi All, >> >> My laptop panicked whilst shutting down yesterday. The shutdown sequence >> seemed to terminate kde4/X correctly but got wedged prior to completing >> the rest as seen on the console. Details below... [snip] Been running with your patch for well over a week now and no recurrence of the panic. I think it's safe to say the patch has fixed the issue for me. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 10:50:45 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20F931065670 for ; Tue, 7 Jul 2009 10:50:45 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247]) by mx1.freebsd.org (Postfix) with ESMTP id 915C78FC0A for ; Tue, 7 Jul 2009 10:50:44 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id n67AofrH023722; Tue, 7 Jul 2009 11:50:41 +0100 (BST) Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk) by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MO8G1-0003yN-Mu; Tue, 07 Jul 2009 11:50:41 +0100 Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.14.3/8.14.3) with ESMTP id n67AofDN056673; Tue, 7 Jul 2009 11:50:41 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: (from ga9@localhost) by buffy.york.ac.uk (8.14.3/8.14.3/Submit) id n67Aofnr056672; Tue, 7 Jul 2009 11:50:41 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin@FreeBSD.org using -f From: Gavin Atkinson To: Gonzalo Nemmi In-Reply-To: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> References: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 07 Jul 2009 11:50:40 +0100 Message-Id: <1246963840.48637.44.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 10:50:45 -0000 On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: > Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to boot "with > ACPI disabled" or "Safe Mode": > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; acpic id = 00 > instruction pointer = 0x70:0xbfe4 > stack pointer = 0x28:0xfa4 > frame pointer = 0x28:0xfd4 > code segment = base 0xc00f0000, limit 0xffff, type 0x1b > = DPL 0, pres 1, def32 0, gran 0 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > [thread pid 0 tid 100000 ] > Stopped at 0xbfe4: *** error reading from address bfe4 *** > db> bt > Tracing pid 0 tid 100000 td 0x0da9b50 > uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 > db> This may well be a known problem that has affected certain Intel motherboards since around 5.x. Although this problem may well be solvable, perhaps the better approach is to fix whatever is stopping you from booting with ACPI enabled? If for some reason you cannot have ACPI enabled, I guess knowing more output than the above would be useful. For example, when booting verbose and with ACPI disabled, what lines are printed before the above? (to do this, break to the loader prompt, and: setenv hint.acpi.0.disabled=1 setenv hint.apic.0.disabled=1 boot -v it's also worth trying just with the first one to just disable ACPI, then just trying the APIC option, to see which of those two are causing you problems) By the way, is this i386 or amd64? Gavin From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 11:38:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13028106566C for ; Tue, 7 Jul 2009 11:38:47 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id CEBA68FC0A for ; Tue, 7 Jul 2009 11:38:46 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n67BaEYR048532; Tue, 7 Jul 2009 07:36:14 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907071136.n67BaEYR048532@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 07 Jul 2009 07:38:45 -0400 To: Alexey Shuvaev From: Mike Tancsa In-Reply-To: <20090707091624.GA7770@wep4035.physik.uni-wuerzburg.de> References: <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> <20090707091624.GA7770@wep4035.physik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 11:38:47 -0000 At 05:16 AM 7/7/2009, Alexey Shuvaev wrote: >It seems you are doing newfs and then mounting it. Why? Just to make sure that post crash, I dont have to fsck it, or that as part of the crash some undetected ufs corruption happened. ---Mike >If you want to remove the data do something like >dd if=/dev/zero of=/dev/ada2 bs=1m >or >dd if=/dev/random of=/dev/ada2 bs=1m > >You could also try smaller block sizes (bs argument) near the bad blocks. > >Just 0.02$, >Alexey. From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 12:44:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB792106567E; Tue, 7 Jul 2009 12:44:18 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 78F078FC1B; Tue, 7 Jul 2009 12:44:18 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOA1n-000092-5u; Tue, 07 Jul 2009 13:44:17 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOA1m-0003LX-17; Tue, 07 Jul 2009 13:44:06 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n67Ci5wt046131; Tue, 7 Jul 2009 13:44:05 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n67Ci5wn046130; Tue, 7 Jul 2009 13:44:05 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 7 Jul 2009 13:44:05 +0100 From: Anton Shterenlikht To: Rink Springer Message-ID: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707095058.GC7827@rink.nu> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.2 X-Spam-Level: - Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 12:44:19 -0000 On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > cpuid = 0 > > KDB: enter: panic > > [thread pid 67078 tid 100097 ] > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > Do you have a backtrace ? no, sorry, I was too quick to reboot. I tried to reproduce the error, got this on the way: # XXX: bogusly disabled high FP regs which is reported from by sys/ia64/ia64/trap.c, and then this error (but no panic this time): ===> usr.bin/yacc (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/closure. c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/error.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/lalr.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/lr0.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/mkpar.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/output.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/reader.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/main.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/skeleton .c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/symtab.c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/verbose. c cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/warshall .c gzip -cn /usr/src/usr.bin/yacc/yacc.1 > yacc.1.gz gzip -cn /usr/src/usr.bin/yacc/yyfix.1 > yyfix.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o yacc closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o ===> usr.bin/yes (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yes/yes.c gzip -cn /usr/src/usr.bin/yes/yes.1 > yes.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o yes yes.o ===> usr.bin/ypcat (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypcat/ypcat.c gzip -cn /usr/src/usr.bin/ypcat/ypcat.1 > ypcat.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypcat ypcat.o ===> usr.bin/ypmatch (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypmatch/ypmat ch.c gzip -cn /usr/src/usr.bin/ypmatch/ypmatch.1 > ypmatch.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypmatch ypmatch.o ===> usr.bin/ypwhich (all) cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/ypwhich/ypwhi ch.c gzip -cn /usr/src/usr.bin/ypwhich/ypwhich.1 > ypwhich.1.gz cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypwhich ypwhich.o 1 error *** Error code 2 1 error *** Error code 2 1 error # ********************** Below are dmesg and make.conf, if it matters. There are several backtraces in dmesg, but I'm not sure now at what stage they appeared. many thanks ********************** GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT-200906 #0: Fri Jun 12 22:56:41 UTC 2009 root@hob.lan.xcllnt.net:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. CPU: Madison (1500.00-Mhz Itanium 2) Origin = "GenuineIntel" Revision = 5 Features = 0x1 real memory = 2126766080 (2028 MB) avail memory = 2013437952 (1920 MB) FPSWA Revision = 0x10012, Entry = 0xe00000407fe60050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: SAPIC Id=1, SAPIC Eid=0 ACPI Warning: 32/64X length mismatch in Gpe0Block: 32/16 20090521 tbfadt-625 ACPI Warning: 32/64X length mismatch in Gpe1Block: 32/16 20090521 tbfadt-625 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: Sleep Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> iomem 0xff5c1004-0xff5c1007 on acpi0 acpi_tz0: on acpi0 pcib0: on acpi0 pci0: on pcib0 ohci0: mem 0x80023000-0x80023fff irq 16 at device 1.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0x80022000-0x80022fff irq 17 at device 1.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0x80021000-0x800210ff irq 18 at device 1.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 0.95 usbus2: on ehci0 atapci0: port 0xd58-0xd5f,0xd64-0xd67,0xd50-0xd57,0xd60-0xd63,0xd40-0xd4f irq 21 at device 2.0 on pci0 atapci0: [ITHREAD] atapci0: HW has secondary channel disabled ata2: on atapci0 ata2: [ITHREAD] fxp0: port 0xd00-0xd3f mem 0x80020000-0x80020fff,0x80000000-0x8001ffff irq 20 at device 3.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:11:0a:31:d6:ec fxp0: [ITHREAD] pcib1: on acpi0 pci32: on pcib1 mpt0: port 0x2100-0x21ff mem 0x90840000-0x9084ffff,0x90830000-0x9083ffff irq 27 at device 1.0 on pci32 mpt0: [ITHREAD] mpt0: MPI Version=1.2.12.0 mpt1: port 0x2000-0x20ff mem 0x90820000-0x9082ffff,0x90810000-0x9081ffff irq 28 at device 1.1 on pci32 mpt1: [ITHREAD] mpt1: MPI Version=1.2.12.0 bge0: mem 0x90800000-0x9080ffff irq 29 at device 2.0 on pci32 miibus1: on bge0 brgphy0: PHY 1 on miibus1 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:11:0a:31:36:40 bge0: [ITHREAD] pcib2: on acpi0 pci64: on pcib2 pcib3: on acpi0 pci96: on pcib3 pcib4: on acpi0 pci128: on pcib4 pcib5: on acpi0 pci192: on pcib5 pcib6: on acpi0 pci224: on pcib6 uart0: <16550 or compatible> mem 0xf4051000-0xf405100f irq 82 at device 1.0 on pci224 uart0: [FILTER] puc0: mem 0xf4050000-0xf4050fff,0xf4020000-0xf403ffff irq 82 at device 1.1 on pci224 puc0: [FILTER] uart1: on puc0 uart1: [FILTER] uart1: console (9600,n,8,1) uart2: on puc0 uart2: [FILTER] vgapci0: port 0xe000-0xe0ff mem 0xf0000000-0xf3ffffff,0xf4040000-0xf404ffff at device 2.0 on pci224 uart3: <16550 or compatible> iomem 0xff5e0000-0xff5e0007 irq 34 on acpi0 uart3: [FILTER] uart4: <16550 or compatible> iomem 0xff5e2000-0xff5e2007 irq 35 on acpi0 uart4: [FILTER] uart4: debug port (9600,n,8,1) cpu0: on acpi0 cpu1: on acpi0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 usbus2: 480Mbps High Speed USB v2.0 ugen2.1: at usbus2 uhub2: on usbus2 acd0: DVDROM at ata2-master PIO4 Waiting 5 seconds for SCSI devices to settle uhub1: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub2: 5 ports with 5 removable, self powered WARNING: WITNESS option enabled, expect reduced performance. da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da0: Command Queueing Enabled da0: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 320.000MB/s transfers (160.000MHz, offset 63, 16bit) da1: Command Queueing Enabled da1: 70007MB (143374738 512 byte sectors: 255H 63S/T 8924C) GEOM_MIRROR: Device mirror/efi launched (2/2). GEOM_MIRROR: Device mirror/root launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/var launched (2/2). GEOM_MIRROR: Device mirror/tmp launched (1/2). GEOM_MIRROR: Device tmp: rebuilding provider da0p5. GEOM_MIRROR: Device mirror/usr launched (1/2). GEOM_MIRROR: Device usr: rebuilding provider da0p6. Trying to mount root from ufs:/dev/mirror/root WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted /tmp: mount pending error: blocks 24 files 6 WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted GEOM_MIRROR: Device tmp: rebuilding provider da0p5 finished. lock order reversal: 1st 0xe0000000109596b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:423 2nd 0xa00000001e4bad40 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 3rd 0xe000000010792448 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe000000010792448, 0x9, 0x0, 0x220, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010792448, 0x80100, 0xe000000010792470, 0xe000000004b3a158, 0x50, 0x33, 0xe000000004b71740, 0x220) at __lockmgr_args+0xe10 ffs_lock(0xa000000032a78dd0, 0xe000000010792448, 0x80100) at ffs_lock+0x130 VOP_LOCK1_APV(0xe000000004cc19f0, 0xa000000032a78db0, 0xe0000000045d5b90) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe0000000107923b0, 0x80100, 0xe000000004b71740, 0x220, 0xe0000000107923c0, 0xa000000032a78dd0, 0xa000000032a78dc8, 0xa000000032a78dc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000107b45e0, 0xa000000032a78fc8, 0xe0000000107923b0, 0xe000000010792470, 0x1, 0x0, 0xa00000000037a000, 0x0) at ffs_snapshot+0x2280 ffs_mount(0x0, 0xe000000004b735e8, 0xa000000032a79100, 0xa000000032a79100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000106c5400) at vfs_donmount+0x1d80 nmount(0xe000000010886000, 0xa000000032a794e8, 0x0, 0xe000000004ac03e0) at nmount+0xe0 syscall(0xa000000032a79400, 0x17a, 0x201000, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c99a28, 0x17a, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xa00000001e4bad40 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe000000010a2a330 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe000000010a2a330, 0x9, 0xffffffffffffffff, 0x319, 0xe0000000109596e0) at witness_checkorder+0x12c0 __lockmgr_args(0xe000000010a2a330, 0x80400, 0xe0000000109596e0, 0xe000000004b717a8, 0x50, 0x33, 0xe000000004b71740, 0x319) at __lockmgr_args+0xe10 ffs_lock(0xa000000032a78dd0, 0xe000000010a2a330, 0x80400) at ffs_lock+0x130 VOP_LOCK1_APV(0xe000000004cc19f0, 0xa000000032a78db0, 0xe000000004b51bb0) at VOP_LOCK1_APV+0x1d0 _vn_lock(0xe000000010959620, 0x80400, 0xe000000004b71740, 0x319, 0xe000000010959630, 0xa000000032a78dd0, 0xa000000032a78dc8, 0xa000000032a78dc0) at _vn_lock+0xf0 ffs_snapshot(0xe0000000107b45e0, 0xa000000032a78fc8, 0xa000000032a78e08, 0xe0000000107ae000, 0xe00000001096d100, 0x0, 0xe00000001062a030, 0xe00000001096d000) at ffs_snapshot+0x3f50 ffs_mount(0x0, 0xe000000004b735e8, 0xa000000032a79100, 0xa000000032a79100) at ffs_mount+0x2160 vfs_donmount(0x0, 0x211000, 0xe0000000106c5400) at vfs_donmount+0x1d80 nmount(0xe000000010886000, 0xa000000032a794e8, 0x0, 0xe000000004ac03e0) at nmount+0xe0 syscall(0xa000000032a79400, 0x17a, 0x201000, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c99a28, 0x17a, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return lock order reversal: 1st 0xe000000010a2a330 snaplk (snaplk) @ /usr/src/sys/kern/vfs_vnops.c:295 2nd 0xe0000000109596b8 ufs (ufs) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b71740) at _witness_debugger+0x60 witness_checkorder(0xe0000000109596b8, 0x9, 0xffffffffffffffff, 0x633, 0x0) at witness_checkorder+0x12c0 __lockmgr_args(0xe0000000109596b8, 0x80000, 0x0, 0xe000000004b3a158, 0x50, 0x33, 0xe000000004b71740, 0x633) at __lockmgr_args+0xe10 ffs_snapremove(0xe000000010959620, 0xe000000004b71740, 0xe000000004b55ab8, 0xe0000000109596b8) at ffs_snapremove+0x200 softdep_releasefile(0xe00000001086f6f8, 0xa000000032a792d0, 0x29f, 0xe000000004a12470, 0x48e) at softdep_releasefile+0x90 ufs_inactive(0xe000000010886000, 0xe00000001086f6f8, 0xe000000010959710) at ufs_inactive+0x400 VOP_INACTIVE_APV(0xe000000004cc21c0, 0xa000000032a792e0, 0xe000000004b54550, 0xe00000000470f940) at VOP_INACTIVE_APV+0x1c0 vinactive(0xe000000010959620, 0xe000000010886000, 0x800, 0xe0000000109596e0) at vinactive+0x110 vput(0xe000000010959620, 0xa000000032a79308, 0xe000000004b55ab8, 0xe0000000109596e0) at vput+0x3f0 vn_close(0xe000000010959620, 0x1, 0xe000000010363c00, 0xe000000010886000) at vn_close+0x310 vn_closefile(0xe000000010723590, 0xe000000010886000, 0xe000000010959620) at vn_closefile+0x1e0 _fdrop(0xe000000010723590, 0xe000000010886000, 0xe000000004589d10, 0xb9b) at _fdrop+0xb0 closef(0xe000000010723590, 0xe000000010886000, 0x0, 0xe00000000458a4c0) at closef+0x570 kern_close(0xe000000010886000, 0xe000000004b3c520) at kern_close+0x270 close(0xe000000010886000, 0xa000000032a794e8, 0xe000000004ac03e0, 0x58f) at close+0x30 syscall(0xa000000032a79400, 0x6, 0x0, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c95468, 0x6, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return GEOM_MIRROR: Device usr: rebuilding provider da0p6 finished. lock order reversal: 1st 0xa00000001e6a59c8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xe0000000107bcc00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self(0xe000000004115b50) at db_trace_self+0x20 db_trace_self_wrapper(0xe000000004654560) at db_trace_self_wrapper+0x70 kdb_backtrace(0xe000000004cf9c38, 0xe00000000467bf60) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0xe000000004b4bac0, 0xe00000000467d800, 0x999, 0xe000000004b73fd0) at _witness_debugger+0x60 witness_checkorder(0xe0000000107bcc00, 0x9, 0xffffffffffffffff, 0x11d, 0x0) at witness_checkorder+0x12c0 _sx_xlock(0xe0000000107bcc00, 0x0, 0xe000000004b73fd0, 0x11d) at _sx_xlock+0xc0 ufsdirhash_acquire(0xe000000010abbd88, 0xe0000000107bcc00, 0xe000000004a0ef40, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000000010abbd88, 0xa000000023710018, 0x18, 0xa000000032a79328) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000000012b997f8, 0xe000000010bee2a0, 0x0, 0x1, 0xa000000023710018) at ufs_dirremove+0x240 ufs_rmdir(0xa000000032a79390, 0xe000000010bee2a0, 0xe000000010abbd88) at ufs_rmdir+0x230 VOP_RMDIR_APV(0xe000000004cc21c0, 0xa000000032a793d8, 0x2, 0xe00000000471aff0) at VOP_RMDIR_APV+0x1c0 kern_rmdirat(0xe000000010886000, 0xffffffffffffff9c, 0x200000004041a508, 0x0) at kern_rmdirat+0x340 kern_rmdir(0xe000000010886000, 0x200000004041a508, 0x0) at kern_rmdir+0x30 rmdir(0xe000000010886000, 0xa000000032a794e8, 0xe000000004ac03e0, 0x58f) at rmdir+0x30 syscall(0xa000000032a79400, 0x89, 0x200000004041a400, 0xe000000010886000, 0xe00000001087ccd8, 0xe000000004c96cf8, 0x89, 0xa000000032a794e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return XXX: bogusly disabled high FP regs --->>> make.conf <<<--- # $FreeBSD: src/share/examples/etc/make.conf,v 1.279 2007/01/17 12:43:06 des Exp $ # copied from /usr/share/examples/etc/make.conf # # Currently the following CPU types are recognized: # Intel x86 architecture: # (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4 # athlon-tbird athlon k8 k6-3 k6-2 k6 k5 # (Intel CPUs) core2 core nocona pentium4m pentium4 prescott # pentium3m pentium3 pentium-m pentium2 # pentiumpro pentium-mmx pentium i486 i386 # (Via CPUs) c3 c3-2 # Alpha/AXP architecture: ev67 ev6 pca56 ev56 ev5 ev45 ev4 # AMD64 architecture: opteron, athlon64, nocona, prescott, core2 # Intel ia64 architecture: itanium2, itanium # # (?= allows to buildworld for a different CPUTYPE.) # CPUTYPE=ia64 #NO_CPU_CFLAGS= # Don't add -march= to CFLAGS automatically #NO_CPU_COPTFLAGS= # Don't add -march= to COPTFLAGS automatically # # CFLAGS controls the compiler settings used when compiling C code. # Note that optimization settings other than -O and -O2 are not recommended # or supported for compiling the world or the kernel - please revert any # nonstandard optimization settings to "-O" or "-O2 -fno-strict-aliasing" # before submitting bug reports without patches to the developers. # # Compiling with -fstrict-aliasing optimization breaks some [notable] ports. # GCC turns on -fstrict-aliasing optimization at all levels above -O[1], so # explicitly turn it off when using compiling with the -O2 optimization level. # CFLAGS= -O2 -fno-strict-aliasing -pipe # # CXXFLAGS controls the compiler settings used when compiling C++ code. # Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish # to add to CXXFLAGS value, "+=" must be used rather than "=". Using "=" # alone will remove the often needed contents of CFLAGS from CXXFLAGS. # CXXFLAGS+= -fconserve-space # # MAKE_SHELL controls the shell used internally by make(1) to process the # command scripts in makefiles. Three shells are supported, sh, ksh, and # csh. Using sh is most common, and advised. Using ksh *may* work, but is # not guaranteed to. Using csh is absurd. The default is to use sh. # MAKE_SHELL=sh # # BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested # for use in developing FreeBSD and testing changes. They can be used by # putting "CFLAGS+=${BDECFLAGS}" in /etc/make.conf. -Wconversion is not # included here due to compiler bugs, e.g., mkdir()'s mode_t argument. # BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \ -Wcast-qual -Wchar-subscripts -Winline \ -Wmissing-prototypes -Wnested-externs -Wpointer-arith \ -Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings # # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # COPTFLAGS= -O -pipe # # Compare before install INSTALL=install -C # # Mtree will follow symlinks #MTREE_FOLLOWS_SYMLINKS= -L # # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= # # To enable installing newgrp(1) with the setuid bit turned on. # Without the setuid bit, newgrp cannot change users' groups. #ENABLE_SUID_NEWGRP= # # To avoid building various parts of the base system: #NO_MODULES= # do not build modules with the kernel #NO_SHARE= # do not go into the share subdir #NO_SHARED= # build /bin and /sbin statically linked (bad idea) # # Variables that control how ppp(8) is built. #PPP_NO_NAT= # do not build with NAT support (see make.conf(5)) #PPP_NO_NETGRAPH= # do not build with Netgraph support #PPP_NO_RADIUS= # do not build with RADIUS support #PPP_NO_SUID= # build with normal permissions # #TRACEROUTE_NO_IPSEC= # do not build traceroute(8) with IPSEC support # # To build sys/modules when building the world (our old way of doing things) #MODULES_WITH_WORLD= # do not build modules when building kernel # # The list of modules to build instead of all of them. MODULES_OVERRIDE= # # The list of modules to never build, applied *after* MODULES_OVERRIDE. #WITHOUT_MODULES= bktr plip # # If you do not want unformatted manual pages to be compressed # when they are installed: # #NO_MANCOMPRESS= # # # Default format for system documentation, depends on your printer. # Set this to "ascii" for simple printers or screen # #PRINTERDEVICE= ps # # # How long to wait for a console keypress before booting the default kernel. # This value is approximately in milliseconds. Keypresses are accepted by the # BIOS before booting from disk, making it possible to give custom boot # parameters even when this is set to 0. # #BOOTWAIT=0 #BOOTWAIT=30000 # # By default, the system will always use the keyboard/video card as system # console. However, the boot blocks may be dynamically configured to use a # serial port in addition to or instead of the keyboard/video console. # # By default we use COM1 as our serial console port *if* we're going to use # a serial port as our console at all. Alter as necessary. # # COM1: = 0x3F8, COM2: = 0x2F8, COM3: = 0x3E8, COM4: = 0x2E8 # #BOOT_COMCONSOLE_PORT= 0x3F8 # # The default serial console speed is 9600. Set the speed to a larger value # for better interactive response. # #BOOT_COMCONSOLE_SPEED= 115200 # # By default the 'pxeboot' loader retrieves the kernel via NFS. Defining # this and recompiling /usr/src/sys/boot will cause it to retrieve the kernel # via TFTP. This allows pxeboot to load a custom BOOTP diskless kernel yet # still mount the server's '/' (i.e. rather than load the server's kernel). # #LOADER_TFTP_SUPPORT= YES # # # Kerberos 5 su (k5su) # If you want to use the k5su utility, define this to have it installed # set-user-ID. #ENABLE_SUID_K5SU= # # # CVSup update flags. Edit SUPFILE settings to reflect whichever distribution # file(s) you use on your site (see /usr/share/examples/cvsup/README for more # information on CVSup and these files). To use, do "make update" in /usr/src. # #SUP_UPDATE= # #SUP= /usr/bin/csup #SUPFLAGS= -g -L 2 #SUPHOST= cvsup.uk.FreeBSD.org #SUPFILE= /usr/share/examples/cvsup/standard-supfile #PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile #DOCSUPFILE= /usr/share/examples/cvsup/doc-supfile # # top(1) uses a hash table for the user names. The size of this hash # can be tuned to match the number of local users. The table size should # be a prime number approximately twice as large as the number of lines in # /etc/passwd. The default number is 20011. # #TOP_TABLE_SIZE= 101 # # Documentation # # The list of languages and encodings to build and install # DOC_LANG= en_US.ISO8859-1 # # # sendmail # # The following sets the default m4 configuration file to use at # install time. Use with caution as a make install will overwrite # any existing /etc/mail/sendmail.cf. Note that SENDMAIL_CF is now # deprecated. The value should be a fully qualified path name. # #SENDMAIL_MC=/etc/mail/myconfig.mc # # The following sets the default m4 configuration file for mail # submission to use at install time. Use with caution as a make # install will overwrite any existing /etc/mail/submit.cf. The # value should be a fully qualified path name. # #SENDMAIL_SUBMIT_MC=/etc/mail/mysubmit.mc # # If you need to build additional .cf files during a make buildworld, # include the full paths to the .mc files in SENDMAIL_ADDITIONAL_MC. # #SENDMAIL_ADDITIONAL_MC=/etc/mail/foo.mc /etc/mail/bar.mc # # The following overrides the default location for the m4 configuration # files used to build a .cf file from a .mc file. # #SENDMAIL_CF_DIR=/usr/local/share/sendmail/cf # # Setting the following variable modifies the flags passed to m4 when # building a .cf file from a .mc file. It can be used to enable # features disabled by default. # #SENDMAIL_M4_FLAGS= # # Setting the following variables modifies the build environment for # sendmail and its related utilities. For example, SASL support can be # added with settings such as: # # with SASLv1: # SENDMAIL_CFLAGS=-I/usr/local/include/sasl1 -DSASL # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl # # with SASLv2: # SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 # SENDMAIL_LDFLAGS=-L/usr/local/lib # SENDMAIL_LDADD=-lsasl2 # # Note: If you are using Cyrus SASL with other applications which require # access to the sasldb file, you should add the following to your # sendmail.mc file: # # define(`confDONT_BLAME_SENDMAIL',`GroupReadableSASLDBFile') # #SENDMAIL_CFLAGS= #SENDMAIL_LDFLAGS= #SENDMAIL_LDADD= #SENDMAIL_DPADD= # # Setting SENDMAIL_SET_USER_ID will install the sendmail binary as a # set-user-ID root binary instead of a set-group-ID smmsp binary and will # prevent the installation of /etc/mail/submit.cf. # This is a deprecated mode of operation. See etc/mail/README for more # information. # #SENDMAIL_SET_USER_ID= # # The permissions to use on alias and map databases generated using # /etc/mail/Makefile. Defaults to 0640. # #SENDMAIL_MAP_PERMS= -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 13:07:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CCF7106564A for ; Tue, 7 Jul 2009 13:07:54 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id EDB468FC13 for ; Tue, 7 Jul 2009 13:07:53 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 03CAC39815; Tue, 7 Jul 2009 15:07:51 +0200 (SAST) Message-ID: <4A5348A4.60401@phat.za.net> Date: Tue, 07 Jul 2009 15:07:48 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Gonzalo Nemmi References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> In-Reply-To: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:07:54 -0000 Hi, Gonzalo Nemmi wrote: > log in > acpiconf -s 3 > suspend works > opened the lid and the screen doesn't come back (backlight never gets back) > hard reset > login again and checked /var/log/messages .. this is what I found: I have problems with suspend too, on AMD64. Basically it works and my systems comes back up, but some devices are hosed afterwards. My bge network interface is one. I get precisely the same PHY timeout errors you're getting after a suspend. The iwn network driver screams the following if I try use it after a suspend: > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_mem_lock: could not lock memory > Jul 7 14:53:17 fuzz last message repeated 7 times > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_transfer_microcode: could not load boot firmware > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_transfer_firmware: could not load boot firmware, error 60 > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_init_locked: could not load firmware, error 60 USB ports resume sometimes, sometimes not: > Jul 7 14:58:44 fuzz kernel: usbus2: port reset timeout > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:369: port 1 reset failed, error=USB_ERR_TIMEOUT > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling port 1 > Jul 7 14:58:44 fuzz kernel: usbus6: port reset timeout > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:369: port 5 reset failed, error=USB_ERR_TIMEOUT > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling port 5 > Jul 7 14:58:55 fuzz kernel: uhci_interrupt: resume detect > Jul 7 14:58:55 fuzz kernel: ugen6.2: at usbus6 (disconnected) > Jul 7 14:58:55 fuzz kernel: ugen5.2: at usbus5 (disconnected) > Jul 7 14:58:56 fuzz kernel: usbus6: port reset timeout > Jul 7 14:58:56 fuzz kernel: uhub_reattach_port:369: port 6 reset failed, error=USB_ERR_TIMEOUT > Jul 7 14:58:56 fuzz kernel: uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling port 6 And I just noticed this message: > Jul 7 14:53:36 fuzz kernel: calcru: runtime went backwards from 18237633 usec to 9377885 usec for pid 10 (idle) Unloading modules from the kernel prior to suspending doesn't seem to work either. On the upside, FreeBSD 8.0 boots rather quickly! :) Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 13:08:13 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B38F51065700; Tue, 7 Jul 2009 13:08:13 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: from pin.if.uz.zgora.pl (pin.if.uz.zgora.pl [212.109.128.251]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5FB8FC13; Tue, 7 Jul 2009 13:08:13 +0000 (UTC) (envelope-from trasz@FreeBSD.org) Received: by pin.if.uz.zgora.pl (Postfix, from userid 1001) id 6B06A39BA3; Tue, 7 Jul 2009 14:49:56 +0200 (CEST) Date: Tue, 7 Jul 2009 14:49:56 +0200 From: Edward Tomasz Napierala To: Andriy Gapon Message-ID: <20090707124956.GA31310@pin.if.uz.zgora.pl> References: <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> <7.1.0.9.0.20090703165005.196d3ba0@sentex.net> <200907050030.n650UkEu028408@lava.sentex.ca> <4A504B0C.2060406@FreeBSD.org> <200907062118.n66LIGRg043316@lava.sentex.ca> <20090706152351.S26418@pooker.samsco.org> <4A531F8D.5040009@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <4A531F8D.5040009@icyb.net.ua> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD-Current , scottl@FreeBSD.org, Alexander Motin , Mike Tancsa Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:08:13 -0000 On 0707T1312, Andriy Gapon wrote: > >> Still the box does a panic when writing to the disk that has bad > >> sectors on it. (I do newfs it between reboots). Again, not sure if > >> this is a "well, dont use a bad disk", but here is the panic again in > >> case it shows something useful. > >> > > > > This is a 'don't use a bad disk' panic; FreeBSD UFS and VM simply can't > > handle errors on reads or writes. > > I think that this is not generally true, especially about reads. > And wasn't there a FreeBSD Foundation sponsored project to fix panics caused by > media going away? I think that panics on I/O errors are related to that. Device going away is slightly different case, but I believe it shouldn't be generally true, except for filesystems with softupdates enabled. For the most part, softupdates don't even try to handle I/O errors - they just panic (e.g. "panic: softdep_move_dependencies: need merge code"). -- If you cut off my head, what would I say? Me and my head, or me and my body? From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 13:05:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D23F1065670; Tue, 7 Jul 2009 13:05:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 437C18FC17; Tue, 7 Jul 2009 13:05:33 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2143326and.13 for ; Tue, 07 Jul 2009 06:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4VFw8EIYibBP+4pIopo7fzEBovy4niRY34322hIHhnY=; b=icmMrqcFAgMFEreePBEvt3TDfhQGeqKspyl+wopNo2MP5GzPIiSgthJfgWxqPrWTVs MyalqoKfm73Aj2RX3vLgCJUkePaZcRk/685FtiLUq32+hNCNzhzhOBzhiqsupXj80q5+ /Zbh2aGBDN5HM/r2ChQjIsruOUQT+UoyFBWS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d2Cleo8hpj7whROhIMxNYExtz6x5kX6SphB1L3GgPLZDNQbOoMIwr0Y3+y1vYAvIV3 wGY3LAFVdyxd92R26DzNrGkCJ7OaFokUdnBIQ8k4b+6XKkRf+bbODaY/uSbATA39Kc4L id9Tvhw1VioGGB8WXM7p6VEMdrZrkazkgC+uM= MIME-Version: 1.0 Received: by 10.100.94.4 with SMTP id r4mr10507202anb.171.1246971932463; Tue, 07 Jul 2009 06:05:32 -0700 (PDT) In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Date: Tue, 7 Jul 2009 16:05:32 +0300 Message-ID: From: Dan Naumov To: Ken Smith Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Jul 2009 13:22:16 +0000 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:05:34 -0000 On Tue, Jul 7, 2009 at 3:33 AM, Ken Smith wrote: > Be careful if you have SCSI drives, more USB disks than just the memory > stick, etc - make sure /dev/da0 (or whatever you use) is the memory > stick. =A0Using this image for livefs based rescue mode is known to not > work, that is one of the things still being worked on. Hey Just wanted a small clarification, does livefs based rescue mode mean "fixit environment" or not? I would like to do some configuration testing with 8.0-beta1, but applying the configuration pretty much requires working in FIXIT, since sysinstall isn't exactly up to the task. - Sincerely, Dan Naumov From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 13:35:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 264361065670; Tue, 7 Jul 2009 13:35:10 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id D81048FC12; Tue, 7 Jul 2009 13:35:09 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 297086D423; Tue, 7 Jul 2009 15:36:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFjoBHSXQkvg; Tue, 7 Jul 2009 15:36:11 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 513596D41E; Tue, 7 Jul 2009 15:36:11 +0200 (CEST) Date: Tue, 7 Jul 2009 15:36:11 +0200 From: Rink Springer To: Anton Shterenlikht Message-ID: <20090707133611.GA66072@rink.nu> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Rink Springer , freebsd-ia64@freebsd.org, freebsd-current@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 13:35:10 -0000 On Tue, Jul 07, 2009 at 01:44:05PM +0100, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 67078 tid 100097 ] > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > Do you have a backtrace ? > > no, sorry, I was too quick to reboot. Shame... well, if you hit it again, please let me know. Haven't yet gotten it myself on my rx2600. > I tried to reproduce the error, got this on the way: > > # XXX: bogusly disabled high FP regs I get this message quite often as well; I intend to figure out what's going on. Marcel, if you have any idea, please let me know. Regards, -- Rink P.W. Springer - http://rink.nu "Doom, gloom and despair. I like it!" - Tiresias From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 14:42:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12813106566C; Tue, 7 Jul 2009 14:42:25 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id B89108FC1A; Tue, 7 Jul 2009 14:42:24 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOBs1-0006Cl-UY; Tue, 07 Jul 2009 15:42:23 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOBs1-0004vZ-9b; Tue, 07 Jul 2009 15:42:09 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n67Eg8qK049616; Tue, 7 Jul 2009 15:42:08 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n67Eg8kC049615; Tue, 7 Jul 2009 15:42:08 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 7 Jul 2009 15:42:08 +0100 From: Anton Shterenlikht To: Rink Springer Message-ID: <20090707144208.GA49582@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707133611.GA66072@rink.nu> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Cc: freebsd-current@FreeBSD.org, freebsd-ia64@FreeBSD.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:42:25 -0000 On Tue, Jul 07, 2009 at 03:36:11PM +0200, Rink Springer wrote: > On Tue, Jul 07, 2009 at 01:44:05PM +0100, Anton Shterenlikht wrote: > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread pid 67078 tid 100097 ] > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > Do you have a backtrace ? > > > > no, sorry, I was too quick to reboot. > > Shame... well, if you hit it again, please let me know. Haven't yet > gotten it myself on my rx2600. > > > I tried to reproduce the error, got this on the way: > > > > # XXX: bogusly disabled high FP regs > > I get this message quite often as well; I intend to figure out what's > going on. Marcel, if you have any idea, please let me know. got it again. Note that I was doing "make -j10 buildworld", and when I got it first time I did "make -j6 buildworld". When I only run one process "make buildworld" I didn't get the panic, but stopped at some other error message. So, buildworld stops at: ===> gnu/usr.bin/cc/cc1 (all) cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/main.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-parser.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -c /usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/c-lang.c cc -O2 -fno-strict-aliasing -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/u sr/src/tmp/usr\" -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1/../../../ ../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config -I/u sr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include -I/usr/src/gnu/usr .bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include -I/usr/src/gnu/usr.bin/cc /cc1/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/src/tmp/legacy/usr /include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-pa rser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbac kend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/o bj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/ob j/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a -legacy ../cc_tools/genchecksum cc1-dummy > cc1-checksum.c and on the console (MP via LAN on rx2600): # panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 cpuid = 1 KDB: enter: panic [thread pid 46793 tid 100148 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; db> bt Tracing pid 46793 tid 100148 td 0xe000000011b22760 kdb_enter(0xe000000004b43148, 0xe000000004b43148, 0xe0000000045f2a20, 0x793) at kdb_enter+0x92 panic(0xe000000004b41618, 0xe000000004b810c0, 0x2a8, 0xe000000011b229dc, 0xe0000 00011b229da) at panic+0x2f0 _mtx_lock_spin_flags(0xe000000015220a70, 0x0, 0xe000000004b810c0, 0x2a8, 0x20000 00000072200, 0x2000000040107010, 0xe000000004ac1c30, 0x716) at _mtx_lock_spin_fl ags+0x90 trap(0x19, 0xa000000032c09400) at trap+0xdb0 ivt_Disabled_FP_Register() at ivt_Disabled_FP_Register+0x30 db> I'Il try to start just 2 processes and see what happens. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 14:46:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF31F1065670 for ; Tue, 7 Jul 2009 14:46:42 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id A43CA8FC1D for ; Tue, 7 Jul 2009 14:46:42 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.0/8.14.0) with ESMTP id n67Ekfoa072783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2009 09:46:42 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n67Ekfdf014776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2009 09:46:41 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n67Ejse1014657; Tue, 7 Jul 2009 09:45:54 -0500 (CDT) (envelope-from dan) Date: Tue, 7 Jul 2009 09:45:54 -0500 From: Dan Nelson To: Anton Shterenlikht Message-ID: <20090707144554.GF5574@dan.emsphone.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email2.allantgroup.com [199.67.51.78]); Tue, 07 Jul 2009 09:46:42 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Rink Springer , freebsd-ia64@freebsd.org, freebsd-current@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:46:43 -0000 In the last episode (Jul 07), Anton Shterenlikht said: > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > cpuid = 0 > > > KDB: enter: panic > > > [thread pid 67078 tid 100097 ] > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > Do you have a backtrace ? > > no, sorry, I was too quick to reboot. > I tried to reproduce the error, got this on the way: If you add "options KDB_TRACE" to your kernel config, you'll get a stack trace automatically on every panic. > # XXX: bogusly disabled high FP regs > > which is reported from by sys/ia64/ia64/trap.c, and then this error > (but no panic this time): > > ===> usr.bin/yacc (all) > cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -c /usr/src/usr.bin/yacc/closure.c [...] > cc -O2 -fno-strict-aliasing -pipe -std=gnu99 -o ypwhich ypwhich.o > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error There are no errors in this output; just make reporting that there was an error. At -j6, the error message itself may be hundreds of lines back. Make lets all remaining parallel jobs finish before exiting. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 14:57:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77F1106566C for ; Tue, 7 Jul 2009 14:57:55 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 905FD8FC0C for ; Tue, 7 Jul 2009 14:57:55 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so1602135rvb.43 for ; Tue, 07 Jul 2009 07:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=oGC+ppW4g0Sp59CHgzz0LtPA2PAxp0pBp/zE5BHg2lM=; b=VE2e0XDhBLY5DJxGTl0s+ZFx2SjhGHIfAieic9tv1EsJfo8mOYrEWd8CCpS/I6zrms wfYPswVkFj4xEyrQ7Vj4vFPyE8B5BCosFXz55elTJdEIA9xKWA3vWm/zg0yhnPs9TASg e2o2+/1vqmOIppfScrOlOptOHL69MApCjhoto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=mcj6PqcSYVvJcqspI/NEumrFuFAImAbF6CYvh6UBSddfQf5jInr5xaEY0hjuIWYRoE Bzxcw3h+YppemVuSbtURn8+OMZfZpYYKh4ITht4u5gAyhCzzLmptjmZuTJrrgZHJrdjM 26LzmdD3NKag8HtfRtvhxgNUbTixWNv7hmfmg= Received: by 10.140.133.10 with SMTP id g10mr3042893rvd.170.1246978675032; Tue, 07 Jul 2009 07:57:55 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id l31sm5217131rvb.43.2009.07.07.07.57.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 07:57:54 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 89325B8083; Tue, 7 Jul 2009 11:57:48 -0300 (BRT) Received: from 189.93.12.19 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Tue, 7 Jul 2009 11:57:48 -0300 (BRT) Message-ID: <8c26b091724a0709f2749cc3e8951f50.squirrel@cygnus.homeunix.com> In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Date: Tue, 7 Jul 2009 11:57:48 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:57:56 -0000 great this new usb image. will be pretty handy I'm sure :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 15:00:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 198F91065674; Tue, 7 Jul 2009 15:00:59 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id A7F658FC23; Tue, 7 Jul 2009 15:00:58 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOCA9-00018u-LG; Tue, 07 Jul 2009 16:00:57 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOCA9-0001M0-0S; Tue, 07 Jul 2009 16:00:53 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n67F0qAC049749; Tue, 7 Jul 2009 16:00:52 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n67F0qWm049748; Tue, 7 Jul 2009 16:00:52 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 7 Jul 2009 16:00:52 +0100 From: Anton Shterenlikht To: Dan Nelson Message-ID: <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707144554.GF5574@dan.emsphone.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707144554.GF5574@dan.emsphone.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Cc: Rink Springer , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 15:00:59 -0000 On Tue, Jul 07, 2009 at 09:45:54AM -0500, Dan Nelson wrote: > In the last episode (Jul 07), Anton Shterenlikht said: > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > cpuid = 0 > > > > KDB: enter: panic > > > > [thread pid 67078 tid 100097 ] > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > Do you have a backtrace ? > > > > no, sorry, I was too quick to reboot. > > I tried to reproduce the error, got this on the way: > > If you add "options KDB_TRACE" to your kernel config, you'll get a stack > trace automatically on every panic. actually, I'll rebuild a kernel first, and then try to rebuid world. I'll put this in as well. Do I still need options KDB # Enable kernel debugger support if I put options KDB_TRACE? > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > There are no errors in this output; just make reporting that there was an > error. At -j6, the error message itself may be hundreds of lines back. > Make lets all remaining parallel jobs finish before exiting. ok, thanks, will keep in mind. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 14:40:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71596106564A for ; Tue, 7 Jul 2009 14:40:35 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: from us1.tomahawkonline.net (us1.tomahawkonline.net [66.98.178.56]) by mx1.freebsd.org (Postfix) with SMTP id 369508FC1A for ; Tue, 7 Jul 2009 14:40:34 +0000 (UTC) (envelope-from sagara@tomahawk.com.sg) Received: (qmail 23014 invoked by alias); 7 Jul 2009 10:55:50 -0000 Message-ID: <20090707105550.23013.qmail@us1.tomahawkonline.net> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> From: "Sagara Wijetunga" To: Ken Smith Date: Tue, 07 Jul 2009 05:55:50 -0500 Mime-Version: 1.0 X-Mailman-Approved-At: Tue, 07 Jul 2009 15:48:48 +0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 14:40:35 -0000 Ken Smith writes: > > The first public test build of the FreeBSD 8.0-RELEASE test cycle is now > available, 8.0-BETA1. Through the next week or so more information > about the release will be posted but here is the current target schedule > for the other 'major events': > > BETA2: July 13, 2009 > BETA3: July 20, 2009 > RC1: July 27, 2009 > RC2: August 17, 2009 > RELEASE:August 31, 2009 > Hi all Congratulations! This is a very good news though we did not expect FreeBSD 8.0 this soon. We planed our Tomahawk Desktop 3.0 to be based on FreeBSD 8.0. Now days we are very busy finalising the Tomahawk Desktop 2.0 beta to be released somewhere in August. Will sure give FreeBSD 8.0 a try after we released our 2.0 beta. We wish good luck to FreeBSD 8.0 team. Best regards Sagara From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 17:57:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B691C1065672 for ; Tue, 7 Jul 2009 17:57:39 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 6AA2D8FC1F for ; Tue, 7 Jul 2009 17:57:39 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.0/8.14.0) with ESMTP id n67Hvcbr089619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2009 12:57:38 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n67HvcL5056257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Jul 2009 12:57:38 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n67HvaWe056254; Tue, 7 Jul 2009 12:57:36 -0500 (CDT) (envelope-from dan) Date: Tue, 7 Jul 2009 12:57:35 -0500 From: Dan Nelson To: Anton Shterenlikht Message-ID: <20090707175735.GG5574@dan.emsphone.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707144554.GF5574@dan.emsphone.com> <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090707150052.GA49701@mech-cluster238.men.bris.ac.uk> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email2.allantgroup.com [199.67.51.78]); Tue, 07 Jul 2009 12:57:38 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Rink Springer , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 17:57:40 -0000 In the last episode (Jul 07), Anton Shterenlikht said: > On Tue, Jul 07, 2009 at 09:45:54AM -0500, Dan Nelson wrote: > > In the last episode (Jul 07), Anton Shterenlikht said: > > > On Tue, Jul 07, 2009 at 11:50:58AM +0200, Rink Springer wrote: > > > > On Tue, Jul 07, 2009 at 10:48:08AM +0100, Anton Shterenlikht wrote: > > > > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/trap.c:680 > > > > > cpuid = 0 > > > > > KDB: enter: panic > > > > > [thread pid 67078 tid 100097 ] > > > > > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe2a8e8,gp ;; > > > > > > > > Do you have a backtrace ? > > > > > > no, sorry, I was too quick to reboot. I tried to reproduce the error, > > > got this on the way: > > > > If you add "options KDB_TRACE" to your kernel config, you'll get a stack > > trace automatically on every panic. > > actually, I'll rebuild a kernel first, and then try to rebuid world. I'll > put this in as well. Do I still need > > options KDB # Enable kernel debugger support > > if I put options KDB_TRACE? I always have both, so I don't know if one requires the other. You should get a compile error if KDB is required and it's not listed. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 18:07:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E0A0106566C; Tue, 7 Jul 2009 18:07:49 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9098FC15; Tue, 7 Jul 2009 18:07:48 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n67I7kAH094219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 14:07:48 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Dan Naumov In-Reply-To: References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-7MsKdWumJEgDal7C3gEE" Organization: U. Buffalo CSE Department Date: Tue, 07 Jul 2009 14:07:43 -0400 Message-Id: <1246990063.25765.18.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:07:49 -0000 --=-7MsKdWumJEgDal7C3gEE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-07-07 at 16:05 +0300, Dan Naumov wrote: > Just wanted a small clarification, does livefs based rescue mode mean > "fixit environment" or not? Yes, that's what it means. It's known to not work at the moment but it's being worked on. I wanted to mention that because it might have been confusing given what I put onto it (the files needed for livefs mode are on it, sysinstall itself needs a bit more work though). But once that is working this is my guess as to what people would find most useful on such an image so I wanted to give people a feel for roughly how big they'll wind up being. It will basically be the dvd minus packages. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-7MsKdWumJEgDal7C3gEE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpTjuYACgkQ/G14VSmup/YI9ACghcxZFClQEx81cwrAoe/0Kz5K 0PgAn3ZksuFDlEya68HbFnMnc3vcepZb =/yqg -----END PGP SIGNATURE----- --=-7MsKdWumJEgDal7C3gEE-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 18:39:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FFDB106564A for ; Tue, 7 Jul 2009 18:39:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id E09248FC1D for ; Tue, 7 Jul 2009 18:39:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=mWr3Gg2zCNgJgtvLSuMA:9 a=Xg8A_g8-J_tqFkZdVEYA:7 a=SMLswts1WtyyLDmFcZ9DzLodgmEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1272763511; Tue, 07 Jul 2009 20:39:51 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 7 Jul 2009 20:39:26 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> <200907061750.39084.hselasky@c2i.net> In-Reply-To: <200907061750.39084.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907072039.27811.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:39:53 -0000 On Monday 06 July 2009 17:50:37 Hans Petter Selasky wrote: > On Monday 06 July 2009 16:11:54 Patrick Lamaiziere wrote: > > > > Shall I setup another box with current to be sure that's a problem > > with the printer and not with the hardware? > > Hi, > > urlpt was just for backwards compatibility. > > Could you try printing using /dev/unlpt0 ? And send me resulting dmesg? > > Power cycle your printer before testing. Hi, There was a small bug in my patch. Could you post-patching edit /sys/dev/serial/ulpt.c And move the: /* set raw write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 0); } And: /* set defrag write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 1); } outside the "if (sc->sc_fflags == 0)", so that the code looks like this: static int urlpt_open(struct usb_fifo *fifo, int fflags) { struct ulpt_softc *sc = usb_fifo_softc(fifo); /* we assume that open is a serial process */ if (sc->sc_fflags == 0) { /* reset USB paralell port */ ulpt_reset(sc); } /* set raw write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 0); } return (unlpt_open(fifo, fflags)); } static int ulpt_open(struct usb_fifo *fifo, int fflags) { struct ulpt_softc *sc = usb_fifo_softc(fifo); /* we assume that open is a serial process */ if (sc->sc_fflags == 0) { /* reset USB paralell port */ ulpt_reset(sc); } /* set defrag write mode */ if (fflags & FWRITE) { usb_fifo_set_write_defrag(fifo, 1); } return (unlpt_open(fifo, fflags)); } --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 18:49:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 627B61065677; Tue, 7 Jul 2009 18:49:34 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id D51248FC17; Tue, 7 Jul 2009 18:49:33 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n67InWJ2093449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 20:49:32 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A5398B5.40308@omnilan.de> Date: Tue, 07 Jul 2009 20:49:25 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Alexander Motin References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> In-Reply-To: <4A5053A8.2060902@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFFA3090460876D8E4D52748F" Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:49:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFFA3090460876D8E4D52748F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 05.07.2009 09:18 (localtime): =2E.. >> Can I safely remove glabel from the unmounted fs and relabel the new=20 >> device? >=20 > I don't very understand whet you mean by "safe"? Safe for what? I tuned off journaling in UFS and removed the journal from the=20 partition. Although gjournal told me that the existing filesystem will=20 be destroyed this didn't happen since I did the newfs on the .journal=20 partition originally. That's what I meant as "safe". In theory it was clear that I can safely=20 relabel the partition, but I was not sure if I understood everything=20 correctly. So far I have not had any problems with ahci, works great! (ich9) At least with HDs, haven't tested ODDs yet. (I'm having burning problems = for a long time so I'm not used to use ODDs with FreeBSD) One thing I'm missing is the possibility to spin down the drive. I have my system on a SSD, the HD is just for ports nad stuff which=20 usually I don't make use of. Is that planned to be integrated? Another question is why "camcontrol tur ada0" returns "Unit is not ready"= readcap also doesn't work. My SSD reports write and read cache present, but disabled. Is the report = or the status bad? camcontrol iden ada0 pass1: ATA/ATAPI-8 SATA 2.x device Protocol SATA revision 2.x device model OCZ SOLID SSD serial number MK0508480C17B0004 firmware revision 02.10104 cylinders 16383 heads 16 sectors/track 63 lba supported 62586880 sectors lba48 not supported dma supported overlap not supported Feature Support Enable Value Vendor write cache yes no read ahead yes no Native Command Queuing (NCQ) no - 0/0x00 Tagged Command Queuing (TCQ) no no 0/0x00 SMART yes yes microcode download no no security no no power management yes yes advanced power management no no 0/0x00 automatic acoustic management no no 254/0xFE 128/0x80 Thansk for your great work so far! Best regards, -Harry --------------enigFFA3090460876D8E4D52748F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpTmLsACgkQLDqVQ9VXb8jnLwCfdnC9/oCNwBVsI63lfSBorFK2 46oAoM2F9gt8DDg5puMYQaaXwrZyN6pC =SLla -----END PGP SIGNATURE----- --------------enigFFA3090460876D8E4D52748F-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 18:57:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAB4B1065675 for ; Tue, 7 Jul 2009 18:57:39 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0A6888FC13 for ; Tue, 7 Jul 2009 18:57:38 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n67IvbqU093739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 20:57:37 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A539AA0.3030901@omnilan.de> Date: Tue, 07 Jul 2009 20:57:36 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF835A6C57283DB3CD30B60EF" Subject: Where to report LORs? (ffs and unionfs LORs included X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 18:57:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF835A6C57283DB3CD30B60EF Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I remember when 7.0 was -current there was a specioal LOR reporting site.= Is it still the best place to report LORs? Currently I have some of them: lock order reversal: 1st 0xc88d88b8 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:492 2nd 0xd9ae0fb0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6= 170 3rd 0xc9d6a9c4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,ec8272cc,c05cfd9f,c05c170b,c0845f64,...)=20 at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f64,c5a0ee28,c5a12a48,ec827328,...) at=20 kdb_backtrace+0x29 _witness_debugger(c0845f64,c9d6a9c4,c0838ab3,c5a12a48,c084d2d2,...) at=20 _witness_debugger+0x1e witness_checkorder(c9d6a9c4,9,c084d2d2,823,0,...) at=20 witness_checkorder+0x815 __lockmgr_args(c9d6a9c4,80100,c9d6a9e0,0,0,...) at __lockmgr_args+0x771 ffs_lock(ec827430,c05cfb7b,c084c7c5,80100,c9d6a96c,...) at ffs_lock+0x7d VOP_LOCK1_APV(c08ad460,ec827430,cae79524,c08c33a0,c9d6a96c,...) at=20 VOP_LOCK1_APV+0xaf _vn_lock(c9d6a96c,80100,c084d2d2,823,4,...) at _vn_lock+0x5e vget(c9d6a96c,80100,cae79480,50,0,...) at vget+0xb8 vfs_hash_get(cb207c94,9bc0b,80000,cae79480,ec82758c,...) at=20 vfs_hash_get+0xdf ffs_vgetf(cb207c94,9bc0b,80000,ec82758c,1,...) at ffs_vgetf+0x43 softdep_sync_metadata(c88d8860,0,c085ff5b,146,0,...) at=20 softdep_sync_metadata+0x5a6 ffs_syncvnode(c88d8860,1,ec827624,c05cfb7b,c083e509,...) at=20 ffs_syncvnode+0x3c9 ffs_truncate(c88d8860,200,0,880,cb0fc400,...) at ffs_truncate+0x644 ufs_direnter(c88d8860,cd399d9c,ec8278e4,ec827bd8,0,...) at=20 ufs_direnter+0x8e0 ufs_makeinode(ec827bd8) at ufs_makeinode+0x4df ufs_create(ec827acc,ec827ae4,0,0,ec827bac,...) at ufs_create+0x2c VOP_CREATE_APV(c08ad460,ec827acc,ec827bd8,ec827a64,0,...) at=20 VOP_CREATE_APV+0xa2 vn_open_cred(ec827bac,ec827c60,1a4,0,cb0fc400,...) at vn_open_cred+0x1fc vn_open(ec827bac,ec827c60,1a4,c7e080e0,c08e0102,...) at vn_open+0x3b kern_openat(cae79480,ffffff9c,33f53970,0,602,...) at kern_openat+0x116 kern_open(cae79480,33f53970,0,601,1b6,...) at kern_open+0x35 open(cae79480,ec827cf8,c,ec827d2c,c088e6ec,...) at open+0x30 syscall(ec827d38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip =3D 0x33dd10fb, esp =3D=20 0xbfbfe02c, ebp =3D 0xbfbfe0b8 --- These two are with unionfs: lock order reversal: 1st 0xc62f08b8 unionfs (unionfs) @=20 /usr/src/sys/fs/unionfs/union_subr.c:356 2nd 0xc62f09c4 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2188 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e83a1868,c05cfd9f,c05c170b,c0845f4b,...)=20 at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a12b80,c5a12a48,e83a18c4,...) at=20 kdb_backtrace+0x29 _witness_debugger(c0845f4b,c62f09c4,c0838ab3,c5a12a48,c084d2d2,...) at=20 _witness_debugger+0x1e witness_checkorder(c62f09c4,9,c084d2d2,88c,0,...) at=20 witness_checkorder+0x815 __lockmgr_args(c62f09c4,80100,c62f09e0,0,0,...) at __lockmgr_args+0x771 ffs_lock(e83a19cc,c5a12b80,c084d2d2,80100,c62f096c,...) at ffs_lock+0x7d VOP_LOCK1_APV(c08ad460,e83a19cc,c0582686,c08c33a0,c62f096c,...) at=20 VOP_LOCK1_APV+0xaf _vn_lock(c62f096c,80100,c084d2d2,88c,c07ff2d1,...) at _vn_lock+0x5e vrele(c62f096c,e83a1a54,c62f08d4,0,0,...) at vrele+0x126 unionfs_noderem(c62f0860,c61d6480,e83a1a94,c07fe256,e83a1ab4,...) at=20 unionfs_noderem+0x4ac unionfs_reclaim(e83a1ab4,1,0,c62f0860,e83a1ad8,...) at unionfs_reclaim+0x= 1b VOP_RECLAIM_APV(c088b7c0,e83a1ab4,0,0,c62f08d4,...) at VOP_RECLAIM_APV+0x= 9f vgonel(c62f08d4,0,c084d2d2,9c5,e83a1b38,...) at vgonel+0x1a9 vrecycle(c62f0860,c61d6480,e83a1b20,c07fe326,e83a1b38,...) at vrecycle+0x= 45 unionfs_inactive(e83a1b38,c62f08d4,c62f0860,c62f08d4,e83a1b50,...) at=20 unionfs_inactive+0x28 VOP_INACTIVE_APV(c088b7c0,e83a1b38,c084d2d2,924,c08c3360,...) at=20 VOP_INACTIVE_APV+0xa0 vinactive(c088b7c0,e83a1b6c,c084d2d2,8aa,e83a1bfc,...) at vinactive+0x82 vput(c62f0860,e83a1c1c,c08409ec,64a,400,...) at vput+0x1c0 kern_readlinkat(c61d6480,ffffff9c,33d7898f,0,bfbfe003,...) at=20 kern_readlinkat+0x16d kern_readlink(c61d6480,33d7898f,0,bfbfe003,0,...) at kern_readlink+0x3c readlink(c61d6480,e83a1cf8,c,c0846dc1,c088ecb8,...) at readlink+0x38 syscall(e83a1d38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (58, FreeBSD ELF32, readlink), eip =3D 0x33cfb3ff, esp =3D=20 0xbfbfdf8c, ebp =3D 0xbfbfe418 --- lock order reversal: 1st 0xc794082c filedesc structure (filedesc structure) @=20 /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xc7f4bce8 ufs (ufs) @ /usr/src/sys/fs/unionfs/union_vnops.c:1821 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e847b9d0,c05cfd9f,c05c170b,c0845f4b,...)=20 at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0f100,c5a12a48,e847ba2c,...) at=20 kdb_backtrace+0x29 _witness_debugger(c0845f4b,c7f4bce8,c0838ab3,c5a12a48,c0834c57,...) at=20 _witness_debugger+0x1e witness_checkorder(c7f4bce8,9,c0834c57,71d,0,...) at=20 witness_checkorder+0x815 __lockmgr_args(c7f4bce8,80500,c7f4bd04,0,0,...) at __lockmgr_args+0x771 ffs_lock(e847bb4c,df,80500,80500,c7f5210c,...) at ffs_lock+0x7d VOP_LOCK1_APV(c08ad460,e847bb4c,c0834c57,71a,100000,...) at=20 VOP_LOCK1_APV+0xaf unionfs_lock(e847bb9c,4,0,80400,c7f5210c,...) at unionfs_lock+0x1d2 VOP_LOCK1_APV(c088b7c0,e847bb9c,c083acd9,c08c33a0,c7f5210c,...) at=20 VOP_LOCK1_APV+0xaf _vn_lock(c7f5210c,80400,c084d2d2,ffb,e847bbf8,...) at _vn_lock+0x5e vfs_knllock(c7f5210c,0,c083acd9,696,c7f4d088,...) at vfs_knllock+0x29 knlist_remove_kq(0,e847bc18,c0618395,c7d3801c,c7f4d088,...) at=20 knlist_remove_kq+0x85 knlist_remove(c7d3801c,c7f4d088,0,e847bc44,c05625ae,...) at=20 knlist_remove+0x1b filt_vfsdetach(c7f4d088,0,c083acd9,777,d,...) at filt_vfsdetach+0x39 knote_fdclose(c70f3b40,12cd,c083a810,440,c794082c,...) at knote_fdclose+0= xec kern_close(c70f3b40,12cd,e847bd2c,c07f304a,c70f3b40,...) at kern_close+0x= c8 close(c70f3b40,e847bcf8,4,c0846835,c088e708,...) at close+0x1a syscall(e847bd38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip =3D 0x33f6de2b, esp =3D=20 0xbfbfe71c, ebp =3D 0xbfbfe738 --- Some more: lock order reversal: 1st 0xd9914750 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc613f800 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:2= 85 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e850e864,c05cfd9f,c05c170b,c0845f4b,...)=20 at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0ee28,c5a12ab0,e850e8c0,...) at=20 kdb_backtrace+0x29 _witness_debugger(c0845f4b,c613f800,c0860649,c5a12ab0,c08602e2,...) at=20 _witness_debugger+0x1e witness_checkorder(c613f800,9,c08602e2,11d,0,...) at=20 witness_checkorder+0x815 _sx_xlock(c613f800,0,c08602e2,11d,c70ca244,...) at _sx_xlock+0x7f ufsdirhash_acquire(d99146f0,e850e9d8,174,da423aa4,e850e990,...) at=20 ufsdirhash_acquire+0x31 ufsdirhash_add(c70ca244,e850e9d8,aa4,e850e97c,e850e980,...) at=20 ufsdirhash_add+0x13 ufs_direnter(c70d2a78,c799e430,e850e9d8,e850ebe0,0,...) at=20 ufs_direnter+0x713 ufs_makeinode(e850ebe0) at ufs_makeinode+0x4df ufs_create(e850ec04,e850ec18,e850eb4c,e850eb4c,0,...) at ufs_create+0x2c VOP_CREATE_APV(c08ad460,e850ec04,e850ebe0,e850eb4c,c6408aac,...) at=20 VOP_CREATE_APV+0xa2 uipc_bind(c7266ce0,c70df300,c7272b40,e850ec64,c05fa439,...) at=20 uipc_bind+0x31f sobind(c7266ce0,c70df300,c7272b40,c70df300,c71fee70,...) at sobind+0x23 kern_bind(c7272b40,4,c70df300,c70df300,c71c8d48,...) at kern_bind+0xaf bind(c7272b40,e850ecf8,c,c0846835,c088f1c0,...) at bind+0x42 syscall(e850ed38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (104, FreeBSD ELF32, bind), eip =3D 0x33d91bd3, esp =3D=20 0xbfbfe87c, ebp =3D 0xbfbfe978 --- lock order reversal: 1st 0xc7fb012c filedesc structure (filedesc structure) @=20 /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xcac46ad0 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e84fba44,c05cfd9f,c05c170b,c0845f4b,...)=20 at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0f100,c5a12be8,e84fbaa0,...) at=20 kdb_backtrace+0x29 _witness_debugger(c0845f4b,cac46ad0,c08340c3,c5a12be8,c084d2d2,...) at=20 _witness_debugger+0x1e witness_checkorder(cac46ad0,9,c084d2d2,ffb,cac46aec,...) at=20 witness_checkorder+0x815 __lockmgr_args(cac46ad0,80400,cac46aec,0,0,0,c084d2d2,ffb) at=20 __lockmgr_args+0x771 vop_stdlock(e84fbb9c,4,0,80400,cac46a78,...) at vop_stdlock+0x5c VOP_LOCK1_APV(c088b540,e84fbb9c,c083acd9,c08c33a0,cac46a78,...) at=20 VOP_LOCK1_APV+0xaf _vn_lock(cac46a78,80400,c084d2d2,ffb,e84fbbf8,...) at _vn_lock+0x5e vfs_knllock(cac46a78,0,c083acd9,696,c703a94c,...) at vfs_knllock+0x29 knlist_remove_kq(0,e84fbc18,c0618395,cacf0364,c703a94c,...) at=20 knlist_remove_kq+0x85 knlist_remove(cacf0364,c703a94c,0,e84fbc44,c05625ae,...) at=20 knlist_remove+0x1b filt_vfsdetach(c703a94c,0,c083acd9,777,16,...) at filt_vfsdetach+0x39 knote_fdclose(c70f4b40,d6,c083a810,440,c7fb012c,...) at knote_fdclose+0xe= c kern_close(c70f4b40,d6,e84fbd2c,c07f304a,c70f4b40,...) at kern_close+0xc8= close(c70f4b40,e84fbcf8,4,c085afd4,c088e708,...) at close+0x1a syscall(e84fbd38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip =3D 0x33f6de2b, esp =3D=20 0xbfbfe5bc, ebp =3D 0xbfbfe5d8 --- lock order reversal: 1st 0xc7917880 kqueue (kqueue) @ /usr/src/sys/kern/kern_event.c:1112 2nd 0xc1c900e8 system map (system map) @ /usr/src/sys/vm/vm_map.c:2762 KDB: stack backtrace: db_trace_self_wrapper(c08430b6,e847b960,c05cfd9f,c05c170b,c0845f4b,...)=20 at db_trace_self_wrapper+0x26 kdb_backtrace(c05c170b,c0845f4b,c5a0c318,c5a0c178,e847b9bc,...) at=20 kdb_backtrace+0x29 _witness_debugger(c0845f4b,c1c900e8,c0861f20,c5a0c178,c086243d,...) at=20 _witness_debugger+0x1e witness_checkorder(c1c900e8,9,c086243d,aca,0,...) at=20 witness_checkorder+0x815 _mtx_lock_flags(c1c900e8,0,c086243d,aca,c7b3c000,...) at=20 _mtx_lock_flags+0xb8 _vm_map_lock(c1c9008c,c086243d,aca,c79956a8,c7b3a000,...) at=20 _vm_map_lock+0x31 vm_map_remove(c1c9008c,c7b3a000,c7b3c000,e847ba48,c078d0b9,...) at=20 vm_map_remove+0x2a kmem_free(c1c9008c,c7b3a000,2000,e847ba60,c078df06,...) at kmem_free+0x30= page_free(c7b3a000,2000,22,2000,e847ba84,...) at page_free+0x46 uma_large_free(c79956a8,c083acd9,458,c7b3a000,600,...) at=20 uma_large_free+0x89 free(c7b3a000,c0892874,1400,458,c7917880,...) at free+0xe9 kqueue_expand(0,500,e847baec,328,df,...) at kqueue_expand+0xf4 kqueue_register(1,e847bb48,1,0,0,...) at kqueue_register+0x11e kern_kevent(c70f3b40,3,1,0,e847bc5c,...) at kern_kevent+0xd7 kevent(c70f3b40,e847bcf8,18,c0846c74,c0890e14,...) at kevent+0x197 syscall(e847bd38) at syscall+0x281 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (363, FreeBSD ELF32, kevent), eip =3D 0x33f50c2b, esp =3D=20 0xbfbfe48c, ebp =3D 0xbfbfe6a8 --- --------------enigF835A6C57283DB3CD30B60EF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpTmqEACgkQLDqVQ9VXb8iZLACdGBlWjCVpL9pkTWWalGBc8im8 gUwAnjTmHFvqlVcExX9/caYkdsBxUC6F =OEVC -----END PGP SIGNATURE----- --------------enigF835A6C57283DB3CD30B60EF-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 19:06:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A4951065670; Tue, 7 Jul 2009 19:06:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id AB82E8FC19; Tue, 7 Jul 2009 19:06:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247940417; Tue, 07 Jul 2009 22:06:24 +0300 Message-ID: <4A539CA3.5030104@FreeBSD.org> Date: Tue, 07 Jul 2009 22:06:11 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <4A5398B5.40308@omnilan.de> In-Reply-To: <4A5398B5.40308@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 19:06:28 -0000 Harald Schmalzbauer wrote: > One thing I'm missing is the possibility to spin down the drive. > I have my system on a SSD, the HD is just for ports nad stuff which > usually I don't make use of. > Is that planned to be integrated? There is no problem, it just wasn't done yet. It should be possible to submit respective ATA command via CAM pass interface to spin-down drive immediately or to set wanted power management level, but respective user-level part in camcontrol is also not implemented yet. > Another question is why "camcontrol tur ada0" returns "Unit is not ready" > readcap also doesn't work. It is all SCSI commands. This implementation expects real direct ATA operation without SCSI emulation parts. But this commands should work for ATAPI devices, that are really SCSI deep inside. > My SSD reports write and read cache present, but disabled. Is the report > or the status bad? > Feature Support Enable Value Vendor > write cache yes no > read ahead yes no It is probably the truth. Existing ATA driver enables this features during drive reset sequence. New one doesn't do it yet. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 19:10:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 604F5106564A; Tue, 7 Jul 2009 19:10:53 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id BD3CB8FC15; Tue, 7 Jul 2009 19:10:52 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n67JApl2094261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jul 2009 21:10:51 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A539DBA.3080702@omnilan.de> Date: Tue, 07 Jul 2009 21:10:50 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Alexander Motin References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <4A5398B5.40308@omnilan.de> <4A539CA3.5030104@FreeBSD.org> In-Reply-To: <4A539CA3.5030104@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB6672EA0B17EE2D0D7A6B57" Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 19:10:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB6672EA0B17EE2D0D7A6B57 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 07.07.2009 21:06 (localtime): =2E.. Thanks for your aeplanations! >> Feature Support Enable Value Vendor= >> write cache yes no >> read ahead yes no >=20 > It is probably the truth. Existing ATA driver enables this features=20 > during drive reset sequence. New one doesn't do it yet. Ic, but my "real" HD ast it enabled: camcontrol iden ada1 pass2: ATA/ATAPI-7 SATA 2.x device Protocol SATA revision 2.x device model SAMSUNG HD322HJ serial number S17AJ9AS305229 firmware revision 1AG01113 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 625142448 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes no 0/0x00 254/0xFE Does the old school HD enable caches itself? Thanks, -Harry --------------enigEB6672EA0B17EE2D0D7A6B57 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpTnbsACgkQLDqVQ9VXb8gGfwCfQI+aZBCQN35vtFBaLJaWMR3P kkQAoLj+zclJBHb1+EcCcfqi0h1iM8EK =L+By -----END PGP SIGNATURE----- --------------enigEB6672EA0B17EE2D0D7A6B57-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 19:16:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F1C1065670; Tue, 7 Jul 2009 19:16:01 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 46A108FC20; Tue, 7 Jul 2009 19:15:59 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247940665; Tue, 07 Jul 2009 22:15:56 +0300 Message-ID: <4A539EDF.8080302@FreeBSD.org> Date: Tue, 07 Jul 2009 22:15:43 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Harald Schmalzbauer References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <4A5398B5.40308@omnilan.de> <4A539CA3.5030104@FreeBSD.org> <4A539DBA.3080702@omnilan.de> In-Reply-To: <4A539DBA.3080702@omnilan.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 19:16:01 -0000 Harald Schmalzbauer wrote: > Alexander Motin schrieb am 07.07.2009 21:06 (localtime): > ... > Thanks for your aeplanations! > >>> Feature Support Enable Value Vendor >>> write cache yes no >>> read ahead yes no >> >> It is probably the truth. Existing ATA driver enables this features >> during drive reset sequence. New one doesn't do it yet. > > Ic, but my "real" HD ast it enabled: > > Does the old school HD enable caches itself? Yes. At least this specific one. My OCZ Vertex SSD also has them enabled by default. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 19:34:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 460B71065678 for ; Tue, 7 Jul 2009 19:34:05 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id CD5078FC0C for ; Tue, 7 Jul 2009 19:34:04 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,364,1243807200"; d="scan'208";a="276576479" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 07 Jul 2009 21:33:51 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 2B6701B07E4; Tue, 7 Jul 2009 21:33:51 +0200 (CEST) Date: Tue, 07 Jul 2009 21:33:51 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Where to report LORs? (ffs and unionfs LORs included X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 19:34:05 -0000 try http://sources.zabbadoz.net/freebsd/lor.html alex From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 20:03:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D58CF106566C for ; Tue, 7 Jul 2009 20:03:51 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by mx1.freebsd.org (Postfix) with ESMTP id 5C4C08FC13 for ; Tue, 7 Jul 2009 20:03:50 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090707200349.KZNF5579.mtaout03-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 7 Jul 2009 21:03:49 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090707200349.DIUV13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com> for ; Tue, 7 Jul 2009 21:03:49 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n67K3jhj001870 for ; Tue, 7 Jul 2009 21:03:45 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by webmail.private.lan (Horde Framework) with HTTP; Tue, 07 Jul 2009 21:03:45 +0100 Message-ID: <20090707210345.13681mi2dwvan78k@webmail.private.lan> Date: Tue, 07 Jul 2009 21:03:45 +0100 From: Ian J Hart To: freebsd-current@freebsd.org References: <20090624153442.137934uzyotkb5og@10.248.192.16> In-Reply-To: <20090624153442.137934uzyotkb5og@10.248.192.16> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=ERehf_AEJYYA:10 a=NLZqzBF-AAAA:8 a=6I5d2MoRAAAA:8 a=VRdyzA9mAAAA:8 a=zd2uoN0lAAAA:8 a=6mGpWblYiIphEkupZzAA:9 a=hhl8yR7ykOPd4GsQp6AA:7 a=9b12fJnQ7G6RXEiHeUUZFmuqybYA:4 a=_dQi-Dcv4p4A:10 a=SV7veod9ZcQA:10 Subject: Re: zpool scrub errors on 3ware 9550SXU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 20:03:52 -0000 Quoting ianjhart@ntlworld.com: > Quoting ianjhart@ntlworld.com: > >> Quoting Kip Macy : >> >>>> >>>> As usual scrubs cleanly on 7.2. Started throwing errors within a >>>> few minutes under 8. Then it paniced, possibly due to scrub -s. >>>> >>>> It's sat at the DB prompt if there's anything I can do. I'll need >>>> idiots guide level instruction. I have a screen dump if someone >>>> want to step up. Off list? >>>> >>>> Highlight seems to be... >>>> >>>> Memory modified after free 0xffffff0004da0c00(248) val=3000000 @ >>>> 0xffffff0004dc00 >>>> Panic: most recently used by none >>> >>> Can you test with recent 7-STABLE? That would tell me whether or not >>> your hitting a general HEAD issues or problems with the v13 import. >> >> It's doing a scrub under 7.2 following another failed test. I'll >> pull it up to stable after that. >> >> Have more data will post that once I've done a couple a jobs. >> >>> >>> Thanks, >>> Kip > > Here's that extra data. > > Updated 3ware/AMCC card firmware. > > Enable onboard SATA and fit a 300GB SATA disk. Remove the floppy and > fit a second 300GB SATA disk. > > Remove the two 500GB disks and replace with 1.5TB units. I can now > create two 8 disk raidz2 giving the same 12 disks worth of storage I > had with one 14 disk raidz2. > > Reinstall the two O/S on the 300GB drives. > > > May be of use to someone, so bear with me. > > Reset to BIOS defaults. Some issues! Disabling sound helps. > > Now suspect motherboard BIOS may be part of the problem. Removed > both cards and tested each version in turn. > > ref: http://www.tyan.com.tw/support_download_bios.aspx?model=S.S2895 > > Started with 1.04 ended up with 1.04. Versions after, detect the > internal; SATA disks as 150 not 300. Most versions lock the keyboard > (KVM) when legacy USB is enabled. That's a PITA when you've just > taken the floopy disk out.No internal SATA disk settings. Be nice to > check the geometry as 7 and 8 sysinstall seem to be behaving > differently. > > With the cards back in. > > Add an ATA disk and CDROM while testing.Easyboot order is SATA0 ATA0 > SATA1. Fdisk the so far blank ATA disk :) > > On board audio clashes with something. BIOS 1.03 and later supports > 16 SCSI boot devices. I disabled booting from the RAID card to allow > the onboard SATA drives to boot. > > Out of space for option ROM error has gone. > > AFAIK CPUs are late enough to support DDR400. Check anyway. Clock > down to 333Mhz. Still fails. > > > > There's one last thing, this BIOS (1.04) does not supply the fix for > AMD errata 169. Later BIOS incorrectly detect the onboard SATA disks. > > Northbridge System Request Queue may stall. > > ref: > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf > > We don't seem to have /dev/msr. Could I fix this using (the shiny > new) cpucontrol? > > Thanks > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > FWIW this is still reproducable with 8.0-BETA1. -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Tue Jul 7 21:12:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1DB7106566C for ; Tue, 7 Jul 2009 21:12:04 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 672E68FC18 for ; Tue, 7 Jul 2009 21:12:04 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so2299660and.13 for ; Tue, 07 Jul 2009 14:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Phfr0cpzJ0abOORQfbC0mAGEIEghNXx0nTAjjqbIKzg=; b=hUKp1OjfgfepJGDSD0HbztUAQt+/84cyQb9XPbnwosboL3bPZb0OlS4K96yoz7Q+sP wf7+afmauXfkmNGC05t7aemzYwnD3A3WKQFc3dqu8RAki/H1anZ0a/4tXU8mBgAc84Ju orMEzi+JCNnxD05Oc9B9z5Ky1nty/bYSc/SsU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NfB3i5AgSIBpl20LLh8om9jkCT3qxKw2o58XUikPtNj0o/fSaaCNZnfSwYnBeidSbN NPZ5qvnPSJE84Fk+t8VYUbIGpTR915FTQY4w0GGPN3KjwbzY2C4BeMtUBoo5MahqOLl5 jGFsgQoI3kQylLRSLC8AZlu/0tWjAJS9wIXYE= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.123.12 with SMTP id v12mr11383223anc.21.1247001123734; Tue, 07 Jul 2009 14:12:03 -0700 (PDT) In-Reply-To: <20090707210345.13681mi2dwvan78k@webmail.private.lan> References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> Date: Tue, 7 Jul 2009 14:12:03 -0700 X-Google-Sender-Auth: 28065829092163e2 Message-ID: <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> From: Kip Macy To: Ian J Hart Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: zpool scrub errors on 3ware 9550SXU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 21:12:05 -0000 Did you answer my question of whether or not this can be reproduced on 7-ST= ABLE? -Kip On Tue, Jul 7, 2009 at 1:03 PM, Ian J Hart wrote: > Quoting ianjhart@ntlworld.com: > >> Quoting ianjhart@ntlworld.com: >> >>> Quoting Kip Macy : >>> >>>>> >>>>> As usual scrubs cleanly on 7.2. Started throwing errors within a few >>>>> minutes under 8. Then it paniced, possibly due to scrub -s. >>>>> >>>>> It's sat at the DB prompt if there's anything I can do. I'll need >>>>> idiots guide level instruction. I have a screen dump if someone want = to step >>>>> up. Off list? >>>>> >>>>> Highlight seems to be... >>>>> >>>>> Memory modified after free 0xffffff0004da0c00(248) val=3D3000000 @ >>>>> 0xffffff0004dc00 >>>>> Panic: most recently used by none >>>> >>>> Can you test with recent 7-STABLE? That would tell me whether or not >>>> your hitting a general HEAD issues or problems with the v13 import. >>> >>> It's doing a scrub under 7.2 following another failed test. I'll pull i= t >>> up to stable after that. >>> >>> Have more data will post that once I've done a couple a jobs. >>> >>>> >>>> Thanks, >>>> Kip >> >> Here's that extra data. >> >> Updated 3ware/AMCC card firmware. >> >> Enable onboard SATA and fit a 300GB SATA disk. Remove the floppy and fit= a >> second 300GB SATA disk. >> >> Remove the two 500GB disks and replace with 1.5TB units. I can now creat= e >> two 8 disk raidz2 giving the same 12 disks worth of storage I had with o= ne >> 14 disk raidz2. >> >> Reinstall the two O/S on the 300GB drives. >> >> >> May be of use to someone, so bear with me. >> >> Reset to BIOS defaults. Some issues! Disabling sound helps. >> >> Now suspect motherboard BIOS may be part of the problem. Removed both >> cards and tested each version in turn. >> >> ref: http://www.tyan.com.tw/support_download_bios.aspx?model=3DS.S2895 >> >> Started with 1.04 ended up with 1.04. Versions after, detect the interna= l; >> SATA disks as 150 not 300. Most versions lock the keyboard (KVM) when le= gacy >> USB is enabled. That's a PITA when you've just taken the floopy disk out= .No >> internal SATA disk settings. Be nice to check the geometry as 7 and 8 >> sysinstall seem to be behaving differently. >> >> With the cards back in. >> >> Add an ATA disk and CDROM while testing.Easyboot order is SATA0 ATA0 >> SATA1. Fdisk the so far blank ATA disk :) >> >> On board audio clashes with something. BIOS 1.03 and later supports 16 >> SCSI boot devices. I disabled booting from the RAID card to allow the >> onboard SATA drives to boot. >> >> Out of space for option ROM error has gone. >> >> AFAIK CPUs are late enough to support DDR400. Check anyway. Clock down t= o >> 333Mhz. Still fails. >> >> >> >> There's one last thing, this BIOS (1.04) does not supply the fix for AMD >> errata 169. Later BIOS incorrectly detect the onboard SATA disks. >> >> Northbridge System Request Queue may stall. >> >> ref: >> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/= 25759.pdf >> >> We don't seem to =A0have /dev/msr. Could I fix this using (the shiny new= ) >> cpucontrol? >> >> Thanks >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g" >> > > FWIW this is still reproducable with 8.0-BETA1. > > -- > ian j hart > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 00:13:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 799431065673; Wed, 8 Jul 2009 00:13:20 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 64EFD8FC0A; Wed, 8 Jul 2009 00:13:20 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMF002OLSLTXW50@asmtp023.mac.com>; Tue, 07 Jul 2009 17:13:06 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> Date: Tue, 07 Jul 2009 17:13:05 -0700 Message-id: References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1068) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:13:21 -0000 On Jul 7, 2009, at 2:48 AM, Anton Shterenlikht wrote: > on the console I get: > > panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/ia64/ia64/ > trap.c:680 > cpuid = 0 > KDB: enter: panic > [thread pid 67078 tid 100097 ] > Stopped at kdb_enter+0x92: [I2] addl > r14=0xffffffffffe2a8e8,gp ;; > db> This is already fixed. Just update your sources, build a new kernel, install it and reboot. Then you can continue the buildworld safely... FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 00:28:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 034A4106566C for ; Wed, 8 Jul 2009 00:28:56 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id A92E98FC08 for ; Wed, 8 Jul 2009 00:28:55 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so7532176yxe.3 for ; Tue, 07 Jul 2009 17:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=enXlZRnmA4oZ5tWhJZyTipwKyG0po2Mkck9y4CTE63o=; b=UIkqxWqQQEivFpasE1j5cnpSVQ68r72Q0Cd5K0ebi+NzTfDyOZ1C0IF2HOF/b1qKTm 82CpxBsOgD4gzi5uYhNacqDDlsM1ieXIH01lq6MvZ8Y6dgUaYY8Rf2vMN9qlh/B88AuY //suF8JLyd14A8J3sb+XaEFJD7HkrIx+4zkI0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=kqMdepvGVjUw0JTakMW2DJuLNTPWc5xz8BKoex9CMYWii468hbAI+4INohRYVy/FgO f+zZXrWuicCBAMWR7TyrWHnRdrk3tODaCqpuac2sjTkEyWzwL/y40cNs9o4cvOXNccXZ 7u0rYFBRGiqd50/CNWpPFZ1yCz1x3aA15ILrc= Received: by 10.90.86.10 with SMTP id j10mr5586422agb.97.1247012934719; Tue, 07 Jul 2009 17:28:54 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.209.40]) by mx.google.com with ESMTPS id 8sm1126115agd.37.2009.07.07.17.28.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 17:28:54 -0700 (PDT) From: Gonzalo Nemmi To: Gavin Atkinson Date: Tue, 7 Jul 2009 21:29:01 -0300 User-Agent: KMail/1.9.10 References: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> <1246963840.48637.44.camel@buffy.york.ac.uk> In-Reply-To: <1246963840.48637.44.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907072129.01232.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:28:56 -0000 On Tuesday 07 July 2009 7:50:40 am Gavin Atkinson wrote: > On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: > > Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to > > boot "with ACPI disabled" or "Safe Mode": > > > > Fatal trap 9: general protection fault while in kernel mode > > cpuid = 0; acpic id = 00 > > instruction pointer = 0x70:0xbfe4 > > stack pointer = 0x28:0xfa4 > > frame pointer = 0x28:0xfd4 > > code segment = base 0xc00f0000, limit 0xffff, type 0x1b > > = DPL 0, pres 1, def32 0, gran 0 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 0 (swapper) > > [thread pid 0 tid 100000 ] > > Stopped at 0xbfe4: *** error reading from address bfe4 *** > > db> bt > > Tracing pid 0 tid 100000 td 0x0da9b50 > > uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 > > db> > > This may well be a known problem that has affected certain Intel > motherboards since around 5.x. Although this problem may well be > solvable, perhaps the better approach is to fix whatever is stopping > you from booting with ACPI enabled? Hello Gavin :) Actually I can boot with ACPI enabled (default boot), what I can't boot is "with ACPI disabled" or in "Safe Mode" since both of them throw a Fatal trap 9. > If for some reason you cannot have ACPI enabled, I guess knowing more > output than the above would be useful. For example, when booting > verbose and with ACPI disabled, what lines are printed before the > above? > > (to do this, break to the loader prompt, and: > > setenv hint.acpi.0.disabled=1 > setenv hint.apic.0.disabled=1 > boot -v setenv hint.acpi.0.disabled=1 and setenv hint.apic.0.disabled=1 yielded a stack overflow each one, so I tried booting to the loader (#6) and then: OK set hint.acpi.0.disabled=1 OK set hint.apic.0.disabled=1 OK boot -v That resulted in the very same Fatal trap 9 described above :s The lines before I get the Fatal trap are: 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 ex_isa_identify() pnpbios: 13 devices, largest 146 bytes PNP0a3: adding io range 0xcf8-0xcff, size=0x8, align=0x2 pnpbios: handle 0 device ID PNP0a03 (030ad041) Fatal trap 9: general protection fault while in kernel mode ... > it's also worth trying just with the first one to just disable ACPI, > then just trying the APIC option, to see which of those two are > causing you problems) > > By the way, is this i386 or amd64? CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz 686-class CPU) You'll fin my boot -v in here should you like to take a look at it: http://pastebin.com/f604c1399 > Gavin Thanks for your concern :) -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 00:29:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F031065702; Wed, 8 Jul 2009 00:29:08 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 7137F8FC16; Wed, 8 Jul 2009 00:29:08 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMF00IBXTCIG970@asmtp029.mac.com>; Tue, 07 Jul 2009 17:29:08 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090707133611.GA66072@rink.nu> Date: Tue, 07 Jul 2009 17:29:06 -0700 Message-id: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> To: Rink Springer X-Mailer: Apple Mail (2.1068) Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:29:09 -0000 On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >> I tried to reproduce the error, got this on the way: >> >> # XXX: bogusly disabled high FP regs > > I get this message quite often as well; I intend to figure out what's > going on. Marcel, if you have any idea, please let me know. It's a race condition. The high FP registers are lazily context-switched and this error is emitted when a thread wants to use the high FP registers when they are disabled and the CPU onto which the thread is running has the high FP registers corresponding to that thread in registers. In that scenario the high FP registers should not even be disabled. In the above case the kernel simply enables the high FP registers and continues the thread. For the most part the condition is harmless, but I've been looking at a panic that's the result of inconsistency in the high FP state, so the race is potentially fatal. BTW: I never got the error when doing a buildworld. I think Anton's non-standard compiler options make GCC much more FP intensive and thus prone to causing the race. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 00:47:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A39106566C for ; Wed, 8 Jul 2009 00:47:50 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id BA5108FC19 for ; Wed, 8 Jul 2009 00:47:49 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by gxk6 with SMTP id 6so5947682gxk.19 for ; Tue, 07 Jul 2009 17:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=XpQjC772sII1f7WG2vfvC3UIvu4/OJI/tr4G8uUBqJY=; b=JKN5HDHqLchQszY7RaLn+9XOX3JvP7gom6sw1hoPrj+3TyD/wBbNU7dbWVzTgs+G22 K6A8L9RvL+k60agGVVr4+uiIILMeN6l8S08tpFwfv+uaHoHc1Uvb/kCwS+Z0AnrTd4V2 Xwyr+kSiXhtFY6LqYSgqLDdNtE0JrFO8RW2xI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=nlOdXY5lASaLCXq6rJbF3ycjuLGmeDZybxbEg9GNICM2N9WU6X8SLG6fNK0+qU3Gbj 2s589CfFRoSdCF0S/RM+vPiY448fQ2ZAWfWc4eFQHe0zEVnp486Grfx7EFfbdR6USTy4 rizYNpQ7A+DCeZIgg2IuygyJvGliYXymn9z5o= Received: by 10.90.84.17 with SMTP id h17mr5268721agb.28.1247014069123; Tue, 07 Jul 2009 17:47:49 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.209.40]) by mx.google.com with ESMTPS id 25sm7459751aga.57.2009.07.07.17.47.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 17:47:48 -0700 (PDT) From: Gonzalo Nemmi To: Aragon Gouveia Date: Tue, 7 Jul 2009 21:47:55 -0300 User-Agent: KMail/1.9.10 References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <4A5348A4.60401@phat.za.net> In-Reply-To: <4A5348A4.60401@phat.za.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907072147.55632.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:47:50 -0000 On Tuesday 07 July 2009 10:07:48 am Aragon Gouveia wrote: > Hi, > > Gonzalo Nemmi wrote: > > log in > > acpiconf -s 3 > > suspend works > > opened the lid and the screen doesn't come back (backlight never > > gets back) hard reset > > login again and checked /var/log/messages .. this is what I found: > > I have problems with suspend too, on AMD64. Basically it works and > my systems comes back up, but some devices are hosed afterwards. > > My bge network interface is one. I get precisely the same PHY > timeout errors you're getting after a suspend. Thos timeouts are all over 7.X, -CURRENT and now -BETA1 .. hope they don't make it into 8.0-RELEASE !!! > The iwn network driver screams the following if I try use it after a > > suspend: > > Jul 7 14:53:17 fuzz kernel: iwn0: iwn_mem_lock: could > > not lock memory Jul 7 14:53:17 fuzz last message > > repeated 7 times Jul 7 14:53:17 fuzz kernel: iwn0: > > iwn_transfer_microcode: could not load boot firmware Jul 7 > > 14:53:17 fuzz kernel: iwn0: iwn_transfer_firmware: > > could not load boot firmware, error 60 Jul 7 14:53:17 > > fuzz kernel: iwn0: iwn_init_locked: could not load firmware, error > > 60 At least you wifi card is supported .. mine is not :( > USB ports resume sometimes, sometimes not: > > Jul 7 14:58:44 fuzz kernel: usbus2: port reset timeout > > Jul 7 14:58:44 fuzz kernel: uhub_reattach_port:369: > > port 1 reset failed, error=USB_ERR_TIMEOUT Jul 7 14:58:44 > > fuzz kernel: uhub_reattach_port:456: device problem > > (USB_ERR_TIMEOUT), disabling port 1 Jul 7 14:58:44 > > fuzz kernel: usbus6: port reset timeout Jul 7 14:58:44 > > fuzz kernel: uhub_reattach_port:369: port 5 reset failed, > > error=USB_ERR_TIMEOUT Jul 7 14:58:44 fuzz kernel: > > uhub_reattach_port:456: device problem (USB_ERR_TIMEOUT), disabling > > port 5 Jul 7 14:58:55 fuzz kernel: uhci_interrupt: > > resume detect Jul 7 14:58:55 fuzz kernel: ugen6.2: > > at usbus6 (disconnected) Jul 7 > > 14:58:55 fuzz kernel: ugen5.2: at > > usbus5 (disconnected) Jul 7 14:58:56 fuzz kernel: > > usbus6: port reset timeout Jul 7 14:58:56 fuzz kernel: > > uhub_reattach_port:369: port 6 reset failed, error=USB_ERR_TIMEOUT > > Jul 7 14:58:56 fuzz kernel: uhub_reattach_port:456: > > device problem (USB_ERR_TIMEOUT), disabling port 6 Never got them .. but now that you mention it .. I think I never tried acpiconf -s 3 with a usb dongle attached to the system .. will try though !! > And I just noticed this message: > > Jul 7 14:53:36 fuzz kernel: calcru: runtime went > > backwards from 18237633 usec to 9377885 usec for pid 10 (idle) > > Unloading modules from the kernel prior to suspending doesn't seem to > work either. Nop .. unloading modules doesn't help at all in here neither :( > On the upside, FreeBSD 8.0 boots rather quickly! :) Yup .. nice boot times ! > > Regards, > Aragon Best Regards Gonzalo -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 00:50:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92A75106564A for ; Wed, 8 Jul 2009 00:50:31 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 445B28FC12 for ; Wed, 8 Jul 2009 00:50:30 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so7553043yxe.3 for ; Tue, 07 Jul 2009 17:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=mk6bJcBExZ14AEWTTNRUggsq0BaeommXZs8KW7mAJ2Y=; b=wHA3an/PrSgXk6zC7LV8BR0sDIM/P7ysDh0KvLicLVi2w3Zb1GyYIfElzL7MbNH4Lf OpAOWzRgUOqKx62He7aOc9kECP9kKKtglMQ6+RTmbBPi0Qx7p1rpAw8STunpH5D86L3N uiU6LD68m0b+8cmqwAWwkPlYjww+UUgW8e8Ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=DMWMzdWSrjWKq0OxnB7Egt3qQlpKHzJEM3iLEpbdrS65V5hqDFda7V0iwBal+VtVRK 0mJV+F92/XdClzJygjaPJfqZfRDNzwJ8UQyJnK/xpacJkEOAt6KCSj4nvWpLMY8DPHkL 1XivfrsohFNrlXzc70oNw9KMVHNGhN+WJvAQA= Received: by 10.90.94.2 with SMTP id r2mr3047469agb.113.1247014229885; Tue, 07 Jul 2009 17:50:29 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.209.40]) by mx.google.com with ESMTPS id 7sm5645133aga.27.2009.07.07.17.50.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 17:50:29 -0700 (PDT) From: Gonzalo Nemmi To: "Paul B. Mahol" Date: Tue, 7 Jul 2009 21:50:36 -0300 User-Agent: KMail/1.9.10 References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> In-Reply-To: <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907072150.36428.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 00:50:31 -0000 On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: > On 7/7/09, Gonzalo Nemmi wrote: > > log in > > acpiconf -s 3 > > suspend works > > opened the lid and the screen doesn't come back (backlight never > > gets back) hard reset > > login again and checked /var/log/messages .. this is what I found: > > > > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > > (disconnected) > > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > > (disconnected) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 0, val 32768) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 0, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 24, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 16, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 16, val 0) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 16, val 0xffffffff) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 16, val 0) > > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 23, val 18) > > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init > > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization > > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a > > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: > > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: > > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: > > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle > > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID > > Count=1, CYCLEMASTER mode > > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > > cable IRM irm(0) (me) > > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept > > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: > > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 > > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] > > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 > > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > > > > any hints on how to further debug or redirect this mail to the > > right list will be greatly appreciated. > > > > more info can be found in here: > > http://forums.freebsd.org/showthread.php?t=3886 > > > > Best Regards > > Gonzalo Nemmi > > i386 resume doesn't work with SMP kernel and SMP CPU. > On amd64 make sure that you have right file loaded in kernel: > for example i915.ko for intel cards. I shoul've mentioned I'm on a: CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz 686-class CPU) and that I've added: hint.smp.disabled=1 to my /boot/device.hints This is what I get: Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept 00:01:19) Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 Should I file a PR? Once again, boot -v in here: http://pastebin.com/f604c1399 More info on my hardware and other messages: http://forums.freebsd.org/showthread.php?t=3886 Best Regards Gonzalo -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 01:13:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4407C106564A for ; Wed, 8 Jul 2009 01:13:56 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id EE4D38FC0A for ; Wed, 8 Jul 2009 01:13:55 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by gxk6 with SMTP id 6so5969704gxk.19 for ; Tue, 07 Jul 2009 18:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=8r9VcR/dairu7yzmaG01hBTvT/yzCxfOhtyCl9to4zQ=; b=nmhAZ+MEFMlDhI4VihDCpsGp1QEuWMjcFZALETNKBOV7b3qQs0eDxg9ufVjAwBcGjg 4CbRsrdq/Q73VyjA6iu50HRJh77qzQDvXJoDODjGXsOj0AvuTyX5K/GH5z4yDQMjPh5C j1sj5oKaXM3PlcBYShWqNBOHa3MR+2UbWSqPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=AjuXEgJ0BdPnv547DkvU/M5MdJRmXAFt/c2GLhqjF7PQyxnKXH4XI/HwAdmudwtABT EdIOvv3/7XnNJXNda7S/jLq4M6HYhQqB2/ub3RjAw4krqXmFA64tTSqkckG0XFr/xBtt r/lk0+RhPArVgkt3ncOlFM1oXwgmNpMJ+3hJ8= Received: by 10.90.86.9 with SMTP id j9mr796234agb.13.1247015635197; Tue, 07 Jul 2009 18:13:55 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.209.40]) by mx.google.com with ESMTPS id 9sm1109274agb.35.2009.07.07.18.13.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 07 Jul 2009 18:13:54 -0700 (PDT) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Tue, 7 Jul 2009 22:14:01 -0300 User-Agent: KMail/1.9.10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907072214.01645.gnemmi@gmail.com> Subject: LOR on kldunload snd_hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 01:13:56 -0000 log in kldload snd_hda cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386) Installed devices: pcm0: at cad 0 nid 1 on hdac0 kld snd_hda [MPSAFE] (1p:1v/1r:1v channels duplex default) mixer Mixer vol is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer mic is currently set to 0:0 Mixer rec is currently set to 0:0 "insert cd" cdcontrol -f /dev/acd0 play 1 "no sound at all" cdcontrol eject kldunload snd_hda Jul 7 21:44:15 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 7 21:54:27 gargoyle kernel: hdac0: mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on pci0 Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Driver Revision: 20090624_0136 Jul 7 21:54:27 gargoyle kernel: hdac0: [ITHREAD] Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X Jul 7 21:54:27 gargoyle kernel: pcm0: at cad 0 nid 1 on hdac0 Jul 7 22:03:27 gargoyle kernel: lock order reversal: Jul 7 22:03:27 gargoyle kernel: 1st 0xc0da8cdc kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 Jul 7 22:03:27 gargoyle kernel: 2nd 0xc0daa4e4 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:255 Jul 7 22:03:27 gargoyle kernel: KDB: stack backtrace: Jul 7 22:03:27 gargoyle kernel: db_trace_self_wrapper(c0c5b564,e6df7ac0,c08b5b35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 7 22:03:27 gargoyle kernel: kdb_backtrace(c08a68db,c0c5e3f9,c452cae8,c452ad40,e6df7b1c,...) at kdb_backtrace+0x29 Jul 7 22:03:27 gargoyle kernel: _witness_debugger(c0c5e3f9,c0daa4e4,c0c58fbb,c452ad40,c0c58ec2,...) at _witness_debugger+0x25 Jul 7 22:03:27 gargoyle kernel: witness_checkorder(c0daa4e4,9,c0c58ec2,ff,0,...) at witness_checkorder+0x839 Jul 7 22:03:27 gargoyle kernel: _sx_xlock(c0daa4e4,0,c0c58ec2,ff,0,...) at _sx_xlock+0x85 Jul 7 22:03:27 gargoyle kernel: sysctl_ctx_free(c4d7379c,0,c4e1c712,4a1,c4ca9480,...) at sysctl_ctx_free+0x30 Jul 7 22:03:27 gargoyle kernel: pcm_unregister(c488f800,c4da3860,c0d3b6c8,a3c,c4887a80,...) at pcm_unregister+0x4e1 Jul 7 22:03:27 gargoyle kernel: device_detach(c488f800,c0865663,c0da9df0,c4dd22d4,c4a95100,...) at device_detach+0x8c Jul 7 22:03:27 gargoyle kernel: driver_module_handler(c4887a80,1,c4dd22d4,109,0,...) at driver_module_handler+0x29c Jul 7 22:03:27 gargoyle kernel: module_unload(c4887a80,c0c54c7c,273,270,c08592b6,...) at module_unload+0x43 Jul 7 22:03:27 gargoyle kernel: linker_file_unload(c4a92600,0,c0c54c7c,437,c4dba000,...) at linker_file_unload+0x15e Jul 7 22:03:27 gargoyle kernel: kern_kldunload(c4ca9480,2,0,e6df7d2c,c0b98e73,...) at kern_kldunload+0xd5 Jul 7 22:03:27 gargoyle kernel: kldunloadf(c4ca9480,e6df7cf8,8,c0c5f4bb,c0d3f0b0,...) at kldunloadf+0x2b Jul 7 22:03:27 gargoyle kernel: syscall(e6df7d38) at syscall+0x2a3 Jul 7 22:03:27 gargoyle kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 7 22:03:27 gargoyle kernel: --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280d573b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 --- Jul 7 22:03:27 gargoyle kernel: pcm0: detached Jul 7 22:03:27 gargoyle kernel: hdac0: detached Any pointers?? Best Regards Gonzalo -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 01:54:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 675A1106564A for ; Wed, 8 Jul 2009 01:54:34 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by mx1.freebsd.org (Postfix) with ESMTP id 1E7488FC14 for ; Wed, 8 Jul 2009 01:54:33 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qyk42 with SMTP id 42so1913748qyk.3 for ; Tue, 07 Jul 2009 18:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rGHC67gpHHwqhaDdB8nhnnAuYsBPqDMfckr+0ASXAig=; b=DDnvzW9MU43HxbgaBfGa/HPWzqc6bkNhJconc/diP/H1g7OMYM4ahnLHgndSduqwHn kvUOD2XvdEhDTXM8TjRtcW2+R6UWOoNi0JK3a7zyeM5Awd7Z7TIIkgulGUT75gWXUwAr YW7MIZytm2LhIRhQCZoi/HD6hqwiOhbXa2Fk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U6mh3zhRdo97uiScFFpY1EnCtgoI01VlSDK8l0hji0A+TVVr0n+hvmIPTTjlNCEkNt 4DLfZr5xKkwZbcrwVIz8KcnlCxQ/W0WB+8RLLD9BACpBYp2fePJm0/0Q3Az3B3y/E4FT UHwmwbP7Undg0VtAGcevBUs3XNQx8XhAvroEM= MIME-Version: 1.0 Received: by 10.229.96.9 with SMTP id f9mr3560843qcn.78.1247018073434; Tue, 07 Jul 2009 18:54:33 -0700 (PDT) In-Reply-To: <200907072214.01645.gnemmi@gmail.com> References: <200907072214.01645.gnemmi@gmail.com> Date: Tue, 7 Jul 2009 20:54:33 -0500 Message-ID: <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> From: "Sam Fourman Jr." To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: LOR on kldunload snd_hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 01:54:34 -0000 On Tue, Jul 7, 2009 at 8:14 PM, Gonzalo Nemmi wrote: > log in > kldload snd_hda > cat /dev/sndstat > > FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386) > Installed devices: > pcm0: at cad 0 nid 1 on hdac0 kld > snd_hda > [MPSAFE] (1p:1v/1r:1v channels duplex default) > > mixer > Mixer vol is currently set to 75:75 > Mixer pcm is currently set to 75:75 > Mixer speaker is currently set to 75:75 > Mixer mic is currently set to 0:0 > Mixer rec is currently set to 0:0 > > "insert cd" > > cdcontrol -f /dev/acd0 play 1 > > "no sound at all" > > cdcontrol eject > kldunload snd_hda I have a similar problem with snd_hda on a 6-1-2009 -CURRENT i386 kernel everything is fine but on a 6-24-2009 -CURRENT i386 kernel I have sound in vlc, but not in my wine applications the moment I boot into a 6-1-2009 kernel everything works fine. Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 03:39:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B51331065672 for ; Wed, 8 Jul 2009 03:39:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3F78FC35 for ; Wed, 8 Jul 2009 03:39:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz21 with SMTP id 21so1421830bwz.43 for ; Tue, 07 Jul 2009 20:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RUFo4+9oO7M5R+VzBgsx7Jzh4vacZ7yWxRbhYW6B/Wc=; b=kArktet/XRTm7Uguje4XikcaIZ0W8/Xt/gDd9hWtZ/YvvAPmkrl7eBVSuGp3swhHSS 52o8bflq72HR+OjUx8cL4GDzT2FJa3iDP9eAmjxR1f7OWIKOqNzTrZx2lm/yrO9Q3OuW 6Rhw1SDWUOUUPav2sarmTCNUKxmpuPwBNAiv4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NkxncTNgKxTzQ8C4stCZNYVTzgwVfpEYF2LRhJuQ4Qy9xnV6G5sj5NIVIYWljR52qk EgY2/R/r9JMHERjFpTM0oWDF2XsSeYNV7q12CErTaqydnoOJH9BF84Qi5A7Mm8a8/fIj 0qGXd4qYdnzMzmeuYjoV7/cPf6ZpYKKTABdBY= MIME-Version: 1.0 Received: by 10.204.68.10 with SMTP id t10mr6511927bki.182.1247024386802; Tue, 07 Jul 2009 20:39:46 -0700 (PDT) In-Reply-To: <200907072150.36428.gnemmi@gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> Date: Wed, 8 Jul 2009 05:39:46 +0200 Message-ID: <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> From: "Paul B. Mahol" To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 03:39:49 -0000 On 7/8/09, Gonzalo Nemmi wrote: > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: >> On 7/7/09, Gonzalo Nemmi wrote: >> > log in >> > acpiconf -s 3 >> > suspend works >> > opened the lid and the screen doesn't come back (backlight never >> > gets back) hard reset >> > login again and checked /var/log/messages .. this is what I found: >> > >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 >> > (disconnected) >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 >> > (disconnected) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 0, val 32768) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 0, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 24, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 16, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 16, val 0) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 16, val 0xffffffff) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 16, val 0) >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 23, val 18) >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID >> > Count=1, CYCLEMASTER mode >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 >> > cable IRM irm(0) (me) >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: > > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 >> > >> > any hints on how to further debug or redirect this mail to the >> > right list will be greatly appreciated. >> > >> > more info can be found in here: >> > http://forums.freebsd.org/showthread.php?t=3886 >> > >> > Best Regards >> > Gonzalo Nemmi >> >> i386 resume doesn't work with SMP kernel and SMP CPU. >> On amd64 make sure that you have right file loaded in kernel: >> for example i915.ko for intel cards. > > I shoul've mentioned I'm on a: > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > 686-class CPU) > > and that I've added: hint.smp.disabled=1 to my /boot/device.hints > > This is what I get: > > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 0, val 32768) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, > val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 24, val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 16, val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 16, val 0) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 16, val 0xffffffff) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 16, val 0) > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 23, val 18) > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > ports. > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > IRM irm(0) (me) > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept > 00:01:19) > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 > > Should I file a PR? > > Once again, boot -v in here: http://pastebin.com/f604c1399 > > More info on my hardware and other messages: > http://forums.freebsd.org/showthread.php?t=3886 > > Best Regards > Gonzalo > -- > Blessings > Gonzalo Nemmi > Sorry, but I dont see what graphic card you are using. Anyway, on i386 you must load vesa.ko if ypu want that resume also resumes video -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 03:59:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCB2F1065672 for ; Wed, 8 Jul 2009 03:59:39 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD4C8FC08 for ; Wed, 8 Jul 2009 03:59:39 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by gxk6 with SMTP id 6so6105525gxk.19 for ; Tue, 07 Jul 2009 20:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=n3+u0kr+/Yh5uzjTmck5m1I4L7pMYoSUbH7ks875ycc=; b=P18u7XBDvGQn4wNlmHYTA56p2+YKYcbtK+OJdtS29oHgDD0jiBbG1MHrGTX3ZEOMEg rFI6p5HFHfwySWaLuBAuX5rRzKSMJxdtJrwtNhBh1tQadf0gqKW7Qs62uG8ScF/sxt5n 4bXGFIc97datGHLXQ1xG8BLJ3hzPUsaFvZUFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jq4SxiUv8Hsh01/yCI7AoD1Fl/LxqPrtnKCkBQxeR+jAI3or4y0LO5enihNosQ2xNn 0aEzM4PJ8Dkh66cWZNrklgur3PiphiHxlRHfPtrY3PbqdlJpEwB1UTtSyvtL3esZNUUP ypja8Kdp6/U/stDH9bqgZqGfN5PsJ1WOEfejQ= MIME-Version: 1.0 Received: by 10.90.96.1 with SMTP id t1mr5405870agb.9.1247025578734; Tue, 07 Jul 2009 20:59:38 -0700 (PDT) In-Reply-To: <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> Date: Wed, 8 Jul 2009 00:59:38 -0300 Message-ID: <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> From: Gonzalo Nemmi To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 03:59:40 -0000 On Wed, Jul 8, 2009 at 12:39 AM, Paul B. Mahol wrote: > On 7/8/09, Gonzalo Nemmi wrote: > > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: > >> On 7/7/09, Gonzalo Nemmi wrote: > >> > log in > >> > acpiconf -s 3 > >> > suspend works > >> > opened the lid and the screen doesn't come back (backlight never > >> > gets back) hard reset > >> > login again and checked /var/log/messages .. this is what I found: > >> > > >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > >> > (disconnected) > >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > >> > (disconnected) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 0, val 32768) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 0, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 24, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 16, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 16, val 0) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 16, val 0xffffffff) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 16, val 0) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 23, val 18) > >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init > >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization > >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a > >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: > >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: > >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: > >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle > >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID > >> > Count=1, CYCLEMASTER mode > >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > >> > cable IRM irm(0) (me) > >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept > >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: > >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: >> > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 > >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] > >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 > >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > >> > > >> > any hints on how to further debug or redirect this mail to the > >> > right list will be greatly appreciated. > >> > > >> > more info can be found in here: > >> > http://forums.freebsd.org/showthread.php?t=3886 > >> > > >> > Best Regards > >> > Gonzalo Nemmi > >> > >> i386 resume doesn't work with SMP kernel and SMP CPU. > >> On amd64 make sure that you have right file loaded in kernel: > >> for example i915.ko for intel cards. > > > > I shoul've mentioned I'm on a: > > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > > 686-class CPU) > > > > and that I've added: hint.smp.disabled=1 to my /boot/device.hints > > > > This is what I get: > > > > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 > > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 > > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 0, val 32768) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, > > val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 24, val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 16, val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 16, val 0) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 16, val 0xffffffff) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 16, val 0) > > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 23, val 18) > > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed > > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure > > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > > ports. > > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset > > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: > > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > > IRM irm(0) (me) > > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 > > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error > > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept > > 00:01:19) > > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 > > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 > > > > Should I file a PR? > > > > Once again, boot -v in here: http://pastebin.com/f604c1399 > > > > More info on my hardware and other messages: > > http://forums.freebsd.org/showthread.php?t=3886 > > > > Best Regards > > Gonzalo > > -- > > Blessings > > Gonzalo Nemmi > > > > Sorry, but I dont see what graphic card you are using. > Anyway, on i386 you must load vesa.ko if ypu want that resume also resumes > video > > -- > Paul 322 vgapci0: port 0xeff8-0xefff mem 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 323 agp0: on vgapci0 324 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 325 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf6e00000 326 agp0: detected 7676k stolen memory 327 agp0: aperture size is 256M 328 vgapci1: mem 0xf6f00000-0xf6ffffff at device 2.1 on pci0 im not running X or anything .. so I guess im using whatever module 8 uses by default (actually I thought it was the vesa module), this is just a plain 8.0-BETA1 install (not even a single port installed). will try loading vesa, see what happens and report back. Thanks for your interest and help Best Regards Gonzalo From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 04:04:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B486106564A for ; Wed, 8 Jul 2009 04:04:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id B99BB8FC08 for ; Wed, 8 Jul 2009 04:04:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz21 with SMTP id 21so1426703bwz.43 for ; Tue, 07 Jul 2009 21:04:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cJ2Q2NI1Qo3vX7TI8TgUSHZpQ/TVpWp3ks106TZ5CDY=; b=rgLlthhcj2MhKV7IMAk5oZoHQurSqOukoyrB7vLowCvK2cGsqwNeVIVQvAieeiILUe 22ExZM0EmGhmCpf4l6SyQOVpkuagQFxtlHPcUwDvG0cVdFuy4oM0si3jA6jnviX7DpDy G/Q5LtAdyYIs8jmqE4/7sJMm7447iPjTo/7rY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MyEzn3tUARxyyjaZrLzpEiuzlF29dVSPdLM2Dvpx3BVZHdsVUP0DgEm0/ZDHD9nTJP SauzaGe4Rfa3o8neNSLvDGrsJhq+6OyvwSjb8mQPh/6fu6RL4+MXnBLBu1DAPmfSbzWd CY2PZlIlwntlFW4V4at31+el2lsSbFMDMbQa4= MIME-Version: 1.0 Received: by 10.204.101.13 with SMTP id a13mr6526384bko.89.1247025891665; Tue, 07 Jul 2009 21:04:51 -0700 (PDT) In-Reply-To: <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> Date: Wed, 8 Jul 2009 06:04:51 +0200 Message-ID: <3a142e750907072104m2787e7f0p5dd30008ad11170d@mail.gmail.com> From: "Paul B. Mahol" To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 04:04:53 -0000 On 7/8/09, Gonzalo Nemmi wrote: > On Wed, Jul 8, 2009 at 12:39 AM, Paul B. Mahol wrote: > >> On 7/8/09, Gonzalo Nemmi wrote: >> > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: >> >> On 7/7/09, Gonzalo Nemmi wrote: >> >> > log in >> >> > acpiconf -s 3 >> >> > suspend works >> >> > opened the lid and the screen doesn't come back (backlight never >> >> > gets back) hard reset >> >> > login again and checked /var/log/messages .. this is what I found: >> >> > >> >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 >> >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend >> >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 >> >> > (disconnected) >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 >> >> > (disconnected) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 0, val 32768) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 0, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 24, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 16, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 16, val 0) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, >> >> > reg 16, val 0xffffffff) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 16, val 0) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, >> >> > reg 23, val 18) >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init >> >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization >> >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a >> >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: >> >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: >> >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: >> >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle >> >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID >> >> > Count=1, CYCLEMASTER mode >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 >> >> > cable IRM irm(0) (me) >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 >> >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error >> >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept >> >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: >> >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: > >> > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] >> >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 >> >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 >> >> > >> >> > any hints on how to further debug or redirect this mail to the >> >> > right list will be greatly appreciated. >> >> > >> >> > more info can be found in here: >> >> > http://forums.freebsd.org/showthread.php?t=3886 >> >> > >> >> > Best Regards >> >> > Gonzalo Nemmi >> >> >> >> i386 resume doesn't work with SMP kernel and SMP CPU. >> >> On amd64 make sure that you have right file loaded in kernel: >> >> for example i915.ko for intel cards. >> > >> > I shoul've mentioned I'm on a: >> > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz >> > 686-class CPU) >> > >> > and that I've added: hint.smp.disabled=1 to my /boot/device.hints >> > >> > This is what I get: >> > >> > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 >> > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 0, val 32768) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 0, >> > val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 24, val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 16, val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 16, val 0) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg >> > 16, val 0xffffffff) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 16, val 0) >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg >> > 23, val 18) >> > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed >> > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 >> > ports. >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 >> > bytes. >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: >> > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode >> > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable >> > IRM irm(0) (me) >> > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error >> > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept >> > 00:01:19) >> > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 >> > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 >> > >> > Should I file a PR? >> > >> > Once again, boot -v in here: http://pastebin.com/f604c1399 >> > >> > More info on my hardware and other messages: >> > http://forums.freebsd.org/showthread.php?t=3886 >> > >> > Best Regards >> > Gonzalo >> > -- >> > Blessings >> > Gonzalo Nemmi >> > >> >> Sorry, but I dont see what graphic card you are using. >> Anyway, on i386 you must load vesa.ko if ypu want that resume also >> resumes >> video >> >> -- >> Paul > > > 322 vgapci0: port 0xeff8-0xefff mem > 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > 323 agp0: on vgapci0 > 324 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 > 325 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf6e00000 > 326 agp0: detected 7676k stolen memory > 327 agp0: aperture size is 256M > 328 vgapci1: mem 0xf6f00000-0xf6ffffff at device > 2.1 on pci0 > > im not running X or anything .. so I guess im using whatever module 8 uses > by default (actually I thought it was the vesa module), this is just a > plain No, you need to load i915.ko or vesa.ko to make video resuming working. > 8.0-BETA1 install (not even a single port installed). > will try loading vesa, see what happens and report back. > > Thanks for your interest and help > Best Regards > Gonzalo > -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 04:29:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3417B106564A for ; Wed, 8 Jul 2009 04:29:49 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id C94AB8FC08 for ; Wed, 8 Jul 2009 04:29:48 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by gxk6 with SMTP id 6so6126543gxk.19 for ; Tue, 07 Jul 2009 21:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JjDhVe7JzpIZxcG+Y2lqTIblDHm6xP9ZM55xcZTELE8=; b=VoUhTWq8E7kJIsY4hQEmsebcnB7EoMVSP/DQH2Rn+ARmocf+wqxqknGGmIKXMSwOtp nFak5TUfUIrAi40rbH58fJWXKZxHw3Vny3IB6vqnyNVL8Qcjz3NJnRtfnkMTAe9gODKV CxHHTkL963Rke2ZUmj6uqCqJEiQxsZNvU+5YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yG6IvwxJd6WNAuiumXEESWLG5azz2GHSOXd710Xa47hRShdlXM0RBjn1k1dUn5DdIA HFHpVzgiE1UEBRdYbO0lWlBE/QC4hunGlb9Nw4KffZBXTpN097bdJePYOoRsLLdiosjU yAGxGu6TxRT+s0eYm9RB+ltvzDkcInyGn5Jms= MIME-Version: 1.0 Received: by 10.90.86.10 with SMTP id j10mr5758120agb.97.1247027387732; Tue, 07 Jul 2009 21:29:47 -0700 (PDT) In-Reply-To: <3a142e750907072104m2787e7f0p5dd30008ad11170d@mail.gmail.com> References: <19e9a5dc0907062310s6de64529uc1fb544d0b357829@mail.gmail.com> <3a142e750907070123r1e18a610h701e834bcd13f840@mail.gmail.com> <200907072150.36428.gnemmi@gmail.com> <3a142e750907072039w3c5d6557ia374920a3787cf1c@mail.gmail.com> <19e9a5dc0907072059p600fbe75ha44bc5d5f1cac7d8@mail.gmail.com> <3a142e750907072104m2787e7f0p5dd30008ad11170d@mail.gmail.com> Date: Wed, 8 Jul 2009 01:29:47 -0300 Message-ID: <19e9a5dc0907072129q2564839o687524a2261370e8@mail.gmail.com> From: Gonzalo Nemmi To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Can't get resume to work on -BETA1/-CURRENT-200906, help needed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 04:29:49 -0000 On Wed, Jul 8, 2009 at 1:04 AM, Paul B. Mahol wrote: > On 7/8/09, Gonzalo Nemmi wrote: > > On Wed, Jul 8, 2009 at 12:39 AM, Paul B. Mahol wrote: > > > >> On 7/8/09, Gonzalo Nemmi wrote: > >> > On Tuesday 07 July 2009 5:23:57 am Paul B. Mahol wrote: > >> >> On 7/7/09, Gonzalo Nemmi wrote: > >> >> > log in > >> >> > acpiconf -s 3 > >> >> > suspend works > >> >> > opened the lid and the screen doesn't come back (backlight never > >> >> > gets back) hard reset > >> >> > login again and checked /var/log/messages .. this is what I found: > >> >> > > >> >> > Jul 7 00:32:01 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> >> > Jul 7 00:32:09 gargoyle acpi: suspend at 20090707 00:32:09 > >> >> > Jul 7 00:32:15 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> >> > Jul 7 00:33:18 gargoyle kernel: ugen3.2: at usbus3 > >> >> > (disconnected) > >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: at uhub6, port 1, addr 2 > >> >> > (disconnected) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 0, val 32768) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 0, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 24, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 16, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 16, val 0) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> >> > reg 16, val 0xffffffff) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 16, val 0) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> >> > reg 23, val 18) > >> >> > Jul 7 00:33:18 gargoyle kernel: bge0: flow-through queue init > >> >> > failed Jul 7 00:33:18 gargoyle kernel: bge0: initialization > >> >> > failure Jul 7 00:33:18 gargoyle kernel: fwohci0: Phy 1394a > >> >> > available S400, 1 ports. Jul 7 00:33:18 gargoyle kernel: fwohci0: > >> >> > Link S400, max_rec 2048 bytes. Jul 7 00:33:18 gargoyle kernel: > >> >> > fwohci0: Initiate bus reset Jul 7 00:33:18 gargoyle kernel: > >> >> > fwohci0: fwohci_intr_core: BUS reset Jul 7 00:33:18 gargoyle > >> >> > kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID > >> >> > Count=1, CYCLEMASTER mode > >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > >> >> > cable IRM irm(0) (me) > >> >> > Jul 7 00:33:18 gargoyle kernel: firewire0: bus manager 0 > >> >> > Jul 7 00:33:18 gargoyle kernel: fwohci0: unrecoverable error > >> >> > Jul 7 00:33:18 gargoyle kernel: wakeup from sleeping state (slept > >> >> > 00:01:03) Jul 7 00:33:18 gargoyle kernel: ugen3.2: > >> >> > at usbus3 Jul 7 00:33:18 gargoyle kernel: ums0: >> >> > Optical Mouse, class 0/0, rev 2.00/0.10, addr 2> on usbus3 > >> >> > Jul 7 00:33:18 gargoyle kernel: ums0: 3 buttons and [XYZ] > >> >> > coordinates ID=1 Jul 7 00:33:18 gargoyle acpi: resumed at 20090707 > >> >> > 00:33:18 Jul 7 00:33:40 gargoyle syslogd: exiting on signal 15 > >> >> > > >> >> > any hints on how to further debug or redirect this mail to the > >> >> > right list will be greatly appreciated. > >> >> > > >> >> > more info can be found in here: > >> >> > http://forums.freebsd.org/showthread.php?t=3886 > >> >> > > >> >> > Best Regards > >> >> > Gonzalo Nemmi > >> >> > >> >> i386 resume doesn't work with SMP kernel and SMP CPU. > >> >> On amd64 make sure that you have right file loaded in kernel: > >> >> for example i915.ko for intel cards. > >> > > >> > I shoul've mentioned I'm on a: > >> > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > >> > 686-class CPU) > >> > > >> > and that I've added: hint.smp.disabled=1 to my /boot/device.hints > >> > > >> > This is what I get: > >> > > >> > Jul 7 21:35:03 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> > Jul 7 21:40:19 gargoyle acpi: suspend at 20090707 21:40:19 > >> > Jul 7 21:40:25 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 0, val 32768) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 0, > >> > val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 24, val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 16, val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 16, val 0) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > >> > 16, val 0xffffffff) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 16, val 0) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > >> > 23, val 18) > >> > Jul 7 21:41:44 gargoyle kernel: bge0: flow-through queue init failed > >> > Jul 7 21:41:44 gargoyle kernel: bge0: initialization failure > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > >> > ports. > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Link S400, max_rec 2048 > >> > bytes. > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: Initiate bus reset > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: fwohci_intr_core: > >> > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > >> > Jul 7 21:41:44 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > >> > IRM irm(0) (me) > >> > Jul 7 21:41:44 gargoyle kernel: firewire0: bus manager 0 > >> > Jul 7 21:41:44 gargoyle kernel: fwohci0: unrecoverable error > >> > Jul 7 21:41:44 gargoyle kernel: wakeup from sleeping state (slept > >> > 00:01:19) > >> > Jul 7 21:41:44 gargoyle acpi: resumed at 20090707 21:41:44 > >> > Jul 7 21:42:45 gargoyle syslogd: exiting on signal 15 > >> > > >> > Should I file a PR? > >> > > >> > Once again, boot -v in here: http://pastebin.com/f604c1399 > >> > > >> > More info on my hardware and other messages: > >> > http://forums.freebsd.org/showthread.php?t=3886 > >> > > >> > Best Regards > >> > Gonzalo > >> > -- > >> > Blessings > >> > Gonzalo Nemmi > >> > > >> > >> Sorry, but I dont see what graphic card you are using. > >> Anyway, on i386 you must load vesa.ko if ypu want that resume also > >> resumes > >> video > >> > >> -- > >> Paul > > > > > > 322 vgapci0: port 0xeff8-0xefff mem > > 0xf6e00000-0xf6efffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 > > 323 agp0: on vgapci0 > > 324 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xe0000000 > > 325 vgapci0: Reserved 0x100000 bytes for rid 0x10 type 3 at 0xf6e00000 > > 326 agp0: detected 7676k stolen memory > > 327 agp0: aperture size is 256M > > 328 vgapci1: mem 0xf6f00000-0xf6ffffff at device > > 2.1 on pci0 > > > > im not running X or anything .. so I guess im using whatever module 8 > uses > > by default (actually I thought it was the vesa module), this is just a > > plain > > No, you need to load i915.ko or vesa.ko to make video resuming working. > > > 8.0-BETA1 install (not even a single port installed). > > will try loading vesa, see what happens and report back. > > > > Thanks for your interest and help > > Best Regards > > Gonzalo > > > > > -- > Paul > Thanks Paul, it kinda worked. I loaded vesa.ko then "acpiconf -s 3", the system _resumed_ but not after the time outs and upon resuming the screen backlight was really dim. Wil try with i915.ko and see what happens. Any ways, heres are the messages I got: Jul 8 01:01:16 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 8 01:01:39 gargoyle acpi: suspend at 20090708 01:01:39 Jul 8 01:01:45 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:02:27 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:02:27 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 8 01:02:27 gargoyle kernel: bge0: flow-through queue init failed Jul 8 01:02:27 gargoyle kernel: bge0: initialization failure Jul 8 01:02:27 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 8 01:02:27 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 8 01:02:27 gargoyle kernel: fwohci0: Initiate bus reset Jul 8 01:02:27 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 8 01:02:27 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 8 01:02:27 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 8 01:02:27 gargoyle kernel: firewire0: bus manager 0 Jul 8 01:02:27 gargoyle kernel: fwohci0: unrecoverable error Jul 8 01:02:27 gargoyle kernel: wakeup from sleeping state (slept 00:00:43) Jul 8 01:02:27 gargoyle acpi: resumed at 20090708 01:02:27 after that, I got my screen back, then I did a sysctl hw.acpi.lid_close_state=S3 and suspended again .. closed the lid, suspended, opened the lid and got the system back, dim light again .. messages: Jul 8 01:06:24 gargoyle acpi: suspend at 20090708 01:06:24 Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:06:37 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:06:37 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 8 01:06:39 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:09:29 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 8 01:09:29 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 8 01:09:29 gargoyle kernel: bge0: flow-through queue init failed Jul 8 01:09:29 gargoyle kernel: bge0: initialization failure Jul 8 01:09:29 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 8 01:09:29 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 8 01:09:29 gargoyle kernel: fwohci0: Initiate bus reset Jul 8 01:09:29 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 8 01:09:29 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 8 01:09:29 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 8 01:09:29 gargoyle kernel: firewire0: bus manager 0 Jul 8 01:09:29 gargoyle kernel: fwohci0: unrecoverable error Jul 8 01:09:29 gargoyle kernel: wakeup from sleeping state (slept 00:02:51) Jul 8 01:09:29 gargoyle acpi: resumed at 20090708 01:09:29 Notice how upon the second "resume" I get PHY timeouts at 01:06:37, before the machine enters the suspend state, which actually takes place at 01:06:39 :s Anyways, it did resume again 01:09:29 :) Will give take a shot at i915.ko and see how it goes. Thanks for your help Paul :) Best Regards Gonzalo From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 09:00:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBB5710656B2 for ; Wed, 8 Jul 2009 09:00:50 +0000 (UTC) (envelope-from chflags@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id C0D678FC12 for ; Wed, 8 Jul 2009 09:00:48 +0000 (UTC) (envelope-from chflags@gmail.com) Received: by yxe11 with SMTP id 11so7892906yxe.3 for ; Wed, 08 Jul 2009 02:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=f7DMpMEZFbSggiwsbYpW31aCtRNazMqSWa2A4C/CH0Y=; b=dop5gkbY6UMM3oVVkwGFsIBzhuFS9QkJBkax56ThNfehrOa2QAoBJWpqMACBJxfsvZ I1GPEwhCO8NNDYu3fhkvwmWFkQ1UaoaUJs98peE0/5ivv/VrSHkzjOf+S5/rfUoB7cpb nUjQC5fMKDGYP/Em0GAyVCiCYgUfOftBMoZhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=J4srFOVPVMSQf1tfpBGFh/a6b7m5kT3UDDhjlR5VStwLlTlzXvwlf8qQLPi7oFbFBT Xdlj4iYH3tKXzD3Bj1udgdo8AIXdXCH3xl82lA+OuJQIXn1U4KVdFEBD2CM16wejFiJx 4+9KkmPakboNvyo8ZFUu74UjCwlonPAakbaFY= MIME-Version: 1.0 Received: by 10.100.42.14 with SMTP id p14mr11879609anp.199.1247042027308; Wed, 08 Jul 2009 01:33:47 -0700 (PDT) Date: Wed, 8 Jul 2009 16:33:47 +0800 Message-ID: <25cb30907080133l656fb10s6221607f00b3d193@mail.gmail.com> From: Kevin Foo To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: regression in atkbd? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chflags@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 09:00:55 -0000 Hi hackers, Did anyone experience issue with atkbd on 8.0? I encountered issue with keyboard and touchpad on HP presario V3400 when trying to upgrade from 7.2-RELEASE to 8.0 prior to and on BETA1.The keyboard and touchpad are working fine on 7.2. On 8.0 prior to BETA1, I managed to obtain dmesg via ssh despite having a non-operational keyboard. The laptop was totally inaccessible on 8.0 BETA1 as it freezed after the line atkbdc0. No information could be obtained. Any ideas? Thanks. /boot/device.hints (default, no changes made) hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" 1) FreeBSD 8.0-BETA1 amd64 as of today with GENERIC kernel:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 system hangs...... 2) FreeBSD 8.0-CURRENT amd64 prior to BETA1 custom kernel without debug/invariant/witness:- <---snip---< atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: unable to set the command byte. kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 55 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: unable to set the command byte. <---snip---< Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.8.txt 3) FreeBSD 7.2-RELEASE-p2 amd64:- <---snip---< 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 57 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 58 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 <---snip---< Full verbosed dmesg at http://ms.shit.la/FreeBSD/dmesg.7.txt -- Regards Kevin Foo From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 09:45:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED601106564A for ; Wed, 8 Jul 2009 09:44:59 +0000 (UTC) (envelope-from ga9@york.ac.uk) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id A023F8FC08 for ; Wed, 8 Jul 2009 09:44:59 +0000 (UTC) (envelope-from ga9@york.ac.uk) Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n689iupY004980; Wed, 8 Jul 2009 10:44:56 +0100 (BST) Received: from offsite-vpn-2-25.nas.york.ac.uk ([172.26.2.25]) by mail-gw6.york.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1MOThv-0004cb-L8; Wed, 08 Jul 2009 10:44:56 +0100 References: <19e9a5dc0907062254u528c4a8ahea2a605e80b1feea@mail.gmail.com> <1246963840.48637.44.camel@buffy.york.ac.uk> <200907072129.01232.gnemmi@gmail.com> Message-Id: <034E7108-6F28-47A9-896B-F9E126BACF93@ury.york.ac.uk> From: Gavin Atkinson To: Gonzalo Nemmi In-Reply-To: <200907072129.01232.gnemmi@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 5F136) Date: Wed, 8 Jul 2009 09:24:49 +0100 X-Mailer: iPhone Mail (5F136) Sender: ga9@york.ac.uk X-York-MailScanner: Found to be clean X-York-MailScanner-From: ga9@york.ac.uk Cc: Gavin Atkinson , "freebsd-current@freebsd.org" Subject: Re: Fatal trap 9 on -BETA1 on boot "with ACPI disabled" or "Safe Mode": X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 09:45:00 -0000 On 8 Jul 2009, at 01:29, Gonzalo Nemmi wrote: > On Tuesday 07 July 2009 7:50:40 am Gavin Atkinson wrote: >> On Tue, 2009-07-07 at 02:54 -0300, Gonzalo Nemmi wrote: >>> Can reproduce it on -CURRENT-200906 and -BETA1 whenever I try to >>> boot "with ACPI disabled" or "Safe Mode": >>> >>> Fatal trap 9: general protection fault while in kernel mode >>> cpuid = 0; acpic id = 00 >>> instruction pointer = 0x70:0xbfe4 >>> stack pointer = 0x28:0xfa4 >>> frame pointer = 0x28:0xfd4 >>> code segment = base 0xc00f0000, limit 0xffff, type 0x1b >>> = DPL 0, pres 1, def32 0, gran 0 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 0 (swapper) >>> [thread pid 0 tid 100000 ] >>> Stopped at 0xbfe4: *** error reading from address bfe4 *** >>> db> bt >>> Tracing pid 0 tid 100000 td 0x0da9b50 >>> uart_z8530_class(780001,0,b0202,ffe,0,...) at 0xbfe4 >>> db> >> >> This may well be a known problem that has affected certain Intel >> motherboards since around 5.x. Although this problem may well be >> solvable, perhaps the better approach is to fix whatever is stopping >> you from booting with ACPI enabled? > > Hello Gavin :) > > Actually I can boot with ACPI enabled (default boot), what I can't > boot > is "with ACPI disabled" or in "Safe Mode" since both of them throw a > Fatal trap 9. If there is no reason not to run with ACPI enabled, I'd recommend you do so. It would also be fair to say that the ACPI code receives far more testing than the non-ACPI code. However... > >> If for some reason you cannot have ACPI enabled, I guess knowing more >> output than the above would be useful. For example, when booting >> verbose and with ACPI disabled, what lines are printed before the >> above? >> >> (to do this, break to the loader prompt, and: >> >> setenv hint.acpi.0.disabled=1 >> setenv hint.apic.0.disabled=1 >> boot -v > > setenv hint.acpi.0.disabled=1 and setenv hint.apic.0.disabled=1 > yielded > a stack overflow each one, so I tried booting to the loader (#6) and > then: > > OK set hint.acpi.0.disabled=1 > OK set hint.apic.0.disabled=1 > OK boot -v > > That resulted in the very same Fatal trap 9 described above :a Can you just try with one or the other? I suspect you'll find it is the disabling of ACPI that is causing the issue, but it's worth checking. > > The lines before I get the Fatal trap are: > > 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 > ex_isa_identify() > pnpbios: 13 devices, largest 146 bytes > PNP0a3: adding io range 0xcf8-0xcff, size=0x8, align=0x2 > pnpbios: handle 0 device ID PNP0a03 (030ad041) > > Fatal trap 9: general protection fault while in kernel mode ... > >> it's also worth trying just with the first one to just disable ACPI, >> then just trying the APIC option, to see which of those two are >> causing you problems) >> >> By the way, is this i386 or amd64? > > CPU: Intel(R) Celeron(R) CPU 560 @ 2.13GHz (2128.02-MHz > 686-class CPU) This cpu will run either the i386 or the amd64 version of FreeBSD. Which are you using? (it's not possible to determine from your dmesg). If it's FreeBSD/amd64 you are running, all bets are off: that pretty much requires ACPI now to function. > You'll fin my boot -v in here should you like to take a look at it: > http://pastebin.com/f604c1399 > >> Gavin > > Thanks for your concern :) Gavin From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 10:13:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 814C51065676 for ; Wed, 8 Jul 2009 10:13:20 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id E9B718FC12 for ; Wed, 8 Jul 2009 10:13:19 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (130.48.233.220.static.exetel.com.au [220.233.48.130]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n68ADAWI015446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jul 2009 19:43:12 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 8 Jul 2009 20:13:04 +1000 User-Agent: KMail/1.9.10 References: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> In-Reply-To: <402C2D9299C36C4BB1C89C5E3539706E5C6012@pdc.mands.hu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1460561.2m9jfaHdQi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907082013.04661.doconnor@gsoft.com.au> X-Spam-Score: -2.014 () AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: M&S - Krasznai =?utf-8?q?Andr=C3=A1s?= Subject: Re: k3b and mkisofs problems on freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 10:13:20 -0000 --nextPart1460561.2m9jfaHdQi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, 6 Jul 2009, M&S - Krasznai Andr=E1s wrote: > I refreshed the sources last time on Friday, and recompiled k3b and > cdrtools again but it is still not working correctly. > > > Did anybody experience such problems with k3b? k3b works for me with -current from April 5th. Tried ktracing it? eg ktrace -dcif k3b.ktr k3b --nocrashhandler --nofork =2D-=20 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 --nextPart1460561.2m9jfaHdQi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKVHEw5ZPcIHs/zowRAs7OAJ4w43SdoKg4blpSb10cq6AysfKB+ACfcXHq WFQJWlTmOXo5P7mH0k+pQEU= =BVbg -----END PGP SIGNATURE----- --nextPart1460561.2m9jfaHdQi-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 11:24:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CDF7106566C; Wed, 8 Jul 2009 11:24:39 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id 08CB18FC0C; Wed, 8 Jul 2009 11:24:33 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090708112432.WJBM6742.mtaout01-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>; Wed, 8 Jul 2009 12:24:32 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout02-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090708112432.JBGW21638.aamtaout02-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Wed, 8 Jul 2009 12:24:32 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n68BOHrl012093; Wed, 8 Jul 2009 12:24:17 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from localhost (localhost [127.0.0.1]) by 10.248.192.16 (Horde Framework) with HTTP; Wed, 08 Jul 2009 12:24:17 +0100 Message-ID: <20090708122417.14619w86w7wfu4ms@10.248.192.16> Date: Wed, 08 Jul 2009 12:24:17 +0100 From: Ian J Hart To: Kip Macy References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> In-Reply-To: <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=ERehf_AEJYYA:10 a=6I5d2MoRAAAA:8 a=NLZqzBF-AAAA:8 a=VRdyzA9mAAAA:8 a=zd2uoN0lAAAA:8 a=BX8Rz6bX0yPUld5tiJsA:9 a=XwdQbzN9QlomNOWKfMsA:7 a=RT0SCdRq0l9H8kyIlLYtxX_hIZcA:4 a=SV7veod9ZcQA:10 a=_dQi-Dcv4p4A:10 Cc: freebsd-current@freebsd.org, Ian J Hart Subject: Re: zpool scrub errors on 3ware 9550SXU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:24:39 -0000 Quoting Kip Macy : > Did you answer my question of whether or not this can be reproduced > on 7-STABLE? Yes I did, but the threading is a little broken, sorry that's my fault. To reiterate, with 7 stable circa Jun 25th scrubs complete okay on the exact same hardware and v6 zpool as fails under 8.0-BETA1. I'm scrubbing under 7 every time a run under 8 fails. A reminder of the setup. 3ware 9550SXU-16 16x 1.5TB seagate. These drives throw bad sectors! 2 8 disk raidz2 vdevs combined into one pool.21.8TB. Test file system with compression on copies 2 I don't think this is a zfs error as such, it looks like the card gives up, which then spawns a whole series of bogus checksum errors (but what do I know). It's odd that it seems to take 40m+ to fail. Offsets are always large. How can I test for/eliminate any LBA error? What else might cause the card to fail (after 40m)? BTW I have to put this into production soon, so I can start testing all the other stuff which might not work (ie samba). Thanks for your help. > > > -Kip > > > > On Tue, Jul 7, 2009 at 1:03 PM, Ian J Hart wrote: >> Quoting ianjhart@ntlworld.com: >> >>> Quoting ianjhart@ntlworld.com: >>> >>>> Quoting Kip Macy : >>>> >>>>>> >>>>>> As usual scrubs cleanly on 7.2. Started throwing errors within a few >>>>>> minutes under 8. Then it paniced, possibly due to scrub -s. >>>>>> >>>>>> It's sat at the DB prompt if there's anything I can do. I'll need >>>>>> idiots guide level instruction. I have a screen dump if someone >>>>>> want to step >>>>>> up. Off list? >>>>>> >>>>>> Highlight seems to be... >>>>>> >>>>>> Memory modified after free 0xffffff0004da0c00(248) val=3000000 @ >>>>>> 0xffffff0004dc00 >>>>>> Panic: most recently used by none >>>>> >>>>> Can you test with recent 7-STABLE? That would tell me whether or not >>>>> your hitting a general HEAD issues or problems with the v13 import. >>>> >>>> It's doing a scrub under 7.2 following another failed test. I'll pull it >>>> up to stable after that. >>>> >>>> Have more data will post that once I've done a couple a jobs. >>>> >>>>> >>>>> Thanks, >>>>> Kip >>> >>> Here's that extra data. >>> >>> Updated 3ware/AMCC card firmware. >>> >>> Enable onboard SATA and fit a 300GB SATA disk. Remove the floppy and fit a >>> second 300GB SATA disk. >>> >>> Remove the two 500GB disks and replace with 1.5TB units. I can now create >>> two 8 disk raidz2 giving the same 12 disks worth of storage I had with one >>> 14 disk raidz2. >>> >>> Reinstall the two O/S on the 300GB drives. >>> >>> >>> May be of use to someone, so bear with me. >>> >>> Reset to BIOS defaults. Some issues! Disabling sound helps. >>> >>> Now suspect motherboard BIOS may be part of the problem. Removed both >>> cards and tested each version in turn. >>> >>> ref: http://www.tyan.com.tw/support_download_bios.aspx?model=S.S2895 >>> >>> Started with 1.04 ended up with 1.04. Versions after, detect the internal; >>> SATA disks as 150 not 300. Most versions lock the keyboard (KVM) >>> when legacy >>> USB is enabled. That's a PITA when you've just taken the floopy disk out.No >>> internal SATA disk settings. Be nice to check the geometry as 7 and 8 >>> sysinstall seem to be behaving differently. >>> >>> With the cards back in. >>> >>> Add an ATA disk and CDROM while testing.Easyboot order is SATA0 ATA0 >>> SATA1. Fdisk the so far blank ATA disk :) >>> >>> On board audio clashes with something. BIOS 1.03 and later supports 16 >>> SCSI boot devices. I disabled booting from the RAID card to allow the >>> onboard SATA drives to boot. >>> >>> Out of space for option ROM error has gone. >>> >>> AFAIK CPUs are late enough to support DDR400. Check anyway. Clock down to >>> 333Mhz. Still fails. >>> >>> >>> >>> There's one last thing, this BIOS (1.04) does not supply the fix for AMD >>> errata 169. Later BIOS incorrectly detect the onboard SATA disks. >>> >>> Northbridge System Request Queue may stall. >>> >>> ref: >>> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25759.pdf >>> >>> We don't seem to  have /dev/msr. Could I fix this using (the shiny new) >>> cpucontrol? >>> >>> Thanks >>> >>> ---------------------------------------------------------------- >>> This message was sent using IMP, the Internet Messaging Program. >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >>> >> >> FWIW this is still reproducable with 8.0-BETA1. >> >> -- >> ian j hart >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > > > -- > When bad men combine, the good must associate; else they will fall one > by one, an unpitied sacrifice in a contemptible struggle. > > Edmund Burke > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- ian j hart -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 11:40:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 144F8106566C; Wed, 8 Jul 2009 11:40:26 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id C008E8FC0A; Wed, 8 Jul 2009 11:40:25 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOVVd-0000r7-HQ; Wed, 08 Jul 2009 12:40:24 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOVVc-000260-P6; Wed, 08 Jul 2009 12:40:21 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n68BeJgZ019816; Wed, 8 Jul 2009 12:40:19 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n68BeJoB019815; Wed, 8 Jul 2009 12:40:19 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 8 Jul 2009 12:40:19 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.5 X-Spam-Level: - Cc: Rink Springer , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:40:26 -0000 On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: > > On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: > >> I tried to reproduce the error, got this on the way: > >> > >> # XXX: bogusly disabled high FP regs > > > > I get this message quite often as well; I intend to figure out what's > > going on. Marcel, if you have any idea, please let me know. > > It's a race condition. The high FP registers are lazily > context-switched and this error is emitted when a thread > wants to use the high FP registers when they are disabled > and the CPU onto which the thread is running has the high > FP registers corresponding to that thread in registers. > In that scenario the high FP registers should not even be > disabled. > > In the above case the kernel simply enables the high FP > registers and continues the thread. For the most part the > condition is harmless, but I've been looking at a panic > that's the result of inconsistency in the high FP state, > so the race is potentially fatal. > > BTW: I never got the error when doing a buildworld. I > think Anton's non-standard compiler options make GCC much > more FP intensive and thus prone to causing the race. hey, my compiler options are just a copy from /usr/share/examples/etc/make.conf with obvious changes, e.g. CPUTYPE=itanium2 The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. Which non-standard options did you spot? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 11:49:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3764C1065672; Wed, 8 Jul 2009 11:49:32 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id E2C9E8FC0C; Wed, 8 Jul 2009 11:49:31 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOVeQ-0000SK-EK; Wed, 08 Jul 2009 12:49:30 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOVeP-0002D6-OX; Wed, 08 Jul 2009 12:49:26 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n68BnPFQ019876; Wed, 8 Jul 2009 12:49:25 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n68BnPq0019875; Wed, 8 Jul 2009 12:49:25 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 8 Jul 2009 12:49:25 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Cc: Rink Springer , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 11:49:32 -0000 On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: > > On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: > >> I tried to reproduce the error, got this on the way: > >> > >> # XXX: bogusly disabled high FP regs > > > > I get this message quite often as well; I intend to figure out what's > > going on. Marcel, if you have any idea, please let me know. > > It's a race condition. The high FP registers are lazily > context-switched and this error is emitted when a thread > wants to use the high FP registers when they are disabled > and the CPU onto which the thread is running has the high > FP registers corresponding to that thread in registers. > In that scenario the high FP registers should not even be > disabled. > > In the above case the kernel simply enables the high FP > registers and continues the thread. For the most part the > condition is harmless, but I've been looking at a panic > that's the result of inconsistency in the high FP state, > so the race is potentially fatal. > > BTW: I never got the error when doing a buildworld. I > think Anton's non-standard compiler options make GCC much > more FP intensive and thus prone to causing the race. Marcel, sorry, I probably misunderstood "compiler options" in the previous reply. Did you mean -j option in make -j10 buildworld? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 13:19:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 30C5C1065672; Wed, 8 Jul 2009 13:19:30 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id E181E8FC15; Wed, 8 Jul 2009 13:19:29 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOX3V-0005GM-5w; Wed, 08 Jul 2009 14:19:28 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOX3T-0003kd-UE; Wed, 08 Jul 2009 14:19:24 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n68DJNXE020239; Wed, 8 Jul 2009 14:19:23 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n68DJNRW020238; Wed, 8 Jul 2009 14:19:23 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 8 Jul 2009 14:19:23 +0100 From: Anton Shterenlikht To: freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Message-ID: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.5 X-Spam-Level: - Cc: Subject: is it safe to reboot while gmirror is rebuilding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 13:19:30 -0000 On FBSD 8.0-current ia64 I've gmirror on 63GB partition, which takes quite a long time to rebuild, perhaps 30 min. Is it safe to reboot, or write to this filesystem, while it is being rebuilt (gmirror status DEGRADED) ? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 13:22:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD841065670; Wed, 8 Jul 2009 13:22:40 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 40E288FC15; Wed, 8 Jul 2009 13:22:39 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 207A578E3F; Wed, 8 Jul 2009 17:22:37 +0400 (MSD) Message-ID: <4A549D9F.9030209@haruhiism.net> Date: Wed, 08 Jul 2009 17:22:39 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Anton Shterenlikht References: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> In-Reply-To: <20090708131923.GA20219@mech-cluster238.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: is it safe to reboot while gmirror is rebuilding? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 13:22:41 -0000 Anton Shterenlikht wrote: > On FBSD 8.0-current ia64 I've gmirror on 63GB partition, which > takes quite a long time to rebuild, perhaps 30 min. Is it > safe to reboot, or write to this filesystem, while it is > being rebuilt (gmirror status DEGRADED) ? > > Doesn't matter which version it is; gmirror checkpoints the rebuild process so you can safely reboot/write/etc. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 14:44:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from miki (localhost [IPv6:::1]) by hub.freebsd.org (Postfix) with SMTP id 428D7106564A; Wed, 8 Jul 2009 14:44:33 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Wed, 8 Jul 2009 22:44:29 +0800 From: Ariff Abdullah To: Gonzalo Nemmi Message-Id: <20090708224429.7d2bb3c0.ariff@FreeBSD.org> In-Reply-To: <200907072214.01645.gnemmi@gmail.com> References: <200907072214.01645.gnemmi@gmail.com> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__8_Jul_2009_22_44_29_+0800_NvjoZL=1L440aOZL" Cc: freebsd-current@freebsd.org Subject: Re: LOR on kldunload snd_hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:44:34 -0000 --Signature=_Wed__8_Jul_2009_22_44_29_+0800_NvjoZL=1L440aOZL Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 7 Jul 2009 22:14:01 -0300 Gonzalo Nemmi wrote: > log in > kldload snd_hda > cat /dev/sndstat >=20 > FreeBSD Audio Driver (newpcm: 32 bit 20090615000/i386) > Installed devices: > pcm0: at cad 0 nid 1 on hdac0 > kld snd_hda > [MPSAFE] (1p:1v/1r:1v channels duplex default) >=20 > mixer > Mixer vol is currently set to 75:75 > Mixer pcm is currently set to 75:75 > Mixer speaker is currently set to 75:75 > Mixer mic is currently set to 0:0 > Mixer rec is currently set to 0:0 >=20 > "insert cd" >=20 > cdcontrol -f /dev/acd0 play 1 >=20 > "no sound at all" >=20 Hardware vendors nowadays tend to ignore analog connection between cd drive and sound card. Obviously, you don't have "cd" mixer . cdcontrol Instead, try dd if=3D/dev/acd0t01 of=3D/dev/dspcd bs=3D2352 . Or use other proper multimedia player with digital audio extraction support. > cdcontrol eject > kldunload snd_hda >=20 > Jul 7 21:44:15 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 7 21:54:27 gargoyle kernel: hdac0: Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at > device 27.0 on pci0 > Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Driver Revision:=20 > 20090624_0136 > Jul 7 21:54:27 gargoyle kernel: hdac0: [ITHREAD] > Jul 7 21:54:27 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel > STAC9228X Jul 7 21:54:27 gargoyle kernel: pcm0: STAC9228X PCM #0 Analog> at cad 0 nid 1 on hdac0 > Jul 7 22:03:27 gargoyle kernel: lock order reversal: > Jul 7 22:03:27 gargoyle kernel: 1st 0xc0da8cdc kernel linker > (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 > Jul 7 22:03:27 gargoyle kernel: 2nd 0xc0daa4e4 sysctl lock (sysctl=20 > lock) @ /usr/src/sys/kern/kern_sysctl.c:255 This probably has nothing or little to do with snd_hda. There are other kernel modules that might trigger this kind of LOR during detach due to freeing sysctl context. > Jul 7 22:03:27 gargoyle kernel: KDB: stack backtrace: > Jul 7 22:03:27 gargoyle kernel:=20 > db_trace_self_wrapper(c0c5b564,e6df7ac0,c08b5b35,c08a68db,c0c5e3f9, > ...) at db_trace_self_wrapper+0x26 > Jul 7 22:03:27 gargoyle kernel:=20 > kdb_backtrace(c08a68db,c0c5e3f9,c452cae8,c452ad40,e6df7b1c,...) at=20 > kdb_backtrace+0x29 > Jul 7 22:03:27 gargoyle kernel:=20 > _witness_debugger(c0c5e3f9,c0daa4e4,c0c58fbb,c452ad40,c0c58ec2,...) > at _witness_debugger+0x25 > Jul 7 22:03:27 gargoyle kernel:=20 > witness_checkorder(c0daa4e4,9,c0c58ec2,ff,0,...) at=20 > witness_checkorder+0x839 > Jul 7 22:03:27 gargoyle kernel: > _sx_xlock(c0daa4e4,0,c0c58ec2,ff,0,...) at _sx_xlock+0x85 > Jul 7 22:03:27 gargoyle kernel:=20 > sysctl_ctx_free(c4d7379c,0,c4e1c712,4a1,c4ca9480,...) at=20 > sysctl_ctx_free+0x30 > Jul 7 22:03:27 gargoyle kernel:=20 > pcm_unregister(c488f800,c4da3860,c0d3b6c8,a3c,c4887a80,...) at=20 > pcm_unregister+0x4e1m,ksd > Jul 7 22:03:27 gargoyle kernel:=20 > device_detach(c488f800,c0865663,c0da9df0,c4dd22d4,c4a95100,...) at=20 > device_detach+0x8c > Jul 7 22:03:27 gargoyle kernel:=20 > driver_module_handler(c4887a80,1,c4dd22d4,109,0,...) at=20 > driver_module_handler+0x29c > Jul 7 22:03:27 gargoyle kernel:=20 > module_unload(c4887a80,c0c54c7c,273,270,c08592b6,...) at=20 > module_unload+0x43 > Jul 7 22:03:27 gargoyle kernel:=20 > linker_file_unload(c4a92600,0,c0c54c7c,437,c4dba000,...) at=20 > linker_file_unload+0x15e > Jul 7 22:03:27 gargoyle kernel:=20 > kern_kldunload(c4ca9480,2,0,e6df7d2c,c0b98e73,...) at=20 > kern_kldunload+0xd5 > Jul 7 22:03:27 gargoyle kernel:=20 > kldunloadf(c4ca9480,e6df7cf8,8,c0c5f4bb,c0d3f0b0,...) at=20 > kldunloadf+0x2b > Jul 7 22:03:27 gargoyle kernel: syscall(e6df7d38) at syscall+0x2a3 > Jul 7 22:03:27 gargoyle kernel: Xint0x80_syscall() at=20 > Xint0x80_syscall+0x20 > Jul 7 22:03:27 gargoyle kernel: --- syscall (444, FreeBSD ELF32,=20 > kldunloadf), eip =3D 0x280d573b, esp =3D 0xbfbfe47c, ebp =3D 0xbfbfecc8 > --- Jul 7 22:03:27 gargoyle kernel: pcm0: detached > Jul 7 22:03:27 gargoyle kernel: hdac0: detached >=20 > -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ ... Going with the standard and orthodox is the death of intellect .............. --Signature=_Wed__8_Jul_2009_22_44_29_+0800_NvjoZL=1L440aOZL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpUsM0ACgkQlr+deMUwTNpuHACfevwK1DPKYdl9hEsja22EU5NC cJEAmwb+kWtesCFc6tBS0I6qMS+oJoHp =P8YB -----END PGP SIGNATURE----- --Signature=_Wed__8_Jul_2009_22_44_29_+0800_NvjoZL=1L440aOZL-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 14:51:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from miki (localhost [IPv6:::1]) by hub.freebsd.org (Postfix) with SMTP id 9BFA51065672; Wed, 8 Jul 2009 14:51:30 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Date: Wed, 8 Jul 2009 22:51:24 +0800 From: Ariff Abdullah To: "Sam Fourman Jr." Message-Id: <20090708225124.69372b06.ariff@FreeBSD.org> In-Reply-To: <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> References: <200907072214.01645.gnemmi@gmail.com> <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__8_Jul_2009_22_51_24_+0800_raWrfG0.0xVLRJgU" Cc: freebsd-current@freebsd.org Subject: Re: LOR on kldunload snd_hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:51:31 -0000 --Signature=_Wed__8_Jul_2009_22_51_24_+0800_raWrfG0.0xVLRJgU Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 7 Jul 2009 20:54:33 -0500 "Sam Fourman Jr." wrote: >=20 [....] > I have a similar problem with snd_hda > on a 6-1-2009 -CURRENT i386 kernel everything is fine > but on a 6-24-2009 -CURRENT i386 kernel > I have sound in vlc, but not in my wine applications >=20 > the moment I boot into a 6-1-2009 kernel everything works fine. >=20 Wine has its own issues. Either set audio Hardware Acceleration to "Emulation" through winecfg , or rebuild wine with this patch: http://people.freebsd.org/~ariff/ports/emulators_wine/patch-xzz -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ ... Going with the standard and orthodox is the death of intellect .............. --Signature=_Wed__8_Jul_2009_22_51_24_+0800_raWrfG0.0xVLRJgU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpUsmwACgkQlr+deMUwTNqzAQCdHVhEEHT9H5UvWpKvMheXsg2+ ZkMAoIsF3smmqilrGmbR6KkUpDdhpo+t =mZF4 -----END PGP SIGNATURE----- --Signature=_Wed__8_Jul_2009_22_51_24_+0800_raWrfG0.0xVLRJgU-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 14:52:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A8B10656B2 for ; Wed, 8 Jul 2009 14:52:32 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from minas.ics.muni.cz (minas.ics.muni.cz [147.251.4.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1DC4D8FC12 for ; Wed, 8 Jul 2009 14:52:29 +0000 (UTC) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK (kloboucek.fi.muni.cz [147.251.54.33]) (authenticated user=hopet@ICS.MUNI.CZ bits=0) by minas.ics.muni.cz (8.13.8/8.13.8/SuSE Linux 0.8) with ESMTP id n68ES3q1011595 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 8 Jul 2009 16:28:03 +0200 From: "Petr Holub" To: Date: Wed, 8 Jul 2009 16:27:58 +0200 Message-ID: <005a01c9ffd8$4db1b340$e91519c0$@muni.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn/vcg7YJYkijBrSrOt3OLrTvU9BQAGkWjw Content-Language: cs X-Muni-Spam-TestIP: 147.251.54.33 X-Muni-Envelope-From: hopet@ics.muni.cz X-Muni-Virus-Test: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (minas.ics.muni.cz [147.251.4.35]); Wed, 08 Jul 2009 16:28:03 +0200 (CEST) Cc: Subject: 8.0-BETA1 lock reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:52:38 -0000 Hi, after upgrading from 7.2 to 8.0-BETA1 today, I've noticed the lock reversal notifications in various parts of the storage subsystem. Examples are shown below. I'm running i386 with GENERIC kernel. Let me know if more info is needed. Petr -----Original Message----- From: Petr Holub [mailto:hopet@evenstar.ics.muni.cz] Sent: Wednesday, July 08, 2009 1:18 PM To: hopet@ics.muni.cz Subject: kloboucek-8.0-BETA1-problem Jul 8 13:04:02 kloboucek kernel: lock order reversal: Jul 8 13:04:02 kloboucek kernel: 1st 0xc744437c ntfs (ntfs) @ /usr/src/sys/kern /vfs_subr.c:2404 Jul 8 13:04:02 kloboucek kernel: 2nd 0xc737b724 ntnode (ntnode) @ /usr/src/sys/ modules/ntfs/../../fs/ntfs/ntfs_subr.c:361 Jul 8 13:04:02 kloboucek kernel: KDB: stack backtrace: Jul 8 13:04:02 kloboucek kernel: db_trace_self_wrapper(c0c5b564,e973b978,c08b5b 35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 8 13:04:02 kloboucek kernel: kdb_backtrace(c08a68db,c0c5e3f9,c6d310c8,c6d30 ff8,e973b9d4,...) at kdb_backtrace+0x29 Jul 8 13:04:02 kloboucek kernel: _witness_debugger(c0c5e3f9,c737b724,c7453600,c 6d30ff8,c745391f,...) at _witness_debugger+0x25 Jul 8 13:04:02 kloboucek kernel: witness_checkorder(c737b724,9,c745391f,169,0,. ..) at witness_checkorder+0x839 Jul 8 13:04:02 kloboucek kernel: __lockmgr_args(c737b724,80100,c737b740,0,0,... ) at __lockmgr_args+0x7a7 Jul 8 13:04:02 kloboucek kernel: ntfs_ntget(c737b700,c74443f0,c74443e0,c737b700 ,e973bb04,...) at ntfs_ntget+0x75 Jul 8 13:04:02 kloboucek kernel: ntfs_reclaim(e973bb04,1,0,c7444324,e973bb28,.. .) at ntfs_reclaim+0x3b Jul 8 13:04:02 kloboucek kernel: VOP_RECLAIM_APV(c7454200,e973bb04,0,0,c7444398 ,...) at VOP_RECLAIM_APV+0xa5 Jul 8 13:04:02 kloboucek kernel: vgonel(c7444398,0,c0c6567e,986,1,...) at vgone l+0x1a4 Jul 8 13:04:02 kloboucek kernel: vflush(c73a4c94,0,1,c75e1240,c75e1240,...) at vflush+0x337 Jul 8 13:04:02 kloboucek kernel: ntfs_unmount(c73a4c94,8000000,c0c64e9d,4f4,80, ...) at ntfs_unmount+0x59 Jul 8 13:04:02 kloboucek kernel: dounmount(c73a4c94,8000000,c75e1240,479,7,...) at dounmount+0x46d Jul 8 13:04:02 kloboucek kernel: unmount(c75e1240,e973bcf8,8,c75e1240,c0d3c288, ...) at unmount+0x30f Jul 8 13:04:02 kloboucek kernel: syscall(e973bd38) at syscall+0x2a3 Jul 8 13:04:02 kloboucek kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 8 13:04:02 kloboucek kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c59af, esp = 0xbfbfe5bc, ebp = 0xbfbfe678 --- Jul 8 13:04:02 kloboucek kernel: lock order reversal: Jul 8 13:04:02 kloboucek kernel: 1st 0xc7445058 ufs (ufs) @ /usr/src/sys/kern/v fs_mount.c:1199 Jul 8 13:04:02 kloboucek kernel: 2nd 0xc74447ac devfs (devfs) @ /usr/src/sys/ke rn/vfs_subr.c:2188 Jul 8 13:04:02 kloboucek kernel: KDB: stack backtrace: Jul 8 13:04:02 kloboucek kernel: db_trace_self_wrapper(c0c5b564,e973ba2c,c08b5b 35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 8 13:04:02 kloboucek kernel: kdb_backtrace(c08a68db,c0c5e3f9,c6d30d88,c6d30 cb8,e973ba88,...) at kdb_backtrace+0x29 Jul 8 13:04:02 kloboucek kernel: _witness_debugger(c0c5e3f9,c74447ac,c0c4d3c5,c 6d30cb8,c0c6567e,...) at _witness_debugger+0x25 Jul 8 13:04:02 kloboucek kernel: witness_checkorder(c74447ac,9,c0c6567e,88c,0,. ..) at witness_checkorder+0x839 Jul 8 13:04:02 kloboucek kernel: __lockmgr_args(c74447ac,80100,c74447c8,0,0,... ) at __lockmgr_args+0x7a7 Jul 8 13:04:02 kloboucek kernel: vop_stdlock(e973bb90,4,c0c56a67,80100,c7444754 ,...) at vop_stdlock+0x62 Jul 8 13:04:02 kloboucek kernel: VOP_LOCK1_APV(c0d38d00,e973bb90,c0da89d8,c0d75 c00,c7444754,...) at VOP_LOCK1_APV+0xb5 Jul 8 13:04:02 kloboucek kernel: _vn_lock(c7444754,80100,c0c6567e,88c,c74534f8, ...) at _vn_lock+0x5e Jul 8 13:04:02 kloboucek kernel: vrele(c7444754,c0c64e9d,469,200,c75e1240,...) at vrele+0x137 Jul 8 13:04:02 kloboucek kernel: ntfs_unmount(c73a4c94,8000000,c0c64e9d,4f4,80, ...) at ntfs_unmount+0x1a0 Jul 8 13:04:02 kloboucek kernel: dounmount(c73a4c94,8000000,c75e1240,479,7,...) at dounmount+0x46d Jul 8 13:04:02 kloboucek kernel: unmount(c75e1240,e973bcf8,8,c75e1240,c0d3c288, ...) at unmount+0x30f Jul 8 13:04:02 kloboucek kernel: syscall(e973bd38) at syscall+0x2a3 Jul 8 13:04:02 kloboucek kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 8 13:04:02 kloboucek kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280c59af, esp = 0xbfbfe5bc, ebp = 0xbfbfe678 --- Jul 8 13:04:14 kloboucek kernel: lock order reversal: Jul 8 13:04:14 kloboucek kernel: 1st 0xdace6460 bufwait (bufwait) @ /usr/src/sy s/kern/vfs_bio.c:2558 Jul 8 13:04:14 kloboucek kernel: 2nd 0xc73b9c00 dirhash (dirhash) @ /usr/src/sy s/ufs/ufs/ufs_dirhash.c:285 Jul 8 13:04:14 kloboucek kernel: KDB: stack backtrace: Jul 8 13:04:14 kloboucek kernel: db_trace_self_wrapper(c0c5b564,e97a0768,c08b5b 35,c08a68db,c0c5e3f9,...) at db_trace_self_wrapper+0x26 Jul 8 13:04:14 kloboucek kernel: kdb_backtrace(c08a68db,c0c5e3f9,c6d2cf60,c6d30 df0,e97a07c4,...) at kdb_backtrace+0x29 Jul 8 13:04:14 kloboucek kernel: _witness_debugger(c0c5e3f9,c73b9c00,c0c7e6a2,c 6d30df0,c0c7e33b,...) at _witness_debugger+0x25 Jul 8 13:04:14 kloboucek kernel: witness_checkorder(c73b9c00,9,c0c7e33b,11d,0,. ..) at witness_checkorder+0x839 Jul 8 13:04:14 kloboucek kernel: _sx_xlock(c73b9c00,0,c0c7e33b,11d,c73aed24,... ) at _sx_xlock+0x85 Jul 8 13:04:14 kloboucek kernel: ufsdirhash_acquire(dace6400,e97a08dc,200,daf57 800,e97a0894,...) at ufsdirhash_acquire+0x35 Jul 8 13:04:14 kloboucek kernel: ufsdirhash_add(c73aed24,e97a08dc,800,e97a0880, e97a0884,...) at ufsdirhash_add+0x13 Jul 8 13:04:14 kloboucek kernel: ufs_direnter(c71a5c90,c75bd754,e97a08dc,e97a0b d4,0,...) at ufs_direnter+0x729 Jul 8 13:04:14 kloboucek kernel: ufs_makeinode(e97a0bd4,0,e97a0ac8,e97a0a24,c0b a67e5,...) at ufs_makeinode+0x4f8 Jul 8 13:04:14 kloboucek kernel: ufs_create(e97a0ac8,e97a0ae0,0,0,e97a0ba8,...) at ufs_create+0x30 Jul 8 13:04:14 kloboucek kernel: VOP_CREATE_APV(c0d5d160,e97a0ac8,e97a0bd4,e97a 0a60,0,...) at VOP_CREATE_APV+0xa5 Jul 8 13:04:14 kloboucek kernel: vn_open_cred(e97a0ba8,e97a0c5c,180,0,c73a8700, ...) at vn_open_cred+0x200 Jul 8 13:04:14 kloboucek kernel: vn_open(e97a0ba8,e97a0c5c,180,c73e71f8,0,...) at vn_open+0x3b Jul 8 13:04:14 kloboucek kernel: kern_openat(c75e2d80,ffffff9c,28e1e6d0,0,a03,. ..) at kern_openat+0x118 Jul 8 13:04:14 kloboucek kernel: kern_open(c75e2d80,28e1e6d0,0,a02,180,...) at kern_open+0x35 Jul 8 13:04:14 kloboucek kernel: open(c75e2d80,e97a0cf8,c,c0c3fdfb,c0d3c0ac,... ) at open+0x30 Jul 8 13:04:14 kloboucek kernel: syscall(e97a0d38) at syscall+0x2a3 Jul 8 13:04:14 kloboucek kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 8 13:04:14 kloboucek kernel: --- syscall (5, FreeBSD ELF32, open), eip = 0x 28a5b13b, esp = 0xbfbfdffc, ebp = 0xbfbfe028 --- lock order reversal: 1st 0xdacfa200 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc73b8c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c5b564,e97d4768,c08b5b35,c08a68db,c0c5e3f9,...) at db_tr ace_self_wrapper+0x26 kdb_backtrace(c08a68db,c0c5e3f9,c6d2cf60,c6d30df0,e97d47c4,...) at kdb_backtrace +0x29 _witness_debugger(c0c5e3f9,c73b8c00,c0c7e6a2,c6d30df0,c0c7e33b,...) at _witness_ debugger+0x25 witness_checkorder(c73b8c00,9,c0c7e33b,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c73b8c00,0,c0c7e33b,11d,c7440828,...) at _sx_xlock+0x85 ufsdirhash_acquire(dacfa1a0,e97d48dc,200,db321a18,e97d4894,...) at ufsdirhash_ac quire+0x35 ufsdirhash_add(c7440828,e97d48dc,2a18,e97d4880,e97d4884,...) at ufsdirhash_add+0 x13 ufs_direnter(c744153c,c813953c,e97d48dc,e97d4bd4,0,...) at ufs_direnter+0x729 ufs_makeinode(e97d4bd4,0,e97d4ac8,e97d4a24,c0ba67e5,...) at ufs_makeinode+0x4f8 ufs_create(e97d4ac8,e97d4ae0,0,0,e97d4ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0d5d160,e97d4ac8,e97d4bd4,e97d4a60,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e97d4ba8,e97d4c5c,180,0,c7357480,...) at vn_open_cred+0x200 vn_open(e97d4ba8,e97d4c5c,180,c73e7690,4a0c65bf,...) at vn_open+0x3b kern_openat(c9119000,ffffff9c,bfbfddec,0,a03,...) at kern_openat+0x118 kern_open(c9119000,bfbfddec,0,a02,180,...) at kern_open+0x35 open(c9119000,e97d4cf8,c,c0c5ec8a,c0d3c0ac,...) at open+0x30 syscall(e97d4d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2815afe3, esp = 0xbfbfd8ec, ebp = 0xbfbfdd98 --- From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 15:05:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD808106567F for ; Wed, 8 Jul 2009 15:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7CEC98FC14 for ; Wed, 8 Jul 2009 15:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 3B2FF41C705; Wed, 8 Jul 2009 17:05:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 1DJgzzMsIoNC; Wed, 8 Jul 2009 17:05:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id A63DA41C70A; Wed, 8 Jul 2009 17:05:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 8910E4448E6; Wed, 8 Jul 2009 15:02:51 +0000 (UTC) Date: Wed, 8 Jul 2009 15:02:51 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Petr Holub In-Reply-To: <005a01c9ffd8$4db1b340$e91519c0$@muni.cz> Message-ID: <20090708150031.E245@maildrop.int.zabbadoz.net> References: <005a01c9ffd8$4db1b340$e91519c0$@muni.cz> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: 8.0-BETA1 lock reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:05:09 -0000 On Wed, 8 Jul 2009, Petr Holub wrote: > Hi, > > after upgrading from 7.2 to 8.0-BETA1 today, I've noticed the > lock reversal notifications in various parts of the storage > subsystem. Examples are shown below. I'm running i386 with > GENERIC kernel. Let me know if more info is needed. Please start reading here, take the time to check the LORs and then report back in detail as said on that page; you'll save a lot of time of quiet a few people: http://sources.zabbadoz.net/freebsd/lor.html Thanks a lot Bjoern -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 15:27:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D96C4106564A; Wed, 8 Jul 2009 15:27:38 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 37DA58FC0C; Wed, 8 Jul 2009 15:27:37 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ey-out-2122.google.com with SMTP id 9so1470382eyd.3 for ; Wed, 08 Jul 2009 08:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=rdkCTeYBPGP64BFC4BGg1na5D2/hnvyhQxncP256jm8=; b=LKcUcOB+UwhJAUoX6EV8Ltl4ziBuUxBwZnbnaBGYl+XxSRfC+ZjENCW7gaGSIqgApc CAxQSRm4cAAHR4jI528Ezm1GVZJRLnfJqMapLUxWaS/foHp/qHfuob4fkLoNsHAhlk1Y xRJOAe3jhH+EFcWRUSKNEa9L/u5C8YlASTTF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=wDGddBRcp9BNhwUPFg4+3BpqGvchR4DKkpwn9StIbs5ycOXiNPlgtAf+rs6JVGCi8e oFBOA5H9Gp/C/vBh/bcpi7GFXL4b65N9szmCCGwUFD0vSXvjlr8R5uQgOH7ATFE3WQUO 1MHTtf54xTIUeco33/1Av1/Iv9GJH1IUoBir0= Received: by 10.210.86.1 with SMTP id j1mr8085067ebb.61.1247065588341; Wed, 08 Jul 2009 08:06:28 -0700 (PDT) Received: from ?127.0.0.1? (87-194-39-182.bethere.co.uk [87.194.39.182]) by mx.google.com with ESMTPS id 10sm2514072eyz.51.2009.07.08.08.06.26 (version=SSLv3 cipher=RC4-MD5); Wed, 08 Jul 2009 08:06:26 -0700 (PDT) From: Tom Evans To: Ariff Abdullah In-Reply-To: <20090708225124.69372b06.ariff@FreeBSD.org> References: <200907072214.01645.gnemmi@gmail.com> <11167f520907071854q5e7e9658mfd082fbd95c5c8a0@mail.gmail.com> <20090708225124.69372b06.ariff@FreeBSD.org> Content-Type: text/plain Date: Wed, 08 Jul 2009 16:06:25 +0100 Message-Id: <1247065585.2437.330.camel@strangepork.london.mintel.ad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , freebsd-current@freebsd.org Subject: Re: LOR on kldunload snd_hda X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 15:27:39 -0000 On Wed, 2009-07-08 at 22:51 +0800, Ariff Abdullah wrote: > On Tue, 7 Jul 2009 20:54:33 -0500 > "Sam Fourman Jr." wrote: > > > > [....] > > I have a similar problem with snd_hda > > on a 6-1-2009 -CURRENT i386 kernel everything is fine > > but on a 6-24-2009 -CURRENT i386 kernel > > I have sound in vlc, but not in my wine applications > > > > the moment I boot into a 6-1-2009 kernel everything works fine. > > > > Wine has its own issues. Either set audio Hardware Acceleration to > "Emulation" through winecfg , or rebuild wine with this patch: > > http://people.freebsd.org/~ariff/ports/emulators_wine/patch-xzz > > Or fire up a terminal, and run: while true; do mixer pcm 80; sleep 1; done while you run your wine apps. Not elegant, but it works. From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 16:20:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 444651065676; Wed, 8 Jul 2009 16:20:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout028.mac.com (asmtpout028.mac.com [17.148.16.103]) by mx1.freebsd.org (Postfix) with ESMTP id 29A108FC0A; Wed, 8 Jul 2009 16:20:10 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp028.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMH007KV1CMJA90@asmtp028.mac.com>; Wed, 08 Jul 2009 09:19:45 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> Date: Wed, 08 Jul 2009 09:19:33 -0700 Message-id: <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1068) Cc: Rink Springer , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:20:11 -0000 On Jul 8, 2009, at 4:40 AM, Anton Shterenlikht wrote: >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > hey, my compiler options are just a copy from > /usr/share/examples/etc/make.conf > > with obvious changes, e.g. CPUTYPE=itanium2 > The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. > > Which non-standard options did you spot? All of them :-) There is no /etc/make.conf by default, so the existence of /etc/make.conf with CFLAGS, COPTFLAGS, etc makes them non-standard. As a special warning: /usr/share/examples/etc/make.conf is inherently i386 biases (like most of the examples and documentation I might add). It's unwise to copy flags from there and expect good results. Even warnings-only examples can cause build breakages (due to -Werror), because compilers for different architectures emit different warnings or emit the same warning at different times. By all means: experiment. But be very careful not to make the assumption that if the code compiles, it'll also run. The weirder the set of compiler options, the more likely you trip over optimization bugs and end up with an unstable system. And I'm not even talking about whether the set of options give you more optimal code in general. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 16:26:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39BB1065676; Wed, 8 Jul 2009 16:26:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 98A028FC19; Wed, 8 Jul 2009 16:26:14 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMH00B9D1NG0A40@asmtp023.mac.com>; Wed, 08 Jul 2009 09:26:14 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> Date: Wed, 08 Jul 2009 09:26:04 -0700 Message-id: References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114925.GA19854@mech-cluster238.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1068) Cc: Rink Springer , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 16:26:15 -0000 On Jul 8, 2009, at 4:49 AM, Anton Shterenlikht wrote: > On Tue, Jul 07, 2009 at 05:29:06PM -0700, Marcel Moolenaar wrote: >> >> On Jul 7, 2009, at 6:36 AM, Rink Springer wrote: >>>> I tried to reproduce the error, got this on the way: >>>> >>>> # XXX: bogusly disabled high FP regs >>> >>> I get this message quite often as well; I intend to figure out >>> what's >>> going on. Marcel, if you have any idea, please let me know. >> >> It's a race condition. The high FP registers are lazily >> context-switched and this error is emitted when a thread >> wants to use the high FP registers when they are disabled >> and the CPU onto which the thread is running has the high >> FP registers corresponding to that thread in registers. >> In that scenario the high FP registers should not even be >> disabled. >> >> In the above case the kernel simply enables the high FP >> registers and continues the thread. For the most part the >> condition is harmless, but I've been looking at a panic >> that's the result of inconsistency in the high FP state, >> so the race is potentially fatal. >> >> BTW: I never got the error when doing a buildworld. I >> think Anton's non-standard compiler options make GCC much >> more FP intensive and thus prone to causing the race. > > Marcel, sorry, I probably misunderstood "compiler options" > in the previous reply. Did you mean -j option in > make -j10 buildworld? -j is a make option. Modulo the FP race you're perfectly fine with any -j value that matches the number of CPUs in your box (with 4xNCPUS a rule-of-thumb maximum probably). If the compiler isn't FP intensive, then even -j128 on a dual- CPU box is not causing you problems (it's pointless though :-) FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 18:00:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31D5106564A for ; Wed, 8 Jul 2009 18:00:05 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 3FEDA8FC0C for ; Wed, 8 Jul 2009 18:00:05 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n68HQhwY000738 for ; Wed, 8 Jul 2009 19:26:43 +0200 Received: from ubm.mine.nu ([85.181.30.210] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 8 Jul 2009 19:26:43 +0200 Date: Wed, 8 Jul 2009 19:26:42 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090708192642.6b30167e.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 08 Jul 2009 18:14:26 +0000 Subject: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 18:00:06 -0000 Hiho! :-) I just put a Highpoint RocketRaid 2322 in our file server. There are no drives connected to it yet. I'm running: FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 15:23:12 CEST 2009 Since I put the 2322 in, the machine hangs late in the boot process with above message. It continues to wait until: run interrupt driven hooks: still waiting for xpt_config (300 seconds) and then theres nothing. No panic, keyboard still works, I can still scroll through dmesg, but nothing more. Before it the hptrr(4) attaches, there's the following message: xpt_dev async called. I searched the archives and found some references to firewire, but the machine in question has no firewire controller. Is there anything else I can do to debug this? For the record, the card is PCIe 4x, but I put it in the PCIe 16x slot. The card seems to work fine though, I can access its BIOS and its recognized by the FreeBSD driver. I'm also running with the new ahci driver. Bye Marc -- "A sudden blow: the great wings beating still Above the staggering girl, her thighs caressed By the dark webs, her nape caught in her bill, She holds her helpless breast upon her breast." W.B. Yeats, Leda and the Swan From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 20:13:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1A49106564A for ; Wed, 8 Jul 2009 20:13:32 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id A7A0B8FC0A for ; Wed, 8 Jul 2009 20:13:32 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yxe11 with SMTP id 11so8535337yxe.3 for ; Wed, 08 Jul 2009 13:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=GxrdrQKeflGvyVaUNfqvzwir/IQD2ol4SvXoolEXzzk=; b=wOPuYHihxsubJXh6L7jJnnIys4wEi54CfV6p7kBuA0/buQXDSpkfTNxj4dBAVzv6cN 2ycUfBOsmfZcuNIdoExOj4XbKxdnUEcdSjFMZ5hnqDK3urY/OzX6QT+by14SPXdPZJSW SE1Vp+rFuo8LzZs6yhTTU7hO03ZGj/UJfNnC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ws95U3L+/BLbDJ4/CcAbtMKoQInFmwLI1wLxUEbPGslR8zdEKGBu48GQ7ueupFYzce Z1Tt9UGDU1tfDOF1fyrSKTg8vE2fE4owNUzIDJ/ibZ7N5in3cPJghiRFDO9zsusmQ9/P WfjhJbzpuUQGR31hRAdp5h4FFkDMSUE5Sc4EA= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.247.4 with SMTP id u4mr13073789anh.9.1247084011921; Wed, 08 Jul 2009 13:13:31 -0700 (PDT) In-Reply-To: <20090708122417.14619w86w7wfu4ms@10.248.192.16> References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> <20090708122417.14619w86w7wfu4ms@10.248.192.16> Date: Wed, 8 Jul 2009 13:13:31 -0700 X-Google-Sender-Auth: 8801cba9842797c7 Message-ID: <3c1674c90907081313q31c48953u8c4bde5d0e156acf@mail.gmail.com> From: Kip Macy To: Ian J Hart Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: zpool scrub errors on 3ware 9550SXU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 20:13:33 -0000 The reason why the results on 7-STABLE are so important is that it is now running the exact same version of ZFS as HEAD. So if you aren't seeing checksum errors on 7-STABLE then the problem lies elsewhere in the storage stack. There are so many things that could cause this that I won't even speculate. Thanks for the information. I'll try to figure out how to narrow it down. -Kip From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 20:27:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DB49106564A; Wed, 8 Jul 2009 20:27:03 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 080098FC0A; Wed, 8 Jul 2009 20:27:02 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n68K1tO3037986; Wed, 8 Jul 2009 22:01:56 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A54FB33.8060705@fgznet.ch> Date: Wed, 08 Jul 2009 22:01:55 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ken Smith References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 20:27:04 -0000 Ken Smith wrote: > The amd64 and i386 architectures include a file named: > > 8.0-BETA1--memstick.img > > If you copy that to a USB memory stick newer machines should be able to > boot from it and use it to install from. Note that you need to > overwrite the contents of the memory stick completely, not copy it into > an existing filesystem on the memory stick. Exactly how you do that > depends on your machine but just to give you an example this works on > the machine I tested it with: > > dd if=8.0-BETA1-amd64-memstick.img of=/dev/da0 bs=10240 conv=sync > > Be careful if you have SCSI drives, more USB disks than just the memory > stick, etc - make sure /dev/da0 (or whatever you use) is the memory > stick. Using this image for livefs based rescue mode is known to not > work, that is one of the things still being worked on. Unfortunately my biggest mem stick has only 512MB. So I tried to dd to an usb drive. (Will get a bigger stick tomorrow) I was successful in installing the image, although, a few packages did not install. I did a kern developer package. I guess the packages are missing on the .img? Right now I'm installing the other things via net. Is this method equal to an usb stick install at all? Below the top of dmesg. TIA, Andreas --- Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #0: Sat Jul 4 03:55:14 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.80GHz (2793.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Features2=0x4400 real memory = 536870912 (512 MB) avail memory = 473395200 (451 MB) --- From owner-freebsd-current@FreeBSD.ORG Wed Jul 8 20:50:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95A5B106564A for ; Wed, 8 Jul 2009 20:50:53 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1B78FC15 for ; Wed, 8 Jul 2009 20:50:52 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n68KomR9010250 for ; Wed, 8 Jul 2009 22:50:48 +0200 Received: from ubm.mine.nu ([85.181.34.61] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 8 Jul 2009 22:50:48 +0200 Date: Wed, 8 Jul 2009 22:50:48 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090708225048.ec9d9cad.ubm@u-boot-man.de> In-Reply-To: <20090708192642.6b30167e.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 08 Jul 2009 21:07:43 +0000 Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 20:50:54 -0000 On Wed, 8 Jul 2009 19:26:42 +0200 Marc "UBM" Bocklet wrote: > > Hiho! :-) > > I just put a Highpoint RocketRaid 2322 in our file server. There are > no drives connected to it yet. > > I'm running: > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 > 15:23:12 CEST 2009 > > Since I put the 2322 in, the machine hangs late in the boot process > with above message. It continues to wait until: > > run interrupt driven hooks: still waiting for xpt_config (300 seconds) > and then theres nothing. No panic, keyboard still works, I can still > scroll through dmesg, but nothing more. > > Before it the hptrr(4) attaches, there's the following message: > > xpt_dev async called. > > I searched the archives and found some references to firewire, but the > machine in question has no firewire controller. > > Is there anything else I can do to debug this? > > For the record, the card is PCIe 4x, but I put it in the PCIe 16x > slot. The card seems to work fine though, I can access its BIOS and > its recognized by the FreeBSD driver. > > I'm also running with the new ahci driver. for the record: verbose boot shows no additional info. Bye Marc From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 03:42:37 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C00A10656A3; Thu, 9 Jul 2009 03:42:37 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id A26C58FC27; Thu, 9 Jul 2009 03:42:36 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n692eN6c099086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Jul 2009 22:40:26 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Andreas Tobler In-Reply-To: <4A54FB33.8060705@fgznet.ch> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-UtWhNAtrVEQmcGkzdMsW" Organization: U. Buffalo CSE Department Date: Wed, 08 Jul 2009 22:40:23 -0400 Message-Id: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 03:42:38 -0000 --=-UtWhNAtrVEQmcGkzdMsW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: > I was successful in installing the image, although, a few packages did=20 > not install. I did a kern developer package. I guess the packages are=20 > missing on the .img? Correct, no packages with BETA1. It's probably the documentation packages it went looking for and couldn't find. I'll be providing at least the docs packages with BETA2. Not sure if I'll start trying to provide a larger set of packages for the DVD or wait for BETA3 for that (leaning towards waiting at the moment). --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-UtWhNAtrVEQmcGkzdMsW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpVWJcACgkQ/G14VSmup/Y05QCglHkXaBxkLwZTqCCaCAKUMZM6 k6cAn0fT/Vf2nSW3DLXlGtHpx/S9l67u =3q9j -----END PGP SIGNATURE----- --=-UtWhNAtrVEQmcGkzdMsW-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 04:27:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0162710659F3 for ; Thu, 9 Jul 2009 04:27:06 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 89B2D8FC18 for ; Thu, 9 Jul 2009 04:27:05 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: by ey-out-2122.google.com with SMTP id 9so1581197eyd.3 for ; Wed, 08 Jul 2009 21:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=xezipfnLxMm/JuU09WLxrvsrj/rf332xLO14elCub+8=; b=JjsH3cSX8uhnG+UYI2x7aM9m6uJ8sMK6HPzGUvk+8xf/yJ7rGUnmZV4If71EXMCDjE vbz6Wcy+pP75gChQZvhfZzR2QCmM8es5io6Ew1fTLXpQEj9Ax43tpr32SbbRhCENmYg6 kMBJMyTEw1sMNGq3oKAKN00T6+0A15hc6/bmQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=V3+3GvvRduPtqJxQjZQZI+wMhnFJ8UXkh4lFlb6yxmtbUy0jUDrTUXva4df4OzVmxo 1Bh1tLfLIchDRYZ3Otti5FfyVtg9hOaKXtSOEvNaKMBNAno3YKUv3hAQnzRIED6rTqFN 0BxzBXxRJjr9fZgAhBAs3HWm/4wYWGC+RTZjY= MIME-Version: 1.0 Received: by 10.210.144.8 with SMTP id r8mr1131802ebd.43.1247111907066; Wed, 08 Jul 2009 20:58:27 -0700 (PDT) Date: Wed, 8 Jul 2009 22:58:27 -0500 Message-ID: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> From: Chris Ruiz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 04:27:07 -0000 i just upgraded from r194562 to r195477 in order to test BETA1 and my e1000 adapter no longer attaching to the driver. pciconf -lv output em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' class = network subclass = ethernet here's a quick list of relevant commits since my last kernel build: r195409, r195168, r195049, r194979, r194925, r194911, r194865. thanks, Chris -- @chrisattack ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 05:33:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 365651065670 for ; Thu, 9 Jul 2009 05:33:12 +0000 (UTC) (envelope-from greenx@yartv.ru) Received: from mail.yartv.ru (ns4.yartelenet.ru [94.158.0.17]) by mx1.freebsd.org (Postfix) with ESMTP id E25A08FC15 for ; Thu, 9 Jul 2009 05:33:11 +0000 (UTC) (envelope-from greenx@yartv.ru) Received: from greenx.yartelenet.ru (unknown [213.187.114.73]) by mail.yartv.ru (Postfix) with ESMTP id 2F207730C9 for ; Thu, 9 Jul 2009 09:26:24 +0400 (MSD) Message-ID: <4A557F71.4060700@yartv.ru> Date: Thu, 09 Jul 2009 09:26:09 +0400 From: Andrey Groshev User-Agent: Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 05:33:12 -0000 Hi, I can not install the patch. Already all try. #rm -R /usr/obj #rm -R /usr/src #cat #cat ~/greenx.sup *default host=cvsup5.ru.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=. *default delete use-rel-suffix src-all #csup ~/greenx.sup ...skip... #cd /usr/src #patch -p0 < cam-ata.20090704.patch ...skip... #make buildworld ...skip... cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo atacontrol.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_ntfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo sconfig.lo fdisk.lo dhclient.lo head.lo mt.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lzfs -lnvpair -luutil -lavl -lgeom -lbsdxml -ljail -lkiconv -lmd -lreadline -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lm /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In function `ata_max_mode': : undefined reference to `min' *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. What am I doing wrong? From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 06:09:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CECD71065674 for ; Thu, 9 Jul 2009 06:09:19 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8D6168FC08 for ; Thu, 9 Jul 2009 06:09:19 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from wald.nfv.gwdg.de ([134.76.242.31] helo=pc028.nfv) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MOmon-0003iP-RZ for freebsd-current@FreeBSD.ORG; Thu, 09 Jul 2009 08:09:17 +0200 Message-ID: <4A55898C.9050907@gwdg.de> Date: Thu, 09 Jul 2009 08:09:16 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: freebsd-current References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> In-Reply-To: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:09:20 -0000 Since ~ yesterday my CURRENT system notifies as BETA1 # uname -a FreeBSD pc028.nfv 8.0-BETA1 FreeBSD 8.0-BETA1 #0: Wed Jul 8 10:13:10 CEST 2009 xxx@xxx.xxx:/usr/obj/usr/src/sys/xxx i386 If I remember right, than CURRENT (HEAD) remained untouched over the last releases and only changes to next version number (i.e. 7.0 towards 8.0) when the next release was branched? Rainer Am 09.07.2009 04:40 (UTC+2) schrieb Ken Smith: > On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: >> I was successful in installing the image, although, a few packages did >> not install. I did a kern developer package. I guess the packages are >> missing on the .img? > > Correct, no packages with BETA1. It's probably the documentation > packages it went looking for and couldn't find. I'll be providing at > least the docs packages with BETA2. Not sure if I'll start trying to > provide a larger set of packages for the DVD or wait for BETA3 for that > (leaning towards waiting at the moment). > From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 06:21:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC781065675 for ; Thu, 9 Jul 2009 06:21:03 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8E38FC1D for ; Thu, 9 Jul 2009 06:21:03 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6965uOP018584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Jul 2009 16:05:57 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247119557; bh=j4f5MThz1tdinTjiB3aSrCteVbEAGPE3Jv5mhcd9Ksw=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=K0vfdM7fC+rX2YOHNyqKdAjuqcmpI5ylIM8QE4EEAoQGpYNCk7k8R0XGTYj/rvJju D6xQg6Be2F1c0w9u9pGmDX6g3uejdG+otz8BUD1DeeaJzyS24upkHl/cuU8ZP0lLUt uG/T4V/sWdfexzmrv4PGHFWRzYKXKHSSyLajF7xg= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6965u99027580 for ; Thu, 9 Jul 2009 16:05:56 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6965uph027579 for freebsd-current@freebsd.org; Thu, 9 Jul 2009 16:05:56 +1000 (AEST) (envelope-from john) Date: Thu, 9 Jul 2009 16:05:56 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:21:04 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I haven't been following this list at all and have not been playing with -CURRENT systems. I have source-upgraded an i386 test server from 7.2-RELEASE-p2 to 8.0-BETA1 because I want to help with making the next -STABLE release as stable as possible. I have posted a couple of other reports to -stable but it has been suggested to me that -current is a more appropriate list? - 8.0-BETA1 GSSAPI/sshd problem http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051061.html - 8.0-BETA1 mergemaster/ntp.conf problems http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051074.html So,... 8.0-BETA1 VMMAPS PROBLEM After upgrading... - boot new kernel to single-user - make installworld - make delete-old - make delete-old-libs - mergemaster - reboot I re-built a few of my applications. I noticed a problem with ntpd 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps and I couldn't kill it. Stopping the operating system appears to be the only remedy. I have re-built a few times (starting with 'make distclean') just to make sure. UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd I have not come across this before. This ntpd distribution builds and runs happily on earler versions (6.n and 7.n) of FreeBSD. You folks have obviously got ntpd 4.2.4p5 running happily in the base system. I have looked at the configure.h in /usr/src/usr.sbin/ntp and it is identical to the corresponding file in 7.2-RELEASE (apart from version ID). Any ideas as to what may be wrong with: ./configure --disable-debugging \ --disable-all-clocks \ --disable-parse-clocks \ --disable-linuxcaps \ --without-sntp \ CFLAGS=3D'-O -pipe -march=3Dpentium4' make make install and why that has served me well until 8.0-BETA1? If I build ntpd 4.2.4p5 as above on 8.0-BETA1 I have the same (vmmaps) problem. The ntpd 4.2.4p5 from the base system runs fine. Thank you. --=20 John Marshall --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpViMQACgkQw/tAaKKahKL+dgCfY3z5q0w6JHWlE5Lf2nTJP/ag enYAoLOSuxzxCzlZ/WbYQ2qCgGUN+GyJ =QzxF -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 06:42:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 082901065672 for ; Thu, 9 Jul 2009 06:42:50 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 8334A8FC0A for ; Thu, 9 Jul 2009 06:42:49 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz21 with SMTP id 21so2063704bwz.43 for ; Wed, 08 Jul 2009 23:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RhkgHXX3iKeVfFBba1YmXePuz8oU9eT7Jjf8T39vtOI=; b=oB7MkuPgw5TJ47vTdfvgC00NDVYKEwsGVUsNHAKvNN5RJAA8DiMhR6dUKqEJIyL+rq BpWcGfs9lCIZu76JYFk0AmkZAm9jQAGsIr0k0PviFzFVrE/xl0SXR9ZAO6GiYmGjbAAY UCI4eDlyI0Xe0GC7AxmcpiW9Cqk7aY8IhJ5Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=kqWPhA2BcmBmYDW1sZ0cyZw3Thq/81tKYeAw4uipm5EvfdwwPnooiKh+gJbEWoi9nt Y0x1JeA3SQxakiLoWpFzgJHYDXMUiDQi5lY5QvtBO71jjmIlufdYPMQASDRY8C3z5niR Lx4LwYH6ZEgdetrnDVNQCejZl/1Yq8PkYj0xg= MIME-Version: 1.0 Received: by 10.204.112.16 with SMTP id u16mr402040bkp.29.1247121768255; Wed, 08 Jul 2009 23:42:48 -0700 (PDT) In-Reply-To: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> Date: Thu, 9 Jul 2009 10:42:48 +0400 Message-ID: From: pluknet To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:42:50 -0000 2009/7/9 John Marshall : > After upgrading... > - boot new kernel to single-user > - make installworld > - make delete-old > - make delete-old-libs > - mergemaster > - reboot > > I re-built a few of my applications. I noticed a problem with ntpd > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > and I couldn't kill it. Stopping the operating system appears to be the > only remedy. I have re-built a few times (starting with 'make > distclean') just to make sure. > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd > Can you place here 'procstat -k 791', where 791 is pid of ntpd? It'd be nice also if you go through all ddb steps described in Debugging Deadlocks chapter of FreeBSD Developers' Handbook. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 06:56:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45665106564A; Thu, 9 Jul 2009 06:56:16 +0000 (UTC) (envelope-from markocpc@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 946BC8FC0A; Thu, 9 Jul 2009 06:56:15 +0000 (UTC) (envelope-from markocpc@gmail.com) Received: by ewy24 with SMTP id 24so408243ewy.43 for ; Wed, 08 Jul 2009 23:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=jSYunYvgwHt9NzU/5cVd0h0zzXTKy1/Yy1/V4yeXB9s=; b=lJs/R0Ky9JIK2A5wR8y0SwMro1KPUKJ7Ou3LFJUK+VR840RIow3CrLa4rmPZ3eUzTg uockeP78DDd3yI2nunqWi+pbpMEZcxFr9wP+BqNeF3xp85xOsinxWPx+tNzTiK+8D66S 9uSDL7Z5RZrzvCq4wim4kL18FsmjRiPeBEaYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=TpIz/1uCPf/Q5BErEY/tJg4jKtaQ3XKW4Y6apYNVrqHy5GQmdoEEqfQOMwwBGsxT59 ecS/VOkCqcXmgeyuuejJO8LzM7giudqlcNFeOY7flZ1rWbpU9W46FdJ7VKxNIHJM8O+6 I4FGqzAvQpWaM5xwTWGwGWpJUARDffFmDjjzI= MIME-Version: 1.0 Received: by 10.211.179.6 with SMTP id g6mr475337ebp.32.1247120660424; Wed, 08 Jul 2009 23:24:20 -0700 (PDT) Date: Thu, 9 Jul 2009 08:24:20 +0200 Message-ID: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> From: Lagrange Marc To: freebsd-amd64@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Building kernel : CPUID_FXSR undeclared (first use...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 06:56:16 -0000 Hi, I've just installed a 8-BETA1 on my new computer, checkouted the sources via svn (http://svn.freebsd.org/base/head). I've recompiled a kernel without debug and whitheness sucessfully, but when i've try to remove some things and it fails. The kernel configuration is here : http://banane.rhaamo.li/NAWAK The CPU is : CPU: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz (2499.73-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10677 Stepping = 7 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20000800 AMD Features2=0x1 TSC: P-state invariant The kernel build error: cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -fno-omit-frame-pointer -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 -Werror /usr/src/sys/amd64/amd64/in_cksum.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=native -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/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 -fno-omit-frame-pointer -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 -Werror /usr/src/sys/amd64/amd64/initcpu.c /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpu': /usr/src/sys/amd64/amd64/initcpu.c:146: error: 'CPUID_FXSR' undeclared (first use in this function) /usr/src/sys/amd64/amd64/initcpu.c:146: error: (Each undeclared identifier is reported only once /usr/src/sys/amd64/amd64/initcpu.c:146: error: for each function it appears in.) *** Error code 1 Stop in /usr/obj/usr/src/sys/NAWAK. *** Error code 1 Stop in /usr/src. I've also experiencing the same issue with audio/oss, it failed on CPUID_FXSR, but now fail with CPU_SSE or CPU_SSE2... If someone have an idea with this problem, Thanks. -- rhaamo on irc.freenode.net/oftc/geeknode From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 07:31:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C00E1065673 for ; Thu, 9 Jul 2009 07:31:02 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id D32B68FC47 for ; Thu, 9 Jul 2009 07:31:01 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n697UsiV020895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Jul 2009 17:30:55 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247124655; bh=tQzABHye8QwkNXmG2ok7YYhC8eyj8NV/QkAQz0dQykM=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=NNefwFn6f9U8TOfQOKoj670AfD9Hx4SrGI/8gIzJpYDlh/68i6qyApZdC2oZtB0Zi wztpuqv4NWto32Bh6mRSbFw+m2Qmv6FwZvPeX/s77SDsbRq5GaQDWnhHYsZ+sPwJPO 5AQkC9KLZky7bZBfHaljJaFMjZdNbyuo0VzpK7AM= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n697UsGC027789 for ; Thu, 9 Jul 2009 17:30:54 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n697Usqj027788 for freebsd-current@freebsd.org; Thu, 9 Jul 2009 17:30:54 +1000 (AEST) (envelope-from john) Date: Thu, 9 Jul 2009 17:30:54 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QTprm0S8XgL7H0Dt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:31:02 -0000 --QTprm0S8XgL7H0Dt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 09 Jul 2009, 10:42 +0400, pluknet wrote: > 2009/7/9 John Marshall : > > After upgrading... > > - boot new kernel to single-user > > - make installworld > > - make delete-old > > - make delete-old-libs > > - mergemaster > > - reboot > > > > I re-built a few of my applications. I noticed a problem with ntpd > > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > > and I couldn't kill it. Stopping the operating system appears to be the > > only remedy. I have re-built a few times (starting with 'make > > distclean') just to make sure. > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMM= AND > > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 ntpd > > >=20 > Can you place here 'procstat -k 791', where 791 is pid of ntpd? > It'd be nice also if you go through all ddb steps described in > Debugging Deadlocks chapter of FreeBSD Developers' Handbook. Here is some procstat output. I'm just rebuilding the kernel with the debugging options enabled - not something I've ever done before. rwsrv05# procstat 2788 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM = =20 2788 1 2788 2788 0 1 john vmmaps FreeBSD ELF32 ntpd = =20 rwsrv05# procstat -k 2788 PID TID COMM TDNAME KSTACK = =20 2788 100164 ntpd - mi_switch sleepq_switch slee= pq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mm= ap syscall Xint0x80_syscall=20 rwsrv05# procstat -v 2788 PID START END PRT RES PRES REF SHD FL TP PATH 2788 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd 2788 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd 2788 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 2788 0x2807e000 0x280ab000 r-x 45 0 171 75 CN vn /libexec/ld-elf.so.1 2788 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 2788 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 2788 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 2788 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 2788 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 2788 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 2788 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 2788 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 2788 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 2788 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 2788 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 2788 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 2788 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 2788 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 2788 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 2788 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 2788 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 2788 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 2788 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 2788 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 2788 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 2788 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 2788 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 2788 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 2788 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 2788 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 2788 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 2788 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 rwsrv05#=20 --=20 John Marshall --QTprm0S8XgL7H0Dt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpVnK4ACgkQw/tAaKKahKKBBACePdmPg6JZdTTv5DVF/LrBKdCq 2ZwAnRUJPtrlXnLsU3wqTL4hma2vtyHN =xdIQ -----END PGP SIGNATURE----- --QTprm0S8XgL7H0Dt-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 07:37:37 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50E93106566B for ; Thu, 9 Jul 2009 07:37:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2D16B8FC0A for ; Thu, 9 Jul 2009 07:37:37 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 6947C46B91 for ; Thu, 9 Jul 2009 03:37:36 -0400 (EDT) Date: Thu, 9 Jul 2009 08:37:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: odd make/build output on ^Z / fg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:37:37 -0000 Today I suspended a kernel build with ^Z to free up a bit of I/O bandwidth on a box. When I re-foregrounded, all appeared fine for a bit, but later when I switched back to the xterm I found this: ototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I../../.. -I../../../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 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror ../../../i386/acpica/acpi_wakeup.c couldn't resume mac_pipe.o: No such process *** Signal 1 couldn't resume audit_arg.o: No such process *** Signal 1 couldn't resume nlm_prot_impl.o: No such process *** Signal 1 couldn't resume nfs_serv.o: No such process *** Signal 1 couldn't resume nfs_vnops.o: No such process *** Signal 1 couldn't resume modules-obj: No such process ===> usb/uether (obj) ===> usb/aue (obj) ... ===> xfs (obj) ===> xl (obj) ===> zfs (obj) ===> zlib (obj) *** Signal 1 6 errors I've never seen that before, but I also don't suspend builds all that frequently. New bug? Old bug? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 07:53:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 234EC106566C for ; Thu, 9 Jul 2009 07:53:28 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id CA7138FC12 for ; Thu, 9 Jul 2009 07:53:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Sender; b=hxWzyQ0Tombimv3ZDMWqL8b4EOpV/bcYmUysOdvP2jklE40F9qyxQSw9658hbiRTLV0kmKYP2TmrOPqJmFkt/FR3SUgOfvpRqjt1i9aeHRAISu0jvaNsWnLFfaHyFNS5XOluTRFgpNx6O+uxgMYbe7Vy2VK2K+3hFQYXW5D6FUg=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MOoRa-0006TZ-AD; Thu, 09 Jul 2009 11:53:26 +0400 Date: Thu, 9 Jul 2009 11:53:24 +0400 From: Eygene Ryabinkin To: Lagrange Marc Message-ID: References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Building kernel : CPUID_FXSR undeclared (first use...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:53:28 -0000 Thu, Jul 09, 2009 at 08:24:20AM +0200, Lagrange Marc wrote: > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=3Dnative > -std=3Dc99 -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=3D8000 --param > inline-unit-growth=3D100 --param large-function-growth=3D1000 > -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 > -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror /usr/src/sys/amd64/amd64/initcpu.c > /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpu': > /usr/src/sys/amd64/amd64/initcpu.c:146: error: 'CPUID_FXSR' undeclared > (first use in this function) > /usr/src/sys/amd64/amd64/initcpu.c:146: error: (Each undeclared > identifier is reported only once > /usr/src/sys/amd64/amd64/initcpu.c:146: error: for each function it appea= rs in.) What output will be produced by the following command (should be invoked =66rom your kernel compile directory, /sys/amd64/compile/ if you compile manually or /usr/obj/usr/src/sys/ for 'make kernel' builds; looks like you is NAWAK): ----- cpp -dD -O2 -frename-registers -pipe -fno-strict-aliasing -march=3Dnative \ -std=3Dc99 -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=3D8000 --param \ inline-unit-growth=3D100 --param large-function-growth=3D1000 \ -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone -mfpmath=3D387 \ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float \ -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector \ -Werror /usr/src/sys/amd64/amd64/initcpu.c 2>&1 ----- And what is inside the file 'machine/specialreg.h' when you're sitting in the same directory? I'd expect that 'make clean && make kernel' invoked from /usr/src should fix your problems, but may be it is not the case, so information requested above will be helpful. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 07:53:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD91C106566B for ; Thu, 9 Jul 2009 07:53:30 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 893298FC16 for ; Thu, 9 Jul 2009 07:53:30 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id C0ACB5D99 for ; Thu, 9 Jul 2009 09:37:53 +0200 (CEST) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jMWRaWYMH+lt for ; Thu, 9 Jul 2009 09:37:53 +0200 (CEST) Received: from bert.mlan.solnet.ch (bert.mlan.solnet.ch [212.101.1.83]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 025D15D98 for ; Thu, 9 Jul 2009 09:37:52 +0200 (CEST) Message-ID: <4A559E50.3090408@bsdunix.ch> Date: Thu, 09 Jul 2009 09:37:52 +0200 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: USB stick installation problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 07:53:31 -0000 Hi I download and copied 8.0-BETA1-amd64-memstick.img to an usb stick as described at http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051018.html. I can boot it and sysinstall runs fine. Later i chose USB stick as install medium but then i get a "no USB stick found" error. Is this an know bug? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:11:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51202106564A; Thu, 9 Jul 2009 08:11:13 +0000 (UTC) (envelope-from markocpc@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7828FC19; Thu, 9 Jul 2009 08:11:12 +0000 (UTC) (envelope-from markocpc@gmail.com) Received: by ewy24 with SMTP id 24so439052ewy.43 for ; Thu, 09 Jul 2009 01:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yQorVcipU+yFE0PAszJAFYO4GKZgkBkpxzzAdS2U2iY=; b=SPeIaA3auNkl4XUopqdqbTvIUpZ8ddCzfQVN0gTqCZjDlFWC6b6+koloZprs6B0XYg O9oCe7aF7Do21/Z5qjCBTkCYIDGjfnpsWgxW9wEPIuJ+Q066xhC6GDFWdE4zug89kGVE vha41SeHgr2OePx545SujfbuXI6PbFRHij2bo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vt+Jz/9K80xJAEPgTRf+Beby9bGJeXBysOUOLg7jtEWdNseDxTMmqr2nB8yOh4VPw5 0D5gVCq3Z13AFabAYaDxcnXjofPrtX2e3WYYFIK6eiF9kUUK3UGYymxdezryh/iinbxZ e2nBWkvmmXL/W1a8QJV9YoPE9kkeBkf4aczcw= MIME-Version: 1.0 Received: by 10.211.179.6 with SMTP id g6mr589533ebp.32.1247127070914; Thu, 09 Jul 2009 01:11:10 -0700 (PDT) In-Reply-To: References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> Date: Thu, 9 Jul 2009 10:11:09 +0200 Message-ID: <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> From: Lagrange Marc To: rea-fbsd@codelabs.ru Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Building kernel : CPUID_FXSR undeclared (first use...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:11:13 -0000 On Thu, Jul 9, 2009 at 9:53 AM, Eygene Ryabinkin wrot= e: > Thu, Jul 09, 2009 at 08:24:20AM +0200, Lagrange Marc wrote: >> cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=3Dnative >> -std=3Dc99 =C2=A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-proto= types >> =C2=A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =C2=A0-W= undef >> -Wno-pointer-sign -fformat-extensions -nostdinc =C2=A0-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=3D8000 --param >> inline-unit-growth=3D100 --param large-function-growth=3D1000 >> -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone =C2=A0-mfpmath= =3D387 >> -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow =C2=A0-msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector >> -Werror =C2=A0/usr/src/sys/amd64/amd64/initcpu.c >> /usr/src/sys/amd64/amd64/initcpu.c: In function 'initializecpu': >> /usr/src/sys/amd64/amd64/initcpu.c:146: error: 'CPUID_FXSR' undeclared >> (first use in this function) >> /usr/src/sys/amd64/amd64/initcpu.c:146: error: (Each undeclared >> identifier is reported only once >> /usr/src/sys/amd64/amd64/initcpu.c:146: error: for each function it appe= ars in.) > > What output will be produced by the following command (should be invoked > from your kernel compile directory, /sys/amd64/compile/ if > you compile manually or /usr/obj/usr/src/sys/ for 'make > kernel' builds; looks like you is NAWAK): > ----- > cpp -dD -O2 -frename-registers -pipe -fno-strict-aliasing -march=3Dnative= \ > -std=3Dc99 =C2=A0-Wall -Wredundant-decls -Wnested-externs -Wstrict-protot= ypes \ > =C2=A0-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual =C2=A0-Wu= ndef \ > =C2=A0-Wno-pointer-sign -fformat-extensions -nostdinc =C2=A0-I. -I/usr/sr= c/sys \ > =C2=A0-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS = \ > =C2=A0-include opt_global.h -fno-common -finline-limit=3D8000 --param \ > =C2=A0inline-unit-growth=3D100 --param large-function-growth=3D1000 \ > =C2=A0-fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone =C2=A0-mfpm= ath=3D387 \ > =C2=A0-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow =C2=A0-msoft-float= \ > =C2=A0-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector \ > =C2=A0-Werror =C2=A0/usr/src/sys/amd64/amd64/initcpu.c 2>&1 > ----- Output here : http://banane.rhaamo.li/bugs/CPUID_FXSR/output_cpp > And what is inside the file 'machine/specialreg.h' when you're sitting > in the same directory? File here : http://banane.rhaamo.li/bugs/CPUID_FXSR/specialreg.h > I'd expect that 'make clean && make kernel' invoked from /usr/src > should fix your problems, but may be it is not the case, so information > requested above will be helpful. Tryied make clean && make kernel after getting requested infos, same error. Thx. > -- > Eygene > =C2=A0_ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0___ =C2=A0= =C2=A0 =C2=A0 _.--. =C2=A0 # > =C2=A0\`.|\..----...-'` =C2=A0 `-._.-'_.-'` =C2=A0 # =C2=A0Remember that = it is hard > =C2=A0/ =C2=A0' ` =C2=A0 =C2=A0 =C2=A0 =C2=A0 , =C2=A0 =C2=A0 =C2=A0 __.-= -' =C2=A0 =C2=A0 =C2=A0# =C2=A0to read the on-line manual > =C2=A0)/' _/ =C2=A0 =C2=A0 \ =C2=A0 `-_, =C2=A0 / =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0# =C2=A0while single-stepping the kernel. > =C2=A0`-'" `"\_ =C2=A0,_.-;_.-\_ ', =C2=A0fsc/as =C2=A0 # > =C2=A0 =C2=A0 _.-'_./ =C2=A0 {_.' =C2=A0 ; / =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 # =C2=A0 =C2=A0-- FreeBSD Developers handbook > =C2=A0 =C2=A0{_.-``-' =C2=A0 =C2=A0 =C2=A0 =C2=A0 {_/ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0# > --=20 rhaamo on irc.freenode.net/oftc/geeknode From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:13:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2ED01065679 for ; Thu, 9 Jul 2009 08:13:03 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.freebsd.org (Postfix) with ESMTP id 633168FC21 for ; Thu, 9 Jul 2009 08:13:03 +0000 (UTC) (envelope-from lars.engels@0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mail.0x20.net (Postfix) with ESMTP id 91360398B1 for ; Thu, 9 Jul 2009 09:56:55 +0200 (CEST) Received: from i011-63.fin-nrw.de (i011-63.fin-nrw.de [193.109.238.130]) by 0x20.net (Horde MIME library) with HTTP; Thu, 09 Jul 2009 09:56:55 +0200 Message-ID: <20090709095655.ekw77l994cggwcc0@0x20.net> X-Priority: 3 (Normal) Date: Thu, 09 Jul 2009 09:56:55 +0200 From: Lars Engels To: current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_3jyor8fodiio"; protocol="application/pgp-signature"; micalg="pgp-sha1" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) Cc: Subject: [regression] em0: watchdog timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:13:04 -0000 This message is in MIME format and has been PGP signed. --=_3jyor8fodiio Content-Type: text/plain; charset=ISO-8859-15; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Moin! After running 7.2-PRERELEASE for some time on my notebook, I decided to upgrade to 8.0-BETA1. While the em interface worked fine all the time with 7.2 I am now seeing this on the BETA: em0: watchdog timeout -- resetting Some googling told me to enable MSI but MSI was already enabled. -- Lars Engels E-Mail: lars.engels@0x20.net --=_3jyor8fodiio Content-Type: application/pgp-signature Content-Description: PGP Digital Signature Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpVoscACgkQKc512sD3afiUIACgydErJvMdszzx6W3arvE8Vs/W cI8An2WxMLrp4QctOCRYVY0oRMbNB0ZF =wKNa -----END PGP SIGNATURE----- --=_3jyor8fodiio-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:19:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D5D106566C; Thu, 9 Jul 2009 08:19:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 7B10B8FC22; Thu, 9 Jul 2009 08:19:49 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=jcmElqFgsJ7uJGIo8zVnwCQvpZCc6hgYyQ3fGNFlEFBM9m/OAHGUWOVy5gd9xbYl9G4G9K7magOf2m+yIDtE5tVgGt8553wx1iLt8nVOjxHxYefFnYbU8mQ2KhBIGLBfAmQfyKdpmmU9BghcQweNcS8x2D4Yin1erQyxVyY4YD0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MOor6-0009Ka-Lm; Thu, 09 Jul 2009 12:19:48 +0400 Date: Thu, 9 Jul 2009 12:19:46 +0400 From: Eygene Ryabinkin To: Lagrange Marc Message-ID: References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Building kernel : CPUID_FXSR undeclared (first use...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:19:50 -0000 Thu, Jul 09, 2009 at 10:11:09AM +0200, Lagrange Marc wrote: > > And what is inside the file 'machine/specialreg.h' when you're sitting > > in the same directory? > > File here : http://banane.rhaamo.li/bugs/CPUID_FXSR/specialreg.h Then, it is simple: you had manually commented the line 105: ----- /*#define CPUID_FXSR 0x01000000*/ ----- Uncomment it (inside /sys/amd64/include/specialreg.h) and rebuild the stuff. Better will be to resync the sources, get rid of all local modifications (if any) and rebuild. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:26:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 014611065673 for ; Thu, 9 Jul 2009 08:26:56 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7E3678FC1E for ; Thu, 9 Jul 2009 08:26:55 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n698QoSk024768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 10:26:54 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A55A9BA.80108@omnilan.de> Date: Thu, 09 Jul 2009 10:26:34 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig35E9F0B63BDE3D2D20635225" Subject: VirtualBox stopped working with -beta1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:26:56 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig35E9F0B63BDE3D2D20635225 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I've been using the great virtualbox port for some weeks with 8-current=20 without problems. Unfortunately it stoped working with recent -current. The complete system hard freezes after starting a vbox machine. Any hints how to obtain a dump? Of course I recompiled virtualbox with=20 the new kernel sources. Thanks, -Harry --------------enig35E9F0B63BDE3D2D20635225 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpVqcoACgkQLDqVQ9VXb8jXrQCfUSjsfvFsNP/SMuoZgPi5Xzq/ tdsAnAnn4VZzRT0vOke7qi1ARpFCIhAo =ZnPP -----END PGP SIGNATURE----- --------------enig35E9F0B63BDE3D2D20635225-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:29:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF9A106564A; Thu, 9 Jul 2009 08:29:12 +0000 (UTC) (envelope-from markocpc@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id B64B48FC1E; Thu, 9 Jul 2009 08:29:11 +0000 (UTC) (envelope-from markocpc@gmail.com) Received: by ewy24 with SMTP id 24so447703ewy.43 for ; Thu, 09 Jul 2009 01:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zX3O3elpEF4wa63cohD2Q9soMiXY032KHvEJJI4nLE4=; b=p2KeuqVW5Yoin3FVPGiYXarQ4Gv9P18SdHnyjWJ5ib8cGS2U+5L1jTtPA8tELYf08/ qJ8GvsA+Ac63oRvkmLClojPiiW7UuUBgbXb2D3rrrZsTMJqcTaT0kSrUSyciNhnplUSy 9FXUVTklyE9u5O47I+cobG5EK8/rMBdIVyLlc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Xm7Bz8Y6Zvf5cP1ueKCR89ec4UNnBbfuQKOZpN2AgyeafvNFIuy4B7utWEvJBPJfeF u4oKHdzXlUpK7w2c0sfusFg8aHpKNlFt7ByuM/QsEgfuY5zY63fkhwg4UyvePhmeo6Rl v+YCgSmZLLhjxaFM6ZRAwnwkJJBmY8T11Xwls= MIME-Version: 1.0 Received: by 10.211.179.6 with SMTP id g6mr610389ebp.32.1247128150738; Thu, 09 Jul 2009 01:29:10 -0700 (PDT) In-Reply-To: References: <1b5ab4050907082324m1c70a304s8487192e46f63fc8@mail.gmail.com> <1b5ab4050907090111q4cb29ea7t2f7518e844efbf54@mail.gmail.com> Date: Thu, 9 Jul 2009 10:29:09 +0200 Message-ID: <1b5ab4050907090129g5599d754w469170297e1b459a@mail.gmail.com> From: Lagrange Marc To: rea-fbsd@codelabs.ru Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: Building kernel : CPUID_FXSR undeclared (first use...) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:29:12 -0000 On Thu, Jul 9, 2009 at 10:19 AM, Eygene Ryabinkin wro= te: > Thu, Jul 09, 2009 at 10:11:09AM +0200, Lagrange Marc wrote: >> > And what is inside the file 'machine/specialreg.h' when you're sitting >> > in the same directory? >> >> File here : http://banane.rhaamo.li/bugs/CPUID_FXSR/specialreg.h > > Then, it is simple: you had manually commented the line 105: > ----- > /*#define =C2=A0 =C2=A0 =C2=A0 CPUID_FXSR =C2=A0 =C2=A0 =C2=A00x01000000*= / > ----- > Uncomment it (inside /sys/amd64/include/specialreg.h) and rebuild > the stuff. =C2=A0Better will be to resync the sources, get rid of all > local modifications (if any) and rebuild. Argl yes... i remember commented this !@# line in oss source (thx symlinks) because oss fail on CPUID_FXSR .. Thx. > -- > Eygene > =C2=A0_ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0___ =C2=A0= =C2=A0 =C2=A0 _.--. =C2=A0 # > =C2=A0\`.|\..----...-'` =C2=A0 `-._.-'_.-'` =C2=A0 # =C2=A0Remember that = it is hard > =C2=A0/ =C2=A0' ` =C2=A0 =C2=A0 =C2=A0 =C2=A0 , =C2=A0 =C2=A0 =C2=A0 __.-= -' =C2=A0 =C2=A0 =C2=A0# =C2=A0to read the on-line manual > =C2=A0)/' _/ =C2=A0 =C2=A0 \ =C2=A0 `-_, =C2=A0 / =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0# =C2=A0while single-stepping the kernel. > =C2=A0`-'" `"\_ =C2=A0,_.-;_.-\_ ', =C2=A0fsc/as =C2=A0 # > =C2=A0 =C2=A0 _.-'_./ =C2=A0 {_.' =C2=A0 ; / =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 # =C2=A0 =C2=A0-- FreeBSD Developers handbook > =C2=A0 =C2=A0{_.-``-' =C2=A0 =C2=A0 =C2=A0 =C2=A0 {_/ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0# > --=20 rhaamo on irc.freenode.net/oftc/geeknode From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:50:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FAE81065673; Thu, 9 Jul 2009 08:50:26 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id D87718FC14; Thu, 9 Jul 2009 08:50:25 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MOpKb-0007gO-2V; Thu, 09 Jul 2009 09:50:25 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MOpKa-0007mW-8s; Thu, 09 Jul 2009 09:50:16 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n698oFMw043408; Thu, 9 Jul 2009 09:50:15 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n698oFLl043407; Thu, 9 Jul 2009 09:50:15 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Thu, 9 Jul 2009 09:50:15 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.5 X-Spam-Level: - Cc: Rink Springer , Anton Shterenlikht , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:50:26 -0000 On Wed, Jul 08, 2009 at 09:19:33AM -0700, Marcel Moolenaar wrote: > > On Jul 8, 2009, at 4:40 AM, Anton Shterenlikht wrote: > > >> BTW: I never got the error when doing a buildworld. I > >> think Anton's non-standard compiler options make GCC much > >> more FP intensive and thus prone to causing the race. > > > > hey, my compiler options are just a copy from > > /usr/share/examples/etc/make.conf > > > > with obvious changes, e.g. CPUTYPE=itanium2 > > The CFLAGS, COPTFLAGS, CXXFLAGS are as in the example make.conf. > > > > Which non-standard options did you spot? > > All of them :-) > > There is no /etc/make.conf by default, so the existence > of /etc/make.conf with CFLAGS, COPTFLAGS, etc makes them > non-standard. > > As a special warning: /usr/share/examples/etc/make.conf > is inherently i386 biases (like most of the examples and > documentation I might add). It's unwise to copy flags > from there and expect good results. Even warnings-only > examples can cause build breakages (due to -Werror), > because compilers for different architectures emit > different warnings or emit the same warning at different > times. > > By all means: experiment. But be very careful not to make > the assumption that if the code compiles, it'll also run. > The weirder the set of compiler options, the more likely > you trip over optimization bugs and end up with an unstable > system. And I'm not even talking about whether the set > of options give you more optimal code in general. I see.. Is there any advice for compiler options on ia64? Perhaps a sample make.conf for ia64? Or would you recommend leaving these options empty: CFLAGS, COPTFLAGS, CXXFLAGS ? I'm sorry if I'm asking obvious questions. Perhaps this is documented/disucced somewhere already? I'm new to ia64, most of my FBSD experience is from alpha and i386. many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 08:52:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C353B106564A for ; Thu, 9 Jul 2009 08:52:48 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 547FE8FC0C for ; Thu, 9 Jul 2009 08:52:48 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n698qgbE023332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Jul 2009 18:52:43 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247129563; bh=i3i5GfEJGeByclh9XTWq/dV2tiK4MZW3umxUj8y3NeE=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=M6/9zSXB5UoUVPukJdAODhGwE7U+tHG0OuxOgjDtBvoy+hnjUvJArYWHatkwdJyU8 0P8MMujXhFXS+Q9stIO2KtFr4XIqrwZKlkFOtEqisJObAGWT+EPArZbuw5v9Yp6mF2 QHLuqNcFbUSLx4Bv+/ZTSS04KaOycO2XYKeY1pks= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n698qgKC027993 for ; Thu, 9 Jul 2009 18:52:42 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n698qgwY027992 for freebsd-current@freebsd.org; Thu, 9 Jul 2009 18:52:42 +1000 (AEST) (envelope-from john) Date: Thu, 9 Jul 2009 18:52:42 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oTHb8nViIGeoXxdp" Content-Disposition: inline In-Reply-To: <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 08:52:49 -0000 --oTHb8nViIGeoXxdp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 09 Jul 2009, 17:30 +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 10:42 +0400, pluknet wrote: > > 2009/7/9 John Marshall : > > > After upgrading... > > > - boot new kernel to single-user > > > - make installworld > > > - make delete-old > > > - make delete-old-libs > > > - mergemaster > > > - reboot > > > > > > I re-built a few of my applications. I noticed a problem with ntpd > > > 4.2.4p7. The build was fine, it started fine, but got stuck in vmmaps > > > and I couldn't kill it. Stopping the operating system appears to be = the > > > only remedy. I have re-built a few times (starting with 'make > > > distclean') just to make sure. > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME CO= MMAND > > > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 nt= pd > > > > >=20 > > Can you place here 'procstat -k 791', where 791 is pid of ntpd? > > It'd be nice also if you go through all ddb steps described in > > Debugging Deadlocks chapter of FreeBSD Developers' Handbook. >=20 > Here is some procstat output. I'm just rebuilding the kernel with the > debugging options enabled - not something I've ever done before. >=20 > rwsrv05# procstat 2788 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM = =20 > 2788 1 2788 2788 0 1 john vmmaps FreeBSD ELF32 ntpd = =20 > rwsrv05# procstat -k 2788 > PID TID COMM TDNAME KSTACK = =20 > 2788 100164 ntpd - mi_switch sleepq_switch sl= eepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap = mmap syscall Xint0x80_syscall=20 > rwsrv05# procstat -v 2788 > PID START END PRT RES PRES REF SHD FL TP PATH > 2788 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/nt= pd > 2788 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/nt= pd > 2788 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 > 2788 0x2807e000 0x280ab000 r-x 45 0 171 75 CN vn /libexec/ld-elf.s= o.1 > 2788 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.s= o.1 > 2788 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 > 2788 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 2788 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 2788 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 2788 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so= .5 > 2788 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so= .5 > 2788 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so= .5 > 2788 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 > 2788 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 2788 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 2788 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 2788 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.s= o.1 > 2788 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.s= o.1 > 2788 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.s= o.1 > 2788 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so= .1 > 2788 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so= .1 > 2788 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so= .1 > 2788 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 2788 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 2788 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 2788 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 2788 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 2788 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 2788 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 > 2788 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 > 2788 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 > 2788 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 > rwsrv05#=20 OK, now that I've rebuilt the kernel with the debugging options not commented out, I'm getting a number of 'lock order reversal' messages printed on the console: is that normal? =46rom the Debugging Deadlocks chapter to which I was referred by pluknet (above) it appears that I need to enter 'sysctl debug.kdb.enter=3D1' or 'sysctl debug.kdb.panic=3D1' after I get the process into the desired 'stuck' state. If I enter either of those commands, the system reboots. Now *I'm* stuck. --=20 John Marshall --oTHb8nViIGeoXxdp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpVr9oACgkQw/tAaKKahKIVIQCfflqAk86596cLM/E89flY9Qg5 00kAnRc9WLdLRTa4nhHVLaB4VJC45X7B =aaKn -----END PGP SIGNATURE----- --oTHb8nViIGeoXxdp-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 09:02:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FA5A106566C; Thu, 9 Jul 2009 09:02:25 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id EF22C8FC13; Thu, 9 Jul 2009 09:02:24 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:48033 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MOpVr-0001TP-5L; Thu, 09 Jul 2009 11:01:57 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id D98393F629; Thu, 9 Jul 2009 11:01:52 +0200 (CEST) Message-Id: <766FFF07-181A-4180-B020-AA3EE46CF6F8@exscape.org> From: Thomas Backman To: FreeBSD current In-Reply-To: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 11:01:51 +0200 References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MOpVr-0001TP-5L. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MOpVr-0001TP-5L e2f9b7d864960823e715427db0b86fde Cc: freebsd-fs@freebsd.org Subject: Re: "New" ZFS crash on FS (pool?) unmount/export X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 09:02:26 -0000 On Jun 20, 2009, at 09:11, Thomas Backman wrote: > I just ran into this tonight. Not sure exactly what triggered it - > the box stopped responding to pings at 02:07AM and it has a cron > backup job using zfs send/recv at 02:00, so I'm guessing it's > related, even though the backup probably should have finished before > then... Hmm. Anyway. > > r194478. > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x288 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805a4989 > stack pointer = 0x28:0xffffff803e8b57e0 > frame pointer = 0x28:0xffffff803e8b5840 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 57514 (zpool) > panic: from debugger > cpuid = 0 > Uptime: 10h22m13s > Physical memory: 2027 MB > > (kgdb) bt > #0 doadump () at pcpu.h:223 > #1 0xffffffff8059c409 in boot (howto=260) at /usr/src/sys/kern/ > kern_shutdown.c:419 > #2 0xffffffff8059c85c in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xffffffff801f1377 in db_panic (addr=Variable "addr" is not > available. > ) at /usr/src/sys/ddb/db_command.c:478 > #4 0xffffffff801f1781 in db_command (last_cmdp=0xffffffff80c38620, > cmd_table=Variable "cmd_table" is not available. > ) at /usr/src/sys/ddb/db_command.c:445 > #5 0xffffffff801f19d0 in db_command_loop () at /usr/src/sys/ddb/ > db_command.c:498 > #6 0xffffffff801f3969 in db_trap (type=Variable "type" is not > available. > ) at /usr/src/sys/ddb/db_main.c:229 > #7 0xffffffff805ce465 in kdb_trap (type=12, code=0, > tf=0xffffff803e8b5730) at /usr/src/sys/kern/subr_kdb.c:534 > #8 0xffffffff8088715d in trap_fatal (frame=0xffffff803e8b5730, > eva=Variable "eva" is not available. > ) at /usr/src/sys/amd64/amd64/trap.c:847 > #9 0xffffffff80887fb2 in trap (frame=0xffffff803e8b5730) at /usr/ > src/sys/amd64/amd64/trap.c:345 > #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:223 > #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, > tid=18446742975830720512, opts=Variable "opts" is not available. > ) > at /usr/src/sys/kern/kern_sx.c:575 > #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not > available. > ) at sx.h:155 > #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/ > zfs.ko > #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=0xffffff0043557d38, > a=0xffffff0043557d50) at vnode_if.c:1926 > #15 0xffffffff80626f6e in vgonel (vp=0xffffff00437a7938) at > vnode_if.h:830 > #16 0xffffffff8062b528 in vflush (mp=0xffffff0060f2a000, rootrefs=0, > flags=0, td=0xffffff0061528000) > at /usr/src/sys/kern/vfs_subr.c:2450 > #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko > #18 0xffffffff8062420a in dounmount (mp=0xffffff0060f2a000, > flags=1626513408, td=Variable "td" is not available. > ) > at /usr/src/sys/kern/vfs_mount.c:1287 > #19 0xffffffff80624975 in unmount (td=0xffffff0061528000, > uap=0xffffff803e8b5c00) > at /usr/src/sys/kern/vfs_mount.c:1172 > #20 0xffffffff8088783f in syscall (frame=0xffffff803e8b5c90) at /usr/ > src/sys/amd64/amd64/trap.c:984 > #21 0xffffffff8086e290 in Xfast_syscall () at /usr/src/sys/amd64/ > amd64/exception.S:364 > #22 0x000000080104e49c in ?? () > Previous frame inner to this frame (corrupt stack?) I might have hit the same thing again... only it didn't *crash* this time, just freeze! I got a "GEOM_GATE: Device ggateX destroyed" on my console, and it stopped responding to pings, keyboard input, etc. (NOTE: The GEOM_GATE message MAY have been an old one. I *think* it was from the night before but can't be sure...) It obviously happened while running my ugly-hack backup script this time too, since it stopped responding to pings ~02:02AM with the script running at 02:00. I'm not sure where it crashed, since snapshots were NOT taken on the "local box". It usually crashes during export, long after taking the snapshots. BTW, current system is BETA1 r195422M (dtrace timestamp patch + libzfs_sendrecv.c patch ( http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html ). Here's the script in its relevant entirety (I removed the "initial backup" part since it never runs using cron anyway). I realize it's an ugly hack (and that my bash-fu could be stronger), but what the heck. Essentially, it creates a GEOM provider of a file, containing a zpool, imports the pool and creates a clone to it, and then exports the pool. The export appears to be what causes all the trouble - usually, not this time around. Every time it crashes it seems to be during or very soon after the export - only this time it didn't even take the snapshots. #!/bin/bash PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/ sbin" function die() { echo "$@" 2>&1 zpool export slave 2>&1 > /dev/null ggatel destroy -u 666 2>&1 > /dev/null exit 1 } function mount_unmount { if [ -z "$1" ]; then die 'Invalid argument given to mount_unmount' elif [[ "$1" == "mount" ]]; then zpool list | grep -q slave if [ "$?" = "0" ]; then echo Already mounted return 0 fi echo Creating ggate device ggatel create -u 666 /mnt/backup/chaos/slavefile || die 'Unable to create GEOM provider from file' echo 'Sleeping for 5 seconds...' sleep 5 echo Importing pool zpool import -R /slave slave || die 'Unable to import slave pool' elif [[ "$1" == "unmount" ]]; then echo Exporting pool zpool export slave || die 'Unable to export slave pool' ggatel destroy -u 666 || die 'Unable to destroy GEOM provider' fi } f [ ! -z "$1" ]; then case $1 in mount) mount_unmount mount; exit 0;; unmount) mount_unmount unmount; exit 0;; initial) initial; exit 0;; backup) ;; *) help;; esac else help fi if [ ! -f "/mnt/backup/chaos/slavefile" ]; then echo 'Backup error! slavefile does not exist!' | mail -s "Backup error" root echo 'Slavefile does not exist!' exit 1 fi mount_unmount mount CURR=$(date +"backup-%F-%H%M") echo Taking snapshots zfs snapshot -r tank@$CURR || die 'Unable to create $CURR snapshot' echo Starting backup... LAST=$(cat /root/.last-backup) zfs send -R -I $LAST tank@$CURR | zfs recv -Fvd slave echo $CURR > /root/.last-backup mount_unmount unmount echo Running rsync rsync -av --delete /bootdir/boot exscape::backup-freebsd/chaos rsync -av --delete /root exscape::backup-freebsd/chaos rsync -av --delete ~serenity exscape::backup-freebsd/chaos echo 'All done!' ------------------- So, in *normal* cases, everything runs just fine. This is the case perhaps 90% of the time. In normal *crashes*, it hangs on export with the above backtrace. This time, all I know is that it crashes soon after starting the backup... during import, perhaps? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 10:33:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87AB2106564A for ; Thu, 9 Jul 2009 10:33:54 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 139DF8FC0A for ; Thu, 9 Jul 2009 10:33:54 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.14] (helo=4.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MOqwq-0007Oj-G6; Thu, 09 Jul 2009 12:33:52 +0200 Received: from t9cfb.t.pppool.de ([89.55.156.251]:45913 helo=ernst.jennejohn.org) by 4.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MOqwq-0003ON-3l; Thu, 09 Jul 2009 12:33:52 +0200 Date: Thu, 9 Jul 2009 12:33:51 +0200 From: Gary Jennejohn To: Andrey Groshev Message-ID: <20090709123351.267dd48a@ernst.jennejohn.org> In-Reply-To: <4A557F71.4060700@yartv.ru> References: <4A557F71.4060700@yartv.ru> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: 149285::1247135632-00001FFE-8B9E83BE/0-0/0-0 Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 10:33:55 -0000 On Thu, 09 Jul 2009 09:26:09 +0400 Andrey Groshev wrote: > I can not install the patch. > Already all try. > [snip error output] > > What am I doing wrong? > Nothing. Lucius Windschuh posted a fix in a previous message. Quoting from Lucius' mail Simply adding #ifndef min #define min(a,b) (((a)<(b))?(a):(b)) #endif in ata_all.c helps, obviously. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 11:39:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CBE11065703 for ; Thu, 9 Jul 2009 11:39:47 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 44E7D8FC1C for ; Thu, 9 Jul 2009 11:39:47 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 640018FC27; Thu, 9 Jul 2009 15:39:45 +0400 (MSD) Date: Thu, 9 Jul 2009 15:39:40 +0400 From: Stanislav Sedov To: Chris Ruiz Message-Id: <20090709153940.4544bfa8.stas@FreeBSD.org> In-Reply-To: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__9_Jul_2009_15_39_40_+0400_m7_1Z1ih9_s1ZUpL" Cc: freebsd-current@freebsd.org Subject: Re: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:39:47 -0000 --Signature=_Thu__9_Jul_2009_15_39_40_+0400_m7_1Z1ih9_s1ZUpL Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 8 Jul 2009 22:58:27 -0500 Chris Ruiz mentioned: > i just upgraded from r194562 to r195477 in order to test BETA1 and my > e1000 adapter no longer attaching to the driver. >=20 > pciconf -lv output >=20 > em0@pci0:0:25:0: class=3D0x020000 card=3D0x00018086 chip=3D0x10bd8= 086 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' > class =3D network > subclass =3D ethernet >=20 > here's a quick list of relevant commits since my last kernel build: > r195409, r195168, r195049, r194979, r194925, r194911, r194865. >=20 Hi, Chris! Can you provide the verbose boot log? --=20 Stanislav Sedov ST4096-RIPE --Signature=_Thu__9_Jul_2009_15_39_40_+0400_m7_1Z1ih9_s1ZUpL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKVdcAAAoJEKN82nOYvCd0NPUP/3dsIYWiFl7MIsSAI7/QBzB6 jDTCtsq6HaTR77NuXEaPBBoGchGTY2M/hP+HSGG6x3ztCm1mFoQifkG4g55Y9Bsu hnPTJVsQ9CBF7ReWZGcDbXiZy/yrnm4AlUINnxoS6XGmWORFEfHHBVvPFRuzoPGL BaC3gPrRXeOUzSrhJMYIRj2QZwgNDzN5JzRUl5i3YOGQL26hxTyec2lRgy3Lj7xz 76n51sO81m8mITwh851sacMY5VcaJGn5ESAtu8aTnhoSuwY8ar7iOfSDOgHkFWc+ P30mzMqOKvz0L1R277WeICWxBhaeTlvCNFn67bzy/RzLIu5I5lloBHfEhfDt+VEM XODWKps5jUL+/fC5pHfN0P+v7QxTrQgZjr4oST5Nd7mwcRzTfP2RIIQLNcIomGN9 sJltDD80KLuUgQBuOt0h0sjNEtJUD+wLKahRmItSmXdMyXIAdgtzm5t5GZiVUbd1 EaV/nvCj7lD9sAeIJgWypOsksOVbjo6Kd8Rv1izSeVC5VYgWNVVaiEGI2CYbLuNe LSgvDjBRJp7Z/ZijImyprRvZyDrt0vNjt8DAVYyVUIk1BD5tcDT+RIzjk82yyJMU ISCAWIIjLxqzZUIbeb3BraiFvvwV1MGrlopX89DTb+0zAR9vIMIgOja/bzulgn6m A87vuN9hXK9D0g6zLj1j =hIEL -----END PGP SIGNATURE----- --Signature=_Thu__9_Jul_2009_15_39_40_+0400_m7_1Z1ih9_s1ZUpL-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 11:45:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 361EE106564A for ; Thu, 9 Jul 2009 11:45:15 +0000 (UTC) (envelope-from greenx@yartv.ru) Received: from mail.yartv.ru (smtp.yartv.ru [94.158.0.17]) by mx1.freebsd.org (Postfix) with ESMTP id E72298FC17 for ; Thu, 9 Jul 2009 11:45:14 +0000 (UTC) (envelope-from greenx@yartv.ru) Received: from greenx.yartelenet.ru (unknown [213.187.114.73]) by mail.yartv.ru (Postfix) with ESMTP id 01002730CD for ; Thu, 9 Jul 2009 15:45:13 +0400 (MSD) Message-ID: <4A55D83E.4020206@yartv.ru> Date: Thu, 09 Jul 2009 15:45:02 +0400 From: Andrey Groshev User-Agent: Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: panic while configuring vlan on msk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 11:45:15 -0000 Hi, again :) it was necessary to work with vlan-s, but did not succeed ... #ifconfig vlan7 create #ifconfig vlan7 vlan 7 vlandev msk0 panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/dev/e1000/if_em.c:1623 cpuid = 1 KBD: enter: panic [thread pid 43561 tid 100322 ] Stopped at kdb_enter+0x3a: movl $0,kbd_why db> bt Tracing pid 43561 tid 100322 td 0xc9967d80 kdb_enter(c0cb1978,c0cb1978,c0cb03e4,eab05a70,1,...) at kdb_enter+0x03 panic(c0cb03e4,0,c0c79470,657,c9967e24,...) at panic+0x136 _mtx_lock_flags(c60db4e4,0,c0c79470,657,c60d7000,...) at _mtx_lock_flags+0x9a em_init(c60d7000) at em_init+0x35 em_register_vlan(0,c60cd400,7,430,c696fb84,...) at em_register_vlan+0x44 vlan_config(eab05b16,eab05b16,12,eab05b24,c6978220,...) at vlan_config+0x316 vlan_ioctl(c6135400,80206939,c6978220,c9967d80,eab05bac,...) at vlan_ioctl+0x2d5 ifioctl(c9520338,80306939,c6978220,c9967d80,ca243500,...) at ifioctl+0x11a8 soo_ioctl(c6d02e38,80206939,c6978220,c65a0b80,c9967d80,...) at soo_ioctl+0x415 kern_ioctl(c9967d80,3,80206939,c6978220,8f52d0,...) at kern_ioctl+0x1fd ioctl(c9967d80,eab05cf8,c,c0cc863f,c0d996dc8,...) at ioctl+0x134 syscall(eab05d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x33dbda23, esp = 0xbfbfe1ec, ebp = 0xbfbfe208 --- $uname -a FreeBSD greenx.yartelenet.ru 8.0-BETA1 FreeBSD 8.0-BETA1 #0: Thu Jul 9 10:55:08 MSD 2009 greenx@greenx.yartelenet.ru:/usr/obj/usr/src/sys/greenx i386 $pciconf -vl|grep -A4 msk mskc0@pci0:2:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' class = network subclass = ethernet From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 12:36:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0014F1065694; Thu, 9 Jul 2009 12:36:27 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 472748FC20; Thu, 9 Jul 2009 12:36:27 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:38484 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MOsrN-0002ZH-4K; Thu, 09 Jul 2009 14:36:24 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 1F1D03F6A8; Thu, 9 Jul 2009 14:36:22 +0200 (CEST) Message-Id: <9FAC783B-5709-460B-B6DA-364DCD0DE8DA@exscape.org> From: Thomas Backman To: FreeBSD current , freebsd-fs@freebsd.org In-Reply-To: <766FFF07-181A-4180-B020-AA3EE46CF6F8@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 14:36:19 +0200 References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> <766FFF07-181A-4180-B020-AA3EE46CF6F8@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MOsrN-0002ZH-4K. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MOsrN-0002ZH-4K a5e81229e71f083d827cc1ed16bcd84c Cc: Subject: Re: "New" ZFS crash on FS (pool?) unmount/export X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 12:36:28 -0000 On Jul 9, 2009, at 11:01, Thomas Backman wrote: > On Jun 20, 2009, at 09:11, Thomas Backman wrote: > >> I just ran into this tonight. Not sure exactly what triggered it - >> the box stopped responding to pings at 02:07AM and it has a cron >> backup job using zfs send/recv at 02:00, so I'm guessing it's >> related, even though the backup probably should have finished >> before then... Hmm. Anyway. >> >> r194478. >> >> kernel trap 12 with interrupts disabled >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x288 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff805a4989 >> stack pointer = 0x28:0xffffff803e8b57e0 >> frame pointer = 0x28:0xffffff803e8b5840 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 57514 (zpool) >> panic: from debugger >> cpuid = 0 >> Uptime: 10h22m13s >> Physical memory: 2027 MB >> >> (kgdb) bt >> #0 doadump () at pcpu.h:223 >> #1 0xffffffff8059c409 in boot (howto=260) at /usr/src/sys/kern/ >> kern_shutdown.c:419 >> #2 0xffffffff8059c85c in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:575 >> #3 0xffffffff801f1377 in db_panic (addr=Variable "addr" is not >> available. >> ) at /usr/src/sys/ddb/db_command.c:478 >> #4 0xffffffff801f1781 in db_command (last_cmdp=0xffffffff80c38620, >> cmd_table=Variable "cmd_table" is not available. >> ) at /usr/src/sys/ddb/db_command.c:445 >> #5 0xffffffff801f19d0 in db_command_loop () at /usr/src/sys/ddb/ >> db_command.c:498 >> #6 0xffffffff801f3969 in db_trap (type=Variable "type" is not >> available. >> ) at /usr/src/sys/ddb/db_main.c:229 >> #7 0xffffffff805ce465 in kdb_trap (type=12, code=0, >> tf=0xffffff803e8b5730) at /usr/src/sys/kern/subr_kdb.c:534 >> #8 0xffffffff8088715d in trap_fatal (frame=0xffffff803e8b5730, >> eva=Variable "eva" is not available. >> ) at /usr/src/sys/amd64/amd64/trap.c:847 >> #9 0xffffffff80887fb2 in trap (frame=0xffffff803e8b5730) at /usr/ >> src/sys/amd64/amd64/trap.c:345 >> #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/ >> exception.S:223 >> #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, >> tid=18446742975830720512, opts=Variable "opts" is not available. >> ) >> at /usr/src/sys/kern/kern_sx.c:575 >> #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not >> available. >> ) at sx.h:155 >> #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/ >> zfs.ko >> #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=0xffffff0043557d38, >> a=0xffffff0043557d50) at vnode_if.c:1926 >> #15 0xffffffff80626f6e in vgonel (vp=0xffffff00437a7938) at >> vnode_if.h:830 >> #16 0xffffffff8062b528 in vflush (mp=0xffffff0060f2a000, >> rootrefs=0, flags=0, td=0xffffff0061528000) >> at /usr/src/sys/kern/vfs_subr.c:2450 >> #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko >> #18 0xffffffff8062420a in dounmount (mp=0xffffff0060f2a000, >> flags=1626513408, td=Variable "td" is not available. >> ) >> at /usr/src/sys/kern/vfs_mount.c:1287 >> #19 0xffffffff80624975 in unmount (td=0xffffff0061528000, >> uap=0xffffff803e8b5c00) >> at /usr/src/sys/kern/vfs_mount.c:1172 >> #20 0xffffffff8088783f in syscall (frame=0xffffff803e8b5c90) at / >> usr/src/sys/amd64/amd64/trap.c:984 >> #21 0xffffffff8086e290 in Xfast_syscall () at /usr/src/sys/amd64/ >> amd64/exception.S:364 >> #22 0x000000080104e49c in ?? () >> Previous frame inner to this frame (corrupt stack?) > > > Here's the script in its relevant entirety [...] > > #!/bin/bash > > PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/ > sbin" > > function die() { > echo "$@" 2>&1 > zpool export slave 2>&1 > /dev/null > ggatel destroy -u 666 2>&1 > /dev/null > exit 1 > } > > function mount_unmount { > if [ -z "$1" ]; then > die 'Invalid argument given to mount_unmount' > elif [[ "$1" == "mount" ]]; then > zpool list | grep -q slave > if [ "$?" = "0" ]; then > echo Already mounted > return 0 > fi > echo Creating ggate device > ggatel create -u 666 /mnt/backup/chaos/slavefile || die 'Unable to > create GEOM provider from file' > echo 'Sleeping for 5 seconds...' > sleep 5 > echo Importing pool > zpool import -R /slave slave || die 'Unable to import slave pool' > elif [[ "$1" == "unmount" ]]; then > echo Exporting pool > zpool export slave || die 'Unable to export slave pool' > ggatel destroy -u 666 || die 'Unable to destroy GEOM provider' > fi > } > > f [ ! -z "$1" ]; then > case $1 in > mount) mount_unmount mount; exit 0;; > unmount) mount_unmount unmount; exit 0;; > initial) initial; exit 0;; > backup) ;; > *) help;; > esac > else > help > fi > > if [ ! -f "/mnt/backup/chaos/slavefile" ]; then > echo 'Backup error! slavefile does not exist!' | mail -s "Backup > error" root > echo 'Slavefile does not exist!' > exit 1 > fi > > mount_unmount mount > > CURR=$(date +"backup-%F-%H%M") > > echo Taking snapshots > zfs snapshot -r tank@$CURR || die 'Unable to create $CURR snapshot' > > echo Starting backup... > LAST=$(cat /root/.last-backup) > zfs send -R -I $LAST tank@$CURR | zfs recv -Fvd slave > > echo $CURR > /root/.last-backup > > mount_unmount unmount > > echo Running rsync > rsync -av --delete /bootdir/boot exscape::backup-freebsd/chaos > rsync -av --delete /root exscape::backup-freebsd/chaos > rsync -av --delete ~serenity exscape::backup-freebsd/chaos > > echo 'All done!' > > ------------------- Sorry for the monologue, but I ran in to this again, this time with a panic again. Similar but not identical to the old one. OK, so I figured I would update my "untouched" src clone (used to save bandwidth from the FBSD SVN server when I feel I need to start with a *clean* source tree), now that there have been quite a few changes since that revision. I pretty much did this (if other shells are different, !$ in bash is the last argument to the previous command.) 1) Clean up /usr/src from "my" stuff 2) svn update 3) svn diff and svn status, to make sure it was clean 4) zfs promote tank/usr/src ## usr/src was a clone of the untouched, read-only fs "tank/usr/src_r194478-UNTOUCHED" 5) zfs destroy -r tank/usr/src_r194478-UNTOUCHED ## The old one, obviously 6) zfs snapshot tank/usr/src@r195488_UNTOUCHED 7) zfs clone !$ tank/usr/src_r195488-UNTOUCHED 8) zfs promote !$ 9) zfs set readonly=on !$ 10) And, in case it may matter, I slightly modified the contents of / usr/src afterwards (applied two patches that aren't merged into HEAD (yet?)). ... I THINK that's it. Since my bash_history got killed in the panic, I may be slighty wrong. In any case, usr/src is now a clone of the readonly UNTOUCHED fs: [root@chaos ~]# zfs get origin tank/usr/src NAME PROPERTY VALUE SOURCE tank/usr/src origin tank/usr/ src_r195488_UNTOUCHED@r195488_UNTOUCHED - I then ran the backup script just posted in this thread: [root@chaos ~]# bash backup.sh backup Creating ggate device Sleeping for 5 seconds... Importing pool Taking snapshots Starting backup... attempting destroy slave/usr/src_r194478-UNTOUCHED@backup-20090709-1250 success attempting destroy slave/usr/src_r194478-UNTOUCHED@r194478-UNTOUCHED failed - trying rename to slave/usr/src_r194478-UNTOUCHED@recv-38883-1 failed (2) - will try again on next pass attempting destroy slave/usr/src_r194478-UNTOUCHED@backup-20090709-1235 success attempting destroy slave/usr/src_r194478-UNTOUCHED failed - trying rename to slave/recv-38883-2 failed (2) - will try again on next pass promoting slave/usr/src another pass: attempting destroy slave/usr/src_r194478-UNTOUCHED success attempting destroy slave/usr/src@r194478-UNTOUCHED success attempting rename slave/usr/src to slave/usr/src_r195488_UNTOUCHED success receiving incremental stream of tank@backup-20090709-1328 into slave@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/tmp@backup-20090709-1328 into slave/tmp@backup-20090709-1328 received 119KB stream in 1 seconds (119KB/sec) receiving incremental stream of tank/var@backup-20090709-1328 into slave/var@backup-20090709-1328 received 211KB stream in 1 seconds (211KB/sec) receiving incremental stream of tank/var/log@backup-20090709-1328 into slave/var/log@backup-20090709-1328 received 468KB stream in 1 seconds (468KB/sec) receiving incremental stream of tank/var/crash@backup-20090709-1328 into slave/var/crash@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/root@backup-20090709-1328 into slave/root@backup-20090709-1328 received 156KB stream in 1 seconds (156KB/sec) receiving incremental stream of tank/usr@backup-20090709-1328 into slave/usr@backup-20090709-1328 received 302KB stream in 1 seconds (302KB/sec) receiving incremental stream of tank/usr/obj@backup-20090709-1328 into slave/usr/obj@backup-20090709-1328 received 8.52MB stream in 8 seconds (1.07MB/sec) receiving incremental stream of tank/usr/ src_r195488_UNTOUCHED@r195488_UNTOUCHED into slave/usr/ src_r195488_UNTOUCHED@r195488_UNTOUCHED received 112MB stream in 43 seconds (2.60MB/sec) receiving incremental stream of tank/usr/ src_r195488_UNTOUCHED@backup-20090709-1328 into slave/usr/ src_r195488_UNTOUCHED@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/usr/ports@backup-20090709-1328 into slave/usr/ports@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) receiving incremental stream of tank/usr/ports/ distfiles@backup-20090709-1328 into slave/usr/ports/ distfiles@backup-20090709-1328 received 312B stream in 1 seconds (312B/sec) found clone origin slave/usr/src_r195488_UNTOUCHED@r195488_UNTOUCHED receiving incremental stream of tank/usr/src@backup-20090709-1328 into slave/usr/src@backup-20090709-1328 received 216KB stream in 1 seconds (216KB/sec) local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring Exporting pool Read from remote host 192.168.1.10: Operation timed out ... and the DDB output (first part copy/paste from kgdb, second part handwritten since the kgdb BT was totally broken, as I expected.) Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x70 fault code = supervisor write data, page not present instruction pointer = 0x20:0xffffffff8036e855 stack pointer = 0x28:0xffffff803ea637d0 frame pointer = 0x28:0xffffff803ea637e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 38905 (zpool) _sx_slock() dmu_buf_update_user()+0x47 zfs_znode_dmu_fini() zfs_freebsd_reclaim() VOP_RECLAIM_APV() vgonel() vflush() zfs_umount() dounmount() unmount() syscall() Xfast_syscall() BTW, what's with the "local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring" part? This is what I get when I try an incremental backup now: [root@chaos ~]# bash backup.sh backup Creating ggate device Sleeping for 5 seconds... Importing pool Taking snapshots Starting backup... local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring receiving incremental stream of tank@backup-20090709-1328 into slave@backup-20090709-1328 snap slave@backup-20090709-1328 already exists; ignoring local fs slave/usr/src does not have fromsnap (backup-20090709-1250 in stream); must have been deleted locally; ignoring warning: cannot send 'tank/tmp@backup-20090709-1328': Broken pipe warning: cannot send 'tank/tmp@backup-20090709-1406': Broken pipe Exporting pool Running rsync ... rsync runs, no panic, but no ZFS backup, either. Guess it's time for another "initial" backup, i.e. start all over with 0 snapshots... The initial backup worked just fine, it found the clone/origin etc. and made it work. Stripped from comments and echo statements, the function is simply: function initial { for BACK in $(zfs list -t snapshot -H -r tank | awk '{print $1}'); do zfs destroy $BACK; done zpool destroy slave 2>/dev/null; sleep 3; ggatel destroy -u 666 2>/dev/null; sleep 3 # Clean up if needed ggatel create -u 666 /mnt/backup/chaos/slavefile; sleep 3 zpool create -f -R /slave slave ggate666 && NOW=$(date +"backup-%Y %m%d-%H%M") || die 'Unable to create pool' zfs snapshot -r tank@$NOW || die 'Unable to snapshot' zfs send -R tank@$NOW | zfs recv -vFd slave mount_unmount unmount echo $NOW > /root/.last-backup } After that, incrementals are fine again. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 13:24:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA8741065678 for ; Thu, 9 Jul 2009 13:24:46 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 3AC558FC15 for ; Thu, 9 Jul 2009 13:24:45 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by fxm24 with SMTP id 24so136699fxm.43 for ; Thu, 09 Jul 2009 06:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=MP3H7gG/WruFpqhpkoBQ3E7qiJRrHgg6e1zrSn8a6yo=; b=WH7ZQrgfLvbRiwYghH2OawBy0WXEfO+Emanxliaq/Ut5aZ7EGhvAyR0MP2xlT2ciKX qsdogQ+oyylngYraQwsOu0ZLpMwDBuA8u5NqiZV1QW9yvjmz6KIAKdKXqN9tgc9577HR tp7QoVkfczK4lyi4CZFhpHAPbiVvtc1jDz7h4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=uHhgUdBqzPnp5yIzC7uGxAZY2gnw5ZEt8JcoTkKCdZ/yyUa5SfWRpgy6PI6CKT14/y 1QW7z5xGkBJqtx3wbq+SEd8LBeDIaWMibrwrj2JckR7SMl4LHGOWbi8dxEp9vKVb1fTi MS+szeqpUKWydmBr/MkFboVM1Vb39vhf0NJ+s= MIME-Version: 1.0 Received: by 10.86.54.8 with SMTP id c8mr225393fga.38.1247145885076; Thu, 09 Jul 2009 06:24:45 -0700 (PDT) In-Reply-To: References: <4A55D83E.4020206@yartv.ru> From: Maxim Ignatenko Date: Thu, 9 Jul 2009 16:24:25 +0300 Message-ID: To: freebsd-current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: panic while configuring vlan on msk X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 13:24:46 -0000 2009/7/9 Andrey Groshev : > Hi, again :) > > it was necessary to work with vlan-s, but did not succeed ... > > #ifconfig vlan7 create > #ifconfig vlan7 vlan 7 vlandev msk0 > > panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/dev/e1000/if_em.c:1= 623 > cpuid =3D 1 > KBD: enter: panic > [thread pid 43561 tid 100322 ] > Stopped at =C2=A0 =C2=A0kdb_enter+0x3a: movl =C2=A0 =C2=A0$0,kbd_why > db> bt > Tracing pid 43561 tid 100322 td 0xc9967d80 > kdb_enter(c0cb1978,c0cb1978,c0cb03e4,eab05a70,1,...) at kdb_enter+0x03 > panic(c0cb03e4,0,c0c79470,657,c9967e24,...) at panic+0x136 > _mtx_lock_flags(c60db4e4,0,c0c79470,657,c60d7000,...) at > _mtx_lock_flags+0x9a > em_init(c60d7000) at em_init+0x35 > em_register_vlan(0,c60cd400,7,430,c696fb84,...) at em_register_vlan+0x44 > vlan_config(eab05b16,eab05b16,12,eab05b24,c6978220,...) at vlan_config+0x= 316 > vlan_ioctl(c6135400,80206939,c6978220,c9967d80,eab05bac,...) at > vlan_ioctl+0x2d5 > ifioctl(c9520338,80306939,c6978220,c9967d80,ca243500,...) at ifioctl+0x11= a8 > soo_ioctl(c6d02e38,80206939,c6978220,c65a0b80,c9967d80,...) at > soo_ioctl+0x415 > kern_ioctl(c9967d80,3,80206939,c6978220,8f52d0,...) at kern_ioctl+0x1fd > ioctl(c9967d80,eab05cf8,c,c0cc863f,c0d996dc8,...) at ioctl+0x134 > syscall(eab05d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x33dbda23, esp =3D 0xbfb= fe1ec, > ebp =3D 0xbfbfe208 --- It seems you stepped on the problem described in http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/132715 em_register_vlan was rewritten r194865, but patch in followup to PR quite trivial and can be applied manually. From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 14:20:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70BA2106566B for ; Thu, 9 Jul 2009 14:20:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B56458FC15 for ; Thu, 9 Jul 2009 14:20:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA10857 for ; Thu, 09 Jul 2009 17:20:02 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A55FC92.5040205@icyb.net.ua> Date: Thu, 09 Jul 2009 17:20:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: [Fwd: AMD SB700/SB710/SB750 docs have been released!] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:20:05 -0000 Might be useful for people hacking on AMD platform drivers and related. -------- Original Message -------- Subject: AMD SB700/SB710/SB750 docs have been released! Date: Thu, 09 Jul 2009 03:59:36 +0200 From: Carl-Daniel Hailfinger To: Coreboot AMD just released the following docs we need for SB700/SB710/SB750 coreboot support: * AMD SB700/710/750 Register Reference Guide * AMD SB700/710/750 BIOS Developer’s Guide * AMD SB700/710/750 Register Programming Requirements * AMD SB710 Databook Links to all data sheets are at http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 This is a great step towards supporting current RS780/SB700 family systems. Immediate benefits of this doc release are: - We can implement SB700/SB710/SB750 support without NDA. - We can study the embedded controller environment and the SuperI/O functionality in some SB7x0 southbridges. Future benefits are: - We can support 690/SB700 boards once the SB700 code is done. - We can test SB700 code in 690/SB700 boards and make sure it works perfectly before we start working on RS780 code. - We have 50% of the docs we need for almost all boards with AMD chipset on sale today. What can we do next? - Implement SB700 code. - RS690/SB700 boards do not exist. However, it seems that RS740 is RS690 with a modified graphics core, so RS740/SB700 boards are the best targets we can pick. List of possible targets with RS740/SB700: - ECS Elitegroup A740GM-M (89-206-V15102) http://www.ecs.com.tw/ECSWebSite/Products/ProductsDetail.aspx?detailid=864&CategoryID=1&DetailName=Specification&MenuID=1&LanID=0 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=3063 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2813 - Gigabyte GA-MA74GM-S2 (rev 1.x and 2.0) http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2775 http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=3062 - ASUS M2A74-AM http://www.asus.com/product.aspx?P_ID=YPZrr3KRcW3MBX5G - MSI K9A2GM-F V3 (MS-7302-020, there seem to be many variants of this board, some of them may have a 740 variant which is not compatible with 690) http://us.msi.com/product/p_spec.asp?model=K9A2GM-F_V3&class=mb Thanks to AMD for releasing these docs! Regards, Carl-Daniel -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 14:21:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D33161065670 for ; Thu, 9 Jul 2009 14:21:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 187E78FC18 for ; Thu, 9 Jul 2009 14:21:26 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n69ELL86003248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2009 17:21:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n69ELLsl087172 for ; Thu, 9 Jul 2009 17:21:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n69ELLNd087137 for freebsd-current@freebsd.org; Thu, 9 Jul 2009 17:21:21 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Jul 2009 17:21:21 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20090709142121.GS55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FiqEyLLt06qkB6ow" Content-Disposition: inline In-Reply-To: <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:21:28 -0000 --FiqEyLLt06qkB6ow Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 17:30 +1000, John Marshall wrote: > > On Thu, 09 Jul 2009, 10:42 +0400, pluknet wrote: > > > 2009/7/9 John Marshall : > > > > After upgrading... > > > > - boot new kernel to single-user > > > > - make installworld > > > > - make delete-old > > > > - make delete-old-libs > > > > - mergemaster > > > > - reboot > > > > > > > > I re-built a few of my applications. I noticed a problem with ntpd > > > > 4.2.4p7. The build was fine, it started fine, but got stuck in vmm= aps > > > > and I couldn't kill it. Stopping the operating system appears to b= e the > > > > only remedy. I have re-built a few times (starting with 'make > > > > distclean') just to make sure. > > > > > > > > UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME = COMMAND > > > > 0 791 1 0 44 0 4944 4920 vmmaps Ds ?? 0:00.01 = ntpd > > > > > > >=20 > > > Can you place here 'procstat -k 791', where 791 is pid of ntpd? > > > It'd be nice also if you go through all ddb steps described in > > > Debugging Deadlocks chapter of FreeBSD Developers' Handbook. > >=20 > > Here is some procstat output. I'm just rebuilding the kernel with the > > debugging options enabled - not something I've ever done before. > >=20 > > rwsrv05# procstat 2788 > > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM= =20 > > 2788 1 2788 2788 0 1 john vmmaps FreeBSD ELF32 ntpd= =20 > > rwsrv05# procstat -k 2788 > > PID TID COMM TDNAME KSTACK = =20 > > 2788 100164 ntpd - mi_switch sleepq_switch = sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mma= p mmap syscall Xint0x80_syscall=20 > > rwsrv05# procstat -v 2788 > > PID START END PRT RES PRES REF SHD FL TP PATH > > 2788 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/= ntpd > > 2788 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/= ntpd > > 2788 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 > > 2788 0x2807e000 0x280ab000 r-x 45 0 171 75 CN vn /libexec/ld-elf= .so.1 > > 2788 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf= .so.1 > > 2788 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 > > 2788 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > > 2788 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > > 2788 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > > 2788 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.= so.5 > > 2788 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.= so.5 > > 2788 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.= so.5 > > 2788 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 > > 2788 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > > 2788 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > > 2788 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > > 2788 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf= .so.1 > > 2788 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf= .so.1 > > 2788 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf= .so.1 > > 2788 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.= so.1 > > 2788 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.= so.1 > > 2788 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.= so.1 > > 2788 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > > 2788 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > > 2788 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > > 2788 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > > 2788 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > > 2788 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > > 2788 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 > > 2788 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 > > 2788 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 > > 2788 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 > > rwsrv05#=20 >=20 > OK, now that I've rebuilt the kernel with the debugging options not > commented out, I'm getting a number of 'lock order reversal' messages > printed on the console: is that normal? >=20 > From the Debugging Deadlocks chapter to which I was referred by pluknet > (above) it appears that I need to enter 'sysctl debug.kdb.enter=3D1' or > 'sysctl debug.kdb.panic=3D1' after I get the process into the desired > 'stuck' state. If I enter either of those commands, the system reboots. > Now *I'm* stuck. Since you have mostly working system, and interesting information most easy accessible by kgdb, attach it to the live kernel: kgdb /dev/mem =46rom there, switch to the stuck process, process do bt find the frame for vm_map_delete, and print the entry: p entry Also, I need to see the information you posted earlier, namely, procstat -k and -v output for the process. --FiqEyLLt06qkB6ow Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpV/OAACgkQC3+MBN1Mb4hMnQCfYV77E+BucFdo3ScitgWSPW3m zOwAn1nXO/9ns8JWl59RJqh9+dRSFedE =2J9a -----END PGP SIGNATURE----- --FiqEyLLt06qkB6ow-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 14:47:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9623106570F for ; Thu, 9 Jul 2009 14:47:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id 849708FC15 for ; Thu, 9 Jul 2009 14:47:47 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.3/8.14.3/NETPLEX) with ESMTP id n69EljdM021937; Thu, 9 Jul 2009 10:47:46 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Thu, 09 Jul 2009 10:47:46 -0400 (EDT) Date: Thu, 9 Jul 2009 10:47:45 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Andriy Gapon In-Reply-To: <4A55FC92.5040205@icyb.net.ua> Message-ID: References: <4A55FC92.5040205@icyb.net.ua> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-758783491-1247150865=:24629" Cc: freebsd-current@freebsd.org Subject: Re: [Fwd: AMD SB700/SB710/SB750 docs have been released!] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 14:47:48 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-758783491-1247150865=:24629 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 9 Jul 2009, Andriy Gapon wrote: > > Might be useful for people hacking on AMD platform drivers and related. > > -------- Original Message -------- > Subject: AMD SB700/SB710/SB750 docs have been released! > Date: Thu, 09 Jul 2009 03:59:36 +0200 > From: Carl-Daniel Hailfinger > To: Coreboot > > AMD just released the following docs we need for SB700/SB710/SB750 > coreboot support: > > * AMD SB700/710/750 Register Reference Guide > * AMD SB700/710/750 BIOS Developer=E2=80=99s Guide > * AMD SB700/710/750 Register Programming Requirements > * AMD SB710 Databook > > Links to all data sheets are at > http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 > > This is a great step towards supporting current RS780/SB700 family system= s. > > Immediate benefits of this doc release are: > - We can implement SB700/SB710/SB750 support without NDA. > - We can study the embedded controller environment and the SuperI/O [ snip ] I am running -current on an ASUS M4A78T-E which has the SB750 chipset. Seems to work fine, -j8 buildworld is 21 minutes, buildkernel with modules is about 7 minutes. I'm not using any of the RAID functionality. The dmesg is here: http://people.freebsd.org/~deischen/asus_m4a78t-e.dmesg --=20 DE ---559023410-758783491-1247150865=:24629-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 16:09:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 722AA106566B for ; Thu, 9 Jul 2009 16:09:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id DCC568FC15 for ; Thu, 9 Jul 2009 16:09:01 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n69G8u30014730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 9 Jul 2009 19:08:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n69G8uaW007943 for ; Thu, 9 Jul 2009 19:08:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n69G8uHP007903 for freebsd-current@freebsd.org; Thu, 9 Jul 2009 19:08:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 9 Jul 2009 19:08:56 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20090709160855.GU55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="twKjCw1/F6C/WBH6" Content-Disposition: inline In-Reply-To: <20090709142121.GS55190@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:09:02 -0000 --twKjCw1/F6C/WBH6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 09, 2009 at 05:21:21PM +0300, Kostik Belousov wrote: > From there, switch to the stuck process, > process > do > bt > find the frame for vm_map_delete, and print the entry: > p entry ^^^^^^^^^^This shall be p *entry >=20 > Also, I need to see the information you posted earlier, namely, procstat > -k and -v output for the process. --twKjCw1/F6C/WBH6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpWFhcACgkQC3+MBN1Mb4gj9QCgyHqZ52EsFl8JF2f4lf5rSwF6 BCYAoJ/3rI3RvAclrzNxlh9VLou4+DQe =eOYy -----END PGP SIGNATURE----- --twKjCw1/F6C/WBH6-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 16:19:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id D907B1065676; Thu, 9 Jul 2009 16:19:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org, Daniel Eischen Date: Thu, 9 Jul 2009 12:19:35 -0400 User-Agent: KMail/1.6.2 References: <4A55FC92.5040205@icyb.net.ua> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-Id: <200907091219.41323.jkim@FreeBSD.org> Cc: Andriy Gapon Subject: Re: [Fwd: AMD SB700/SB710/SB750 docs have been released!] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:19:52 -0000 On Thursday 09 July 2009 10:47 am, Daniel Eischen wrote: > On Thu, 9 Jul 2009, Andriy Gapon wrote: > > Might be useful for people hacking on AMD platform drivers and > > related. > > > > -------- Original Message -------- > > Subject: AMD SB700/SB710/SB750 docs have been released! > > Date: Thu, 09 Jul 2009 03:59:36 +0200 > > From: Carl-Daniel Hailfinger > > To: Coreboot > > > > AMD just released the following docs we need for > > SB700/SB710/SB750 coreboot support: > > > > * AMD SB700/710/750 Register Reference Guide > > * AMD SB700/710/750 BIOS Developer’s Guide > > * AMD SB700/710/750 Register Programming Requirements > > * AMD SB710 Databook > > > > Links to all data sheets are at > > http://www.coreboot.org/Datasheets#AMD_SB700.2FSB710.2FSB750 > > > > This is a great step towards supporting current RS780/SB700 > > family systems. > > > > Immediate benefits of this doc release are: > > - We can implement SB700/SB710/SB750 support without NDA. > > - We can study the embedded controller environment and the > > SuperI/O > > [ snip ] > > I am running -current on an ASUS M4A78T-E which has the SB750 > chipset. Seems to work fine, -j8 buildworld is 21 minutes, > buildkernel with modules is about 7 minutes. I'm not using any of > the RAID functionality. > > The dmesg is here: > > http://people.freebsd.org/~deischen/asus_m4a78t-e.dmesg I implemented SB700 combined mode support for ata(4) on -CURRENT: http://svn.freebsd.org/changeset/base/191568 I did it without the docs and I had many unanswered questions. Now I am very happy to see they are finally released without NDA. :-) Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 16:34:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C07EA106567A for ; Thu, 9 Jul 2009 16:34:14 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by mx1.freebsd.org (Postfix) with ESMTP id 77AFB8FC26 for ; Thu, 9 Jul 2009 16:34:14 +0000 (UTC) (envelope-from sektie@gmail.com) Received: by qyk42 with SMTP id 42so223328qyk.3 for ; Thu, 09 Jul 2009 09:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=HtaKHGCMkaAupi5x0ydlR1SgtOEsYtVoZElmKJRJP4k=; b=mPJDm3UxGAsaN0vUlvz+f1k+drPv1c1wOSaxUeww2RTHDXV8id7ErTnBmBq9Kc92EK wuQmHPIXLH4oFpRgdPGf4d4eGAdI27dg8tyMkWLZSr3dKA5bspgcUSNSABxTroCLSaoL OzifyQOVK9LL2bc+Qua/eYStWTiaIbLxyTldk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=dYVPPbw59TXanX/dOZqiuqwsWBbhMJhsc3BzCxkBM/SBlMnZOc0fmJQLKU6nJKznMB GaD4DdUNKDfnVZTTHWl5HqpUGnzVMLNDjt3WlrdVN4Zrb7Lntj0nzMLHykVLFwwIWG8l oYH5d3CpUxNcMMDoWYDToRpkljzpylWynAvjg= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.229.95.77 with SMTP id c13mr179633qcn.2.1247156010738; Thu, 09 Jul 2009 09:13:30 -0700 (PDT) In-Reply-To: <4A559E50.3090408@bsdunix.ch> References: <4A559E50.3090408@bsdunix.ch> Date: Thu, 9 Jul 2009 09:13:30 -0700 X-Google-Sender-Auth: c1c74fe6f41cc5c0 Message-ID: From: Randi Harper To: Thomas Vogt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: USB stick installation problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:34:15 -0000 On Thu, Jul 9, 2009 at 12:37 AM, Thomas Vogt wrote: > Hi > > I download and copied 8.0-BETA1-amd64-memstick.img to an usb stick as > described at > http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051018.html. > > I can boot it and sysinstall runs fine. Later i chose USB stick as > install medium but then i get a "no USB stick found" error. Is this an > know bug? > > Regards, > Thomas Possibly. Can you please tell sysinstall to rescan devices or restart the sysinstall process and tell me if that makes a difference? -- randi From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 16:39:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B781065670; Thu, 9 Jul 2009 16:39:47 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 89E098FC14; Thu, 9 Jul 2009 16:39:47 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMI0035BWXKFG20@asmtp026.mac.com>; Thu, 09 Jul 2009 09:39:22 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> Date: Thu, 09 Jul 2009 09:39:20 -0700 Message-id: <8B6FE903-10E5-4A32-8E2E-482595D8F495@mac.com> References: <20090707094808.GA93317@mech-cluster238.men.bris.ac.uk> <20090707095058.GC7827@rink.nu> <20090707124405.GA46091@mech-cluster238.men.bris.ac.uk> <20090707133611.GA66072@rink.nu> <93B562A8-9FE7-44D5-91E4-C9AB1A25BD2A@mac.com> <20090708114019.GA19781@mech-cluster238.men.bris.ac.uk> <650DC54B-5FA6-49CB-8A9C-58461289778F@mac.com> <20090709085014.GE43264@mech-cluster238.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1068) Cc: Rink Springer , freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: buildworld panic on ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 16:39:50 -0000 On Jul 9, 2009, at 1:50 AM, Anton Shterenlikht wrote: >> By all means: experiment. But be very careful not to make >> the assumption that if the code compiles, it'll also run. >> The weirder the set of compiler options, the more likely >> you trip over optimization bugs and end up with an unstable >> system. And I'm not even talking about whether the set >> of options give you more optimal code in general. > > I see.. > > Is there any advice for compiler options on ia64? My advise at this time is to not change from the default. I haven't done any kind of experimentation or know of any- one else who did, to make any kind of claim as to the effectiveness or harm of various compiler options. I'm not talking cleanroom experiments here. I'm sure that there have been plenty of people looking at SPECcpu and who came up with a very creative set of compiler options that make SPECcpu perform "optimally" (for each program). This normally also includes fixing the compiler (and even adding special case code) to have correct code generated in that case. I'm talking about a safe set of options that people can use and that yields correct code 99.9% of the time and gives acceptable (if not good) code. I cannot stress the importance of having the toolchain generate correct code when working on a FreeBSD port to a different architecture. > I'm sorry if I'm asking obvious questions. > Perhaps this is documented/disucced somewhere > already? I'm new to ia64, most of my FBSD > experience is from alpha and i386. These aren't obvious questions. Compiler options, if they are being discussed, are primarily discussed for i386 or amd64. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 17:15:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F313106564A for ; Thu, 9 Jul 2009 17:15:35 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id EACC88FC19 for ; Thu, 9 Jul 2009 17:15:34 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so100791qwd.7 for ; Thu, 09 Jul 2009 10:15:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=JN2ldGUQ6V6kot7apB1p9c6GVvxEhrhqjxCIrBvKz2E=; b=U94aKLFuHXbXep6QgrlN1c6KcmEWa1JfPgXoZWcxL9fr0QblCQCQ92ZzclzW2V9WWC Tw3Vf4hkfJreT20YEMEaVDWqhWs3fpX7LSReRjCHOs1MAFzhLZFnpaNuJ13rHNUhXzfR EWq9N1w5CUfdIHrgoy8wuam06AhwPETeCLP4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=JKlf+IQ950X0dfLDGJcs0dO6OQ2RPAVLDrM9+0rR2LGd0WMS+T/yp/PEn2n4UXMclO f2MUWphqk3MsrJDhXlp1d/Hqy1TLnK/Pmma0ytMFGeGS40mGJDvyyraakCefsqbt4qL2 TB7M3QOIAxBpWBmSef7CQ7ESGnUaopGHD3Tc8= MIME-Version: 1.0 Received: by 10.229.86.145 with SMTP id s17mr182330qcl.10.1247159734184; Thu, 09 Jul 2009 10:15:34 -0700 (PDT) Date: Thu, 9 Jul 2009 12:15:34 -0500 Message-ID: <11167f520907091015l35827121r30b848922425d840@mail.gmail.com> From: "Sam Fourman Jr." To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: FreeBSD 8 BETA1 DHCP trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:15:35 -0000 Hello list, I have had issues obtaining DHCP address on Asus dual nic motherboards with kernels built after ~ 6-6-2009 (eg nfe0 will not dhcp just times out but nfe1 will work) I played with my hardware for a bit before I noticed it was a FreeBSD bug. sure enough revert back to a 6-1-2009 kernel and nfe0 and 1 dhcp again. Sam Fourman Jr. sfourman@ ~/.wine/drive_c/Program Files/World of Warcraft]$ dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #0: Tue Jul 7 21:47:44 CDT 2009 sfourman@:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.64-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x408e3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3135557632 (2990 MB) ACPI APIC Table: <022609 APIC1009> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) 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 kbd1 at kbdmux0 acpi0: <022609 XSDT1009> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 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) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 1.7 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xdc00-0xdc7f mem 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: irq 17 at device 4.0 on pci0 pci2: on pcib2 pci0: at device 9.0 (no driver attached) isab0: port 0x2f00-0x2f7f at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xf7ffb000-0xf7ffbfff irq 22 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xf7ffac00-0xf7ffacff irq 23 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f mem 0xf7ff9000-0xf7ff9fff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0xb800-0xb807,0xb480-0xb483,0xb400-0xb407,0xb080-0xb083,0xb000-0xb00f mem 0xf7ff8000-0xf7ff8fff irq 22 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f mem 0xf7ff7000-0xf7ff7fff irq 23 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib3: at device 15.0 on pci0 pci3: on pcib3 fwohci0: port 0xec00-0xec7f mem 0xfbfff800-0xfbffffff irq 18 at device 7.0 on pci3 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:01:af:44:a4 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xbcbb0000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:af:44:a4 fwe0: Ethernet address: 02:1e:8c:af:44:a4 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:01:af:44:a4 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode hdac0: mem 0xf7ff0000-0xf7ff3fff irq 21 at device 15.1 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] nfe0: port 0xa080-0xa087 mem 0xf7ff6000-0xf7ff6fff,0xf7ffa800-0xf7ffa8ff,0xf7ffa400-0xf7ffa40f irq 20 at device 17.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:23:54:96:dd:8d nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xa000-0xa007 mem 0xf7ff5000-0xf7ff5fff,0xf7ffa000-0xf7ffa0ff,0xf7ff4c00-0xf7ff4c0f irq 20 at device 18.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 2 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: Ethernet address: 00:23:54:96:de:2f nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib4: at device 19.0 on pci0 pci4: on pcib4 pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 pcib7: at device 24.0 on pci0 pci7: on pcib7 acpi_button0: on acpi0 ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] atrtc1: port 0x70-0x71 on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - CA, should be C2 20090521 tbutils-275 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 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. ppc0: parallel port not found. Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ad6: 152627MB at ata3-master SATA300 GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). ad10: 238475MB at ata5-master SATA300 acd0: DVDR at ata6-master SATA150 acd1: DVDR at ata7-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1988B pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 GEOM: ad6s1: geometry does not match label (255h,63s != 16h,63s). uhub0: 10 ports with 10 removable, self powered SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 uhub1: 10 ports with 10 removable, self powered Root mount waiting for: usbus1 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 Trying to mount root from ufs:/dev/ad6s1a uhub2: 4 ports with 2 removable, bus powered ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 ugen0.4: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=0 ugen0.5: at usbus0 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 uhid1: on usbus0 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 lock order reversal: 1st 0xc7826270 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1054 2nd 0xc7827df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e9884818,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d30910,c6d30840,e9884874,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,c7827df4,c0c4dec5,c6d30840,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(c7827df4,9,c0c6617e,823,0,...) at witness_checkorder+0x839 __lockmgr_args(c7827df4,80100,c7827e10,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(e988497c,c08b5cdb,c0c4e0f6,80100,c7827d9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0d39660,e988497c,c7677764,c0d76700,c7827d9c,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c7827d9c,80100,c0c6617e,823,8,...) at _vn_lock+0x5e vget(c7827d9c,80100,c76776c0,15e,c0c4e018,...) at vget+0xb9 devfs_allocv(c7431480,c7619000,e9884a14,9d,c0f17a58,...) at devfs_allocv+0x102 devfs_root(c7619000,80000,e9884c30,42c,0,...) at devfs_root+0x4a vfs_donmount(c76776c0,0,c7437300,c7437300,bfbfde39,...) at vfs_donmount+0x14bb nmount(c76776c0,e9884cf8,c,c76776c0,c0d3f3b8,...) at nmount+0x75 syscall(e9884d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (378, FreeBSD ELF32, nmount), eip = 0x33ce7d3b, esp = 0xbfbfde0c, ebp = 0xbfbfe368 --- nfe1: link state changed to DOWN nfe1: link state changed to UP lock order reversal: 1st 0xdad11570 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xc747c200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e991c860,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d2cf60,c6d30978,e991c8bc,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,c747c200,c0c7f0d0,c6d30978,c0c7ed69,...) at _witness_debugger+0x25 witness_checkorder(c747c200,9,c0c7ed69,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c747c200,0,c0c7ed69,11d,c7823414,...) at _sx_xlock+0x85 ufsdirhash_acquire(dad11510,e991c9d4,3c,db78b5e4,e991c98c,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c7823414,e991c9d4,5e4,e991c978,e991c97c,...) at ufsdirhash_add+0x13 ufs_direnter(c78c2754,c7cf2c90,e991c9d4,e991cbdc,0,...) at ufs_direnter+0x729 ufs_makeinode(e991cbdc,e991cb48,e991cc00,e991cb1c,c0ba7255,...) at ufs_makeinode+0x4f8 ufs_create(e991cc00,e991cc14,e991cb48,e991cb48,0,...) at ufs_create+0x30 VOP_CREATE_APV(c0d5dc60,e991cc00,e991cbdc,e991cb48,c7a857fc,...) at VOP_CREATE_APV+0xa5 uipc_bind(c7a7c9a8,c7682180,c78ad6c0,e991cc60,c08e1e02,...) at uipc_bind+0x32e sobind(c7a7c9a8,c7682180,c78ad6c0,c7682180,c7532188,...) at sobind+0x23 kern_bind(c78ad6c0,3,c7682180,c7682180,8094884,...) at kern_bind+0xc2 bind(c78ad6c0,e991ccf8,c,c0c5f78a,c0d3d5c0,...) at bind+0x46 syscall(e991cd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (104, FreeBSD ELF32, bind), eip = 0x33d9bdff, esp = 0xbfbfe85c, ebp = 0xbfbfe958 --- lock order reversal: 1st 0xc838b164 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3496 2nd 0xdadbd5c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6170 3rd 0xc838b058 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,eb9ed8c0,c08b5f35,c08a6cdb,c0c5ef12,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5ef12,c6d2cf60,c6d30910,eb9ed91c,...) at kdb_backtrace+0x29 _witness_debugger(c0c5ef12,c838b058,c0c51b6a,c6d30910,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(c838b058,9,c0c6617e,823,0,...) at witness_checkorder+0x839 __lockmgr_args(c838b058,80100,c838b074,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(eb9eda2c,c08b5cdb,c0c65671,80100,c838b000,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d5dc60,eb9eda2c,c83ab0a4,c0d76700,c838b000,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c838b000,80100,c0c6617e,823,4,...) at _vn_lock+0x5e vget(c838b000,80100,c83ab000,50,0,...) at vget+0xb9 vfs_hash_get(c761ea10,11606,80000,c83ab000,eb9edb88,...) at vfs_hash_get+0xe6 ffs_vgetf(c761ea10,11606,80000,eb9edb88,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c838b10c,0,c0c7e9e2,146,0,...) at softdep_sync_metadata+0x5ba ffs_syncvnode(c838b10c,1,c83c7e58,dad,c838b1b4,...) at ffs_syncvnode+0x3e2 ffs_fsync(eb9edc5c,eb9edcf8,0,eb9edc5c,eb9edc80,...) at ffs_fsync+0x27 VOP_FSYNC_APV(c0d5dc60,eb9edc5c,c0c67206,dad,0,...) at VOP_FSYNC_APV+0xa5 fsync(c83ab000,eb9edcf8,4,c0c7d380,c0d3d4c4,...) at fsync+0x1df syscall(eb9edd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (95, FreeBSD ELF32, fsync), eip = 0x341ec127, esp = 0xbfbfe19c, ebp = 0xbfbfe1b8 --- lock order reversal: 1st 0xc7a6b52c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xc8439488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e99b1a2c,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d2d238,c6d30910,e99b1a88,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,c8439488,c0c51b6a,c6d30910,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(c8439488,9,c0c6617e,ffb,c84394a4,...) at witness_checkorder+0x839 __lockmgr_args(c8439488,80400,c84394a4,0,0,...) at __lockmgr_args+0x7a7 ffs_lock(e99b1b98,4,0,80400,c8439430,...) at ffs_lock+0x8a VOP_LOCK1_APV(c0d5dc60,e99b1b98,c0c53d5d,c0d76700,c8439430,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c8439430,80400,c0c6617e,ffb,e99b1bf4,...) at _vn_lock+0x5e vfs_knllock(c8439430,0,c0c53d5d,696,c836b4c8,...) at vfs_knllock+0x29 knlist_remove_kq(0,e99b1c14,c0900ee9,c8438580,c836b4c8,...) at knlist_remove_kq+0x85 knlist_remove(c8438580,c836b4c8,0,e99b1c40,c0844625,...) at knlist_remove+0x1b filt_vfsdetach(c836b4c8,0,c0c53d5d,777,19,...) at filt_vfsdetach+0x39 knote_fdclose(c7995240,12b9,c0c538a5,440,c7a6b52c,...) at knote_fdclose+0xf5 kern_close(c7995240,12b9,e99b1d2c,c0b998e3,c7995240,...) at kern_close+0xd2 close(c7995240,e99b1cf8,4,c0c5f78a,c0d3cb08,...) at close+0x1a syscall(e99b1d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x33f7a9e3, esp = 0xbfbfe6bc, ebp = 0xbfbfe6d8 --- acquiring duplicate lock of same type: "ftlk" 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,eba20b58,c08b5f35,c08a6cdb,c0c5edec,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5edec,c1104957,c6d30ec0,eba20bb4,...) at kdb_backtrace+0x29 _witness_debugger(c0c5edec,c1104993,c1104957,cb,0,...) at _witness_debugger+0x25 witness_checkorder(c7d2fc00,9,c1104957,cb,0,...) at witness_checkorder+0x469 _sx_xlock(c7d2fc00,0,c1104957,cb,0,...) at _sx_xlock+0x85 futex_get0(c0ee7cf0,c862b9a4,c0ee7cf0,c0d44960,c0c9133c,...) at futex_get0+0x116 linux_sys_futex(c862b900,eba20cf8,eba20d18,eba20d1c,c1107f40,...) at linux_sys_futex+0x6f syscall(eba20d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x34399533, esp = 0xbfbfbeec, ebp = 0x4000001 --- lock order reversal: 1st 0xc7a6b52c filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xcc545ce8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4091 KDB: stack backtrace: db_trace_self_wrapper(c0c5c064,e99b1a34,c08b5f35,c08a6cdb,c0c5eef9,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08a6cdb,c0c5eef9,c6d2d238,c6d30b80,e99b1a90,...) at kdb_backtrace+0x29 _witness_debugger(c0c5eef9,cc545ce8,c0c4e978,c6d30b80,c0c6617e,...) at _witness_debugger+0x25 witness_checkorder(cc545ce8,9,c0c6617e,ffb,cc545d04,...) at witness_checkorder+0x839 __lockmgr_args(cc545ce8,80400,cc545d04,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(e99b1b98,4,0,80400,cc545c90,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0d3a320,e99b1b98,c0c53d5d,c0d76700,cc545c90,...) at VOP_LOCK1_APV+0xb5 _vn_lock(cc545c90,80400,c0c6617e,ffb,e99b1bf4,...) at _vn_lock+0x5e vfs_knllock(cc545c90,0,c0c53d5d,696,c7e16154,...) at vfs_knllock+0x29 knlist_remove_kq(0,e99b1c14,c0900ee9,c9358580,c7e16154,...) at knlist_remove_kq+0x85 knlist_remove(c9358580,c7e16154,0,e99b1c40,c0844625,...) at knlist_remove+0x1b filt_vfsdetach(c7e16154,0,c0c53d5d,777,1,...) at filt_vfsdetach+0x39 knote_fdclose(c7995240,2061,c0c538a5,440,c7a6b52c,...) at knote_fdclose+0xf5 kern_close(c7995240,2061,e99b1d2c,c0b998e3,c7995240,...) at kern_close+0xd2 close(c7995240,e99b1cf8,4,c0c796fe,c0d3cb08,...) at close+0x1a syscall(e99b1d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (6, FreeBSD ELF32, close), eip = 0x33f7a9e3, esp = 0xbfbfe67c, ebp = 0xbfbfe698 --- From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 17:31:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DFB10656EF for ; Thu, 9 Jul 2009 17:31:15 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A829D8FC24 for ; Thu, 9 Jul 2009 17:31:14 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA15356 for ; Thu, 09 Jul 2009 20:31:13 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A562960.3010801@freebsd.org> Date: Thu, 09 Jul 2009 20:31:12 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:31:16 -0000 As you might be aware DTrace timestamps right now are derived from TSC value. http://en.wikipedia.org/wiki/Time_Stamp_Counter DTrace timestamps are measured in nano-seconds and the formula similar to the following is used for calculations: rdtsc() * 1000000000 / tsc_freq where rdtsc is a function that returns current TSC value and tsc_freq is a frequency of TSC. This formula is supposed to produce proper results if tsc_freq stays constant. But there are environment where this might not be the case. If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. because of powerd), then tsc_freq changes too. As a result, the formula would produce wildly different values and, most importantly, was values would non be monotonic. Timestamp values that jump back and forth would not only be useless for a user, they would also confuse DTrace internal logic. There are at least the following two alternatives: 1. Keep things as they are and warn users not to change CPU clock frequency when they use DTrace and the CPU doesn't have invariant TSC. I think that this should cause only minor inconveniences to a portion of DTrace users. 2. Use raw TSC value as a DTrace timestamp and document this difference from the original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: manual conversion is needed to get "real" time (using the same formula). Please note that in this case timestamps would be in non-linear time dimension if TSC frequency changes, so to get meaningful timestamps (when needed/important) one would still have to make sure that TSC frequency stay constant. Please share your opinion on these approaches. Or suggest yest another alternative. Just in case, related sysctls: machdep.tsc_freq kern.timecounter.invariant_tsc -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 17:52:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E9EB106568B for ; Thu, 9 Jul 2009 17:52:44 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by mx1.freebsd.org (Postfix) with ESMTP id 6B4708FC18 for ; Thu, 9 Jul 2009 17:52:43 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: by ewy6 with SMTP id 6so9896ewy.43 for ; Thu, 09 Jul 2009 10:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HjM1mKoH61j3FbUfVb9y8DM346beGcHpZI8/kAT+9Is=; b=uL2pX1Sb6fHV2/0H8ZMOFu9Gas6rrYKWBYg1SZH7U/SYlZ7bD/QH2VggHJf956Q6H+ juWXuAxkXSqMCN05jMb7XCoSUa3M0XipKlayLKKreKBknrFAa85w8aLg97mk1Yz2ypoz cVBkXwlnWDRMDTtYnYQIcHoaR8Zsd43WkxlaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SWAXDzETwIjtrLYJew30b+yYp/mCEeOvsefde04veEBfIzOz3W/iCMW53V0Gio+kwd bMcFd6gJ0hEUWiBywKZORzaSaPNMg2Xw4ttkqvC/jrgarc70HFksmkQLG0AUwTj+dGPZ e7PP2jrJyFjSXx+2cMUUonWp/WRoW/t1B4WhM= MIME-Version: 1.0 Received: by 10.210.86.1 with SMTP id j1mr1286283ebb.27.1247161962374; Thu, 09 Jul 2009 10:52:42 -0700 (PDT) In-Reply-To: <20090709153940.4544bfa8.stas@FreeBSD.org> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> Date: Thu, 9 Jul 2009 12:52:42 -0500 Message-ID: <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> From: Chris Ruiz To: Stanislav Sedov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 17:52:44 -0000 On Thu, Jul 9, 2009 at 6:39 AM, Stanislav Sedov wrote: > On Wed, 8 Jul 2009 22:58:27 -0500 > Chris Ruiz mentioned: > >> i just upgraded from r194562 to r195477 in order to test BETA1 and my >> e1000 adapter no longer attaching to the driver. >> >> pciconf -lv output >> >> em0@pci0:0:25:0: =A0 =A0 =A0 =A0class=3D0x020000 card=3D0x00018086 chip= =3D0x10bd8086 >> rev=3D0x02 hdr=3D0x00 >> =A0 =A0 vendor =A0 =A0 =3D 'Intel Corporation' >> =A0 =A0 device =A0 =A0 =3D 'Intel 82566DM Gigabit Ethernet Adapter (8256= 6DM)' >> =A0 =A0 class =A0 =A0 =A0=3D network >> =A0 =A0 subclass =A0 =3D ethernet >> >> here's a quick list of relevant commits since my last kernel build: >> r195409, r195168, r195049, r194979, r194925, r194911, r194865. >> > > Hi, Chris! > > Can you provide the verbose boot log? Turns out it's caused by the driver thinking the EEPROM checksum is invalid. Here's a verbose dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #0 r195483: Wed Jul 8 21:51:57 CDT 2009 root@attack.young-alumni.com:/usr/obj/usr/src/sys/FAILWHALE WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80dce000. Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80dce2b0. Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff80dce95= 8. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff80dcef= 88. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3001458636 Hz CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3001.46-MHz K8-class = CPU) Origin =3D "GenuineIntel" Id =3D 0x6fb Stepping =3D 11 Features=3D0xbfebfbff Features2=3D0xe3f5 AMD Features=3D0x20100800 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000040fff, 262144 bytes (64 pages) 0x0000000000051000 - 0x0000000000099fff, 299008 bytes (73 pages) 0x0000000000e01000 - 0x00000000cdbcbfff, 3437015040 bytes (839115 pages) 0x00000000cdc9a000 - 0x00000000ceec4fff, 19050496 bytes (4651 pages) 0x00000000ceec7000 - 0x00000000cef79fff, 733184 bytes (179 pages) 0x00000000cefe5000 - 0x00000000cefe5fff, 4096 bytes (1 pages) 0x00000000ceff2000 - 0x00000000ceff2fff, 4096 bytes (1 pages) 0x00000000cefff000 - 0x00000000ceffffff, 4096 bytes (1 pages) 0x0000000100000000 - 0x000000021cbf3fff, 4777263104 bytes (1166324 pages) avail memory =3D 8192516096 (7812 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI: RSDP 0xfe020 00014 (v0 INTEL ) ACPI: RSDT 0xceffd038 00070 (v1 INTEL DQ3510J 000003BA 01000013) ACPI: FACP 0xceffc000 00074 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: DSDT 0xceff8000 03D6A (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: FACS 0xcef87000 00040 ACPI: APIC 0xceff7000 00078 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: WDDT 0xceff6000 00040 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: MCFG 0xceff5000 0003C (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: ASF! 0xceff4000 000A6 (v32 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: HPET 0xceff3000 00038 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: DMAR 0xceff1000 000F8 (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: ASPT 0xceff0000 0002C (v3 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: WDTT 0xcefef000 002CC (v1 INTEL DQ3510J 000003BA MSFT 01000013) ACPI: SSDT 0xcefee000 00204 (v1 INTEL CpuPm 000003BA MSFT 01000013) ACPI: SSDT 0xcefed000 001F9 (v1 INTEL Cpu0Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefec000 001F9 (v1 INTEL Cpu1Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefeb000 001F9 (v1 INTEL Cpu2Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefea000 001F9 (v1 INTEL Cpu3Ist 000003BA MSFT 01000013) ACPI: SSDT 0xcefe9000 000DD (v1 INTEL Cpu0Cst 000003BA MSFT 01000013) ACPI: SSDT 0xcefe8000 000DD (v1 INTEL Cpu1Cst 000003BA MSFT 01000013) ACPI: SSDT 0xcefe7000 000DD (v1 INTEL Cpu2Cst 000003BA MSFT 01000013) ACPI: SSDT 0xcefe6000 000DD (v1 INTEL Cpu3Cst 000003BA MSFT 01000013) ACPI: TCPA 0xcef7b000 00032 (v2 INTEL TIANO 00000002 MSFT 01000013) 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 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> ichwd module loaded io: kbd0 at kbdmux0 mem: nfslock: pseudo-device null: random: acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000011000 pa 0x4000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 Validation 0 9 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 Validation 0 9 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 Validation 0 10 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 Validation 0 11 N 0 3 4 5 7 9 10 11 12 After Disable 0 255 N 0 3 4 5 7 9 10 11 12 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route 64= -bit Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x29b0, revid=3D0x02 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x29b2, revid=3D0x02 domain=3D0, bus=3D0, slot=3D2, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xe0380000, size 19, enabled map[14]: type I/O Port, range 32, base 0x2458, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, ena= bled map[1c]: type Memory, range 32, base 0xe0200000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x29b3, revid=3D0x02 domain=3D0, bus=3D0, slot=3D2, func=3D1 class=3D03-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0300000, size 19, enabled found-> vendor=3D0x8086, dev=3D0x29b4, revid=3D0x02 domain=3D0, bus=3D0, slot=3D3, func=3D0 class=3D07-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0006, statreg=3D0x0018, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe0427100, size 4, enabled pcib0: matched entry for 0.3.INTA pcib0: slot 3 INTA hardwired to IRQ 16 found-> vendor=3D0x8086, dev=3D0x29b6, revid=3D0x02 domain=3D0, bus=3D0, slot=3D3, func=3D2 class=3D01-01-85, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D9 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x2450, size 3, enabled map[14]: type I/O Port, range 32, base 0x246c, size 2, enabled map[18]: type I/O Port, range 32, base 0x2448, size 3, enabled map[1c]: type I/O Port, range 32, base 0x2468, size 2, enabled map[20]: type I/O Port, range 32, base 0x2420, size 4, enabled pcib0: matched entry for 0.3.INTC pcib0: slot 3 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x29b7, revid=3D0x02 domain=3D0, bus=3D0, slot=3D3, func=3D3 class=3D07-00-02, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x00b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type I/O Port, range 32, base 0x2440, size 3, enabled map[14]: type Memory, range 32, base 0xe0425000, size 12, enabled pcib0: matched entry for 0.3.INTB pcib0: slot 3 INTB hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x10bd, revid=3D0x02 domain=3D0, bus=3D0, slot=3D25, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled map[14]: type Memory, range 32, base 0xe0424000, size 12, enabled map[18]: type I/O Port, range 32, base 0x2400, size 5, enabled pcib0: matched entry for 0.25.INTA pcib0: slot 25 INTA hardwired to IRQ 20 found-> vendor=3D0x8086, dev=3D0x2937, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D9 map[20]: type I/O Port, range 32, base 0x20e0, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x2938, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D9 map[20]: type I/O Port, range 32, base 0x20c0, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 found-> vendor=3D0x8086, dev=3D0x2939, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D10 map[20]: type I/O Port, range 32, base 0x20a0, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x293c, revid=3D0x02 domain=3D0, bus=3D0, slot=3D26, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0426c00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 17 found-> vendor=3D0x8086, dev=3D0x293e, revid=3D0x02 domain=3D0, bus=3D0, slot=3D27, func=3D0 class=3D04-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xe0420000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=3D0x8086, dev=3D0x2940, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=3D0x8086, dev=3D0x2942, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D1 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=3D0x8086, dev=3D0x2944, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D2 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=3D0x8086, dev=3D0x2946, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D3 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=3D0x8086, dev=3D0x2948, revid=3D0x02 domain=3D0, bus=3D0, slot=3D28, func=3D4 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D1 cmdreg=3D0x0000, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=3D0x8086, dev=3D0x2934, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0x2080, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x2935, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x2060, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=3D0x8086, dev=3D0x2936, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D9 map[20]: type I/O Port, range 32, base 0x2040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=3D0x8086, dev=3D0x293a, revid=3D0x02 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0426800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=3D0x8086, dev=3D0x244e, revid=3D0x92 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x0010, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2914, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x2922, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D2 class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x02b0, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D9 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0x2438, size 3, enabled map[14]: type I/O Port, range 32, base 0x2464, size 2, enabled map[18]: type I/O Port, range 32, base 0x2430, size 3, enabled map[1c]: type I/O Port, range 32, base 0x2460, size 2, enabled map[20]: type I/O Port, range 32, base 0x2020, size 5, enabled map[24]: type Memory, range 32, base 0xe0426000, size 11, enabled pcib0: matched entry for 0.31.INTA pcib0: slot 31 INTA hardwired to IRQ 21 found-> vendor=3D0x8086, dev=3D0x2930, revid=3D0x02 domain=3D0, bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0003, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D9 map[10]: type Memory, range 64, base 0xe0427000, size 8, enabled map[20]: type I/O Port, range 32, base 0x2000, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 18 vgapci0: port 0x2458-0x245f mem 0xe0380000-0xe03fffff,0xd0000000-0xdfffffff,0xe0200000-0xe02fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xe0380000 vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xe0200000 agp0: detected 6140k stolen memory agp0: aperture size is 256M vgapci1: mem 0xe0300000-0xe037ffff at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) atapci0: port 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f irq 18 at device 3.2 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2420 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2450 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x246c ata2: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: stat1=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata2: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2448 atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2468 ata3: reset tp1 mask=3D03 ostat0=3D7f ostat1=3D7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat0=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: stat1=3D0x7f err=3D0x7f lsb=3D0x7f msb=3D0x7f ata3: reset tp2 stat0=3Dff stat1=3Dff devices=3D0x0 ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 3.3 (no driver attached) em0: port 0x2400-0x241f mem 0xe0400000-0xe041ffff,0xe0424000-0xe0424fff irq 20 at device 25.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 50 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe0424000 em0: The EEPROM Checksum Is Not Valid device_attach: em0 attach returned 5 uhci0: port 0x20e0-0x20ff irq 18 at device 26.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20e0 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup =3D 0x0f10 usbus0: on uhci0 uhci1: port 0x20c0-0x20df irq 21 at device 26.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20c0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup =3D 0x0f10 usbus1: on uhci1 uhci2: port 0x20a0-0x20bf irq 17 at device 26.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20a0 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup =3D 0x0f10 usbus2: on uhci2 ehci0: mem 0xe0426c00-0xe0426fff irq 17 at device 26.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426c00 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib1: at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 pcib2: at device 28.1 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 pcib3: at device 28.2 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x1000-0x1fff pcib3: memory decode 0xe0100000-0xe01fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=3D0, physical bus=3D3 found-> vendor=3D0x11ab, dev=3D0x6101, revid=3D0xb1 domain=3D0, bus=3D3, slot=3D0, func=3D0 class=3D01-01-8f, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D16 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D9 powerspec 2 supports D0 D1 D3 current D0 MSI supports 1 message map[10]: type I/O Port, range 32, base 0x1018, size 3, enabled pcib3: requested I/O range 0x1018-0x101f: in range map[14]: type I/O Port, range 32, base 0x1024, size 2, enabled pcib3: requested I/O range 0x1024-0x1027: in range map[18]: type I/O Port, range 32, base 0x1010, size 3, enabled pcib3: requested I/O range 0x1010-0x1017: in range map[1c]: type I/O Port, range 32, base 0x1020, size 2, enabled pcib3: requested I/O range 0x1020-0x1023: in range map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled pcib3: requested I/O range 0x1000-0x100f: in range map[24]: type Memory, range 32, base 0xe0100000, size 9, enabled pcib3: requested memory range 0xe0100000-0xe01001ff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 atapci1: port 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f mem 0xe0100000-0xe01001ff irq 18 at device 0.0 on pci3 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1000 atapci1: [MPSAFE] atapci1: [ITHREAD] ata4: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1018 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1024 ata4: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D51 ata4: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata4: stat1=3D0x10 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata4: reset tp2 stat0=3D00 stat1=3D10 devices=3D0x30000 ata4: [MPSAFE] ata4: [ITHREAD] pcib4: at device 28.3 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x0-0x0 pcib4: no prefetched decode pci4: on pcib4 pci4: domain=3D0, physical bus=3D4 pcib5: at device 28.4 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0x0-0x0 pcib5: no prefetched decode pci5: on pcib5 pci5: domain=3D0, physical bus=3D5 uhci3: port 0x2080-0x209f irq 23 at device 29.0 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2080 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup =3D 0x0f10 usbus4: on uhci3 uhci4: port 0x2060-0x207f irq 19 at device 29.1 on pci0 uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup =3D 0x0f10 usbus5: on uhci4 uhci5: port 0x2040-0x205f irq 18 at device 29.2 on pci0 uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup =3D 0x0f10 usbus6: on uhci5 ehci1: mem 0xe0426800-0xe0426bff irq 23 at device 29.7 on pci0 ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426800 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib6: at device 30.0 on pci0 pcib6: domain 0 pcib6: secondary bus 6 pcib6: subordinate bus 6 pcib6: I/O decode 0xf000-0xfff pcib6: memory decode 0xe0000000-0xe00fffff pcib6: no prefetched decode pcib6: Subtractively decoded bridge. pci6: on pcib6 pci6: domain=3D0, physical bus=3D6 found-> vendor=3D0x168c, dev=3D0x0013, revid=3D0x01 domain=3D0, bus=3D6, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0216, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x0a (2500 ns), maxlat=3D0x1c (7000 ns) intpin=3Da, irq=3D9 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0000000, size 16, enabled pcib6: requested memory range 0xe0000000-0xe000ffff: good pcib6: matched entry for 6.0.INTA pcib6: slot 0 INTA hardwired to IRQ 21 found-> vendor=3D0x11c1, dev=3D0x5811, revid=3D0x70 domain=3D0, bus=3D6, slot=3D3, func=3D0 class=3D0c-00-10, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0216, statreg=3D0x0290, cachelnsz=3D16 (dwords) lattimer=3D0x20 (960 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x18 (6000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xe0010000, size 12, enabled pcib6: requested memory range 0xe0010000-0xe0010fff: good pcib6: matched entry for 6.3.INTA pcib6: slot 3 INTA hardwired to IRQ 19 ath0: mem 0xe0000000-0xe000ffff irq 21 at device 0.0 on pci6 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe0000000 ath0: [MPSAFE] ath0: [ITHREAD] ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: turboG rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: AR2413 mac 7.9 RF2413 phy 4.5 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons fwohci0: mem 0xe0010000-0xe0010fff irq 19 at device 3.0 on pci6 fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0010000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=3D0) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:90:27:00:01:d0:dc:04 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x41000 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=3D0x00000001, SelfID Count=3D2, CYCLEMAS= TER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f mem 0xe0426000-0xe04267ff irq 21 at device 31.2 on pci0 atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xe0426000 atapci2: AHCI called from vendor specific driver atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported atapci2: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC EM 6ports ata5: on atapci2 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect time=3D0ms status=3D00000123 ata5: ready wait time=3D14ms ata5: software reset port 15... ata5: ready wait time=3D0ms ata5: SIGNATURE: 00000101 ata5: AHCI reset done: devices=3D00000001 ata5: [MPSAFE] ata5: [ITHREAD] ata6: on atapci2 ata6: AHCI reset... ata6: hardware reset ... ata6: SATA connect time=3D0ms status=3D00000123 ata6: ready wait time=3D49ms ata6: software reset port 15... ata6: ready wait time=3D0ms ata6: SIGNATURE: 00000101 ata6: AHCI reset done: devices=3D00000001 ata6: [MPSAFE] ata6: [ITHREAD] ata7: on atapci2 ata7: AHCI reset... ata7: hardware reset ... ata7: SATA connect time=3D0ms status=3D00000123 ata7: ready wait time=3D26ms ata7: software reset port 15... ata7: ready wait time=3D0ms ata7: SIGNATURE: 00000101 ata7: AHCI reset done: devices=3D00000001 ata7: [MPSAFE] ata7: [ITHREAD] ata8: on atapci2 ata8: AHCI reset... ata8: hardware reset ... ata8: SATA connect timeout status=3D00000000 ata8: AHCI reset done: phy reset found no device ata8: [MPSAFE] ata8: [ITHREAD] ata9: on atapci2 ata9: AHCI reset... ata9: hardware reset ... ata9: SATA connect time=3D0ms status=3D00000123 ata9: ready wait time=3D22ms ata9: software reset port 15... ata9: ready wait time=3D0ms ata9: SIGNATURE: 00000101 ata9: AHCI reset done: devices=3D00000001 ata9: [MPSAFE] ata9: [ITHREAD] ata10: on atapci2 ata10: AHCI reset... ata10: hardware reset ... ata10: SATA connect time=3D0ms status=3D00000123 ata10: ready wait time=3D22ms ata10: software reset port 15... ata10: ready wait time=3D0ms ata10: SIGNATURE: 00000101 ata10: AHCI reset done: devices=3D00000001 ata10: [MPSAFE] ata10: [ITHREAD] ichsmb0: port 0x2000-0x201f mem 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2000 ichsmb0: [MPSAFE] ichsmb0: [ITHREAD] smbus0: on ichsmb0 smb0: on smbus0 atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 54 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 est0: Invalid id16 (set, cur) =3D (2086, 2346) est0: Invalid freq 2664, ignored. est0: Invalid id16 (set, cur) =3D (1826, 2346) est0: Invalid freq 2331, ignored. est0: Invalid id16 (set, cur) =3D (1565, 2346) est0: Invalid freq 1998, ignored. p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est1: Invalid id16 (set, cur) =3D (2086, 2346) est1: Invalid freq 2664, ignored. est1: Invalid id16 (set, cur) =3D (1826, 2346) est1: Invalid freq 2331, ignored. est1: Invalid id16 (set, cur) =3D (1565, 2346) est1: Invalid freq 1998, ignored. p4tcc1: on cpu1 isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer isa_probe_children: disabling PnP devices ichwd0: on isa0 isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer ichwd0: Intel ICH9DO watchdog timer (ICH9 or equivalent) ichwd0: timer disabled atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0 failed to probe at port 0x60 on isa0 fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 ppc0 failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 508766 -> 100000 WARNING: ZFS is considered to be an experimental feature in FreeBSD. lapic: Divisor 2, Frequency 166747704 hz Timecounter "TSC" frequency 3001458636 Hz quality -100 Timecounters tick every 1.000 msec pflog0: bpf attached lo0: firewire0: 2 nodes, maxhop <=3D 1 cable IRM irm(1) (me) firewire0: bus manager 1 bpf attached ata2: Identifying devices: 00000000 ata2: New devices: 00000000 ata3: Identifying devices: 00000000 ata3: New devices: 00000000 ata4: Identifying devices: 00030000 ata4: New devices: 00030000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ata4-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA66 cable=3D80 wire ata4-slave: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA66 cable=3D40 wire ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 ZFS filesystem version 13 ZFS storage pool version 13 acd0: DVDR drive at ata4 as master acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, UD= MA66 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: DMA limited to UDMA33, device found non-ATA66 cable acd1: DVDROM drive at ata4 as slave acd1: read 687KB/s (8251KB/s), 512KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd1: Writes: acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ata5: Identifying devices: 00000001 ata5: New devices: 00000001 ata5-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad10: 476940MB at ata5-master SATA300 ad10: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queu= e GEOM: new disk ad10 ad10: Intel check1 failed ad10: Adaptec check1 failed ad10: LSI (v3) check1 failed ad10: LSI (v2) check1 failed ad10: FreeBSD check1 failed ata6: Identifying devices: 00000001 ata6: New devices: 00000001 ata6-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad12: 476940MB at ata6-master SATA300 ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queu= e GEOM: new disk ad12 firewire0: New S400 device ID:001f5bfffe2776a6 fwohci0: txd err=3D 3 miss Ack err ad12: Intel check1 failed ad12: Adaptec check1 failed ad12: LSI (v3) check1 failed ad12: LSI (v2) check1 failed ad12: FreeBSD check1 failed ata7: Identifying devices: 00000001 ata7: New devices: 00000001 ata7-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad14: 238475MB at ata7-master SATA300 ad14: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth queu= e GEOM: new disk ad14 ad14: Intel check1 failed ad14: Adaptec check1 failed ad14: LSI (v3) check1 failed ad14: LSI (v2) check1 failed ad14: FreeBSD check1 failed ata8: Identifying devices: 00000000 ata8: New devices: 00000000 ata9: Identifying devices: 00000001 ata9: New devices: 00000001 ata9-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad18: 715404MB at ata9-master SATA300 ad18: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth qu= eue GEOM: new disk ad18 ad18: Intel check1 failed uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ad18: Adaptec check1 failed uhub4: 2 ports with 2 removable, self powered ad18: LSI (v3) check1 failed uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered ad18: LSI (v2) check1 failed ad18: FreeBSD check1 failed ata10: Identifying devices: 00000001 ata10: New devices: 00000001 ata10-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA133 cable=3D40 wire ad20: 715404MB at ata10-master SATA300 ad20: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth qu= eue GEOM: new disk ad20 ad20: Intel check1 failed ad20: Adaptec check1 failed ad20: LSI (v3) check1 failed ad20: LSI (v2) check1 failed ad20: FreeBSD check1 failed (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 49 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 Root mount waiting for: usbus3 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? GEOM: new disk da0pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: 40.000MB/s transfers da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3859MB (7905279 512 byte sectors: 255H 63S/T 492C) Trying to mount root from zfs:alert ugen5.2: at usbus5 ukbd0: on usbus5 kbd: new array size 4 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 ugen2.2: at usbus2 ct_to_ts([2009-07-09 12:36:12]) =3D 1247142972.000000000 start_init: trying /sbin/init lock order reversal: 1st 0xffffffff80815040 pf task mtx (pf task mtx) @ /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 2nd 0xffffffff809f7b40 ifnet (ifnet) @ /usr/src/sys/net/if.c:1887 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7d2 _rw_rlock() at _rw_rlock+0x60 ifunit() at ifunit+0x22 pfioctl() at pfioctl+0x20ea devfs_ioctl_f() at devfs_ioctl_f+0x6e kern_ioctl() at kern_ioctl+0xbc ioctl() at ioctl+0xf0 syscall() at syscall+0x18b Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x80098a88c, rsp =3D 0x7fffffffb5c8, rbp =3D 0x7fffffffb710 --- lock order reversal: 1st 0xffffff0074026098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 2nd 0xffffff007417dba8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x49 witness_checkorder() at witness_checkorder+0x7d2 __lockmgr_args() at __lockmgr_args+0xc92 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xc2 _vn_lock() at _vn_lock+0x50 vget() at vget+0x6c devfs_allocv() at devfs_allocv+0xee devfs_root() at devfs_root+0x41 vfs_donmount() at vfs_donmount+0xf93 nmount() at nmount+0x74 syscall() at syscall+0x18b Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007aaffc, rsp =3D 0x7fffffffdd28, rbp =3D 0x800a04048 --- Thanks, Chris --=20 @chrisattack ----------------------------------------- http://twitter.com/chrisattack http://chrisattack.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:01:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C2AD1065675; Thu, 9 Jul 2009 18:01:59 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id CB6818FC12; Thu, 9 Jul 2009 18:01:58 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:40291 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MOxvQ-0004mW-6E; Thu, 09 Jul 2009 20:00:54 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id F051AF9A6F; Thu, 9 Jul 2009 20:00:51 +0200 (CEST) Message-Id: From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A562960.3010801@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 20:00:49 +0200 References: <4A562960.3010801@freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MOxvQ-0004mW-6E. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MOxvQ-0004mW-6E be2621d07d7beec1ece6b6451ce85bbe Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:01:59 -0000 On Jul 9, 2009, at 19:31, Andriy Gapon wrote: > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock > frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that > this should > cause only minor inconveniences to a portion of DTrace users. Hmm, but "things as they are" causes an overflow about every 10 seconds, so the value is quite useless now (which, of course, you know about, having written a patch for it :) Is scenario #1 after the patch (PR kern/127441 for the rest of you) or not? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:19:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AE6F1065677; Thu, 9 Jul 2009 18:19:05 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id EDF6E8FC18; Thu, 9 Jul 2009 18:19:04 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 24344443E; Thu, 9 Jul 2009 20:19:04 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n69IJ0jp060970; Thu, 9 Jul 2009 20:19:01 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1247163543; bh=CtDk7+AQbNTPjvrPITl9Gnrv0DInA0uNbGtcw2oghIM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=fK95G1wz/Fb2+VMEGGY1KX4NMS26FZ5F1qWw/v3TIsri00p1u91QYtvx24i/y9qeX R5XEtvVd9/KdBwZTL2lPw== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=mxHH/ySiGvYp7azZGHZ3LJLofVVL2nxvPqCESc0FEBKWiGOpR+Dcma5kGJj8A/62f 8cS13rr1ScNnbpvIjd59A== Message-ID: <4A563494.1010209@restart.be> Date: Thu, 09 Jul 2009 20:19:00 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090627) MIME-Version: 1.0 To: Andriy Gapon References: <4A562960.3010801@freebsd.org> In-Reply-To: <4A562960.3010801@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:19:05 -0000 Andriy Gapon wrote: > As you might be aware DTrace timestamps right now are derived from TSC value. > http://en.wikipedia.org/wiki/Time_Stamp_Counter > > DTrace timestamps are measured in nano-seconds and the formula similar to the > following is used for calculations: > rdtsc() * 1000000000 / tsc_freq > where rdtsc is a function that returns current TSC value and tsc_freq is a > frequency of TSC. > > This formula is supposed to produce proper results if tsc_freq stays constant. > But there are environment where this might not be the case. > If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. > because of powerd), then tsc_freq changes too. > As a result, the formula would produce wildly different values and, most > importantly, was values would non be monotonic. Timestamp values that jump back > and forth would not only be useless for a user, they would also confuse DTrace > internal logic. > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. Im absolutely for this solution with a warning in the doc. It seems to me that when you use dtrace, you don't try at the same time to be power efficient... except if you want to dtrace powerd, of course. henri From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:20:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EE810656A8 for ; Thu, 9 Jul 2009 18:20:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A534D8FC19 for ; Thu, 9 Jul 2009 18:20:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA17045; Thu, 09 Jul 2009 21:20:50 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A563501.1090905@freebsd.org> Date: Thu, 09 Jul 2009 21:20:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Thomas Backman References: <4A562960.3010801@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:20:53 -0000 on 09/07/2009 21:00 Thomas Backman said the following: > On Jul 9, 2009, at 19:31, Andriy Gapon wrote: >> There are at least the following two alternatives: >> >> 1. Keep things as they are and warn users not to change CPU clock >> frequency when >> they use DTrace and the CPU doesn't have invariant TSC. I think that >> this should >> cause only minor inconveniences to a portion of DTrace users. > Hmm, but "things as they are" causes an overflow about every 10 seconds, > so the value is quite useless now (which, of course, you know about, > having written a patch for it :) This is because of a deficiency in the implementation of the formula, not because of the formula itself. > Is scenario #1 after the patch (PR kern/127441 for the rest of you) or not? Yes, after the patch :) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:30:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C379910656B2; Thu, 9 Jul 2009 18:30:59 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 7C7CF8FC0A; Thu, 9 Jul 2009 18:30:59 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:43904 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MOyOK-0000nU-3E; Thu, 09 Jul 2009 20:30:45 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id ED35FF9943; Thu, 9 Jul 2009 20:30:45 +0200 (CEST) Message-Id: <732354CB-8FF2-4040-8ABD-B94076551C57@exscape.org> From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A563501.1090905@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 20:30:43 +0200 References: <4A562960.3010801@freebsd.org> <4A563501.1090905@freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MOyOK-0000nU-3E. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MOyOK-0000nU-3E a65a50a0ef47b5e90be4da1910aba92f Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:31:00 -0000 On Jul 9, 2009, at 20:20, Andriy Gapon wrote: > on 09/07/2009 21:00 Thomas Backman said the following: >> On Jul 9, 2009, at 19:31, Andriy Gapon wrote: >>> There are at least the following two alternatives: >>> >>> 1. Keep things as they are and warn users not to change CPU clock >>> frequency when >>> they use DTrace and the CPU doesn't have invariant TSC. I think that >>> this should >>> cause only minor inconveniences to a portion of DTrace users. >> Hmm, but "things as they are" causes an overflow about every 10 >> seconds, >> so the value is quite useless now (which, of course, you know about, >> having written a patch for it :) > > This is because of a deficiency in the implementation of the > formula, not because > of the formula itself. > >> Is scenario #1 after the patch (PR kern/127441 for the rest of you) >> or not? > > Yes, after the patch :) In that case, I too strongly prefer alternative #1. It keeps the timestamp *time*-based, and not tick-based (thus not breaking Solaris/ OS X etc. compatibility), for one. It also makes it a whole lot easier to actually *time* things - is it even possible for a non-kernel- programmer DTrace user to easily convert the ticks to nanoseconds somewhat accurately? I think that's as good a reason as any (the first one, that is). If ZFS is kept as compatible as possible between OSes, then so should DTrace, IMHO. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:33:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66F3C1065670; Thu, 9 Jul 2009 18:33:49 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id C53368FC0C; Thu, 9 Jul 2009 18:33:48 +0000 (UTC) (envelope-from marius@nuenneri.ch) Received: by bwz21 with SMTP id 21so310962bwz.43 for ; Thu, 09 Jul 2009 11:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.171.1 with SMTP id y1mr590244muo.39.1247162529878; Thu, 09 Jul 2009 11:02:09 -0700 (PDT) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Date: Thu, 9 Jul 2009 20:02:09 +0200 Message-ID: From: =?ISO-8859-1?Q?Marius_N=FCnnerich?= To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:33:49 -0000 On Thu, Jul 9, 2009 at 19:31, Andriy Gapon wrote: > > As you might be aware DTrace timestamps right now are derived from TSC value. > http://en.wikipedia.org/wiki/Time_Stamp_Counter > > DTrace timestamps are measured in nano-seconds and the formula similar to the > following is used for calculations: > rdtsc() * 1000000000 / tsc_freq > where rdtsc is a function that returns current TSC value and tsc_freq is a > frequency of TSC. > > This formula is supposed to produce proper results if tsc_freq stays constant. > But there are environment where this might not be the case. > If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. > because of powerd), then tsc_freq changes too. > As a result, the formula would produce wildly different values and, most > importantly, was values would non be monotonic. Timestamp values that jump back > and forth would not only be useless for a user, they would also confuse DTrace > internal logic. > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. > > 2. Use raw TSC value as a DTrace timestamp and document this difference from the > original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: > manual conversion is needed to get "real" time (using the same formula). > Please note that in this case timestamps would be in non-linear time dimension if > TSC frequency changes, so to get meaningful timestamps (when needed/important) one > would still have to make sure that TSC frequency stay constant. > > Please share your opinion on these approaches. > Or suggest yest another alternative. What about atomically changing tsc_freq every time the frequency is changed? > > Just in case, related sysctls: > machdep.tsc_freq > kern.timecounter.invariant_tsc From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:35:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB4B1065676 for ; Thu, 9 Jul 2009 18:35:05 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id EE0268FC1D for ; Thu, 9 Jul 2009 18:35:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by yxe11 with SMTP id 11so558652yxe.3 for ; Thu, 09 Jul 2009 11:35:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cZnJeKPnCdBBwEaKxuUtsGlaT9a/Z1s5cZSj2+OoMns=; b=h4dKHSgrmTJ9p17/oJocXtFem/Rs2pcDk4gl2bun7DBcalungmdvvnY4Lza7d7kvW2 7CDllIxtfg9PsKFuJ5lDFXiiaMKhV1+Qut4Hf8Btvsu3Bac7HmI821vnuELXLXhvRU5+ RpSXFKx6PrciMmuggKNtwXh0JT443gs54Y05I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DAaGyUuaxvJkBTq8hE5lCRcD6/Kwv3bM/qvE2yTXmcgDTaZQ0dP3DeWD8kxwRcjuZY Lx494EhpbHHRHGhshjXiJo28ST8RrlxmP2/NpLcaKmndJNxAPkV3EGzrIarbGVb8gCuf OvVoCx1xJoWjy//YxCIw/sFhpfWGaSnZnNOe4= MIME-Version: 1.0 Received: by 10.100.227.5 with SMTP id z5mr1442939ang.175.1247164504297; Thu, 09 Jul 2009 11:35:04 -0700 (PDT) In-Reply-To: <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> Date: Thu, 9 Jul 2009 11:35:03 -0700 Message-ID: <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> From: Jack Vogel To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Stanislav Sedov , freebsd-current@freebsd.org Subject: Re: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:35:06 -0000 I am looking into this, thanks for the report. Jack On Thu, Jul 9, 2009 at 10:52 AM, Chris Ruiz wrote: > On Thu, Jul 9, 2009 at 6:39 AM, Stanislav Sedov wrote: > > On Wed, 8 Jul 2009 22:58:27 -0500 > > Chris Ruiz mentioned: > > > >> i just upgraded from r194562 to r195477 in order to test BETA1 and my > >> e1000 adapter no longer attaching to the driver. > >> > >> pciconf -lv output > >> > >> em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 > >> rev=0x02 hdr=0x00 > >> vendor = 'Intel Corporation' > >> device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' > >> class = network > >> subclass = ethernet > >> > >> here's a quick list of relevant commits since my last kernel build: > >> r195409, r195168, r195049, r194979, r194925, r194911, r194865. > >> > > > > Hi, Chris! > > > > Can you provide the verbose boot log? > > Turns out it's caused by the driver thinking the EEPROM checksum is > invalid. Here's a verbose dmesg: > > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-BETA1 #0 r195483: Wed Jul 8 21:51:57 CDT 2009 > root@attack.young-alumni.com:/usr/obj/usr/src/sys/FAILWHALE > WARNING: WITNESS option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80dce000. > Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80dce2b0. > Preloaded elf obj module "/boot/kernel/opensolaris.ko" at > 0xffffffff80dce958. > Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at > 0xffffffff80dcef88. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 3001458636 Hz > CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3001.46-MHz K8-class > CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > Features=0xbfebfbff > Features2=0xe3f5 > AMD Features=0x20100800 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 8589934592 (8192 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x0000000000040fff, 262144 bytes (64 pages) > 0x0000000000051000 - 0x0000000000099fff, 299008 bytes (73 pages) > 0x0000000000e01000 - 0x00000000cdbcbfff, 3437015040 bytes (839115 pages) > 0x00000000cdc9a000 - 0x00000000ceec4fff, 19050496 bytes (4651 pages) > 0x00000000ceec7000 - 0x00000000cef79fff, 733184 bytes (179 pages) > 0x00000000cefe5000 - 0x00000000cefe5fff, 4096 bytes (1 pages) > 0x00000000ceff2000 - 0x00000000ceff2fff, 4096 bytes (1 pages) > 0x00000000cefff000 - 0x00000000ceffffff, 4096 bytes (1 pages) > 0x0000000100000000 - 0x000000021cbf3fff, 4777263104 bytes (1166324 pages) > avail memory = 8192516096 (7812 MB) > ACPI APIC Table: > INTR: Adding local APIC 1 as a target > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > APIC: CPU 0 has ACPI ID 1 > APIC: CPU 1 has ACPI ID 2 > ULE: setup cpu 0 > ULE: setup cpu 1 > This module (opensolaris) contains code covered by the > Common Development and Distribution License (CDDL) > see http://opensolaris.org/os/licensing/opensolaris_license/ > ACPI: RSDP 0xfe020 00014 (v0 INTEL ) > ACPI: RSDT 0xceffd038 00070 (v1 INTEL DQ3510J 000003BA 01000013) > ACPI: FACP 0xceffc000 00074 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: DSDT 0xceff8000 03D6A (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: FACS 0xcef87000 00040 > ACPI: APIC 0xceff7000 00078 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: WDDT 0xceff6000 00040 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: MCFG 0xceff5000 0003C (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: ASF! 0xceff4000 000A6 (v32 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: HPET 0xceff3000 00038 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: DMAR 0xceff1000 000F8 (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: ASPT 0xceff0000 0002C (v3 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: WDTT 0xcefef000 002CC (v1 INTEL DQ3510J 000003BA MSFT 01000013) > ACPI: SSDT 0xcefee000 00204 (v1 INTEL CpuPm 000003BA MSFT 01000013) > ACPI: SSDT 0xcefed000 001F9 (v1 INTEL Cpu0Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefec000 001F9 (v1 INTEL Cpu1Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefeb000 001F9 (v1 INTEL Cpu2Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefea000 001F9 (v1 INTEL Cpu3Ist 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe9000 000DD (v1 INTEL Cpu0Cst 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe8000 000DD (v1 INTEL Cpu1Cst 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe7000 000DD (v1 INTEL Cpu2Cst 000003BA MSFT 01000013) > ACPI: SSDT 0xcefe6000 000DD (v1 INTEL Cpu3Cst 000003BA MSFT 01000013) > ACPI: TCPA 0xcef7b000 00032 (v2 INTEL TIANO 00000002 MSFT 01000013) > 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 > lapic0: Routing NMI -> LINT1 > lapic0: LINT1 trigger: edge > lapic0: LINT1 polarity: high > lapic1: Routing NMI -> LINT1 > lapic1: LINT1 trigger: edge > lapic1: LINT1 polarity: high > ioapic0 irqs 0-23 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > wlan: <802.11 Link Layer> > ichwd module loaded > io: > kbd0 at kbdmux0 > mem: > nfslock: pseudo-device > null: > random: > acpi0: on motherboard > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xffffff8000011000 pa 0x4000 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 > ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > Validation 0 10 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 > Validation 0 9 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link4: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link5: Index IRQ Rtd Ref IRQs > Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 > Validation 0 9 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link6: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 > Validation 0 10 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > pci_link7: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 > Validation 0 11 N 0 3 4 5 7 9 10 11 12 > After Disable 0 255 N 0 3 4 5 7 9 10 11 12 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route > 64-bit > Timecounter "HPET" frequency 14318180 Hz quality 900 > acpi_button0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x29b0, revid=0x02 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x29b2, revid=0x02 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > map[10]: type Memory, range 32, base 0xe0380000, size 19, enabled > map[14]: type I/O Port, range 32, base 0x2458, size 3, enabled > map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size > 28, enabled > map[1c]: type Memory, range 32, base 0xe0200000, size 20, enabled > pcib0: matched entry for 0.2.INTA > pcib0: slot 2 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x29b3, revid=0x02 > domain=0, bus=0, slot=2, func=1 > class=03-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0300000, size 19, enabled > found-> vendor=0x8086, dev=0x29b4, revid=0x02 > domain=0, bus=0, slot=3, func=0 > class=07-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xe0427100, size 4, enabled > pcib0: matched entry for 0.3.INTA > pcib0: slot 3 INTA hardwired to IRQ 16 > found-> vendor=0x8086, dev=0x29b6, revid=0x02 > domain=0, bus=0, slot=3, func=2 > class=01-01-85, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=9 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type I/O Port, range 32, base 0x2450, size 3, enabled > map[14]: type I/O Port, range 32, base 0x246c, size 2, enabled > map[18]: type I/O Port, range 32, base 0x2448, size 3, enabled > map[1c]: type I/O Port, range 32, base 0x2468, size 2, enabled > map[20]: type I/O Port, range 32, base 0x2420, size 4, enabled > pcib0: matched entry for 0.3.INTC > pcib0: slot 3 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x29b7, revid=0x02 > domain=0, bus=0, slot=3, func=3 > class=07-00-02, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=10 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type I/O Port, range 32, base 0x2440, size 3, enabled > map[14]: type Memory, range 32, base 0xe0425000, size 12, enabled > pcib0: matched entry for 0.3.INTB > pcib0: slot 3 INTB hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x10bd, revid=0x02 > domain=0, bus=0, slot=25, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled > map[14]: type Memory, range 32, base 0xe0424000, size 12, enabled > map[18]: type I/O Port, range 32, base 0x2400, size 5, enabled > pcib0: matched entry for 0.25.INTA > pcib0: slot 25 INTA hardwired to IRQ 20 > found-> vendor=0x8086, dev=0x2937, revid=0x02 > domain=0, bus=0, slot=26, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=9 > map[20]: type I/O Port, range 32, base 0x20e0, size 5, enabled > pcib0: matched entry for 0.26.INTA > pcib0: slot 26 INTA hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x2938, revid=0x02 > domain=0, bus=0, slot=26, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=9 > map[20]: type I/O Port, range 32, base 0x20c0, size 5, enabled > pcib0: matched entry for 0.26.INTB > pcib0: slot 26 INTB hardwired to IRQ 21 > found-> vendor=0x8086, dev=0x2939, revid=0x02 > domain=0, bus=0, slot=26, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=10 > map[20]: type I/O Port, range 32, base 0x20a0, size 5, enabled > pcib0: matched entry for 0.26.INTC > pcib0: slot 26 INTC hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x293c, revid=0x02 > domain=0, bus=0, slot=26, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=10 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0426c00, size 10, enabled > pcib0: matched entry for 0.26.INTC > pcib0: slot 26 INTC hardwired to IRQ 17 > found-> vendor=0x8086, dev=0x293e, revid=0x02 > domain=0, bus=0, slot=27, func=0 > class=04-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type Memory, range 64, base 0xe0420000, size 14, enabled > pcib0: matched entry for 0.27.INTA > pcib0: slot 27 INTA hardwired to IRQ 22 > found-> vendor=0x8086, dev=0x2940, revid=0x02 > domain=0, bus=0, slot=28, func=0 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2942, revid=0x02 > domain=0, bus=0, slot=28, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=b, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2944, revid=0x02 > domain=0, bus=0, slot=28, func=2 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=c, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2946, revid=0x02 > domain=0, bus=0, slot=28, func=3 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=d, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2948, revid=0x02 > domain=0, bus=0, slot=28, func=4 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > intpin=a, irq=255 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message > found-> vendor=0x8086, dev=0x2934, revid=0x02 > domain=0, bus=0, slot=29, func=0 > class=0c-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > map[20]: type I/O Port, range 32, base 0x2080, size 5, enabled > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x2935, revid=0x02 > domain=0, bus=0, slot=29, func=1 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=11 > map[20]: type I/O Port, range 32, base 0x2060, size 5, enabled > pcib0: matched entry for 0.29.INTB > pcib0: slot 29 INTB hardwired to IRQ 19 > found-> vendor=0x8086, dev=0x2936, revid=0x02 > domain=0, bus=0, slot=29, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=9 > map[20]: type I/O Port, range 32, base 0x2040, size 5, enabled > pcib0: matched entry for 0.29.INTC > pcib0: slot 29 INTC hardwired to IRQ 18 > found-> vendor=0x8086, dev=0x293a, revid=0x02 > domain=0, bus=0, slot=29, func=7 > class=0c-03-20, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0426800, size 10, enabled > pcib0: matched entry for 0.29.INTA > pcib0: slot 29 INTA hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x244e, revid=0x92 > domain=0, bus=0, slot=30, func=0 > class=06-04-01, hdrtype=0x01, mfdev=0 > cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2914, revid=0x02 > domain=0, bus=0, slot=31, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x2922, revid=0x02 > domain=0, bus=0, slot=31, func=2 > class=01-06-01, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=9 > powerspec 3 supports D0 D3 current D0 > MSI supports 16 messages > map[10]: type I/O Port, range 32, base 0x2438, size 3, enabled > map[14]: type I/O Port, range 32, base 0x2464, size 2, enabled > map[18]: type I/O Port, range 32, base 0x2430, size 3, enabled > map[1c]: type I/O Port, range 32, base 0x2460, size 2, enabled > map[20]: type I/O Port, range 32, base 0x2020, size 5, enabled > map[24]: type Memory, range 32, base 0xe0426000, size 11, enabled > pcib0: matched entry for 0.31.INTA > pcib0: slot 31 INTA hardwired to IRQ 21 > found-> vendor=0x8086, dev=0x2930, revid=0x02 > domain=0, bus=0, slot=31, func=3 > class=0c-05-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=b, irq=9 > map[10]: type Memory, range 64, base 0xe0427000, size 8, enabled > map[20]: type I/O Port, range 32, base 0x2000, size 5, enabled > pcib0: matched entry for 0.31.INTB > pcib0: slot 31 INTB hardwired to IRQ 18 > vgapci0: port 0x2458-0x245f mem > 0xe0380000-0xe03fffff,0xd0000000-0xdfffffff,0xe0200000-0xe02fffff irq > 16 at device 2.0 on pci0 > agp0: on vgapci0 > vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 > vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xe0380000 > vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xe0200000 > agp0: detected 6140k stolen memory > agp0: aperture size is 256M > vgapci1: mem 0xe0300000-0xe037ffff at device > 2.1 on pci0 > pci0: at device 3.0 (no driver attached) > atapci0: port > 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f > irq 18 at device 3.2 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2420 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49 > atapci0: [MPSAFE] > atapci0: [ITHREAD] > ata2: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2450 > atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x246c > ata2: reset tp1 mask=03 ostat0=7f ostat1=7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f > ata2: reset tp2 stat0=ff stat1=ff devices=0x0 > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2448 > atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2468 > ata3: reset tp1 mask=03 ostat0=7f ostat1=7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f > ata3: reset tp2 stat0=ff stat1=ff devices=0x0 > ata3: [MPSAFE] > ata3: [ITHREAD] > pci0: at device 3.3 (no driver attached) > em0: port 0x2400-0x241f > mem 0xe0400000-0xe041ffff,0xe0424000-0xe0424fff irq 20 at device 25.0 > on pci0 > em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 > em0: attempting to allocate 1 MSI vectors (1 supported) > msi: routing MSI IRQ 256 to local APIC 0 vector 50 > em0: using IRQ 256 for MSI > em0: Using MSI interrupt > em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe0424000 > em0: The EEPROM Checksum Is Not Valid > device_attach: em0 attach returned 5 > uhci0: port 0x20e0-0x20ff irq 18 > at device 26.0 on pci0 > uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20e0 > uhci0: [MPSAFE] > uhci0: [ITHREAD] > uhci0: LegSup = 0x0f10 > usbus0: on uhci0 > uhci1: port 0x20c0-0x20df irq 21 > at device 26.1 on pci0 > uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20c0 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 > uhci1: [MPSAFE] > uhci1: [ITHREAD] > uhci1: LegSup = 0x0f10 > usbus1: on uhci1 > uhci2: port 0x20a0-0x20bf irq 17 > at device 26.2 on pci0 > uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20a0 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 51 > uhci2: [MPSAFE] > uhci2: [ITHREAD] > uhci2: LegSup = 0x0f10 > usbus2: on uhci2 > ehci0: mem > 0xe0426c00-0xe0426fff irq 17 at device 26.7 on pci0 > ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426c00 > ehci0: [MPSAFE] > ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > pci0: at device 27.0 (no driver attached) > pcib1: at device 28.0 on pci0 > pcib1: domain 0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: I/O decode 0x0-0x0 > pcib1: no prefetched decode > pci1: on pcib1 > pci1: domain=0, physical bus=1 > pcib2: at device 28.1 on pci0 > pcib2: domain 0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: I/O decode 0x0-0x0 > pcib2: no prefetched decode > pci2: on pcib2 > pci2: domain=0, physical bus=2 > pcib3: at device 28.2 on pci0 > pcib3: domain 0 > pcib3: secondary bus 3 > pcib3: subordinate bus 3 > pcib3: I/O decode 0x1000-0x1fff > pcib3: memory decode 0xe0100000-0xe01fffff > pcib3: no prefetched decode > pci3: on pcib3 > pci3: domain=0, physical bus=3 > found-> vendor=0x11ab, dev=0x6101, revid=0xb1 > domain=0, bus=3, slot=0, func=0 > class=01-01-8f, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=9 > powerspec 2 supports D0 D1 D3 current D0 > MSI supports 1 message > map[10]: type I/O Port, range 32, base 0x1018, size 3, enabled > pcib3: requested I/O range 0x1018-0x101f: in range > map[14]: type I/O Port, range 32, base 0x1024, size 2, enabled > pcib3: requested I/O range 0x1024-0x1027: in range > map[18]: type I/O Port, range 32, base 0x1010, size 3, enabled > pcib3: requested I/O range 0x1010-0x1017: in range > map[1c]: type I/O Port, range 32, base 0x1020, size 2, enabled > pcib3: requested I/O range 0x1020-0x1023: in range > map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled > pcib3: requested I/O range 0x1000-0x100f: in range > map[24]: type Memory, range 32, base 0xe0100000, size 9, enabled > pcib3: requested memory range 0xe0100000-0xe01001ff: good > pcib3: matched entry for 3.0.INTA > pcib3: slot 0 INTA hardwired to IRQ 18 > atapci1: port > 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f > mem 0xe0100000-0xe01001ff irq 18 at device 0.0 on pci3 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1000 > atapci1: [MPSAFE] > atapci1: [ITHREAD] > ata4: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1018 > atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1024 > ata4: reset tp1 mask=03 ostat0=50 ostat1=51 > ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb > ata4: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb > ata4: reset tp2 stat0=00 stat1=10 devices=0x30000 > ata4: [MPSAFE] > ata4: [ITHREAD] > pcib4: at device 28.3 on pci0 > pcib4: domain 0 > pcib4: secondary bus 4 > pcib4: subordinate bus 4 > pcib4: I/O decode 0x0-0x0 > pcib4: no prefetched decode > pci4: on pcib4 > pci4: domain=0, physical bus=4 > pcib5: at device 28.4 on pci0 > pcib5: domain 0 > pcib5: secondary bus 5 > pcib5: subordinate bus 5 > pcib5: I/O decode 0x0-0x0 > pcib5: no prefetched decode > pci5: on pcib5 > pci5: domain=0, physical bus=5 > uhci3: port 0x2080-0x209f irq 23 > at device 29.0 on pci0 > uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2080 > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 > uhci3: [MPSAFE] > uhci3: [ITHREAD] > uhci3: LegSup = 0x0f10 > usbus4: on uhci3 > uhci4: port 0x2060-0x207f irq 19 > at device 29.1 on pci0 > uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 > ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 > uhci4: [MPSAFE] > uhci4: [ITHREAD] > uhci4: LegSup = 0x0f10 > usbus5: on uhci4 > uhci5: port 0x2040-0x205f irq 18 > at device 29.2 on pci0 > uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 > uhci5: [MPSAFE] > uhci5: [ITHREAD] > uhci5: LegSup = 0x0f10 > usbus6: on uhci5 > ehci1: mem > 0xe0426800-0xe0426bff irq 23 at device 29.7 on pci0 > ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426800 > ehci1: [MPSAFE] > ehci1: [ITHREAD] > usbus7: EHCI version 1.0 > usbus7: on ehci1 > pcib6: at device 30.0 on pci0 > pcib6: domain 0 > pcib6: secondary bus 6 > pcib6: subordinate bus 6 > pcib6: I/O decode 0xf000-0xfff > pcib6: memory decode 0xe0000000-0xe00fffff > pcib6: no prefetched decode > pcib6: Subtractively decoded bridge. > pci6: on pcib6 > pci6: domain=0, physical bus=6 > found-> vendor=0x168c, dev=0x0013, revid=0x01 > domain=0, bus=6, slot=0, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) > intpin=a, irq=9 > powerspec 2 supports D0 D3 current D0 > map[10]: type Memory, range 32, base 0xe0000000, size 16, enabled > pcib6: requested memory range 0xe0000000-0xe000ffff: good > pcib6: matched entry for 6.0.INTA > pcib6: slot 0 INTA hardwired to IRQ 21 > found-> vendor=0x11c1, dev=0x5811, revid=0x70 > domain=0, bus=6, slot=3, func=0 > class=0c-00-10, hdrtype=0x00, mfdev=0 > cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) > lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x18 (6000 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type Memory, range 32, base 0xe0010000, size 12, enabled > pcib6: requested memory range 0xe0010000-0xe0010fff: good > pcib6: matched entry for 6.3.INTA > pcib6: slot 3 INTA hardwired to IRQ 19 > ath0: mem 0xe0000000-0xe000ffff irq 21 at device 0.0 on pci6 > ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe0000000 > ath0: [MPSAFE] > ath0: [ITHREAD] > ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > ath0: turboG rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps > 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > ath0: AR2413 mac 7.9 RF2413 phy 4.5 > ath0: Use hw queue 1 for WME_AC_BE traffic > ath0: Use hw queue 0 for WME_AC_BK traffic > ath0: Use hw queue 2 for WME_AC_VI traffic > ath0: Use hw queue 3 for WME_AC_VO traffic > ath0: Use hw queue 8 for CAB traffic > ath0: Use hw queue 9 for beacons > fwohci0: mem 0xe0010000-0xe0010fff irq 19 at device > 3.0 on pci6 > fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0010000 > fwohci0: [MPSAFE] > fwohci0: [ITHREAD] > fwohci0: OHCI version 1.0 (ROM=0) > fwohci0: No. of Isochronous channels is 8. > fwohci0: EUI64 00:90:27:00:01:d0:dc:04 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x41000 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: fwohci_intr_core: BUS reset > fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER > mode > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci2: port > 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f > mem 0xe0426000-0xe04267ff irq 21 at device 31.2 on pci0 > atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 > atapci2: [MPSAFE] > atapci2: [ITHREAD] > atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xe0426000 > atapci2: AHCI called from vendor specific driver > atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported > atapci2: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd > CCC EM 6ports > ata5: on atapci2 > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect time=0ms status=00000123 > ata5: ready wait time=14ms > ata5: software reset port 15... > ata5: ready wait time=0ms > ata5: SIGNATURE: 00000101 > ata5: AHCI reset done: devices=00000001 > ata5: [MPSAFE] > ata5: [ITHREAD] > ata6: on atapci2 > ata6: AHCI reset... > ata6: hardware reset ... > ata6: SATA connect time=0ms status=00000123 > ata6: ready wait time=49ms > ata6: software reset port 15... > ata6: ready wait time=0ms > ata6: SIGNATURE: 00000101 > ata6: AHCI reset done: devices=00000001 > ata6: [MPSAFE] > ata6: [ITHREAD] > ata7: on atapci2 > ata7: AHCI reset... > ata7: hardware reset ... > ata7: SATA connect time=0ms status=00000123 > ata7: ready wait time=26ms > ata7: software reset port 15... > ata7: ready wait time=0ms > ata7: SIGNATURE: 00000101 > ata7: AHCI reset done: devices=00000001 > ata7: [MPSAFE] > ata7: [ITHREAD] > ata8: on atapci2 > ata8: AHCI reset... > ata8: hardware reset ... > ata8: SATA connect timeout status=00000000 > ata8: AHCI reset done: phy reset found no device > ata8: [MPSAFE] > ata8: [ITHREAD] > ata9: on atapci2 > ata9: AHCI reset... > ata9: hardware reset ... > ata9: SATA connect time=0ms status=00000123 > ata9: ready wait time=22ms > ata9: software reset port 15... > ata9: ready wait time=0ms > ata9: SIGNATURE: 00000101 > ata9: AHCI reset done: devices=00000001 > ata9: [MPSAFE] > ata9: [ITHREAD] > ata10: on atapci2 > ata10: AHCI reset... > ata10: hardware reset ... > ata10: SATA connect time=0ms status=00000123 > ata10: ready wait time=22ms > ata10: software reset port 15... > ata10: ready wait time=0ms > ata10: SIGNATURE: 00000101 > ata10: AHCI reset done: devices=00000001 > ata10: [MPSAFE] > ata10: [ITHREAD] > ichsmb0: port 0x2000-0x201f mem > 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 > ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2000 > ichsmb0: [MPSAFE] > ichsmb0: [ITHREAD] > smbus0: on ichsmb0 > smb0: on smbus0 > atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us) > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 54 > uart0: [FILTER] > uart0: fast interrupt > uart0: console (115200,n,8,1) > cpu0: on acpi0 > coretemp0: on cpu0 > est0: on cpu0 > est0: Invalid id16 (set, cur) = (2086, 2346) > est0: Invalid freq 2664, ignored. > est0: Invalid id16 (set, cur) = (1826, 2346) > est0: Invalid freq 2331, ignored. > est0: Invalid id16 (set, cur) = (1565, 2346) > est0: Invalid freq 1998, ignored. > p4tcc0: on cpu0 > cpu1: on acpi0 > coretemp1: on cpu1 > est1: on cpu1 > est1: Invalid id16 (set, cur) = (2086, 2346) > est1: Invalid freq 2664, ignored. > est1: Invalid id16 (set, cur) = (1826, 2346) > est1: Invalid freq 2331, ignored. > est1: Invalid id16 (set, cur) = (1565, 2346) > est1: Invalid freq 1998, ignored. > p4tcc1: on cpu1 > isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer > isa_probe_children: disabling PnP devices > ichwd0: on isa0 > isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer > ichwd0: Intel ICH9DO watchdog timer (ICH9 or equivalent) > ichwd0: timer disabled > atrtc: atrtc0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > isa_probe_children: probing non-PnP devices > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0 failed to probe at port 0x60 on isa0 > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > ppc0 failed to probe at irq 7 on isa0 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > Device configuration finished. > Reducing kern.maxvnodes 508766 -> 100000 > WARNING: ZFS is considered to be an experimental feature in FreeBSD. > lapic: Divisor 2, Frequency 166747704 hz > Timecounter "TSC" frequency 3001458636 Hz quality -100 > Timecounters tick every 1.000 msec > pflog0: bpf attached > lo0: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) > firewire0: bus manager 1 > bpf attached > ata2: Identifying devices: 00000000 > ata2: New devices: 00000000 > ata3: Identifying devices: 00000000 > ata3: New devices: 00000000 > ata4: Identifying devices: 00030000 > ata4: New devices: 00030000 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > usbus6: 12Mbps Full Speed USB v1.0 > usbus7: 480Mbps High Speed USB v2.0 > ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire > ata4-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > ugen6.1: at usbus6 > uhub6: on usbus6 > ugen7.1: at usbus7 > uhub7: on usbus7 > ZFS filesystem version 13 > ZFS storage pool version 13 > acd0: DVDR drive at ata4 as master > acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, > UDMA66 > acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet > acd0: Writes: CDR, CDRW, DVDR, test write, burnproof > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > acd1: DMA limited to UDMA33, device found non-ATA66 cable > acd1: DVDROM drive at ata4 as slave > acd1: read 687KB/s (8251KB/s), 512KB buffer, UDMA33 > acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet > acd1: Writes: > acd1: Audio: play, 256 volume levels > acd1: Mechanism: ejectable tray, unlocked > acd1: Medium: no/blank disc > ata5: Identifying devices: 00000001 > ata5: New devices: 00000001 > ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad10: 476940MB at ata5-master SATA300 > ad10: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad10 > ad10: Intel check1 failed > ad10: Adaptec check1 failed > ad10: LSI (v3) check1 failed > ad10: LSI (v2) check1 failed > ad10: FreeBSD check1 failed > ata6: Identifying devices: 00000001 > ata6: New devices: 00000001 > ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad12: 476940MB at ata6-master SATA300 > ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad12 > firewire0: New S400 device ID:001f5bfffe2776a6 > fwohci0: txd err= 3 miss Ack err > ad12: Intel check1 failed > ad12: Adaptec check1 failed > ad12: LSI (v3) check1 failed > ad12: LSI (v2) check1 failed > ad12: FreeBSD check1 failed > ata7: Identifying devices: 00000001 > ata7: New devices: 00000001 > ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad14: 238475MB at ata7-master SATA300 > ad14: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad14 > ad14: Intel check1 failed > ad14: Adaptec check1 failed > ad14: LSI (v3) check1 failed > ad14: LSI (v2) check1 failed > ad14: FreeBSD check1 failed > ata8: Identifying devices: 00000000 > ata8: New devices: 00000000 > ata9: Identifying devices: 00000001 > ata9: New devices: 00000001 > ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad18: 715404MB at ata9-master SATA300 > ad18: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad18 > ad18: Intel check1 failed > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > ad18: Adaptec check1 failed > uhub4: 2 ports with 2 removable, self powered > ad18: LSI (v3) check1 failed > uhub5: 2 ports with 2 removable, self powered > uhub6: 2 ports with 2 removable, self powered > ad18: LSI (v2) check1 failed > ad18: FreeBSD check1 failed > ata10: Identifying devices: 00000001 > ata10: New devices: 00000001 > ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire > ad20: 715404MB at ata10-master SATA300 > ad20: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth > queue > GEOM: new disk ad20 > ad20: Intel check1 failed > ad20: Adaptec check1 failed > ad20: LSI (v3) check1 failed > ad20: LSI (v2) check1 failed > ad20: FreeBSD check1 failed > (probe0:sbp0:0:0:0): error 22 > (probe0:sbp0:0:0:0): Unretryable Error > (probe1:sbp0:0:1:0): error 22 > (probe1:sbp0:0:1:0): Unretryable Error > (probe2:sbp0:0:2:0): error 22 > (probe2:sbp0:0:2:0): Unretryable Error > (probe3:sbp0:0:3:0): error 22 > (probe3:sbp0:0:3:0): Unretryable Error > (probe4:sbp0:0:4:0): error 22 > (probe4:sbp0:0:4:0): Unretryable Error > (probe5:sbp0:0:5:0): error 22 > (probe5:sbp0:0:5:0): Unretryable Error > (probe6:sbp0:0:6:0): error 22 > (probe6:sbp0:0:6:0): Unretryable Error > ATA PseudoRAID loaded > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 > ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 49 > ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus7 usbus3 > Root mount waiting for: usbus7 usbus3 > uhub3: 6 ports with 6 removable, self powered > uhub7: 6 ports with 6 removable, self powered > ugen3.2: at usbus3 > umass0: 2> on usbus3 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > Root mount waiting for: usbus3 > umass0:1:0:-1: Attached to scbus1 > (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? > GEOM: new disk da0pass0 at umass-sim0 bus 0 target 0 lun 0 > > pass0: Removable Direct Access SCSI-0 device > pass0: 40.000MB/s transfers > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 3859MB (7905279 512 byte sectors: 255H 63S/T 492C) > Trying to mount root from zfs:alert > ugen5.2: at usbus5 > ukbd0: 2> on usbus5 > kbd: new array size 4 > kbd1 at ukbd0 > kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 > ugen2.2: at usbus2 > ct_to_ts([2009-07-09 12:36:12]) = 1247142972.000000000 > start_init: trying /sbin/init > lock order reversal: > 1st 0xffffffff80815040 pf task mtx (pf task mtx) @ > /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 > 2nd 0xffffffff809f7b40 ifnet (ifnet) @ /usr/src/sys/net/if.c:1887 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7d2 > _rw_rlock() at _rw_rlock+0x60 > ifunit() at ifunit+0x22 > pfioctl() at pfioctl+0x20ea > devfs_ioctl_f() at devfs_ioctl_f+0x6e > kern_ioctl() at kern_ioctl+0xbc > ioctl() at ioctl+0xf0 > syscall() at syscall+0x18b > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098a88c, rsp = > 0x7fffffffb5c8, rbp = 0x7fffffffb710 --- > lock order reversal: > 1st 0xffffff0074026098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 > 2nd 0xffffff007417dba8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x49 > witness_checkorder() at witness_checkorder+0x7d2 > __lockmgr_args() at __lockmgr_args+0xc92 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xc2 > _vn_lock() at _vn_lock+0x50 > vget() at vget+0x6c > devfs_allocv() at devfs_allocv+0xee > devfs_root() at devfs_root+0x41 > vfs_donmount() at vfs_donmount+0xf93 > nmount() at nmount+0x74 > syscall() at syscall+0x18b > Xfast_syscall() at Xfast_syscall+0xd0 > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007aaffc, rsp = > 0x7fffffffdd28, rbp = 0x800a04048 --- > > Thanks, > > Chris > -- > @chrisattack > ----------------------------------------- > http://twitter.com/chrisattack > http://chrisattack.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:43:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A0EB1065721 for ; Thu, 9 Jul 2009 18:43:39 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 949198FC1C for ; Thu, 9 Jul 2009 18:43:38 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id VAA17469; Thu, 09 Jul 2009 21:43:36 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A563A57.8090907@freebsd.org> Date: Thu, 09 Jul 2009 21:43:35 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Marius_N=FCnnerich?= References: <4A562960.3010801@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:43:40 -0000 on 09/07/2009 21:02 Marius Nünnerich said the following: > What about atomically changing tsc_freq every time the frequency is changed? This is what actually does happen, but it doesn't help. Say, there is a moment T1 when TSC has value N and tsc_freq is X, and moment T2 when when TSC value (N + 1) and tsc_freq is 10*X. So the formula gives: t1 = N / X t2 = (N+1) / (10*X) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 18:52:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5B72106564A; Thu, 9 Jul 2009 18:52:32 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from smtp.fgznet.ch (mail.fgznet.ch [81.92.96.47]) by mx1.freebsd.org (Postfix) with ESMTP id 50BE48FC17; Thu, 9 Jul 2009 18:52:32 +0000 (UTC) (envelope-from andreast-list@fgznet.ch) Received: from deuterium.andreas.nets ([91.190.8.131]) by smtp.fgznet.ch (8.13.8/8.13.8/Submit_SMTPAUTH) with ESMTP id n69IqL1o053881; Thu, 9 Jul 2009 20:52:22 +0200 (CEST) (envelope-from andreast-list@fgznet.ch) Message-ID: <4A563C65.20402@fgznet.ch> Date: Thu, 09 Jul 2009 20:52:21 +0200 From: Andreas Tobler User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Ken Smith References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> In-Reply-To: <1247107223.31816.7.camel@bauer.cse.buffalo.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 81.92.96.47 Cc: freebsd-current , freebsd-stable Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:52:33 -0000 Ken Smith wrote: > On Wed, 2009-07-08 at 22:01 +0200, Andreas Tobler wrote: >> I was successful in installing the image, although, a few packages did >> not install. I did a kern developer package. I guess the packages are >> missing on the .img? > > Correct, no packages with BETA1. It's probably the documentation > packages it went looking for and couldn't find. I'll be providing at > least the docs packages with BETA2. Not sure if I'll start trying to > provide a larger set of packages for the DVD or wait for BETA3 for that > (leaning towards waiting at the moment). Ok, that means no doc/dict/docproj/man/ports/src (and the ones I didn't choose) in the BETA1? I did the install again with a real stick and everything went fine besides not finding the above packages. Thanks, Andreas From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 19:55:29 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA60106566C; Thu, 9 Jul 2009 19:55:29 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 8E42B8FC15; Thu, 9 Jul 2009 19:55:29 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n69JdWNv054452; Thu, 9 Jul 2009 15:39:32 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n69JdWjr054451; Thu, 9 Jul 2009 15:39:32 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Thu, 9 Jul 2009 15:39:32 -0400 From: David Schultz To: Andriy Gapon Message-ID: <20090709193932.GA54408@zim.MIT.EDU> Mail-Followup-To: Andriy Gapon , freebsd-current@FreeBSD.ORG References: <4A562960.3010801@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A562960.3010801@freebsd.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 19:55:30 -0000 On Thu, Jul 09, 2009, Andriy Gapon wrote: > > As you might be aware DTrace timestamps right now are derived from TSC value. > http://en.wikipedia.org/wiki/Time_Stamp_Counter > > DTrace timestamps are measured in nano-seconds and the formula similar to the > following is used for calculations: > rdtsc() * 1000000000 / tsc_freq > where rdtsc is a function that returns current TSC value and tsc_freq is a > frequency of TSC. > > This formula is supposed to produce proper results if tsc_freq stays constant. > But there are environment where this might not be the case. > If a CPU has a non-invariant TSC and processor's clock frequency changes (e.g. > because of powerd), then tsc_freq changes too. > As a result, the formula would produce wildly different values and, most > importantly, was values would non be monotonic. Timestamp values that jump back > and forth would not only be useless for a user, they would also confuse DTrace > internal logic. Doesn't Solaris DTRT and compensate for TSC frequency changes? Why can't we do the same thing? From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 22:26:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76A5A106564A for ; Thu, 9 Jul 2009 22:26:15 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0659D8FC15 for ; Thu, 9 Jul 2009 22:26:14 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy6 with SMTP id 6so183891ewy.43 for ; Thu, 09 Jul 2009 15:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xRZWxhQoYZvAPI1Dg78ONlW3u7EDBCgADF81AeytqxE=; b=av49q0Z2c8igf+/LQJTRNUolwC6c8xv8g+fDSOecYZhX1qu5MXbPq3wAjI8aFVudIk 2gpuTLNAx5bglnix1jJjK9oyUr8CBBBNBJVIdqqinq7jFOnDREW9QymRPqlrqGSsTr7G awn+FAZ29fHY69fH/9ZHfwL9Gd5hA+cV8fn5o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=rqOzuXRAEGEDlrfp9mU+xy148URuEkqdo0ZBG06W9VYnUilclUlnnW/u1POx1HecUQ GXXdDgknIgvNcUwWXn6P6gTY6XbukvpeuuerMIEq8tpzO8fS0Q0ipJ9yPYQ7BT/ckclN gSFA7A46p2bWhR8j7fp1nuY+tsEHC8hUj6w20= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.216.21.205 with SMTP id r55mr344402wer.175.1247176932350; Thu, 09 Jul 2009 15:02:12 -0700 (PDT) In-Reply-To: <4A562960.3010801@freebsd.org> References: <4A562960.3010801@freebsd.org> Date: Thu, 9 Jul 2009 23:02:12 +0100 X-Google-Sender-Auth: f1bb0587e6dd5660 Message-ID: From: Andrew Brampton To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 22:26:15 -0000 2009/7/9 Andriy Gapon : > > > There are at least the following two alternatives: > > 1. Keep things as they are and warn users not to change CPU clock frequency when > they use DTrace and the CPU doesn't have invariant TSC. I think that this should > cause only minor inconveniences to a portion of DTrace users. > > 2. Use raw TSC value as a DTrace timestamp and document this difference from the > original DTrace. Advantage: timestamp value is always monotonic. Disadvantage: > manual conversion is needed to get "real" time (using the same formula). > Please note that in this case timestamps would be in non-linear time dimension if > TSC frequency changes, so to get meaningful timestamps (when needed/important) one > would still have to make sure that TSC frequency stay constant. > According to wikipedia newer Intel processors have a constant rate TSC whos freq does not change. If this features is available on most processors today, then I am happy to stick with option 1. Another problem with this is that on a multicore machine each core may have different TSC values. Has anyone thought how to address this issue? Could we calculate the offset of each core from core0, and then ensure the offset is applied to the tsc value when it is needed? thanks Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 9 23:12:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03F95106566B; Thu, 9 Jul 2009 23:12:32 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id BB8BA8FC1F; Thu, 9 Jul 2009 23:12:31 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n69Me7jT002144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2009 18:40:08 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Randi Harper In-Reply-To: References: <4A559E50.3090408@bsdunix.ch> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4G5vpQ+DyGx/sD3nhwHy" Date: Thu, 09 Jul 2009 18:40:02 -0400 Message-Id: <1247179202.9053.39.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: current@freebsd.org, Thomas Vogt Subject: Re: USB stick installation problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 23:12:32 -0000 --=-4G5vpQ+DyGx/sD3nhwHy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2009-07-09 at 09:13 -0700, Randi Harper wrote: > On Thu, Jul 9, 2009 at 12:37 AM, Thomas Vogt wro= te: >=20 > > Hi > > > > I download and copied 8.0-BETA1-amd64-memstick.img to an usb stick as > > described at > > http://lists.freebsd.org/pipermail/freebsd-stable/2009-July/051018.html= . > > > > I can boot it and sysinstall runs fine. Later i chose USB stick as > > install medium but then i get a "no USB stick found" error. Is this an > > know bug? > > > > Regards, > > Thomas >=20 > Possibly. Can you please tell sysinstall to rescan devices or restart the > sysinstall process and tell me if that makes a difference? >=20 > -- randi Expanding on this slightly - I did have this problem on one of the machines I tested with. What Randi means by having sysinstall rescan devices is go into the "Options" section. Inside the Options Editor on the right side column there is an entry for "Re-scan Devices". Please use that and then try a normal install. That seemed to work for me on the one machine I had this glitch with. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-4G5vpQ+DyGx/sD3nhwHy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpWccIACgkQ/G14VSmup/bOuwCfdj/DL21ZgIT+b04Lb1fOE3/M OTUAniqsiKUsD/+Rsn+atJ6hhgw6xHel =OrcC -----END PGP SIGNATURE----- --=-4G5vpQ+DyGx/sD3nhwHy-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 00:13:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433E21065675; Fri, 10 Jul 2009 00:13:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 8A39B8FC12; Fri, 10 Jul 2009 00:13:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by yxe11 with SMTP id 11so902680yxe.3 for ; Thu, 09 Jul 2009 17:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TkrvYGnUyneXzCiFSnq+mLMWEnHSP0n3pNbwejDnWUU=; b=hztvXlcMY5ek2oSz4QEMXZXsEVickKsN+xpOj8OihopCdmKWLRNF8uXohiZUG/FhNg U/3RADV0xznrBlMek86gbv+ljrQYEvLTzGlUsLi2+KHCURdnd3Pw7Go9+x1gT6RSVSWi h4unQpHCpa83j/GQ6+gw9o71OjgYCcBASSv0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=PARM0M5vLw5iEeo0zWdDGC/0Ae0uU366opPFabtOW8uZ5jPP/54Z6uKQeLM2qf1oIf zFpy5UqZrsWjIIC4gh0tHd+cl1J4i2l34vEBmoY4lcYMJNSQ6RVmsBLMfIqAelTHTMLq 5diq/i1Lv1Rm54Jyfmch6bKvJwUgzFBavmMx8= MIME-Version: 1.0 Received: by 10.100.107.17 with SMTP id f17mr1972485anc.82.1247184814857; Thu, 09 Jul 2009 17:13:34 -0700 (PDT) In-Reply-To: <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> Date: Thu, 9 Jul 2009 17:13:34 -0700 Message-ID: <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> From: Jack Vogel To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Stanislav Sedov , freebsd-current@freebsd.org Subject: Re: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 00:13:36 -0000 I have tried to reproduce this and cannot, can you tell me more details about this hardware, is it off-the-shelf or something non-production, etc etc. Did an install of a stock ICH9 system with this NIC, and have seen no such checksum failure, everything works fine :( Jack On Thu, Jul 9, 2009 at 11:35 AM, Jack Vogel wrote: > I am looking into this, thanks for the report. > > Jack > > > > On Thu, Jul 9, 2009 at 10:52 AM, Chris Ruiz wrote: > >> On Thu, Jul 9, 2009 at 6:39 AM, Stanislav Sedov wrote: >> > On Wed, 8 Jul 2009 22:58:27 -0500 >> > Chris Ruiz mentioned: >> > >> >> i just upgraded from r194562 to r195477 in order to test BETA1 and my >> >> e1000 adapter no longer attaching to the driver. >> >> >> >> pciconf -lv output >> >> >> >> em0@pci0:0:25:0: class=0x020000 card=0x00018086 chip=0x10bd8086 >> >> rev=0x02 hdr=0x00 >> >> vendor = 'Intel Corporation' >> >> device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' >> >> class = network >> >> subclass = ethernet >> >> >> >> here's a quick list of relevant commits since my last kernel build: >> >> r195409, r195168, r195049, r194979, r194925, r194911, r194865. >> >> >> > >> > Hi, Chris! >> > >> > Can you provide the verbose boot log? >> >> Turns out it's caused by the driver thinking the EEPROM checksum is >> invalid. Here's a verbose dmesg: >> >> Copyright (c) 1992-2009 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 8.0-BETA1 #0 r195483: Wed Jul 8 21:51:57 CDT 2009 >> root@attack.young-alumni.com:/usr/obj/usr/src/sys/FAILWHALE >> WARNING: WITNESS option enabled, expect reduced performance. >> Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80dce000. >> Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff80dce2b0. >> Preloaded elf obj module "/boot/kernel/opensolaris.ko" at >> 0xffffffff80dce958. >> Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at >> 0xffffffff80dcef88. >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> Calibrating TSC clock ... TSC clock: 3001458636 Hz >> CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (3001.46-MHz K8-class >> CPU) >> Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 >> >> Features=0xbfebfbff >> Features2=0xe3f5 >> AMD Features=0x20100800 >> AMD Features2=0x1 >> TSC: P-state invariant >> real memory = 8589934592 (8192 MB) >> Physical memory chunk(s): >> 0x0000000000001000 - 0x0000000000040fff, 262144 bytes (64 pages) >> 0x0000000000051000 - 0x0000000000099fff, 299008 bytes (73 pages) >> 0x0000000000e01000 - 0x00000000cdbcbfff, 3437015040 bytes (839115 pages) >> 0x00000000cdc9a000 - 0x00000000ceec4fff, 19050496 bytes (4651 pages) >> 0x00000000ceec7000 - 0x00000000cef79fff, 733184 bytes (179 pages) >> 0x00000000cefe5000 - 0x00000000cefe5fff, 4096 bytes (1 pages) >> 0x00000000ceff2000 - 0x00000000ceff2fff, 4096 bytes (1 pages) >> 0x00000000cefff000 - 0x00000000ceffffff, 4096 bytes (1 pages) >> 0x0000000100000000 - 0x000000021cbf3fff, 4777263104 bytes (1166324 pages) >> avail memory = 8192516096 (7812 MB) >> ACPI APIC Table: >> INTR: Adding local APIC 1 as a target >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> APIC: CPU 0 has ACPI ID 1 >> APIC: CPU 1 has ACPI ID 2 >> ULE: setup cpu 0 >> ULE: setup cpu 1 >> This module (opensolaris) contains code covered by the >> Common Development and Distribution License (CDDL) >> see http://opensolaris.org/os/licensing/opensolaris_license/ >> ACPI: RSDP 0xfe020 00014 (v0 INTEL ) >> ACPI: RSDT 0xceffd038 00070 (v1 INTEL DQ3510J 000003BA 01000013) >> ACPI: FACP 0xceffc000 00074 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: DSDT 0xceff8000 03D6A (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: FACS 0xcef87000 00040 >> ACPI: APIC 0xceff7000 00078 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: WDDT 0xceff6000 00040 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: MCFG 0xceff5000 0003C (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: ASF! 0xceff4000 000A6 (v32 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: HPET 0xceff3000 00038 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: DMAR 0xceff1000 000F8 (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: ASPT 0xceff0000 0002C (v3 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: WDTT 0xcefef000 002CC (v1 INTEL DQ3510J 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefee000 00204 (v1 INTEL CpuPm 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefed000 001F9 (v1 INTEL Cpu0Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefec000 001F9 (v1 INTEL Cpu1Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefeb000 001F9 (v1 INTEL Cpu2Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefea000 001F9 (v1 INTEL Cpu3Ist 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe9000 000DD (v1 INTEL Cpu0Cst 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe8000 000DD (v1 INTEL Cpu1Cst 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe7000 000DD (v1 INTEL Cpu2Cst 000003BA MSFT 01000013) >> ACPI: SSDT 0xcefe6000 000DD (v1 INTEL Cpu3Cst 000003BA MSFT 01000013) >> ACPI: TCPA 0xcef7b000 00032 (v2 INTEL TIANO 00000002 MSFT 01000013) >> 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 >> lapic0: Routing NMI -> LINT1 >> lapic0: LINT1 trigger: edge >> lapic0: LINT1 polarity: high >> lapic1: Routing NMI -> LINT1 >> lapic1: LINT1 trigger: edge >> lapic1: LINT1 polarity: high >> ioapic0 irqs 0-23 on motherboard >> cpu0 BSP: >> ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >> wlan: <802.11 Link Layer> >> ichwd module loaded >> io: >> kbd0 at kbdmux0 >> mem: >> nfslock: pseudo-device >> null: >> random: >> acpi0: on motherboard >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >> acpi0: [MPSAFE] >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> acpi0: wakeup code va 0xffffff8000011000 pa 0x4000 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.TMEM -> bus 0 dev 0 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.PAMX -> bus 0 dev 0 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR0 -> bus 0 dev 31 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PRR1 -> bus 0 dev 31 func 0 >> acpi_bus_number: root bus has no _BBN, assuming 0 >> AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.IELK.ELR0 -> bus 0 dev 0 func 0 >> ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 >> pci_link0: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link1: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 >> Validation 0 10 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link2: Index IRQ Rtd Ref IRQs >> Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 >> Validation 0 9 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link3: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link4: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link5: Index IRQ Rtd Ref IRQs >> Initial Probe 0 9 N 0 3 4 5 7 9 10 11 12 >> Validation 0 9 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link6: Index IRQ Rtd Ref IRQs >> Initial Probe 0 10 N 0 3 4 5 7 9 10 11 12 >> Validation 0 10 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> pci_link7: Index IRQ Rtd Ref IRQs >> Initial Probe 0 11 N 0 3 4 5 7 9 10 11 12 >> Validation 0 11 N 0 3 4 5 7 9 10 11 12 >> After Disable 0 255 N 0 3 4 5 7 9 10 11 12 >> acpi_hpet0: iomem 0xfed00000-0xfed003ff on >> acpi0 >> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route >> 64-bit >> Timecounter "HPET" frequency 14318180 Hz quality 900 >> acpi_button0: on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pci0: domain=0, physical bus=0 >> found-> vendor=0x8086, dev=0x29b0, revid=0x02 >> domain=0, bus=0, slot=0, func=0 >> class=06-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x29b2, revid=0x02 >> domain=0, bus=0, slot=2, func=0 >> class=03-00-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> map[10]: type Memory, range 32, base 0xe0380000, size 19, enabled >> map[14]: type I/O Port, range 32, base 0x2458, size 3, enabled >> map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size >> 28, enabled >> map[1c]: type Memory, range 32, base 0xe0200000, size 20, enabled >> pcib0: matched entry for 0.2.INTA >> pcib0: slot 2 INTA hardwired to IRQ 16 >> found-> vendor=0x8086, dev=0x29b3, revid=0x02 >> domain=0, bus=0, slot=2, func=1 >> class=03-80-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0300000, size 19, enabled >> found-> vendor=0x8086, dev=0x29b4, revid=0x02 >> domain=0, bus=0, slot=3, func=0 >> class=07-80-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0006, statreg=0x0018, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 64, base 0xe0427100, size 4, enabled >> pcib0: matched entry for 0.3.INTA >> pcib0: slot 3 INTA hardwired to IRQ 16 >> found-> vendor=0x8086, dev=0x29b6, revid=0x02 >> domain=0, bus=0, slot=3, func=2 >> class=01-01-85, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=9 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type I/O Port, range 32, base 0x2450, size 3, enabled >> map[14]: type I/O Port, range 32, base 0x246c, size 2, enabled >> map[18]: type I/O Port, range 32, base 0x2448, size 3, enabled >> map[1c]: type I/O Port, range 32, base 0x2468, size 2, enabled >> map[20]: type I/O Port, range 32, base 0x2420, size 4, enabled >> pcib0: matched entry for 0.3.INTC >> pcib0: slot 3 INTC hardwired to IRQ 18 >> found-> vendor=0x8086, dev=0x29b7, revid=0x02 >> domain=0, bus=0, slot=3, func=3 >> class=07-00-02, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=10 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type I/O Port, range 32, base 0x2440, size 3, enabled >> map[14]: type Memory, range 32, base 0xe0425000, size 12, enabled >> pcib0: matched entry for 0.3.INTB >> pcib0: slot 3 INTB hardwired to IRQ 17 >> found-> vendor=0x8086, dev=0x10bd, revid=0x02 >> domain=0, bus=0, slot=25, func=0 >> class=02-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 32, base 0xe0400000, size 17, enabled >> map[14]: type Memory, range 32, base 0xe0424000, size 12, enabled >> map[18]: type I/O Port, range 32, base 0x2400, size 5, enabled >> pcib0: matched entry for 0.25.INTA >> pcib0: slot 25 INTA hardwired to IRQ 20 >> found-> vendor=0x8086, dev=0x2937, revid=0x02 >> domain=0, bus=0, slot=26, func=0 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=9 >> map[20]: type I/O Port, range 32, base 0x20e0, size 5, enabled >> pcib0: matched entry for 0.26.INTA >> pcib0: slot 26 INTA hardwired to IRQ 18 >> found-> vendor=0x8086, dev=0x2938, revid=0x02 >> domain=0, bus=0, slot=26, func=1 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=9 >> map[20]: type I/O Port, range 32, base 0x20c0, size 5, enabled >> pcib0: matched entry for 0.26.INTB >> pcib0: slot 26 INTB hardwired to IRQ 21 >> found-> vendor=0x8086, dev=0x2939, revid=0x02 >> domain=0, bus=0, slot=26, func=2 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=10 >> map[20]: type I/O Port, range 32, base 0x20a0, size 5, enabled >> pcib0: matched entry for 0.26.INTC >> pcib0: slot 26 INTC hardwired to IRQ 17 >> found-> vendor=0x8086, dev=0x293c, revid=0x02 >> domain=0, bus=0, slot=26, func=7 >> class=0c-03-20, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=10 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0426c00, size 10, enabled >> pcib0: matched entry for 0.26.INTC >> pcib0: slot 26 INTC hardwired to IRQ 17 >> found-> vendor=0x8086, dev=0x293e, revid=0x02 >> domain=0, bus=0, slot=27, func=0 >> class=04-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=10 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message, 64 bit >> map[10]: type Memory, range 64, base 0xe0420000, size 14, enabled >> pcib0: matched entry for 0.27.INTA >> pcib0: slot 27 INTA hardwired to IRQ 22 >> found-> vendor=0x8086, dev=0x2940, revid=0x02 >> domain=0, bus=0, slot=28, func=0 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2942, revid=0x02 >> domain=0, bus=0, slot=28, func=1 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2944, revid=0x02 >> domain=0, bus=0, slot=28, func=2 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2946, revid=0x02 >> domain=0, bus=0, slot=28, func=3 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=d, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2948, revid=0x02 >> domain=0, bus=0, slot=28, func=4 >> class=06-04-00, hdrtype=0x01, mfdev=1 >> cmdreg=0x0000, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=255 >> powerspec 2 supports D0 D3 current D0 >> MSI supports 1 message >> found-> vendor=0x8086, dev=0x2934, revid=0x02 >> domain=0, bus=0, slot=29, func=0 >> class=0c-03-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> map[20]: type I/O Port, range 32, base 0x2080, size 5, enabled >> pcib0: matched entry for 0.29.INTA >> pcib0: slot 29 INTA hardwired to IRQ 23 >> found-> vendor=0x8086, dev=0x2935, revid=0x02 >> domain=0, bus=0, slot=29, func=1 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=11 >> map[20]: type I/O Port, range 32, base 0x2060, size 5, enabled >> pcib0: matched entry for 0.29.INTB >> pcib0: slot 29 INTB hardwired to IRQ 19 >> found-> vendor=0x8086, dev=0x2936, revid=0x02 >> domain=0, bus=0, slot=29, func=2 >> class=0c-03-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=c, irq=9 >> map[20]: type I/O Port, range 32, base 0x2040, size 5, enabled >> pcib0: matched entry for 0.29.INTC >> pcib0: slot 29 INTC hardwired to IRQ 18 >> found-> vendor=0x8086, dev=0x293a, revid=0x02 >> domain=0, bus=0, slot=29, func=7 >> class=0c-03-20, hdrtype=0x00, mfdev=0 >> cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0426800, size 10, enabled >> pcib0: matched entry for 0.29.INTA >> pcib0: slot 29 INTA hardwired to IRQ 23 >> found-> vendor=0x8086, dev=0x244e, revid=0x92 >> domain=0, bus=0, slot=30, func=0 >> class=06-04-01, hdrtype=0x01, mfdev=0 >> cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x2914, revid=0x02 >> domain=0, bus=0, slot=31, func=0 >> class=06-01-00, hdrtype=0x00, mfdev=1 >> cmdreg=0x0107, statreg=0x0210, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> found-> vendor=0x8086, dev=0x2922, revid=0x02 >> domain=0, bus=0, slot=31, func=2 >> class=01-06-01, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=9 >> powerspec 3 supports D0 D3 current D0 >> MSI supports 16 messages >> map[10]: type I/O Port, range 32, base 0x2438, size 3, enabled >> map[14]: type I/O Port, range 32, base 0x2464, size 2, enabled >> map[18]: type I/O Port, range 32, base 0x2430, size 3, enabled >> map[1c]: type I/O Port, range 32, base 0x2460, size 2, enabled >> map[20]: type I/O Port, range 32, base 0x2020, size 5, enabled >> map[24]: type Memory, range 32, base 0xe0426000, size 11, enabled >> pcib0: matched entry for 0.31.INTA >> pcib0: slot 31 INTA hardwired to IRQ 21 >> found-> vendor=0x8086, dev=0x2930, revid=0x02 >> domain=0, bus=0, slot=31, func=3 >> class=0c-05-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=b, irq=9 >> map[10]: type Memory, range 64, base 0xe0427000, size 8, enabled >> map[20]: type I/O Port, range 32, base 0x2000, size 5, enabled >> pcib0: matched entry for 0.31.INTB >> pcib0: slot 31 INTB hardwired to IRQ 18 >> vgapci0: port 0x2458-0x245f mem >> 0xe0380000-0xe03fffff,0xd0000000-0xdfffffff,0xe0200000-0xe02fffff irq >> 16 at device 2.0 on pci0 >> agp0: on vgapci0 >> vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 >> vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xe0380000 >> vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xe0200000 >> agp0: detected 6140k stolen memory >> agp0: aperture size is 256M >> vgapci1: mem 0xe0300000-0xe037ffff at device >> 2.1 on pci0 >> pci0: at device 3.0 (no driver attached) >> atapci0: port >> 0x2450-0x2457,0x246c-0x246f,0x2448-0x244f,0x2468-0x246b,0x2420-0x242f >> irq 18 at device 3.2 on pci0 >> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x2420 >> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 49 >> atapci0: [MPSAFE] >> atapci0: [ITHREAD] >> ata2: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x2450 >> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0x246c >> ata2: reset tp1 mask=03 ostat0=7f ostat1=7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata2: reset tp2 stat0=ff stat1=ff devices=0x0 >> ata2: [MPSAFE] >> ata2: [ITHREAD] >> ata3: on atapci0 >> atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x2448 >> atapci0: Reserved 0x4 bytes for rid 0x1c type 4 at 0x2468 >> ata3: reset tp1 mask=03 ostat0=7f ostat1=7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f >> ata3: reset tp2 stat0=ff stat1=ff devices=0x0 >> ata3: [MPSAFE] >> ata3: [ITHREAD] >> pci0: at device 3.3 (no driver attached) >> em0: port 0x2400-0x241f >> mem 0xe0400000-0xe041ffff,0xe0424000-0xe0424fff irq 20 at device 25.0 >> on pci0 >> em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe0400000 >> em0: attempting to allocate 1 MSI vectors (1 supported) >> msi: routing MSI IRQ 256 to local APIC 0 vector 50 >> em0: using IRQ 256 for MSI >> em0: Using MSI interrupt >> em0: Reserved 0x1000 bytes for rid 0x14 type 3 at 0xe0424000 >> em0: The EEPROM Checksum Is Not Valid >> device_attach: em0 attach returned 5 >> uhci0: port 0x20e0-0x20ff irq 18 >> at device 26.0 on pci0 >> uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20e0 >> uhci0: [MPSAFE] >> uhci0: [ITHREAD] >> uhci0: LegSup = 0x0f10 >> usbus0: on uhci0 >> uhci1: port 0x20c0-0x20df irq 21 >> at device 26.1 on pci0 >> uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20c0 >> ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 >> uhci1: [MPSAFE] >> uhci1: [ITHREAD] >> uhci1: LegSup = 0x0f10 >> usbus1: on uhci1 >> uhci2: port 0x20a0-0x20bf irq 17 >> at device 26.2 on pci0 >> uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x20a0 >> ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 51 >> uhci2: [MPSAFE] >> uhci2: [ITHREAD] >> uhci2: LegSup = 0x0f10 >> usbus2: on uhci2 >> ehci0: mem >> 0xe0426c00-0xe0426fff irq 17 at device 26.7 on pci0 >> ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426c00 >> ehci0: [MPSAFE] >> ehci0: [ITHREAD] >> usbus3: EHCI version 1.0 >> usbus3: on ehci0 >> pci0: at device 27.0 (no driver attached) >> pcib1: at device 28.0 on pci0 >> pcib1: domain 0 >> pcib1: secondary bus 1 >> pcib1: subordinate bus 1 >> pcib1: I/O decode 0x0-0x0 >> pcib1: no prefetched decode >> pci1: on pcib1 >> pci1: domain=0, physical bus=1 >> pcib2: at device 28.1 on pci0 >> pcib2: domain 0 >> pcib2: secondary bus 2 >> pcib2: subordinate bus 2 >> pcib2: I/O decode 0x0-0x0 >> pcib2: no prefetched decode >> pci2: on pcib2 >> pci2: domain=0, physical bus=2 >> pcib3: at device 28.2 on pci0 >> pcib3: domain 0 >> pcib3: secondary bus 3 >> pcib3: subordinate bus 3 >> pcib3: I/O decode 0x1000-0x1fff >> pcib3: memory decode 0xe0100000-0xe01fffff >> pcib3: no prefetched decode >> pci3: on pcib3 >> pci3: domain=0, physical bus=3 >> found-> vendor=0x11ab, dev=0x6101, revid=0xb1 >> domain=0, bus=3, slot=0, func=0 >> class=01-01-8f, hdrtype=0x00, mfdev=0 >> cmdreg=0x0007, statreg=0x0010, cachelnsz=16 (dwords) >> lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) >> intpin=a, irq=9 >> powerspec 2 supports D0 D1 D3 current D0 >> MSI supports 1 message >> map[10]: type I/O Port, range 32, base 0x1018, size 3, enabled >> pcib3: requested I/O range 0x1018-0x101f: in range >> map[14]: type I/O Port, range 32, base 0x1024, size 2, enabled >> pcib3: requested I/O range 0x1024-0x1027: in range >> map[18]: type I/O Port, range 32, base 0x1010, size 3, enabled >> pcib3: requested I/O range 0x1010-0x1017: in range >> map[1c]: type I/O Port, range 32, base 0x1020, size 2, enabled >> pcib3: requested I/O range 0x1020-0x1023: in range >> map[20]: type I/O Port, range 32, base 0x1000, size 4, enabled >> pcib3: requested I/O range 0x1000-0x100f: in range >> map[24]: type Memory, range 32, base 0xe0100000, size 9, enabled >> pcib3: requested memory range 0xe0100000-0xe01001ff: good >> pcib3: matched entry for 3.0.INTA >> pcib3: slot 0 INTA hardwired to IRQ 18 >> atapci1: port >> 0x1018-0x101f,0x1024-0x1027,0x1010-0x1017,0x1020-0x1023,0x1000-0x100f >> mem 0xe0100000-0xe01001ff irq 18 at device 0.0 on pci3 >> atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1000 >> atapci1: [MPSAFE] >> atapci1: [ITHREAD] >> ata4: on atapci1 >> atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1018 >> atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x1024 >> ata4: reset tp1 mask=03 ostat0=50 ostat1=51 >> ata4: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb >> ata4: stat1=0x10 err=0x01 lsb=0x14 msb=0xeb >> ata4: reset tp2 stat0=00 stat1=10 devices=0x30000 >> ata4: [MPSAFE] >> ata4: [ITHREAD] >> pcib4: at device 28.3 on pci0 >> pcib4: domain 0 >> pcib4: secondary bus 4 >> pcib4: subordinate bus 4 >> pcib4: I/O decode 0x0-0x0 >> pcib4: no prefetched decode >> pci4: on pcib4 >> pci4: domain=0, physical bus=4 >> pcib5: at device 28.4 on pci0 >> pcib5: domain 0 >> pcib5: secondary bus 5 >> pcib5: subordinate bus 5 >> pcib5: I/O decode 0x0-0x0 >> pcib5: no prefetched decode >> pci5: on pcib5 >> pci5: domain=0, physical bus=5 >> uhci3: port 0x2080-0x209f irq 23 >> at device 29.0 on pci0 >> uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2080 >> ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 >> uhci3: [MPSAFE] >> uhci3: [ITHREAD] >> uhci3: LegSup = 0x0f10 >> usbus4: on uhci3 >> uhci4: port 0x2060-0x207f irq 19 >> at device 29.1 on pci0 >> uhci4: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2060 >> ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 >> uhci4: [MPSAFE] >> uhci4: [ITHREAD] >> uhci4: LegSup = 0x0f10 >> usbus5: on uhci4 >> uhci5: port 0x2040-0x205f irq 18 >> at device 29.2 on pci0 >> uhci5: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2040 >> uhci5: [MPSAFE] >> uhci5: [ITHREAD] >> uhci5: LegSup = 0x0f10 >> usbus6: on uhci5 >> ehci1: mem >> 0xe0426800-0xe0426bff irq 23 at device 29.7 on pci0 >> ehci1: Reserved 0x400 bytes for rid 0x10 type 3 at 0xe0426800 >> ehci1: [MPSAFE] >> ehci1: [ITHREAD] >> usbus7: EHCI version 1.0 >> usbus7: on ehci1 >> pcib6: at device 30.0 on pci0 >> pcib6: domain 0 >> pcib6: secondary bus 6 >> pcib6: subordinate bus 6 >> pcib6: I/O decode 0xf000-0xfff >> pcib6: memory decode 0xe0000000-0xe00fffff >> pcib6: no prefetched decode >> pcib6: Subtractively decoded bridge. >> pci6: on pcib6 >> pci6: domain=0, physical bus=6 >> found-> vendor=0x168c, dev=0x0013, revid=0x01 >> domain=0, bus=6, slot=0, func=0 >> class=02-00-00, hdrtype=0x00, mfdev=0 >> cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 >> ns) >> intpin=a, irq=9 >> powerspec 2 supports D0 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0000000, size 16, enabled >> pcib6: requested memory range 0xe0000000-0xe000ffff: good >> pcib6: matched entry for 6.0.INTA >> pcib6: slot 0 INTA hardwired to IRQ 21 >> found-> vendor=0x11c1, dev=0x5811, revid=0x70 >> domain=0, bus=6, slot=3, func=0 >> class=0c-00-10, hdrtype=0x00, mfdev=0 >> cmdreg=0x0216, statreg=0x0290, cachelnsz=16 (dwords) >> lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x18 (6000 >> ns) >> intpin=a, irq=11 >> powerspec 2 supports D0 D1 D2 D3 current D0 >> map[10]: type Memory, range 32, base 0xe0010000, size 12, enabled >> pcib6: requested memory range 0xe0010000-0xe0010fff: good >> pcib6: matched entry for 6.3.INTA >> pcib6: slot 3 INTA hardwired to IRQ 19 >> ath0: mem 0xe0000000-0xe000ffff irq 21 at device 0.0 on >> pci6 >> ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xe0000000 >> ath0: [MPSAFE] >> ath0: [ITHREAD] >> ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >> ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps >> 24Mbps 36Mbps 48Mbps 54Mbps >> ath0: turboG rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps >> 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >> ath0: AR2413 mac 7.9 RF2413 phy 4.5 >> ath0: Use hw queue 1 for WME_AC_BE traffic >> ath0: Use hw queue 0 for WME_AC_BK traffic >> ath0: Use hw queue 2 for WME_AC_VI traffic >> ath0: Use hw queue 3 for WME_AC_VO traffic >> ath0: Use hw queue 8 for CAB traffic >> ath0: Use hw queue 9 for beacons >> fwohci0: mem 0xe0010000-0xe0010fff irq 19 at device >> 3.0 on pci6 >> fwohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0010000 >> fwohci0: [MPSAFE] >> fwohci0: [ITHREAD] >> fwohci0: OHCI version 1.0 (ROM=0) >> fwohci0: No. of Isochronous channels is 8. >> fwohci0: EUI64 00:90:27:00:01:d0:dc:04 >> fwohci0: Phy 1394a available S400, 2 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> firewire0: on fwohci0 >> dcons_crom0: on firewire0 >> dcons_crom0: bus_addr 0x41000 >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: fwohci_intr_core: BUS reset >> fwohci0: fwohci_intr_core: node_id=0x00000001, SelfID Count=2, CYCLEMASTER >> mode >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci2: port >> 0x2438-0x243f,0x2464-0x2467,0x2430-0x2437,0x2460-0x2463,0x2020-0x203f >> mem 0xe0426000-0xe04267ff irq 21 at device 31.2 on pci0 >> atapci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2020 >> atapci2: [MPSAFE] >> atapci2: [ITHREAD] >> atapci2: Reserved 0x800 bytes for rid 0x24 type 3 at 0xe0426000 >> atapci2: AHCI called from vendor specific driver >> atapci2: AHCI v1.20 controller with 6 3Gbps ports, PM supported >> atapci2: Caps: 64bit NCQ SNTF ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd >> CCC EM 6ports >> ata5: on atapci2 >> ata5: AHCI reset... >> ata5: hardware reset ... >> ata5: SATA connect time=0ms status=00000123 >> ata5: ready wait time=14ms >> ata5: software reset port 15... >> ata5: ready wait time=0ms >> ata5: SIGNATURE: 00000101 >> ata5: AHCI reset done: devices=00000001 >> ata5: [MPSAFE] >> ata5: [ITHREAD] >> ata6: on atapci2 >> ata6: AHCI reset... >> ata6: hardware reset ... >> ata6: SATA connect time=0ms status=00000123 >> ata6: ready wait time=49ms >> ata6: software reset port 15... >> ata6: ready wait time=0ms >> ata6: SIGNATURE: 00000101 >> ata6: AHCI reset done: devices=00000001 >> ata6: [MPSAFE] >> ata6: [ITHREAD] >> ata7: on atapci2 >> ata7: AHCI reset... >> ata7: hardware reset ... >> ata7: SATA connect time=0ms status=00000123 >> ata7: ready wait time=26ms >> ata7: software reset port 15... >> ata7: ready wait time=0ms >> ata7: SIGNATURE: 00000101 >> ata7: AHCI reset done: devices=00000001 >> ata7: [MPSAFE] >> ata7: [ITHREAD] >> ata8: on atapci2 >> ata8: AHCI reset... >> ata8: hardware reset ... >> ata8: SATA connect timeout status=00000000 >> ata8: AHCI reset done: phy reset found no device >> ata8: [MPSAFE] >> ata8: [ITHREAD] >> ata9: on atapci2 >> ata9: AHCI reset... >> ata9: hardware reset ... >> ata9: SATA connect time=0ms status=00000123 >> ata9: ready wait time=22ms >> ata9: software reset port 15... >> ata9: ready wait time=0ms >> ata9: SIGNATURE: 00000101 >> ata9: AHCI reset done: devices=00000001 >> ata9: [MPSAFE] >> ata9: [ITHREAD] >> ata10: on atapci2 >> ata10: AHCI reset... >> ata10: hardware reset ... >> ata10: SATA connect time=0ms status=00000123 >> ata10: ready wait time=22ms >> ata10: software reset port 15... >> ata10: ready wait time=0ms >> ata10: SIGNATURE: 00000101 >> ata10: AHCI reset done: devices=00000001 >> ata10: [MPSAFE] >> ata10: [ITHREAD] >> ichsmb0: port 0x2000-0x201f mem >> 0xe0427000-0xe04270ff irq 18 at device 31.3 on pci0 >> ichsmb0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x2000 >> ichsmb0: [MPSAFE] >> ichsmb0: [ITHREAD] >> smbus0: on ichsmb0 >> smb0: on smbus0 >> atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 >> atrtc0: registered as a time-of-day clock (resolution 1000000us) >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 54 >> uart0: [FILTER] >> uart0: fast interrupt >> uart0: console (115200,n,8,1) >> cpu0: on acpi0 >> coretemp0: on cpu0 >> est0: on cpu0 >> est0: Invalid id16 (set, cur) = (2086, 2346) >> est0: Invalid freq 2664, ignored. >> est0: Invalid id16 (set, cur) = (1826, 2346) >> est0: Invalid freq 2331, ignored. >> est0: Invalid id16 (set, cur) = (1565, 2346) >> est0: Invalid freq 1998, ignored. >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> coretemp1: on cpu1 >> est1: on cpu1 >> est1: Invalid id16 (set, cur) = (2086, 2346) >> est1: Invalid freq 2664, ignored. >> est1: Invalid id16 (set, cur) = (1826, 2346) >> est1: Invalid freq 2331, ignored. >> est1: Invalid id16 (set, cur) = (1565, 2346) >> est1: Invalid freq 1998, ignored. >> p4tcc1: on cpu1 >> isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer >> isa_probe_children: disabling PnP devices >> ichwd0: on isa0 >> isab0: found ICH9 or equivalent chipset: Intel ICH9DO watchdog timer >> ichwd0: Intel ICH9DO watchdog timer (ICH9 or equivalent) >> ichwd0: timer disabled >> atrtc: atrtc0 already exists; skipping it >> sc: sc0 already exists; skipping it >> uart: uart0 already exists; skipping it >> isa_probe_children: probing non-PnP devices >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> atkbdc0 failed to probe at port 0x60 on isa0 >> fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 >> ppc0 failed to probe at irq 7 on isa0 >> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >> isa_probe_children: probing PnP devices >> Device configuration finished. >> Reducing kern.maxvnodes 508766 -> 100000 >> WARNING: ZFS is considered to be an experimental feature in FreeBSD. >> lapic: Divisor 2, Frequency 166747704 hz >> Timecounter "TSC" frequency 3001458636 Hz quality -100 >> Timecounters tick every 1.000 msec >> pflog0: bpf attached >> lo0: firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) (me) >> firewire0: bus manager 1 >> bpf attached >> ata2: Identifying devices: 00000000 >> ata2: New devices: 00000000 >> ata3: Identifying devices: 00000000 >> ata3: New devices: 00000000 >> ata4: Identifying devices: 00030000 >> ata4: New devices: 00030000 >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 480Mbps High Speed USB v2.0 >> usbus4: 12Mbps Full Speed USB v1.0 >> usbus5: 12Mbps Full Speed USB v1.0 >> usbus6: 12Mbps Full Speed USB v1.0 >> usbus7: 480Mbps High Speed USB v2.0 >> ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=80 wire >> ata4-slave: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> ugen1.1: at usbus1 >> uhub1: on usbus1 >> ugen2.1: at usbus2 >> uhub2: on usbus2 >> ugen3.1: at usbus3 >> uhub3: on usbus3 >> ugen4.1: at usbus4 >> uhub4: on usbus4 >> ugen5.1: at usbus5 >> uhub5: on usbus5 >> ugen6.1: at usbus6 >> uhub6: on usbus6 >> ugen7.1: at usbus7 >> uhub7: on usbus7 >> ZFS filesystem version 13 >> ZFS storage pool version 13 >> acd0: DVDR drive at ata4 as master >> acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, >> UDMA66 >> acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet >> acd0: Writes: CDR, CDRW, DVDR, test write, burnproof >> acd0: Audio: play, 256 volume levels >> acd0: Mechanism: ejectable tray, unlocked >> acd0: Medium: no/blank disc >> acd1: DMA limited to UDMA33, device found non-ATA66 cable >> acd1: DVDROM drive at ata4 as slave >> acd1: read 687KB/s (8251KB/s), 512KB buffer, UDMA33 >> acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet >> acd1: Writes: >> acd1: Audio: play, 256 volume levels >> acd1: Mechanism: ejectable tray, unlocked >> acd1: Medium: no/blank disc >> ata5: Identifying devices: 00000001 >> ata5: New devices: 00000001 >> ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad10: 476940MB at ata5-master SATA300 >> ad10: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad10 >> ad10: Intel check1 failed >> ad10: Adaptec check1 failed >> ad10: LSI (v3) check1 failed >> ad10: LSI (v2) check1 failed >> ad10: FreeBSD check1 failed >> ata6: Identifying devices: 00000001 >> ata6: New devices: 00000001 >> ata6-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad12: 476940MB at ata6-master SATA300 >> ad12: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad12 >> firewire0: New S400 device ID:001f5bfffe2776a6 >> fwohci0: txd err= 3 miss Ack err >> ad12: Intel check1 failed >> ad12: Adaptec check1 failed >> ad12: LSI (v3) check1 failed >> ad12: LSI (v2) check1 failed >> ad12: FreeBSD check1 failed >> ata7: Identifying devices: 00000001 >> ata7: New devices: 00000001 >> ata7-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad14: 238475MB at ata7-master SATA300 >> ad14: 488397168 sectors [484521C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad14 >> ad14: Intel check1 failed >> ad14: Adaptec check1 failed >> ad14: LSI (v3) check1 failed >> ad14: LSI (v2) check1 failed >> ad14: FreeBSD check1 failed >> ata8: Identifying devices: 00000000 >> ata8: New devices: 00000000 >> ata9: Identifying devices: 00000001 >> ata9: New devices: 00000001 >> ata9-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad18: 715404MB at ata9-master SATA300 >> ad18: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad18 >> ad18: Intel check1 failed >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> ad18: Adaptec check1 failed >> uhub4: 2 ports with 2 removable, self powered >> ad18: LSI (v3) check1 failed >> uhub5: 2 ports with 2 removable, self powered >> uhub6: 2 ports with 2 removable, self powered >> ad18: LSI (v2) check1 failed >> ad18: FreeBSD check1 failed >> ata10: Identifying devices: 00000001 >> ata10: New devices: 00000001 >> ata10-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> ad20: 715404MB at ata10-master SATA300 >> ad20: 1465149168 sectors [1453521C/16H/63S] 16 sectors/interrupt 1 depth >> queue >> GEOM: new disk ad20 >> ad20: Intel check1 failed >> ad20: Adaptec check1 failed >> ad20: LSI (v3) check1 failed >> ad20: LSI (v2) check1 failed >> ad20: FreeBSD check1 failed >> (probe0:sbp0:0:0:0): error 22 >> (probe0:sbp0:0:0:0): Unretryable Error >> (probe1:sbp0:0:1:0): error 22 >> (probe1:sbp0:0:1:0): Unretryable Error >> (probe2:sbp0:0:2:0): error 22 >> (probe2:sbp0:0:2:0): Unretryable Error >> (probe3:sbp0:0:3:0): error 22 >> (probe3:sbp0:0:3:0): Unretryable Error >> (probe4:sbp0:0:4:0): error 22 >> (probe4:sbp0:0:4:0): Unretryable Error >> (probe5:sbp0:0:5:0): error 22 >> (probe5:sbp0:0:5:0): Unretryable Error >> (probe6:sbp0:0:6:0): error 22 >> (probe6:sbp0:0:6:0): Unretryable Error >> ATA PseudoRAID loaded >> SMP: AP CPU #1 Launched! >> cpu1 AP: >> ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff >> lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff >> timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 >> ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 1 vector 48 >> ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 49 >> ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 1 vector 50 >> WARNING: WITNESS option enabled, expect reduced performance. >> Root mount waiting for: usbus7 usbus3 >> Root mount waiting for: usbus7 usbus3 >> uhub3: 6 ports with 6 removable, self powered >> uhub7: 6 ports with 6 removable, self powered >> ugen3.2: at usbus3 >> umass0: > 2> on usbus3 >> umass0: SCSI over Bulk-Only; quirks = 0x0000 >> Root mount waiting for: usbus3 >> umass0:1:0:-1: Attached to scbus1 >> (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? >> GEOM: new disk da0pass0 at umass-sim0 bus 0 target 0 lun 0 >> >> pass0: Removable Direct Access SCSI-0 device >> pass0: 40.000MB/s transfers >> da0 at umass-sim0 bus 0 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 3859MB (7905279 512 byte sectors: 255H 63S/T 492C) >> Trying to mount root from zfs:alert >> ugen5.2: at usbus5 >> ukbd0: > 2> on usbus5 >> kbd: new array size 4 >> kbd1 at ukbd0 >> kbd1: ukbd0, generic (0), config:0x0, flags:0x3d0000 >> ugen2.2: at usbus2 >> ct_to_ts([2009-07-09 12:36:12]) = 1247142972.000000000 >> start_init: trying /sbin/init >> lock order reversal: >> 1st 0xffffffff80815040 pf task mtx (pf task mtx) @ >> /usr/src/sys/contrib/pf/net/pf_ioctl.c:1394 >> 2nd 0xffffffff809f7b40 ifnet (ifnet) @ /usr/src/sys/net/if.c:1887 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x49 >> witness_checkorder() at witness_checkorder+0x7d2 >> _rw_rlock() at _rw_rlock+0x60 >> ifunit() at ifunit+0x22 >> pfioctl() at pfioctl+0x20ea >> devfs_ioctl_f() at devfs_ioctl_f+0x6e >> kern_ioctl() at kern_ioctl+0xbc >> ioctl() at ioctl+0xf0 >> syscall() at syscall+0x18b >> Xfast_syscall() at Xfast_syscall+0xd0 >> --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098a88c, rsp = >> 0x7fffffffb5c8, rbp = 0x7fffffffb710 --- >> lock order reversal: >> 1st 0xffffff0074026098 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1054 >> 2nd 0xffffff007417dba8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a >> _witness_debugger() at _witness_debugger+0x49 >> witness_checkorder() at witness_checkorder+0x7d2 >> __lockmgr_args() at __lockmgr_args+0xc92 >> vop_stdlock() at vop_stdlock+0x39 >> VOP_LOCK1_APV() at VOP_LOCK1_APV+0xc2 >> _vn_lock() at _vn_lock+0x50 >> vget() at vget+0x6c >> devfs_allocv() at devfs_allocv+0xee >> devfs_root() at devfs_root+0x41 >> vfs_donmount() at vfs_donmount+0xf93 >> nmount() at nmount+0x74 >> syscall() at syscall+0x18b >> Xfast_syscall() at Xfast_syscall+0xd0 >> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007aaffc, rsp = >> 0x7fffffffdd28, rbp = 0x800a04048 --- >> >> Thanks, >> >> Chris >> -- >> @chrisattack >> ----------------------------------------- >> http://twitter.com/chrisattack >> http://chrisattack.com >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 02:54:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BBEC106566C for ; Fri, 10 Jul 2009 02:54:15 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2248FC19 for ; Fri, 10 Jul 2009 02:54:15 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n6A2sEqH022566; Thu, 9 Jul 2009 19:54:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 62brfwiytwpmwwv7xf6zegxuea; Thu, 09 Jul 2009 19:54:13 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A56AD55.2010201@freebsd.org> Date: Thu, 09 Jul 2009 19:54:13 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Andriy Gapon References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> In-Reply-To: <4A563A57.8090907@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?Marius_N=FCnnerich?= , freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 02:54:15 -0000 Andriy Gapon wrote: > on 09/07/2009 21:02 Marius Nünnerich said the following: >> What about atomically changing tsc_freq every time the frequency is changed? > > This is what actually does happen, but it doesn't help. > > Say, there is a moment T1 when TSC has value N and tsc_freq is X, and moment T2 > when when TSC value (N + 1) and tsc_freq is 10*X. > So the formula gives: > > t1 = N / X > t2 = (N+1) / (10*X) Instead of just storing tsc_freq at each frequency change, you really need: * Last timestamp just before frequency change (t0) * new frequency (f) * TSC value at frequency change (c0) Then t = t0 + (rdtsc() - c0) / f Of course, I haven't looked at the code to tell what your range limitations are. Tim From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 02:57:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9237106566C for ; Fri, 10 Jul 2009 02:57:19 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 6307D8FC15 for ; Fri, 10 Jul 2009 02:57:19 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id n6A27V4i013451 for ; Fri, 10 Jul 2009 12:07:35 +1000 Message-ID: <4A56A263.4020307@swin.edu.au> Date: Fri, 10 Jul 2009 12:07:31 +1000 From: Mattia Rossi User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: FreeBSD Current References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> <4A563C65.20402@fgznet.ch> In-Reply-To: <4A563C65.20402@fgznet.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Vlc services discovery (SAP) panics kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 02:57:20 -0000 I've tried to use vlc 1.0.0 (goldeneye) - it was also happening with previous versions. Every time I try SAP service discovery the system freezes. Trying on the command line gave me a Fatal error 12 message, page fault while in kernel mode. I've tried to reinstall all ports related to vlc (using portmaster), no changes. Wanted to reinstall all ports from scratch, but as kdelibs3 still doesn't have the latest working libusb2 patch included and kdegraphics4 pulls in sane-backends which does not compile because of libusb2, I actually can't rebuild my system without patching around and stuff - which sucks. Don't know if somebody else is experiencing the same problems... mostly the vlc one. Mat Btw.: no kernel dumps available.. seems that the instructions at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html do not work (for me). From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 03:13:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 861401065674 for ; Fri, 10 Jul 2009 03:13:12 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtao105.cox.net (eastrmmtao105.cox.net [68.230.240.47]) by mx1.freebsd.org (Postfix) with ESMTP id F24A88FC1C for ; Fri, 10 Jul 2009 03:13:11 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090710031311.BBTC14338.eastrmmtao105.cox.net@eastrmimpo01.cox.net>; Thu, 9 Jul 2009 23:13:11 -0400 Received: from localhost ([68.103.37.153]) by eastrmimpo01.cox.net with bizsmtp id E3DA1c0093JFCbG023DAta; Thu, 09 Jul 2009 23:13:11 -0400 X-VR-Score: -200.00 X-Authority-Analysis: v=1.0 c=1 a=RzlibptnTU0A:10 a=6I5d2MoRAAAA:8 a=kviXuzpPAAAA:8 a=YQwyG0xAVI5sdLNHuxgA:9 a=0TNkM6B4Bob_owrR6PMA:7 a=QasC2j3q2kTC3c3NHHKwPBku6-YA:4 a=Lyl-Mu7FfQ4A:10 a=4vB-4DCPJfMA:10 a=SV7veod9ZcQA:10 X-CM-Score: 0.00 Date: Thu, 09 Jul 2009 22:14:01 -0500 To: "Mattia Rossi" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> <4A563C65.20402@fgznet.ch> <4A56A263.4020307@swin.edu.au> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <4A56A263.4020307@swin.edu.au> User-Agent: Opera Mail/9.64 (Linux) Cc: FreeBSD Current Subject: Re: Vlc services discovery (SAP) panics kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 03:13:12 -0000 On Thu, 09 Jul 2009 21:07:31 -0500, Mattia Rossi wrote: > I've tried to use vlc 1.0.0 (goldeneye) - it was also happening with > previous versions. > Every time I try SAP service discovery the system freezes. > > Trying on the command line gave me a Fatal error 12 message, page fault > while in kernel mode. > > I've tried to reinstall all ports related to vlc (using portmaster), no > changes. > > Wanted to reinstall all ports from scratch, but as kdelibs3 still > doesn't have the latest working libusb2 patch included and kdegraphics4 > pulls in sane-backends which does not compile because of libusb2, I > actually can't rebuild my system without patching around and stuff - > which sucks. The kdebase3 (you need to make sure you have latest -CURRENT) should be fixed that was committed a few days ago. As for the sane-backends, I have disabled USB support by default in -CURRENT for us can install KDE3 or KDE4 (don't remember). I agree with you about that broke libusb2 is quiet annoy, but we will get there. Cheers, Mezz > Don't know if somebody else is experiencing the same problems... mostly > the vlc one. > > Mat > > Btw.: no kernel dumps available.. seems that the instructions at > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > do not work (for me). -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 03:58:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69D2C106566C for ; Fri, 10 Jul 2009 03:58:55 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id C3F808FC0C for ; Fri, 10 Jul 2009 03:58:54 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6A3wnsg060977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jul 2009 13:58:49 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247198329; bh=JVzBavO5+xJ4bEhkasTrwieF/RH+QDWUjhDFUiOuk6g=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=hU5AWK3jEcEELflKEFGUsOORSxYXPtnfMCiQ40YORvgM1cMhj+pVlXEAKbbOcoXoi qOplG7Bt2uCoxbKH+BGSFUxHemdgmOxSqo9SZ71bDkNJ419es8WHN/zNfSqwLuOYdP sa9X40YRr19DP6jq8aATkU3U62MyDicJO2e6ewVc= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6A3wngs032023 for ; Fri, 10 Jul 2009 13:58:49 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6A3wnEB032022 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 13:58:49 +1000 (AEST) (envelope-from john) Date: Fri, 10 Jul 2009 13:58:49 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <20090709142121.GS55190@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 03:58:55 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > > OK, now that I've rebuilt the kernel with the debugging options not > > commented out, I'm getting a number of 'lock order reversal' messages > > printed on the console: is that normal? > >=20 > > From the Debugging Deadlocks chapter to which I was referred by pluknet > > (above) it appears that I need to enter 'sysctl debug.kdb.enter=3D1' or > > 'sysctl debug.kdb.panic=3D1' after I get the process into the desired > > 'stuck' state. If I enter either of those commands, the system reboots. > > Now *I'm* stuck. >=20 > Since you have mostly working system, and interesting information most > easy accessible by kgdb, attach it to the live kernel: > kgdb /dev/mem >=20 > From there, switch to the stuck process, > process I tried that... (kgdb) process 1373 Undefined command: "process". Try "help". It took me several more hours to discover "proc" which I assume is what you meant? > do > bt > find the frame for vm_map_delete, and print the entry: > p entry I have no idea which number(s) to plug in here. I hope I guessed the right one. > Also, I need to see the information you posted earlier, namely, procstat > -k and -v output for the process. rwsrv05# procstat 1373 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM = =20 1373 1 1373 1373 0 1 john vmmaps FreeBSD ELF32 ntpd = =20 rwsrv05# procstat -k 1373 PID TID COMM TDNAME KSTACK = =20 1373 100168 ntpd - mi_switch sleepq_switch slee= pq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mm= ap syscall Xint0x80_syscall=20 rwsrv05# procstat -v 1373 PID START END PRT RES PRES REF SHD FL TP PATH 1373 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd 1373 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd 1373 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 1373 0x2807e000 0x280ab000 r-x 45 0 143 62 CN vn /libexec/ld-elf.so.1 1373 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 1373 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 1373 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 1373 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 1373 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 1373 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 1373 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 1373 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 1373 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 1373 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 1373 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 1373 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 1373 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 1373 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 1373 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 1373 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 1373 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 1373 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 1373 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 1373 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 1373 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 1373 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 1373 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 1373 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 1373 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 1373 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 1373 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 1373 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 rwsrv05# kgdb /spare/obj8/usr/src/sys/RWSRV05/kernel.debug /dev/mem 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 condition= s. 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"... #0 sched_switch (td=3D0xc08ad090, newtd=3D0xc4d4d900, flags=3D260) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid =3D PCPU_GET(cpuid); Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. (kgdb) proc 1373 [Switching to thread 154 (Thread 100168)]#0 sched_switch (td=3D0xc5776240,= newtd=3D0xc4d4db40, flags=3D0x104) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid =3D PCPU_GET(cpuid); (kgdb) bt 1373 #0 sched_switch (td=3D0xc5776240, newtd=3D0xc4d4db40, flags=3D0x104) at /u= sr/src/sys/kern/sched_ule.c:1864 During symbol reading, Incomplete CFI data; unspecified registers at 0xc05f= e876. #1 0xc05e572f in mi_switch (flags=3D0x104, newtd=3D0x0) at /usr/src/sys/ke= rn/kern_synch.c:444 #2 0xc06147fc in sleepq_switch (wchan=3D0xc5a5f338, pri=3D0x44) at /usr/sr= c/sys/kern/subr_sleepqueue.c:505 #3 0xc0615495 in sleepq_wait (wchan=3D0xc5a5f338, pri=3D0x44) at /usr/src/= sys/kern/subr_sleepqueue.c:584 #4 0xc05e5bd9 in _sleep (ident=3D0xc5a5f338, lock=3D0xc0a243a4, priority= =3D0x244, wmesg=3D0xc08357af "vmmaps", timo=3D0x0) at /usr/src/sys/kern/kern_synch.c:232 #5 0xc075f8d7 in vm_map_unlock_and_wait (map=3D0xc5a5f2b8, timo=3D0x0) at = /usr/src/sys/vm/vm_map.c:638 #6 0xc075f987 in vm_map_delete (map=3D0xc5a5f2b8, start=3D0x2836e000, end= =3D0x28374000) at /usr/src/sys/vm/vm_map.c:2703 #7 0xc076136e in vm_map_fixed (map=3D0xc5a5f2b8, object=3D0xc52ffc38, offs= et=3D0x0, start=3D0x2836e000, length=3D0x6000,=20 prot=3D0x5, max=3D0x7, cow=3D0x112) at /usr/src/sys/vm/vm_map.c:1367 #8 0xc0763a48 in vm_mmap (map=3D0xc5a5f2b8, addr=3D0xe7840c70, size=3D0x60= 00, prot=3DVariable "prot" is not available. ) at /usr/src/sys/vm/vm_mmap.c:1439 #9 0xc07641ef in mmap (td=3D0xc5776240, uap=3D0xe7840cf8) at /usr/src/sys/= vm/vm_mmap.c:390 #10 0xc07b955f in syscall (frame=3D0xe7840d38) at /usr/src/sys/i386/i386/tr= ap.c:1073 #11 0xc079dff0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :261 #12 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) p *0xc5a5f2b8=20 $1 =3D 0xc58cb048 --=20 John Marshall --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpWvHkACgkQw/tAaKKahKK2JwCfbP3SRWwxeONNQR9zHoOEZZEq heYAn1G3sm8mQKJ0qvg2MhZoKmj/63DX =RBni -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 04:21:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 140D3106566B for ; Fri, 10 Jul 2009 04:21:12 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 868C78FC1E for ; Fri, 10 Jul 2009 04:21:11 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6A4L6OI061620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jul 2009 14:21:07 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247199667; bh=Qtcve4Ym/nji+wnqhC5IcWCLfwMCeGwLIfppLb92W0I=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=bR/bb0FwZWAHQxrhMfOgl1lhavfZqXFSXnjn5H0gXba34fo5pHiJopSNqF+VRzboQ JleJlast4JvRFVzT/FsJe+gM2NMAbJ2hLwWJRh2xm0BdB5DdVF28sazbhsw8bc2hzV f4ec99a1tExp/xawtP2wbZlcfO1WOvGBiOUp9dM4= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6A4L6fK032096 for ; Fri, 10 Jul 2009 14:21:06 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6A4L6pE032095 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 14:21:06 +1000 (AEST) (envelope-from john) Date: Fri, 10 Jul 2009 14:21:06 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8NvZYKFJsRX2Djef" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 04:21:12 -0000 --8NvZYKFJsRX2Djef Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of days ago. Today I had a nasty surprise when I fired up bsdlabel to increase the size of a swap partition. I booted the system off the 7.2-RELEASE live filesystem CD and its bsdlabel displayed "normal" labels. I used the bsdlabel off the 7.2 livefs CD to edit the label. Here's what I see from 8.0-BETA1. Scary stuff! rwsrv05# bsdlabel da0s1 # /dev/da0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 1048576 16065 4.2BSD 2048 16384 8=20 b: 8388608 1064641 swap =20 c: 33543720 16065 unused 0 0 # "raw" part, don't= edit e: 4194304 9453249 4.2BSD 2048 16384 28552=20 f: 19912232 13647553 4.2BSD 2048 16384 28552=20 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system u= tilities partition f: partition extends past end of unit rwsrv05# bsdlabel da0s2 # /dev/da0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 67103505 33559785 unused 0 0 # "raw" part, don't= edit d: 33554432 33559785 4.2BSD 2048 16384 28552=20 e: 33549073 67114217 4.2BSD 2048 16384 28552=20 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system u= tilities partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit rwsrv05# bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 156301425 63 unused 0 0 # "raw" part, don'= t edit d: 156301409 79 4.2BSD 2048 16384 28552=20 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system u= tilities partition d: partition extends past end of unit --=20 John Marshall --8NvZYKFJsRX2Djef Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpWwbIACgkQw/tAaKKahKK16gCgzw/vp7U8TWImJOYSlftI75cN AxEAniY0nBLA5vfbaqnVYiiKA2yr4pig =k4wu -----END PGP SIGNATURE----- --8NvZYKFJsRX2Djef-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 05:45:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F335C106566B for ; Fri, 10 Jul 2009 05:45:41 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 708EC8FC0C for ; Fri, 10 Jul 2009 05:45:38 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA25444; Fri, 10 Jul 2009 08:45:35 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MP8vO-000Kiy-Nz; Fri, 10 Jul 2009 08:45:34 +0300 Message-ID: <4A56D57D.1090508@freebsd.org> Date: Fri, 10 Jul 2009 08:45:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: David Schultz , freebsd-current@freebsd.org References: <4A562960.3010801@freebsd.org> <20090709193932.GA54408@zim.MIT.EDU> In-Reply-To: <20090709193932.GA54408@zim.MIT.EDU> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:45:42 -0000 on 09/07/2009 22:39 David Schultz said the following: > Doesn't Solaris DTRT and compensate for TSC frequency changes? > Why can't we do the same thing? That very well may be. I haven't thoroughly checked but I think that even we are doing the right thing when we use TSC as a timecounter. But at this moment I am looking for a quick/simple and "sufficiently good" fix for the bigger problems with DTrace timestamping (kern/127441). Another side of the "simplicity" is that the timestamp function for DTrace needs to be fast and should not itself be probed. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 05:50:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 873F0106564A for ; Fri, 10 Jul 2009 05:50:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 027F88FC19 for ; Fri, 10 Jul 2009 05:50:50 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA25514; Fri, 10 Jul 2009 08:50:49 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MP90T-000KjK-8I; Fri, 10 Jul 2009 08:50:49 +0300 Message-ID: <4A56D6B7.8050100@freebsd.org> Date: Fri, 10 Jul 2009 08:50:47 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: Tim Kientzle References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> In-Reply-To: <4A56AD55.2010201@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Marius_N=FCnnerich?= , freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:50:52 -0000 on 10/07/2009 05:54 Tim Kientzle said the following: > > Instead of just storing tsc_freq at each frequency change, > you really need: > * Last timestamp just before frequency change (t0) > * new frequency (f) > * TSC value at frequency change (c0) > > Then > t = t0 + (rdtsc() - c0) / f > > Of course, I haven't looked at the code to tell > what your range limitations are. Yes, tracking the TSC frequency changes should allow us to have correct DTrace timecounting. But I am not sure if we really need this (or can have this). Because otherwise I can not see why we have a distinct/specialized DTrace TSC-based timecounting when we already have general purpose TSC timecounting that already works correctly (if I am not mistaken). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 05:58:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2E05106564A for ; Fri, 10 Jul 2009 05:58:31 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CC1978FC12 for ; Fri, 10 Jul 2009 05:58:23 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id IAA25564 for ; Fri, 10 Jul 2009 08:58:21 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1MP97l-000Kjq-7y for freebsd-current@freebsd.org; Fri, 10 Jul 2009 08:58:21 +0300 Message-ID: <4A56D87B.6000202@freebsd.org> Date: Fri, 10 Jul 2009 08:58:19 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090406) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> <4A56D6B7.8050100@freebsd.org> In-Reply-To: <4A56D6B7.8050100@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 05:58:32 -0000 Thinking aloud - maybe we could always use one value of tsc_freq (or something like max_tsc_freq). This wouldn't give us correct timestamps when TSC frequency is changing, but it would give us something that is always proportional to TSC value and thus has its properties - monotonicity in the first place. And, of course, there is no problem when TSC frequency is constant. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 06:14:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D08E1065673 for ; Fri, 10 Jul 2009 06:14:19 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 9AFB68FC1D for ; Fri, 10 Jul 2009 06:14:18 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=JkWhZbFNKwblSK/Ftyt0+nN4hf/+yZDIYAm56g2lv2NQsmbdDIH7LIbkMiPElmlpzetW3BTsmApavXh/EuhSQ1FJnoZhVKHQA/AaWLDvE1AIyKR1dvDCFfpgFyPzYBDep1QTRlM+uN5XffOpnGQlX788+lYX9KXg6yvKJFVJQ2Q=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MP9NB-0004yW-Ms for freebsd-current@freebsd.org; Fri, 10 Jul 2009 10:14:17 +0400 Date: Fri, 10 Jul 2009 10:14:15 +0400 From: Eygene Ryabinkin To: freebsd-current@freebsd.org Message-ID: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> Sender: rea-fbsd@codelabs.ru Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 06:14:19 -0000 Jogh, good day. Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of > days ago. > > Today I had a nasty surprise when I fired up bsdlabel to increase the > size of a swap partition. I booted the system off the 7.2-RELEASE live > filesystem CD and its bsdlabel displayed "normal" labels. I used the > bsdlabel off the 7.2 livefs CD to edit the label. > > Here's what I see from 8.0-BETA1. Scary stuff! > > rwsrv05# bsdlabel da0s1 > # /dev/da0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 1048576 16065 4.2BSD 2048 16384 8 > b: 8388608 1064641 swap > c: 33543720 16065 unused 0 0 # "raw" part, don't edit > e: 4194304 9453249 4.2BSD 2048 16384 28552 > f: 19912232 13647553 4.2BSD 2048 16384 28552 > partition c: partition extends past end of unit > bsdlabel: partition c doesn't start at 0! > bsdlabel: An incorrect partition c may cause problems for standard system utilities > partition f: partition extends past end of unit And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about 'c' that doesn't start at 0, but no stuff will be marked as 'extends past end of unit' ;)) The problem is that your 8.x kernel is likely misses GEOM_BSD, so gctl_issue() inside readlabel() of bsdlabel.c will choke on it. Mine problems on one of the hosts were solved by adding GEOM_BSD and recompiling the kernel, though it has the only slice that started at 63 (MBR offset). > rwsrv05# bsdlabel da0s2 > # /dev/da0s2: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > c: 67103505 33559785 unused 0 0 # "raw" part, don't edit > d: 33554432 33559785 4.2BSD 2048 16384 28552 > e: 33549073 67114217 4.2BSD 2048 16384 28552 > partition c: partition extends past end of unit > bsdlabel: partition c doesn't start at 0! > bsdlabel: An incorrect partition c may cause problems for standard system utilities > partition d: partition extends past end of unit > partition e: offset past end of unit > partition e: partition extends past end of unit This part gets trickier, because partition 'c' reports strange offset. I had reproduced this problem at my notebook, so I'll try to debug it further. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 07:10:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78C5B106564A for ; Fri, 10 Jul 2009 07:10:27 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id E8B1B8FC0C for ; Fri, 10 Jul 2009 07:10:26 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6A7AOSZ024029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jul 2009 17:10:24 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247209824; bh=hT0DyTZRWosNfuPx+Nj/l5NsOp+GQXcpneSbaLj9A0w=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=ZvRZ4ZiUzBCnCzUsFuAXl35dhxliVQ8afngPFp2lvJ2R7meirZAGwuZ87VnkSMG3N IJc9mBBexG2/cjoFYwPC6b/84BVPSpSATt46SZZJ43CoIxUxHTUzKI3zK/tS/M7V9R 4LLACsdXVtf1PqcOvXPLA6FZk9Wy6k4ZtDyUWjxE= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6A7AOv9032592 for ; Fri, 10 Jul 2009 17:10:24 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6A7ANeu032591 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 17:10:23 +1000 (AEST) (envelope-from john) Date: Fri, 10 Jul 2009 17:10:23 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DBIVS5p969aUjpLe" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 07:10:27 -0000 --DBIVS5p969aUjpLe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote: > Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: > > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple of > > days ago. > >=20 > > Today I had a nasty surprise when I fired up bsdlabel to increase the > > size of a swap partition. I booted the system off the 7.2-RELEASE live > > filesystem CD and its bsdlabel displayed "normal" labels. I used the > > bsdlabel off the 7.2 livefs CD to edit the label. > >=20 > > Here's what I see from 8.0-BETA1. Scary stuff! > >=20 > > rwsrv05# bsdlabel da0s1 > > # /dev/da0s1: > > 8 partitions: > > # size offset fstype [fsize bsize bps/cpg] > > a: 1048576 16065 4.2BSD 2048 16384 8=20 > > b: 8388608 1064641 swap =20 > > c: 33543720 16065 unused 0 0 # "raw" part, d= on't edit > > e: 4194304 9453249 4.2BSD 2048 16384 28552=20 > > f: 19912232 13647553 4.2BSD 2048 16384 28552=20 > > partition c: partition extends past end of unit > > bsdlabel: partition c doesn't start at 0! > > bsdlabel: An incorrect partition c may cause problems for standard syst= em utilities > > partition f: partition extends past end of unit >=20 > And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about > 'c' that doesn't start at 0, but no stuff will be marked as 'extends past > end of unit' ;)) >=20 > The problem is that your 8.x kernel is likely misses GEOM_BSD, so > gctl_issue() inside readlabel() of bsdlabel.c will choke on it. > Mine problems on one of the hosts were solved by adding GEOM_BSD and > recompiling the kernel, though it has the only slice that started at > 63 (MBR offset). >=20 > > rwsrv05# bsdlabel da0s2 > > # /dev/da0s2: > > 8 partitions: > > # size offset fstype [fsize bsize bps/cpg] > > c: 67103505 33559785 unused 0 0 # "raw" part, d= on't edit > > d: 33554432 33559785 4.2BSD 2048 16384 28552=20 > > e: 33549073 67114217 4.2BSD 2048 16384 28552=20 > > partition c: partition extends past end of unit > > bsdlabel: partition c doesn't start at 0! > > bsdlabel: An incorrect partition c may cause problems for standard syst= em utilities > > partition d: partition extends past end of unit > > partition e: offset past end of unit > > partition e: partition extends past end of unit >=20 > This part gets trickier, because partition 'c' reports strange offset. > I had reproduced this problem at my notebook, so I'll try to debug it > further. Thank you Eygene, Rebuilding the kernel with the GEOM_BSD option configured didn't make any difference for me. I notice that the offset for the start of the slice 2 c partition seems to include the size of the entire s1 slice. --=20 John Marshall --DBIVS5p969aUjpLe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpW6V8ACgkQw/tAaKKahKKZVwCfUa/Bhuia0g+/Irqw/9h13E2d emsAoIaxdkiN06i2vt2IgOF+imMtuJna =h0ZC -----END PGP SIGNATURE----- --DBIVS5p969aUjpLe-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 07:58:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21076106566C; Fri, 10 Jul 2009 07:58:49 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mx1.freebsd.org (Postfix) with ESMTP id 7D37F8FC1D; Fri, 10 Jul 2009 07:58:48 +0000 (UTC) (envelope-from yr.retarded@gmail.com) Received: by ewy27 with SMTP id 27so22732ewy.43 for ; Fri, 10 Jul 2009 00:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8QZr9ICAPDgdf8ofhzRkFz+1EpuLC/VLgIDlQtMN7vA=; b=tYzljwVntfNGri1AJ+Xksfxqa0AI8f+zx7Ka9lcYRRgKr/wWg5nkCRlcC4p+Bu0d/5 9bHDucvzK4CyPxQs9kvW/Co/g6dxdU+nj567G7h6DLHepK0ED1ql8FBX4kOe8sKmwCGl hf2Yd5eGI/IGXkgPMAhMbe3nWBMukV2WqaHeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=uz73IQ15KRiJffLGThH8bZFxYFI7+lOzacepltqY8Y1jxzfPM1D8V8ttBHfnBR8XSF slv397fnVCjMp+Hz7KuzUtD7qgRZgO4vLg0HoTFnNTRxMmm8Ih0sSvWbGAbNIC0fwQSj 6Uf5Rzdo58PNsWnVgpKaxar3ORiN4x5P/O5ys= MIME-Version: 1.0 Received: by 10.210.81.9 with SMTP id e9mr2060614ebb.42.1247212726577; Fri, 10 Jul 2009 00:58:46 -0700 (PDT) In-Reply-To: <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> Date: Fri, 10 Jul 2009 02:58:46 -0500 Message-ID: <58c737d70907100058u263ab795g442c62d67ba2345f@mail.gmail.com> From: Chris Ruiz To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stanislav Sedov , freebsd-current@freebsd.org Subject: Re: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 07:58:49 -0000 On Thu, Jul 9, 2009 at 7:13 PM, Jack Vogel wrote: > I have tried to reproduce this and cannot,=A0 can you tell me more detail= s > about > this hardware, is it off-the-shelf or something non-production, etc etc. > > Did an install of a stock ICH9 system with this NIC, and have seen no > such checksum failure, everything works fine :( I've never had any problems with my network controller before now (driver version 6.9.9 works) so this is indeed strange. This is an Intel=AE Desktop Board DQ35JO (1), so the nic is built in. This is off the shelf two year old equipment used for a home server, nothing spectacular. Thanks, Chris (1) http://www.intel.com/support/motherboards/desktop/dq35jo/ From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 08:24:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 012EC106564A for ; Fri, 10 Jul 2009 08:24:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 505528FC51 for ; Fri, 10 Jul 2009 08:24:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n6A8NvGk074197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jul 2009 11:23:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n6A8NuLB064841 for ; Fri, 10 Jul 2009 11:23:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6A8Nusd064840 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 11:23:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Jul 2009 11:23:56 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20090710082356.GZ55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SqEPCaGsKgsesFh5" Content-Disposition: inline In-Reply-To: <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 08:24:05 -0000 --SqEPCaGsKgsesFh5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 10, 2009 at 01:58:49PM +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > > On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > > > OK, now that I've rebuilt the kernel with the debugging options not > > > commented out, I'm getting a number of 'lock order reversal' messages > > > printed on the console: is that normal? > > >=20 > > > From the Debugging Deadlocks chapter to which I was referred by plukn= et > > > (above) it appears that I need to enter 'sysctl debug.kdb.enter=3D1' = or > > > 'sysctl debug.kdb.panic=3D1' after I get the process into the desired > > > 'stuck' state. If I enter either of those commands, the system reboo= ts. > > > Now *I'm* stuck. > >=20 > > Since you have mostly working system, and interesting information most > > easy accessible by kgdb, attach it to the live kernel: > > kgdb /dev/mem > >=20 > > From there, switch to the stuck process, > > process >=20 > I tried that... >=20 > (kgdb) process 1373 > Undefined command: "process". Try "help". >=20 > It took me several more hours to discover "proc" which I assume is what > you meant? Yes. >=20 > > do > > bt > > find the frame for vm_map_delete, and print the entry: > > p entry >=20 > I have no idea which number(s) to plug in here. I hope I guessed the > right one. >=20 > > Also, I need to see the information you posted earlier, namely, procstat > > -k and -v output for the process. >=20 > rwsrv05# procstat 1373 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM = =20 > 1373 1 1373 1373 0 1 john vmmaps FreeBSD ELF32 ntpd = =20 > rwsrv05# procstat -k 1373 > PID TID COMM TDNAME KSTACK = =20 > 1373 100168 ntpd - mi_switch sleepq_switch sl= eepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap = mmap syscall Xint0x80_syscall=20 > rwsrv05# procstat -v 1373 > PID START END PRT RES PRES REF SHD FL TP PATH > 1373 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/nt= pd > 1373 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/nt= pd > 1373 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 > 1373 0x2807e000 0x280ab000 r-x 45 0 143 62 CN vn /libexec/ld-elf.s= o.1 > 1373 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.s= o.1 > 1373 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 > 1373 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 1373 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so= .5 > 1373 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so= .5 > 1373 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so= .5 > 1373 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 > 1373 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 1373 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.s= o.1 > 1373 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.s= o.1 > 1373 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.s= o.1 > 1373 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so= .1 > 1373 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so= .1 > 1373 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so= .1 > 1373 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 1373 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 1373 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 > 1373 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 > 1373 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 > 1373 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 >=20 > rwsrv05# kgdb /spare/obj8/usr/src/sys/RWSRV05/kernel.debug /dev/mem > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... > #0 sched_switch (td=3D0xc08ad090, newtd=3D0xc4d4d900, flags=3D260) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid =3D PCPU_GET(cpuid); > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. >=20 > Type 'getsyms' after connection to load kld symbols. >=20 > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > (kgdb) proc 1373 > [Switching to thread 154 (Thread 100168)]#0 sched_switch (td=3D0xc577624= 0, newtd=3D0xc4d4db40, flags=3D0x104) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid =3D PCPU_GET(cpuid); > (kgdb) bt 1373 > #0 sched_switch (td=3D0xc5776240, newtd=3D0xc4d4db40, flags=3D0x104) at = /usr/src/sys/kern/sched_ule.c:1864 > During symbol reading, Incomplete CFI data; unspecified registers at 0xc0= 5fe876. > #1 0xc05e572f in mi_switch (flags=3D0x104, newtd=3D0x0) at /usr/src/sys/= kern/kern_synch.c:444 > #2 0xc06147fc in sleepq_switch (wchan=3D0xc5a5f338, pri=3D0x44) at /usr/= src/sys/kern/subr_sleepqueue.c:505 > #3 0xc0615495 in sleepq_wait (wchan=3D0xc5a5f338, pri=3D0x44) at /usr/sr= c/sys/kern/subr_sleepqueue.c:584 > #4 0xc05e5bd9 in _sleep (ident=3D0xc5a5f338, lock=3D0xc0a243a4, priority= =3D0x244, wmesg=3D0xc08357af "vmmaps", timo=3D0x0) > at /usr/src/sys/kern/kern_synch.c:232 > #5 0xc075f8d7 in vm_map_unlock_and_wait (map=3D0xc5a5f2b8, timo=3D0x0) a= t /usr/src/sys/vm/vm_map.c:638 > #6 0xc075f987 in vm_map_delete (map=3D0xc5a5f2b8, start=3D0x2836e000, en= d=3D0x28374000) at /usr/src/sys/vm/vm_map.c:2703 This frame (vm_map_delete). > #7 0xc076136e in vm_map_fixed (map=3D0xc5a5f2b8, object=3D0xc52ffc38, of= fset=3D0x0, start=3D0x2836e000, length=3D0x6000,=20 > prot=3D0x5, max=3D0x7, cow=3D0x112) at /usr/src/sys/vm/vm_map.c:1367 > #8 0xc0763a48 in vm_mmap (map=3D0xc5a5f2b8, addr=3D0xe7840c70, size=3D0x= 6000, prot=3DVariable "prot" is not available. > ) at /usr/src/sys/vm/vm_mmap.c:1439 > #9 0xc07641ef in mmap (td=3D0xc5776240, uap=3D0xe7840cf8) at /usr/src/sy= s/vm/vm_mmap.c:390 > #10 0xc07b955f in syscall (frame=3D0xe7840d38) at /usr/src/sys/i386/i386/= trap.c:1073 > #11 0xc079dff0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:261 > #12 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) p *0xc5a5f2b8=20 > $1 =3D 0xc58cb048 This is useless. You need to do either p *entry or p *(struct vm_map_entry *)
>=20 > --=20 > John Marshall --SqEPCaGsKgsesFh5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpW+pwACgkQC3+MBN1Mb4gk7gCgjoPkx+e6gr7g7GRVnPrA4ECS 6FcAnRw6HMf7TIXSVGC1YyBSWod6eepu =FEZj -----END PGP SIGNATURE----- --SqEPCaGsKgsesFh5-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 08:28:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65C2B106564A for ; Fri, 10 Jul 2009 08:28:34 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mx1.freebsd.org (Postfix) with ESMTP id C85EC8FC16 for ; Fri, 10 Jul 2009 08:28:33 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ewy27 with SMTP id 27so35388ewy.43 for ; Fri, 10 Jul 2009 01:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=F98Qr7grra+z9+bhrscOOc8H0pJWOyJLX1Lac75GLek=; b=NjYVylhMbl3frUFw5aW4ue4v7XXc5QxxMBluH4O/JeB9gQxYzutPpQEitbIXP3YmM2 ofHlr8RZeQyDVEaAWP2y3iqxBX4xBex+pTdyawpkXZgbZKttmUDI/RPkA5pGQxB7ACLh Wg8RIrpAzBQH3N+kwhkijE1pEdig5t37p//nY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=gLUXkW0MF8+mvXVIwkP5tHgD2gXFw5q55xLfrahzpuN7GMUhDoILvAYuswm+2mDA3v Xmd2Z548mB6RE2A6N8Jy1ggIRQa+8kBCSY6RvQdFgBLB16BLYeXZDfWtyYJPeMpobYoF F2RcMoiCXi8qBL2pWTi4PMtBKOKJ6iPIn5mJM= Received: by 10.210.131.6 with SMTP id e6mr2082225ebd.63.1247214512740; Fri, 10 Jul 2009 01:28:32 -0700 (PDT) Received: from ?127.0.0.1? (87-194-39-182.bethere.co.uk [87.194.39.182]) by mx.google.com with ESMTPS id 7sm2079691eyb.55.2009.07.10.01.28.31 (version=SSLv3 cipher=RC4-MD5); Fri, 10 Jul 2009 01:28:32 -0700 (PDT) From: Tom Evans To: John Marshall In-Reply-To: <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> Content-Type: text/plain Date: Fri, 10 Jul 2009 09:28:30 +0100 Message-Id: <1247214510.2437.1693.camel@strangepork.london.mintel.ad> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 08:28:34 -0000 On Fri, 2009-07-10 at 13:58 +1000, John Marshall wrote: > On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > > On Thu, Jul 09, 2009 at 06:52:42PM +1000, John Marshall wrote: > > > OK, now that I've rebuilt the kernel with the debugging options not > > > commented out, I'm getting a number of 'lock order reversal' messages > > > printed on the console: is that normal? > > > > > > From the Debugging Deadlocks chapter to which I was referred by pluknet > > > (above) it appears that I need to enter 'sysctl debug.kdb.enter=1' or > > > 'sysctl debug.kdb.panic=1' after I get the process into the desired > > > 'stuck' state. If I enter either of those commands, the system reboots. > > > Now *I'm* stuck. > > > > Since you have mostly working system, and interesting information most > > easy accessible by kgdb, attach it to the live kernel: > > kgdb /dev/mem > > > > From there, switch to the stuck process, > > process > > I tried that... > > (kgdb) process 1373 > Undefined command: "process". Try "help". > > It took me several more hours to discover "proc" which I assume is what > you meant? > > > do > > bt > > find the frame for vm_map_delete, and print the entry: > > p entry > > I have no idea which number(s) to plug in here. I hope I guessed the > right one. > > > Also, I need to see the information you posted earlier, namely, procstat > > -k and -v output for the process. > > rwsrv05# procstat 1373 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM > 1373 1 1373 1373 0 1 john vmmaps FreeBSD ELF32 ntpd > rwsrv05# procstat -k 1373 > PID TID COMM TDNAME KSTACK > 1373 100168 ntpd - mi_switch sleepq_switch sleepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mmap syscall Xint0x80_syscall > rwsrv05# procstat -v 1373 > PID START END PRT RES PRES REF SHD FL TP PATH > 1373 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd > 1373 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd > 1373 0x8080000 0x8100000 rw- 128 0 1 0 C- df > 1373 0x2807e000 0x280ab000 r-x 45 0 143 62 CN vn /libexec/ld-elf.so.1 > 1373 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 > 1373 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df > 1373 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 1373 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 1373 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 > 1373 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 > 1373 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 > 1373 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df > 1373 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 1373 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 1373 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 > 1373 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 > 1373 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 > 1373 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 > 1373 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 > 1373 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 > 1373 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 1373 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 1373 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 1373 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 1373 0x28358000 0x2836e000 rw- 22 0 1 0 C- df > 1373 0x2836e000 0x2837a000 --- 0 0 0 0 -- -- > 1373 0x28400000 0x28500000 rw- 256 0 1 0 C- df > 1373 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df > > rwsrv05# kgdb /spare/obj8/usr/src/sys/RWSRV05/kernel.debug /dev/mem > 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"... > #0 sched_switch (td=0xc08ad090, newtd=0xc4d4d900, flags=260) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. > > Type 'getsyms' after connection to load kld symbols. > > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > (kgdb) proc 1373 > [Switching to thread 154 (Thread 100168)]#0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid = PCPU_GET(cpuid); > (kgdb) bt 1373 > #0 sched_switch (td=0xc5776240, newtd=0xc4d4db40, flags=0x104) at /usr/src/sys/kern/sched_ule.c:1864 > During symbol reading, Incomplete CFI data; unspecified registers at 0xc05fe876. > #1 0xc05e572f in mi_switch (flags=0x104, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:444 > #2 0xc06147fc in sleepq_switch (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:505 > #3 0xc0615495 in sleepq_wait (wchan=0xc5a5f338, pri=0x44) at /usr/src/sys/kern/subr_sleepqueue.c:584 > #4 0xc05e5bd9 in _sleep (ident=0xc5a5f338, lock=0xc0a243a4, priority=0x244, wmesg=0xc08357af "vmmaps", timo=0x0) > at /usr/src/sys/kern/kern_synch.c:232 > #5 0xc075f8d7 in vm_map_unlock_and_wait (map=0xc5a5f2b8, timo=0x0) at /usr/src/sys/vm/vm_map.c:638 > #6 0xc075f987 in vm_map_delete (map=0xc5a5f2b8, start=0x2836e000, end=0x28374000) at /usr/src/sys/vm/vm_map.c:2703 > #7 0xc076136e in vm_map_fixed (map=0xc5a5f2b8, object=0xc52ffc38, offset=0x0, start=0x2836e000, length=0x6000, > prot=0x5, max=0x7, cow=0x112) at /usr/src/sys/vm/vm_map.c:1367 > #8 0xc0763a48 in vm_mmap (map=0xc5a5f2b8, addr=0xe7840c70, size=0x6000, prot=Variable "prot" is not available. > ) at /usr/src/sys/vm/vm_mmap.c:1439 > #9 0xc07641ef in mmap (td=0xc5776240, uap=0xe7840cf8) at /usr/src/sys/vm/vm_mmap.c:390 > #10 0xc07b955f in syscall (frame=0xe7840d38) at /usr/src/sys/i386/i386/trap.c:1073 > #11 0xc079dff0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 > #12 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) p *0xc5a5f2b8 > $1 = 0xc58cb048 > At this stage, you want to type 'f 6', to go to frame 6, (the vm_map_delete function) and then type 'p *entry' to print the struct pointed to by the local variable entry in that frame. Cheers Tom From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 11:12:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CC1610656FD; Fri, 10 Jul 2009 11:12:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 75EA18FC27; Fri, 10 Jul 2009 11:12:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1139D46B46; Fri, 10 Jul 2009 07:12:38 -0400 (EDT) Date: Fri, 10 Jul 2009 12:12:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andriy Gapon In-Reply-To: <4A56D87B.6000202@freebsd.org> Message-ID: References: <4A562960.3010801@freebsd.org> <4A563A57.8090907@freebsd.org> <4A56AD55.2010201@freebsd.org> <4A56D6B7.8050100@freebsd.org> <4A56D87B.6000202@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:12:39 -0000 On Fri, 10 Jul 2009, Andriy Gapon wrote: > Thinking aloud - maybe we could always use one value of tsc_freq (or > something like max_tsc_freq). This wouldn't give us correct timestamps when > TSC frequency is changing, but it would give us something that is always > proportional to TSC value and thus has its properties - monotonicity in the > first place. And, of course, there is no problem when TSC frequency is > constant. Just a point from a user perspective: I find it useful (important even) to be able to compare timing between runs on the same box, and while that means I need to control for the frequency changing in an experimental sense, in as much as timestamp measurements in dtrace can be normalized, that would be helpful. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 11:26:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 399A11065673 for ; Fri, 10 Jul 2009 11:26:35 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id C362B8FC1D for ; Fri, 10 Jul 2009 11:26:34 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6ABQWbk031582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jul 2009 21:26:32 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247225192; bh=JBf2ShqJJyA1CnhcHNSwCS+PbnmHps3bEVBRsy6Ykrs=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=YbGf+6PdKl25jzlPGIZj1xmXO8R5lgTleQWoLeMd1tXb3BkB7mxDSBL7bzF+dTHMS 3XCleEoZGuZA8TkQMKgBHZRKqL0OdyH+hykos8Zl4HJmdDW8+pWNjKCH9N8e/r5PxN hNt1mesGIgMb27RvoGV36FumZ32eDAxn8gSN1ZVY= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6ABQWZp033617 for ; Fri, 10 Jul 2009 21:26:32 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6ABQVw7033616 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 21:26:31 +1000 (AEST) (envelope-from john) Date: Fri, 10 Jul 2009 21:26:31 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bjuZg6miEcdLYP6q" Content-Disposition: inline In-Reply-To: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:26:35 -0000 --bjuZg6miEcdLYP6q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 10 Jul 2009, 17:10 +1000, John Marshall wrote: > On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote: > > Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: > > > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple= of > > > days ago. > > >=20 > > > Today I had a nasty surprise when I fired up bsdlabel to increase the > > > size of a swap partition. I booted the system off the 7.2-RELEASE li= ve > > > filesystem CD and its bsdlabel displayed "normal" labels. I used the > > > bsdlabel off the 7.2 livefs CD to edit the label. > > >=20 > > > Here's what I see from 8.0-BETA1. Scary stuff! > > >=20 > > > rwsrv05# bsdlabel da0s1 > > > # /dev/da0s1: > > > 8 partitions: > > > # size offset fstype [fsize bsize bps/cpg] > > > a: 1048576 16065 4.2BSD 2048 16384 8=20 > > > b: 8388608 1064641 swap =20 > > > c: 33543720 16065 unused 0 0 # "raw" part,= don't edit > > > e: 4194304 9453249 4.2BSD 2048 16384 28552=20 > > > f: 19912232 13647553 4.2BSD 2048 16384 28552=20 > > > partition c: partition extends past end of unit > > > bsdlabel: partition c doesn't start at 0! > > > bsdlabel: An incorrect partition c may cause problems for standard sy= stem utilities > > > partition f: partition extends past end of unit > >=20 > > And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about > > 'c' that doesn't start at 0, but no stuff will be marked as 'extends pa= st > > end of unit' ;)) > >=20 > > The problem is that your 8.x kernel is likely misses GEOM_BSD, so > > gctl_issue() inside readlabel() of bsdlabel.c will choke on it. > > Mine problems on one of the hosts were solved by adding GEOM_BSD and > > recompiling the kernel, though it has the only slice that started at > > 63 (MBR offset). > >=20 > > > rwsrv05# bsdlabel da0s2 > > > # /dev/da0s2: > > > 8 partitions: > > > # size offset fstype [fsize bsize bps/cpg] > > > c: 67103505 33559785 unused 0 0 # "raw" part,= don't edit > > > d: 33554432 33559785 4.2BSD 2048 16384 28552=20 > > > e: 33549073 67114217 4.2BSD 2048 16384 28552=20 > > > partition c: partition extends past end of unit > > > bsdlabel: partition c doesn't start at 0! > > > bsdlabel: An incorrect partition c may cause problems for standard sy= stem utilities > > > partition d: partition extends past end of unit > > > partition e: offset past end of unit > > > partition e: partition extends past end of unit > >=20 > > This part gets trickier, because partition 'c' reports strange offset. > > I had reproduced this problem at my notebook, so I'll try to debug it > > further. >=20 > Thank you Eygene, >=20 > Rebuilding the kernel with the GEOM_BSD option configured didn't make > any difference for me. I notice that the offset for the start of the > slice 2 c partition seems to include the size of the entire s1 slice. I don't think it's just bsdlabel. I just noticed this in DMESG... WARNING: da0s1 expected rawoffset 0, found 16065 WARNING: da0s2 expected rawoffset 0, found 33559785 WARNING: da0s4 expected rawoffset 0, found 100663290 WARNING: da1s1 expected rawoffset 0, found 16065 WARNING: da1s2 expected rawoffset 0, found 33559785 WARNING: da1s4 expected rawoffset 0, found 67103505 WARNING: da0s1a expected rawoffset 0, found 16065 WARNING: da0s2d expected rawoffset 0, found 33559785 WARNING: da0s4d expected rawoffset 0, found 100663290 WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 WARNING: da1s1d expected rawoffset 0, found 16065 WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 WARNING: da1s2d expected rawoffset 0, found 33559785 WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 WARNING: da1s4d expected rawoffset 0, found 67103505 WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 Trying to mount root from ufs:/dev/da0s1a WARNING: da0s1a expected rawoffset 0, found 16065 WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 WARNING: ad0s1 expected rawoffset 0, found 63 WARNING: da1s1 expected rawoffset 0, found 16065 WARNING: da1s1d expected rawoffset 0, found 16065 WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 WARNING: da1s2 expected rawoffset 0, found 33559785 WARNING: da1s2d expected rawoffset 0, found 33559785 WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 WARNING: da1s4 expected rawoffset 0, found 67103505 WARNING: da1s4d expected rawoffset 0, found 67103505 WARNING: da0s2 expected rawoffset 0, found 33559785 WARNING: da0s2d expected rawoffset 0, found 33559785 WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 WARNING: da0s2 expected rawoffset 0, found 33559785 WARNING: da0s4 expected rawoffset 0, found 100663290 WARNING: da0s4d expected rawoffset 0, found 100663290 WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 --=20 John Marshall --bjuZg6miEcdLYP6q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpXJWcACgkQw/tAaKKahKJ9UwCgjt+1zk3M5gY19tHiEZgW/aa+ oQ8An2WuEardu099woamPS191TCKbrHL =M8Kk -----END PGP SIGNATURE----- --bjuZg6miEcdLYP6q-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 11:33:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C821065673 for ; Fri, 10 Jul 2009 11:33:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 020C68FC17 for ; Fri, 10 Jul 2009 11:33:11 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz21 with SMTP id 21so648733bwz.43 for ; Fri, 10 Jul 2009 04:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9ghoLwQqjBTa6I0vetKyrsyp40pQ1j3K+01B03qW6qU=; b=RlgOyzGxLlHsNsKpN/P20mW0bjAcKJDOdzBIsSui+GIEpADeqo6JFAMoEQr129Rk6E dctBRIX9OaOFGGlp9v73WNZT1NY8q0OIiqsBLFImDi7mllpyTIpPU83w1FMbrTJRED3j WG/v9LAVtd3aweiASSkMvejX688UmRhqETg/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=QZd0+e7a35URx55PByT47OeJxdnU3a14wPHGrhEHUXnYLNO9r+FpbDiFipB9gcAB3A w6GNuZAKlYKFQfcPs9lDxo3G2D76IgiXC3H/hwe9hCv+m25rTeYRdfhpuofultj69Kp0 5eWuvT6pZXv89lJ6zF6k8wowog+ckn+/39F6Q= MIME-Version: 1.0 Received: by 10.204.117.141 with SMTP id r13mr1778717bkq.207.1247225590777; Fri, 10 Jul 2009 04:33:10 -0700 (PDT) In-Reply-To: <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> Date: Fri, 10 Jul 2009 13:33:10 +0200 Message-ID: <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> From: "Paul B. Mahol" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:33:12 -0000 On 7/10/09, John Marshall wrote: > On Fri, 10 Jul 2009, 17:10 +1000, John Marshall wrote: >> On Fri, 10 Jul 2009, 10:14 +0400, Eygene Ryabinkin wrote: >> > Fri, Jul 10, 2009 at 02:21:06PM +1000, John Marshall wrote: >> > > This system was source-upgrade from 7.2-RELEASE to 8.0-BETA1 a couple >> > > of >> > > days ago. >> > > >> > > Today I had a nasty surprise when I fired up bsdlabel to increase the >> > > size of a swap partition. I booted the system off the 7.2-RELEASE >> > > live >> > > filesystem CD and its bsdlabel displayed "normal" labels. I used the >> > > bsdlabel off the 7.2 livefs CD to edit the label. >> > > >> > > Here's what I see from 8.0-BETA1. Scary stuff! >> > > >> > > rwsrv05# bsdlabel da0s1 >> > > # /dev/da0s1: >> > > 8 partitions: >> > > # size offset fstype [fsize bsize bps/cpg] >> > > a: 1048576 16065 4.2BSD 2048 16384 8 >> > > b: 8388608 1064641 swap >> > > c: 33543720 16065 unused 0 0 # "raw" part, >> > > don't edit >> > > e: 4194304 9453249 4.2BSD 2048 16384 28552 >> > > f: 19912232 13647553 4.2BSD 2048 16384 28552 >> > > partition c: partition extends past end of unit >> > > bsdlabel: partition c doesn't start at 0! >> > > bsdlabel: An incorrect partition c may cause problems for standard >> > > system utilities >> > > partition f: partition extends past end of unit >> > >> > And if you'll invoke 'bsdlabel -A da0s1' then it will whine only about >> > 'c' that doesn't start at 0, but no stuff will be marked as 'extends >> > past >> > end of unit' ;)) >> > >> > The problem is that your 8.x kernel is likely misses GEOM_BSD, so >> > gctl_issue() inside readlabel() of bsdlabel.c will choke on it. >> > Mine problems on one of the hosts were solved by adding GEOM_BSD and >> > recompiling the kernel, though it has the only slice that started at >> > 63 (MBR offset). >> > >> > > rwsrv05# bsdlabel da0s2 >> > > # /dev/da0s2: >> > > 8 partitions: >> > > # size offset fstype [fsize bsize bps/cpg] >> > > c: 67103505 33559785 unused 0 0 # "raw" part, >> > > don't edit >> > > d: 33554432 33559785 4.2BSD 2048 16384 28552 >> > > e: 33549073 67114217 4.2BSD 2048 16384 28552 >> > > partition c: partition extends past end of unit >> > > bsdlabel: partition c doesn't start at 0! >> > > bsdlabel: An incorrect partition c may cause problems for standard >> > > system utilities >> > > partition d: partition extends past end of unit >> > > partition e: offset past end of unit >> > > partition e: partition extends past end of unit >> > >> > This part gets trickier, because partition 'c' reports strange offset. >> > I had reproduced this problem at my notebook, so I'll try to debug it >> > further. >> >> Thank you Eygene, >> >> Rebuilding the kernel with the GEOM_BSD option configured didn't make >> any difference for me. I notice that the offset for the start of the >> slice 2 c partition seems to include the size of the entire s1 slice. > > I don't think it's just bsdlabel. I just noticed this in DMESG... > > WARNING: da0s1 expected rawoffset 0, found 16065 > WARNING: da0s2 expected rawoffset 0, found 33559785 > WARNING: da0s4 expected rawoffset 0, found 100663290 > WARNING: da1s1 expected rawoffset 0, found 16065 > WARNING: da1s2 expected rawoffset 0, found 33559785 > WARNING: da1s4 expected rawoffset 0, found 67103505 > WARNING: da0s1a expected rawoffset 0, found 16065 > WARNING: da0s2d expected rawoffset 0, found 33559785 > WARNING: da0s4d expected rawoffset 0, found 100663290 > WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 > WARNING: da1s1d expected rawoffset 0, found 16065 > WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 > WARNING: da1s2d expected rawoffset 0, found 33559785 > WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 > WARNING: da1s4d expected rawoffset 0, found 67103505 > WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 > WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 > WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 > WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 > WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 > WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 > WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 > Trying to mount root from ufs:/dev/da0s1a > WARNING: da0s1a expected rawoffset 0, found 16065 > WARNING: ufsid/454bbd55fb8748ad expected rawoffset 0, found 16065 > WARNING: ad0s1 expected rawoffset 0, found 63 > WARNING: da1s1 expected rawoffset 0, found 16065 > WARNING: da1s1d expected rawoffset 0, found 16065 > WARNING: ufsid/44c73ece4c594eee expected rawoffset 0, found 16065 > WARNING: ufsid/44c73ece4c594eeed expected rawoffset 0, found 16065 > WARNING: da1s2 expected rawoffset 0, found 33559785 > WARNING: da1s2d expected rawoffset 0, found 33559785 > WARNING: ufsid/44ca989c1c946f80 expected rawoffset 0, found 33559785 > WARNING: ufsid/44ca989c1c946f80d expected rawoffset 0, found 33559785 > WARNING: da1s4 expected rawoffset 0, found 67103505 > WARNING: da1s4d expected rawoffset 0, found 67103505 > WARNING: da0s2 expected rawoffset 0, found 33559785 > WARNING: da0s2d expected rawoffset 0, found 33559785 > WARNING: ufsid/44caacedfa48b1aa expected rawoffset 0, found 67103505 > WARNING: ufsid/44cab13667346452 expected rawoffset 0, found 33559785 > WARNING: ufsid/44caacedfa48b1aad expected rawoffset 0, found 67103505 > WARNING: da0s2 expected rawoffset 0, found 33559785 > WARNING: da0s4 expected rawoffset 0, found 100663290 > WARNING: da0s4d expected rawoffset 0, found 100663290 > WARNING: ufsid/44cab1426f1a14df expected rawoffset 0, found 100663290 > WARNING: ufsid/44cab1426f1a14dfd expected rawoffset 0, found 100663290 > > -- > John Marshall > There is one not so trivial solution. Recreating labels with gpart(8) -- Paul From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 11:42:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02F57106564A for ; Fri, 10 Jul 2009 11:42:38 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5B1E58FC1E for ; Fri, 10 Jul 2009 11:42:37 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6ABgZaX031899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 10 Jul 2009 21:42:35 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247226156; bh=QT3K42mj3gkgHPdpZXgGQcodOoW6QdnXfgAEZgoEQVg=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=ZtieHIKHA4Tv2T533nLanzNpm5aabH6FClj9H+1IBuViUmTWGPubmMcjBb5w1q7Rk G0LIrrExqw1QaBdP4Zd/CpGN4SvWkzKZJHrUOozqUSwxRHJwz6AWCKN4DCZ856jOqb O1R6jfY0D7mQCE6pzcDZz2jLyUtnuhpdu5Qq0frA= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6ABgZ0n033659 for ; Fri, 10 Jul 2009 21:42:35 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6ABgZrp033658 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 21:42:35 +1000 (AEST) (envelope-from john) Date: Fri, 10 Jul 2009 21:42:34 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> <1247214510.2437.1693.camel@strangepork.london.mintel.ad> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KuLpqunXa7jZSBt+" Content-Disposition: inline In-Reply-To: <1247214510.2437.1693.camel@strangepork.london.mintel.ad> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 11:42:38 -0000 --KuLpqunXa7jZSBt+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 10 Jul 2009, 09:28 +0100, Tom Evans wrote: > On Fri, 2009-07-10 at 13:58 +1000, John Marshall wrote: > > On Thu, 09 Jul 2009, 17:21 +0300, Kostik Belousov wrote: > > > Since you have mostly working system, and interesting information most > > > easy accessible by kgdb, attach it to the live kernel: > > > kgdb /dev/mem > > >=20 > > > From there, switch to the stuck process, > > > process > >=20 > > I tried that... > >=20 > > (kgdb) process 1373 > > Undefined command: "process". Try "help". > >=20 > > It took me several more hours to discover "proc" which I assume is what > > you meant? > >=20 > > > do > > > bt > > > find the frame for vm_map_delete, and print the entry: > > > p entry > >=20 > > I have no idea which number(s) to plug in here. I hope I guessed the > > right one. > >=20 > > > Also, I need to see the information you posted earlier, namely, procs= tat > > > -k and -v output for the process. > >=20 > At this stage, you want to type 'f 6', to go to frame 6, (the > vm_map_delete function) and then type 'p *entry' to print the struct > pointed to by the local variable entry in that frame. Thank you Tom! You could see I was struggling. Now, hopefully, I can provide something useful this time. rwsrv05# procstat 1270 PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM = =20 1270 1 1270 1270 0 1 john vmmaps FreeBSD ELF32 ntpd = =20 rwsrv05# procstat -k 1270 PID TID COMM TDNAME KSTACK = =20 1270 100184 ntpd - mi_switch sleepq_switch slee= pq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap mm= ap syscall Xint0x80_syscall=20 rwsrv05# procstat -v 1270 PID START END PRT RES PRES REF SHD FL TP PATH 1270 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/ntpd 1270 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/ntpd 1270 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 1270 0x2807e000 0x280ab000 r-x 45 0 170 75 CN vn /libexec/ld-elf.so.1 1270 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.so.1 1270 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 1270 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 1270 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 1270 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 1270 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so.5 1270 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so.5 1270 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so.5 1270 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 1270 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 1270 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 1270 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 1270 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.so.1 1270 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.so.1 1270 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.so.1 1270 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so.1 1270 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so.1 1270 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so.1 1270 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 1270 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 1270 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 1270 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 1270 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 1270 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 1270 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 1270 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 1270 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 1270 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 rwsrv05# kgdb kernel.debug /dev/mem 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 condition= s. 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"... #0 sched_switch (td=3D0xc08af410, newtd=3D0xc4d4db40, flags=3D260) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid =3D PCPU_GET(cpuid); Ready to go. Enter 'tr' to connect to the remote target with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port or 'trf portno' to connect to the remote target with the firewire interface. portno defaults to 5556. Type 'getsyms' after connection to load kld symbols. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. (kgdb) proc 1270 [Switching to thread 168 (Thread 100184)]#0 sched_switch (td=3D0xc592fd80,= newtd=3D0xc4d4db40, flags=3D0x104) at /usr/src/sys/kern/sched_ule.c:1864 1864 cpuid =3D PCPU_GET(cpuid); (kgdb) bt #0 sched_switch (td=3D0xc592fd80, newtd=3D0xc4d4db40, flags=3D0x104) at /u= sr/src/sys/kern/sched_ule.c:1864 During symbol reading, Incomplete CFI data; unspecified registers at 0xc060= 09d6. #1 0xc05e788f in mi_switch (flags=3D0x104, newtd=3D0x0) at /usr/src/sys/ke= rn/kern_synch.c:444 #2 0xc061695c in sleepq_switch (wchan=3D0xc5909f00, pri=3D0x44) at /usr/sr= c/sys/kern/subr_sleepqueue.c:505 #3 0xc06175f5 in sleepq_wait (wchan=3D0xc5909f00, pri=3D0x44) at /usr/src/= sys/kern/subr_sleepqueue.c:584 #4 0xc05e7d39 in _sleep (ident=3D0xc5909f00, lock=3D0xc0a26724, priority= =3D0x244, wmesg=3D0xc0837aa0 "vmmaps", timo=3D0x0) at /usr/src/sys/kern/kern_synch.c:232 #5 0xc0761a37 in vm_map_unlock_and_wait (map=3D0xc5909e80, timo=3D0x0) at = /usr/src/sys/vm/vm_map.c:638 #6 0xc0761ae7 in vm_map_delete (map=3D0xc5909e80, start=3D0x2836e000, end= =3D0x28374000) at /usr/src/sys/vm/vm_map.c:2703 #7 0xc07634ce in vm_map_fixed (map=3D0xc5909e80, object=3D0xc5254990, offs= et=3D0x0, start=3D0x2836e000, length=3D0x6000,=20 prot=3D0x5, max=3D0x7, cow=3D0x112) at /usr/src/sys/vm/vm_map.c:1367 #8 0xc0765ba8 in vm_mmap (map=3D0xc5909e80, addr=3D0xe787ac70, size=3D0x60= 00, prot=3DVariable "prot" is not available. ) at /usr/src/sys/vm/vm_mmap.c:1439 #9 0xc076634f in mmap (td=3D0xc592fd80, uap=3D0xe787acf8) at /usr/src/sys/= vm/vm_mmap.c:390 #10 0xc07bb6bf in syscall (frame=3D0xe787ad38) at /usr/src/sys/i386/i386/tr= ap.c:1073 #11 0xc07a0150 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s= :261 #12 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) f 6 #6 0xc0761ae7 in vm_map_delete (map=3D0xc5909e80, start=3D0x2836e000, end= =3D0x28374000) at /usr/src/sys/vm/vm_map.c:2703 2703 (void) vm_map_unlock_and_wait(map, 0); (kgdb) p *entry $1 =3D { prev =3D 0xc5812b40,=20 next =3D 0xc59ec7e0,=20 left =3D 0xc5812b40,=20 right =3D 0xc59ec7e0,=20 start =3D 0x2836e000,=20 end =3D 0x2837a000,=20 avail_ssize =3D 0x0,=20 adj_free =3D 0x86000,=20 max_free =3D 0x976e0000,=20 object =3D { vm_object =3D 0x0,=20 sub_map =3D 0x0 },=20 offset =3D 0x0,=20 eflags =3D 0x600,=20 protection =3D 0x0,=20 max_protection =3D 0x7,=20 inheritance =3D 0x1,=20 wired_count =3D 0xffffffff,=20 lastr =3D 0x1c,=20 uip =3D 0x0 } (kgdb)=20 --=20 John Marshall --KuLpqunXa7jZSBt+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpXKSoACgkQw/tAaKKahKLGrACffJpDtsJM7iwHCQz+hFCPAX6t HW4AoLvMgKIMZ3qTRrHyTdoDJSN/znzk =ab+c -----END PGP SIGNATURE----- --KuLpqunXa7jZSBt+-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 12:27:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A6891065670 for ; Fri, 10 Jul 2009 12:27:20 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 190818FC12 for ; Fri, 10 Jul 2009 12:27:18 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04059; Fri, 10 Jul 2009 15:27:15 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A5733A3.20409@freebsd.org> Date: Fri, 10 Jul 2009 15:27:15 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Andrew Brampton References: <4A562960.3010801@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 12:27:20 -0000 on 10/07/2009 01:02 Andrew Brampton said the following: > According to wikipedia newer Intel processors have a constant rate TSC > whos freq does not change. If this features is available on most > processors today, then I am happy to stick with option 1. > > Another problem with this is that on a multicore machine each core may > have different TSC values. Has anyone thought how to address this > issue? Could we calculate the offset of each core from core0, and then > ensure the offset is applied to the tsc value when it is needed? Yes. The actual code accounts for inter-CPU/core TSC skew. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 13:24:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF5F0106566B for ; Fri, 10 Jul 2009 13:24:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7438FC0A for ; Fri, 10 Jul 2009 13:24:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n6ADOTEN095635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jul 2009 16:24:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n6ADOTWO009119 for ; Fri, 10 Jul 2009 16:24:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6ADOTAw009118 for freebsd-current@freebsd.org; Fri, 10 Jul 2009 16:24:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 10 Jul 2009 16:24:29 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20090710132429.GA55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> <1247214510.2437.1693.camel@strangepork.london.mintel.ad> <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYtRAvLPyLojxZ7Y" Content-Disposition: inline In-Reply-To: <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:24:36 -0000 --zYtRAvLPyLojxZ7Y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 10, 2009 at 09:42:34PM +1000, John Marshall wrote: > rwsrv05# procstat 1270 > PID PPID PGID SID TSID THR LOGIN WCHAN EMUL COMM = =20 > 1270 1 1270 1270 0 1 john vmmaps FreeBSD ELF32 ntpd = =20 >=20 > rwsrv05# procstat -k 1270 > PID TID COMM TDNAME KSTACK = =20 > 1270 100184 ntpd - mi_switch sleepq_switch sl= eepq_wait _sleep vm_map_unlock_and_wait vm_map_delete vm_map_fixed vm_mmap = mmap syscall Xint0x80_syscall=20 >=20 > rwsrv05# procstat -v 1270 > PID START END PRT RES PRES REF SHD FL TP PATH > 1270 0x8048000 0x807e000 r-x 54 60 2 1 CN vn /usr/local/bin/nt= pd > 1270 0x807e000 0x8080000 rw- 2 0 1 0 C- vn /usr/local/bin/nt= pd > 1270 0x8080000 0x8100000 rw- 128 0 1 0 C- df=20 > 1270 0x2807e000 0x280ab000 r-x 45 0 170 75 CN vn /libexec/ld-elf.s= o.1 > 1270 0x280ab000 0x280ad000 rw- 2 0 1 0 C- vn /libexec/ld-elf.s= o.1 > 1270 0x280ad000 0x280c0000 rw- 19 0 1 0 C- df=20 > 1270 0x280c0000 0x280d7000 r-x 23 0 1 0 CN vn /lib/libm.so.5 > 1270 0x280d7000 0x280d8000 r-x 1 0 1 0 CN vn /lib/libm.so.5 > 1270 0x280d8000 0x280d9000 rw- 1 0 1 0 C- vn /lib/libm.so.5 > 1270 0x280d9000 0x28211000 r-x 312 0 1 0 CN vn /lib/libcrypto.so= .5 > 1270 0x28211000 0x28212000 r-x 1 0 1 0 CN vn /lib/libcrypto.so= .5 > 1270 0x28212000 0x2822a000 rw- 24 0 1 0 C- vn /lib/libcrypto.so= .5 > 1270 0x2822a000 0x2822c000 rw- 2 0 1 0 C- df=20 > 1270 0x2822c000 0x28232000 r-x 6 0 1 0 CN vn /lib/libkvm.so.4 > 1270 0x28232000 0x28233000 r-x 1 0 1 0 CN vn /lib/libkvm.so.4 > 1270 0x28233000 0x28234000 rw- 1 0 1 0 C- vn /lib/libkvm.so.4 > 1270 0x28234000 0x2824c000 r-x 24 0 1 0 CN vn /usr/lib/libelf.s= o.1 > 1270 0x2824c000 0x2824d000 r-x 1 0 1 0 CN vn /usr/lib/libelf.s= o.1 > 1270 0x2824d000 0x2824e000 rw- 1 0 1 0 C- vn /usr/lib/libelf.s= o.1 > 1270 0x2824e000 0x28251000 r-x 3 0 15 10 CN vn /usr/lib/librt.so= .1 > 1270 0x28251000 0x28252000 r-x 1 0 1 0 CN vn /usr/lib/librt.so= .1 > 1270 0x28252000 0x28253000 rw- 1 0 1 0 C- vn /usr/lib/librt.so= .1 > 1270 0x28253000 0x28260000 r-x 13 0 1 0 CN vn /lib/libmd.so.4 > 1270 0x28260000 0x28261000 r-x 1 0 1 0 CN vn /lib/libmd.so.4 > 1270 0x28261000 0x28262000 rw- 1 0 1 0 C- vn /lib/libmd.so.4 > 1270 0x28262000 0x28351000 r-x 239 0 1 0 CN vn /lib/libc.so.7 > 1270 0x28351000 0x28352000 r-x 1 0 1 0 CN vn /lib/libc.so.7 > 1270 0x28352000 0x28358000 rw- 6 0 1 0 C- vn /lib/libc.so.7 > 1270 0x28358000 0x2836e000 rw- 22 0 1 0 C- df=20 > 1270 0x2836e000 0x2837a000 --- 0 0 0 0 -- --=20 > 1270 0x28400000 0x28500000 rw- 256 0 1 0 C- df=20 > 1270 0xbfbe0000 0xbfc00000 rwx 32 0 1 0 C- df=20 >=20 > rwsrv05# kgdb kernel.debug /dev/mem > 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 conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd"... > #0 sched_switch (td=3D0xc08af410, newtd=3D0xc4d4db40, flags=3D260) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid =3D PCPU_GET(cpuid); > Ready to go. Enter 'tr' to connect to the remote target > with /dev/cuad0, 'tr /dev/cuad1' to connect to a different port > or 'trf portno' to connect to the remote target with the firewire > interface. portno defaults to 5556. >=20 > Type 'getsyms' after connection to load kld symbols. >=20 > If you're debugging a local system, you can use 'kldsyms' instead > to load the kld symbols. That's a less obnoxious interface. > (kgdb) proc 1270 > [Switching to thread 168 (Thread 100184)]#0 sched_switch (td=3D0xc592fd8= 0, newtd=3D0xc4d4db40, flags=3D0x104) > at /usr/src/sys/kern/sched_ule.c:1864 > 1864 cpuid =3D PCPU_GET(cpuid); > (kgdb) bt > #0 sched_switch (td=3D0xc592fd80, newtd=3D0xc4d4db40, flags=3D0x104) at = /usr/src/sys/kern/sched_ule.c:1864 > During symbol reading, Incomplete CFI data; unspecified registers at 0xc0= 6009d6. > #1 0xc05e788f in mi_switch (flags=3D0x104, newtd=3D0x0) at /usr/src/sys/= kern/kern_synch.c:444 > #2 0xc061695c in sleepq_switch (wchan=3D0xc5909f00, pri=3D0x44) at /usr/= src/sys/kern/subr_sleepqueue.c:505 > #3 0xc06175f5 in sleepq_wait (wchan=3D0xc5909f00, pri=3D0x44) at /usr/sr= c/sys/kern/subr_sleepqueue.c:584 > #4 0xc05e7d39 in _sleep (ident=3D0xc5909f00, lock=3D0xc0a26724, priority= =3D0x244, wmesg=3D0xc0837aa0 "vmmaps", timo=3D0x0) > at /usr/src/sys/kern/kern_synch.c:232 > #5 0xc0761a37 in vm_map_unlock_and_wait (map=3D0xc5909e80, timo=3D0x0) a= t /usr/src/sys/vm/vm_map.c:638 > #6 0xc0761ae7 in vm_map_delete (map=3D0xc5909e80, start=3D0x2836e000, en= d=3D0x28374000) at /usr/src/sys/vm/vm_map.c:2703 > #7 0xc07634ce in vm_map_fixed (map=3D0xc5909e80, object=3D0xc5254990, of= fset=3D0x0, start=3D0x2836e000, length=3D0x6000,=20 > prot=3D0x5, max=3D0x7, cow=3D0x112) at /usr/src/sys/vm/vm_map.c:1367 > #8 0xc0765ba8 in vm_mmap (map=3D0xc5909e80, addr=3D0xe787ac70, size=3D0x= 6000, prot=3DVariable "prot" is not available. > ) at /usr/src/sys/vm/vm_mmap.c:1439 > #9 0xc076634f in mmap (td=3D0xc592fd80, uap=3D0xe787acf8) at /usr/src/sy= s/vm/vm_mmap.c:390 > #10 0xc07bb6bf in syscall (frame=3D0xe787ad38) at /usr/src/sys/i386/i386/= trap.c:1073 > #11 0xc07a0150 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception= .s:261 > #12 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) f 6 > #6 0xc0761ae7 in vm_map_delete (map=3D0xc5909e80, start=3D0x2836e000, en= d=3D0x28374000) at /usr/src/sys/vm/vm_map.c:2703 > 2703 (void) vm_map_unlock_and_wait(map, 0); > (kgdb) p *entry > $1 =3D { > prev =3D 0xc5812b40,=20 > next =3D 0xc59ec7e0,=20 > left =3D 0xc5812b40,=20 > right =3D 0xc59ec7e0,=20 > start =3D 0x2836e000,=20 > end =3D 0x2837a000,=20 > avail_ssize =3D 0x0,=20 > adj_free =3D 0x86000,=20 > max_free =3D 0x976e0000,=20 > object =3D { > vm_object =3D 0x0,=20 > sub_map =3D 0x0 > },=20 > offset =3D 0x0,=20 > eflags =3D 0x600,=20 > protection =3D 0x0,=20 > max_protection =3D 0x7,=20 > inheritance =3D 0x1,=20 > wired_count =3D 0xffffffff,=20 > lastr =3D 0x1c,=20 > uip =3D 0x0 > } > (kgdb)=20 Thank you, I see what is going on. Please, try the following patch. diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 7cc2c2d..dc7a490 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -2354,12 +2354,12 @@ vm_map_wire(vm_map_t map, vm_offset_t start, vm_off= set_t end, if (entry->wired_count =3D=3D 0) { if ((entry->protection & (VM_PROT_READ|VM_PROT_EXECUTE)) =3D=3D 0) { + entry->eflags |=3D MAP_ENTRY_WIRE_SKIPPED; if ((flags & VM_MAP_WIRE_HOLESOK) =3D=3D 0) { end =3D entry->end; rv =3D KERN_INVALID_ADDRESS; goto done; } - entry->eflags |=3D MAP_ENTRY_WIRE_SKIPPED; goto next_entry; } entry->wired_count++; --zYtRAvLPyLojxZ7Y Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpXQQwACgkQC3+MBN1Mb4jlqwCg9G6iXuhuwrM7CN8Rqhs5qtsa +K8AoPUFI4GZaH68TylTelb9F3oqG9qw =YnHT -----END PGP SIGNATURE----- --zYtRAvLPyLojxZ7Y-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 13:41:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B24AF106564A; Fri, 10 Jul 2009 13:41:38 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 197B88FC1D; Fri, 10 Jul 2009 13:41:37 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=W4yUWwPuJRMA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=6I5d2MoRAAAA:8 a=CoTBo_Zjxy5KCONG29UA:9 a=w2JCi8v50dWtrkD0lxoA:7 a=SV94tEyFvL4lw_EyKiQKwkPS-NsA:4 a=SV7veod9ZcQA:10 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1106224194; Fri, 10 Jul 2009 15:41:36 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org, freebsd-current@freebsd.org Date: Fri, 10 Jul 2009 15:41:15 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907101541.16698.hselasky@c2i.net> Cc: Alexander Best Subject: Re: detaching usb device without unmounting it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:41:39 -0000 This is not an USB issue. Try -current. --HPS On Friday 10 July 2009 11:05:48 Alexander Best wrote: > since the usb2 stack allows one to detach a mounted usb device without the > kernel panic'ing i'd like to know which steps are necessary to be taken > after detaching a device? because i tried the following: > > 1. attach device > 2. mount device > 3. detach device > > when i tried to unmount the device i got the follwing error message: > > g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 > > and the console got locked up (ctr+c didn't work). so i tried to reboot > using ctrl+alt+del. however after the message: "All buffers synced" there > was no reboot. so i had to do a hard reset. however after the reset freebsd > fsck'ed my harddrives. so they didn't unmount properly. > > should i have used `umount -f`? or just plug the device back in again? or > isn't it possible to unmount a device that has already been detached? > > i'm running r195476 btw. > > alex > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 13:46:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCB1A1065679; Fri, 10 Jul 2009 13:46:26 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3441B8FC26; Fri, 10 Jul 2009 13:46:25 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,378,1243807200"; d="scan'208";a="276859850" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 10 Jul 2009 15:46:24 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5C4111B07E4; Fri, 10 Jul 2009 15:46:24 +0200 (CEST) Date: Fri, 10 Jul 2009 15:46:24 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Hans Petter Selasky , , Message-ID: In-Reply-To: <200907101541.16698.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: detaching usb device without unmounting it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:46:27 -0000 actually i'm running current: FreeBSD otaku 8.0-BETA1 FreeBSD 8.0-BETA1 #0 r195534: Fri Jul 10 11:52:48 CEST 2009 root@otaku:/usr/obj/usr/src/sys/ARUNDEL i386 updated my kernel sources a few hours ago. should i report this to the freebsd-current@ list then? alex Hans Petter Selasky schrieb am 2009-07-10: > This is not an USB issue. > Try -current. > --HPS > On Friday 10 July 2009 11:05:48 Alexander Best wrote: > > since the usb2 stack allows one to detach a mounted usb device > > without the > > kernel panic'ing i'd like to know which steps are necessary to be > > taken > > after detaching a device? because i tried the following: > > 1. attach device > > 2. mount device > > 3. detach device > > when i tried to unmount the device i got the follwing error > > message: > > g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 > > and the console got locked up (ctr+c didn't work). so i tried to > > reboot > > using ctrl+alt+del. however after the message: "All buffers synced" > > there > > was no reboot. so i had to do a hard reset. however after the reset > > freebsd > > fsck'ed my harddrives. so they didn't unmount properly. > > should i have used `umount -f`? or just plug the device back in > > again? or > > isn't it possible to unmount a device that has already been > > detached? > > i'm running r195476 btw. > > alex > > _______________________________________________ > > freebsd-usb@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > > To unsubscribe, send any mail to > > "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 13:46:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5379B106564A; Fri, 10 Jul 2009 13:46:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 158628FC18; Fri, 10 Jul 2009 13:46:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n6ADkSL4047808; Fri, 10 Jul 2009 09:46:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6ADkS9M077776; Fri, 10 Jul 2009 09:46:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B7D027302F; Fri, 10 Jul 2009 09:46:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090710134627.B7D027302F@freebsd-current.sentex.ca> Date: Fri, 10 Jul 2009 09:46:27 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:46:30 -0000 TB --- 2009-07-10 12:22:05 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-10 12:22:05 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-07-10 12:22:05 - cleaning the object tree TB --- 2009-07-10 12:22:51 - cvsupping the source tree TB --- 2009-07-10 12:22:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-07-10 12:23:02 - building world TB --- 2009-07-10 12:23:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-10 12:23:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-10 12:23:02 - TARGET=ia64 TB --- 2009-07-10 12:23:02 - TARGET_ARCH=ia64 TB --- 2009-07-10 12:23:02 - TZ=UTC TB --- 2009-07-10 12:23:02 - __MAKE_CONF=/dev/null TB --- 2009-07-10 12:23:02 - cd /src TB --- 2009-07-10 12:23:02 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 10 12:23:04 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/camcontrol/camcontrol.c /src/sbin/camcontrol/util.c /src/sbin/camcontrol/modeedit.c echo camcontrol: /obj/ia64/src/tmp/usr/lib/libc.a /obj/ia64/src/tmp/usr/lib/libcam.a /obj/ia64/src/tmp/usr/lib/libsbuf.a /obj/ia64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'ataidentify': /src/sbin/camcontrol/camcontrol.c:1195: warning: cast increases required alignment of target type /src/sbin/camcontrol/camcontrol.c:1196: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-10 13:46:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-10 13:46:27 - ERROR: failed to build world TB --- 2009-07-10 13:46:27 - 4063.59 user 327.13 system 5062.35 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 13:48:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1402106566C; Fri, 10 Jul 2009 13:48:02 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 3B9228FC16; Fri, 10 Jul 2009 13:48:02 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,378,1243807200"; d="scan'208";a="276859969" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 10 Jul 2009 15:48:01 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 5555B1B07E4; Fri, 10 Jul 2009 15:48:01 +0200 (CEST) Date: Fri, 10 Jul 2009 15:48:01 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Hans Petter Selasky , , Message-ID: In-Reply-To: <200907101541.16698.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: detaching usb device without unmounting it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 13:48:03 -0000 oh. i just did. ;-) didn't see you put freebsd-current@ in the "To:" field. alex Hans Petter Selasky schrieb am 2009-07-10: > This is not an USB issue. > Try -current. > --HPS > On Friday 10 July 2009 11:05:48 Alexander Best wrote: > > since the usb2 stack allows one to detach a mounted usb device > > without the > > kernel panic'ing i'd like to know which steps are necessary to be > > taken > > after detaching a device? because i tried the following: > > 1. attach device > > 2. mount device > > 3. detach device > > when i tried to unmount the device i got the follwing error > > message: > > g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 > > and the console got locked up (ctr+c didn't work). so i tried to > > reboot > > using ctrl+alt+del. however after the message: "All buffers synced" > > there > > was no reboot. so i had to do a hard reset. however after the reset > > freebsd > > fsck'ed my harddrives. so they didn't unmount properly. > > should i have used `umount -f`? or just plug the device back in > > again? or > > isn't it possible to unmount a device that has already been > > detached? > > i'm running r195476 btw. > > alex > > _______________________________________________ > > freebsd-usb@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > > To unsubscribe, send any mail to > > "freebsd-usb-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 14:02:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ED201065670 for ; Fri, 10 Jul 2009 14:02:26 +0000 (UTC) (envelope-from stringflow@gmail.com) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mx1.freebsd.org (Postfix) with ESMTP id E233E8FC1C for ; Fri, 10 Jul 2009 14:02:25 +0000 (UTC) (envelope-from stringflow@gmail.com) Received: by ewy27 with SMTP id 27so207318ewy.43 for ; Fri, 10 Jul 2009 07:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=sWBKavD2tlIcVZHaFyB/rjeQ3rntca1ixSyhR7BHUrE=; b=Ql2pRrSm+VnoCujDq6cBoXv1P0krD4FWLQeLN5AHZfOrzHHlV5nc8YgwvMjHEwTnz5 6yocmJIVbP9sbUAIHygxUqXLMjVXnR4bwB5yk0WyIoWsGOl1whxa4yGw7Ly1kPj4ET/R xWIJRIAe9NArv9utf/9UI+cvlk+NLX2ak2+o8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xQBv5rIzQvJahfjcxekTIGG5JSlfuI0MOQMM0+BRWPsSimYqgcmHGbAq5rYOWJ8sHd 605vOuUzi5W8zWvVevm74KFqOpega8GhjcDkN4G+4MmOzuqwtdrymJduSV98aLHmmrZz C5ulH0Q+TCbMJpxVqsgHiSiTpB+LhuCsvNVAg= MIME-Version: 1.0 Received: by 10.210.70.14 with SMTP id s14mr1244382eba.38.1247233191205; Fri, 10 Jul 2009 06:39:51 -0700 (PDT) Date: Fri, 10 Jul 2009 21:39:51 +0800 Message-ID: From: kevin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Benjamin.Close@clearchain.com Subject: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 14:02:26 -0000 Hi, I notice iwn's firmware hasn't been updated for a long time.Is there any plan to import newer version iwn firmware ? current version is iwlwifi-4965-ucode-4.44.17 in the source tree, while latest version is iwlwifi-4965-ucode-228.61.2.24. http://www.intellinuxwireless.org/?n=downloads&f=ucodes_4965 Thanks, Kevin From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 14:38:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF0B4106564A; Fri, 10 Jul 2009 14:38:08 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 5607F8FC15; Fri, 10 Jul 2009 14:38:08 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,378,1243807200"; d="scan'208";a="8096947" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 10 Jul 2009 16:38:06 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id CD2751B0764; Fri, 10 Jul 2009 16:38:06 +0200 (CEST) Date: Fri, 10 Jul 2009 16:38:06 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: "M. Warner Losh" Message-ID: In-Reply-To: <20090710.080932.439672019.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: detaching usb device without unmounting it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 14:38:09 -0000 hmmm...i just tried that: 1. attach the device 2. mount the device @ mnt/umass 3. detach the device 4. do `umount -f /mnt/umass` i got the same error message i got when not using the f switch. also i forget to mention this lor: Jul 10 16:26:24 otaku kernel: lock order reversal: Jul 10 16:26:24 otaku kernel: 1st 0xc81569c0 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1199 Jul 10 16:26:24 otaku kernel: 2nd 0xc8dec9c0 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:944 Jul 10 16:26:24 otaku kernel: KDB: stack backtrace: Jul 10 16:26:24 otaku kernel: db_trace_self_wrapper(c07d787b,ea61ca3c,c0609a25,c05fa4db,c07da81e,...) at db_trace_self_wrapper+0x26 Jul 10 16:26:24 otaku kernel: kdb_backtrace(c05fa4db,c07da81e,c78f0bc0,c78f0af0,ea61ca98,...) at kdb_backtrace+0x29 Jul 10 16:26:24 otaku kernel: _witness_debugger(c07da81e,c8dec9c0,c07c9650,c78f0af0,c07c9f08,...) at _witness_debugger+0x25 Jul 10 16:26:24 otaku kernel: witness_checkorder(c8dec9c0,9,c07c9f08,3b0,c8deca28,...) at witness_checkorder+0x839 Jul 10 16:26:24 otaku kernel: __lockmgr_args(c8dec9c0,80400,c8deca28,0,0,...) at __lockmgr_args+0x7b7 Jul 10 16:26:24 otaku kernel: vop_stdlock(ea61cba0,c09abbc8,c8a8ee24,80400,c8dec968,...) at vop_stdlock+0x68 Jul 10 16:26:24 otaku kernel: VOP_LOCK1_APV(c0820980,ea61cba0,ea61cbc0,c0853f80,c8dec968,...) at VOP_LOCK1_APV+0xb5 Jul 10 16:26:24 otaku kernel: _vn_lock(c8dec968,80400,c07c9f08,3b0,c7ea35a0,...) at _vn_lock+0x78 Jul 10 16:26:24 otaku kernel: msdosfs_sync(c7ea35a0,1,ea61cc38,4f4,80,...) at msdosfs_sync+0x29c Jul 10 16:26:24 otaku kernel: dounmount(c7ea35a0,8080000,c8a8ed80,479,1,...) at dounmount+0x44e Jul 10 16:26:24 otaku kernel: unmount(c8a8ed80,ea61ccf8,8,65,c,...) at unmount+0x2bf Jul 10 16:26:24 otaku kernel: syscall(ea61cd38) at syscall+0x2a6 Jul 10 16:26:24 otaku kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 10 16:26:24 otaku kernel: --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d730f, esp = 0xbfbfe4bc, ebp = 0xbfbfe588 --- again i can't get back to the shell using ctrl+c. switching to another console and issuing a reboot stalls at the very same point. alex M. Warner Losh schrieb am 2009-07-10: > In message: > > Alexander Best writes: > : since the usb2 stack allows one to detach a mounted usb device > without the > : kernel panic'ing > usb1 allowed that too. the problem rarely was inside the usb stack > (although there were some problems). The problem was at the higher > levels of cam, the buffer cache and the file system. There were > changes scattered throughout the rest of the system to allow devices > to suddenly disappear. All usb2 did was fix a few edge cases in usb. > : i'd like to know which steps are necessary to be taken after > : detaching a device? because i tried the following: > : > : 1. attach device > : 2. mount device > : 3. detach device > : > : when i tried to unmount the device i got the follwing error > message: > : > : g_vfs_done():label/usb[WRITE(offset=19456, length=4096)]error = 6 > The proper action is limited to 'umount -f'. You can't reattach it, > you can't really touch any files in the system (some cached files > might be ok), you certainly can't write to it. > : and the console got locked up (ctr+c didn't work). so i tried to > reboot using > : ctrl+alt+del. however after the message: "All buffers synced" there > was no > : reboot. so i had to do a hard reset. however after the reset > freebsd fsck'ed > : my harddrives. so they didn't unmount properly. > : > : should i have used `umount -f`? or just plug the device back in > again? or > : isn't it possible to unmount a device that has already been > detached? > You should have done an umount -f. You can't plug it back in again > because we don't have support at the right levels (CAM(?), GEOM, > buffer cache, fs) to allow previously orphaned resources to be > reconnected to a new device. The device was destroyed, and data was > destroyed with it... > Warner From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 14:39:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CABF106568C for ; Fri, 10 Jul 2009 14:39:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2FD8FC24 for ; Fri, 10 Jul 2009 14:39:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by yxe11 with SMTP id 11so1553339yxe.3 for ; Fri, 10 Jul 2009 07:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=srr0sqRu7o9hckQW2xZn7QaKVdc/+uWslNFbgKuUlsg=; b=mKYL+90oaYBPKsenB3usQCYoWkV3Zr2+CdYULu2skcSE2qRN2XKiv7kDqShtWNG9ct sGn9ELYstAdGINWzxjuMDp8pSCfSKQS/FdUcQomNI5hxM4/CKHW4956IpdbthOCSBTlN OiaFNYdvkJhhK5k5Dy2/hNKRFWB/wjMqL6YvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EOqbkVW23mNzUzGFjh4AOrx8iedgYmcPGm9Fm8rZLC/zbmtRv4J8udJcXkzp1Sj2I7 fE/LAG6qtpHlQNLizkB62wMrwq30bMc/8eXfSOhMc5jXBei4pFgRTvuf3PddefcgqnWf tA82kYj6Fkt00R6n1cwGGlrtw4AcbDSGIhOPA= MIME-Version: 1.0 Sender: adrian.chadd@gmail.com Received: by 10.100.13.14 with SMTP id 14mr2792640anm.51.1247236758482; Fri, 10 Jul 2009 07:39:18 -0700 (PDT) In-Reply-To: <4A5733A3.20409@freebsd.org> References: <4A562960.3010801@freebsd.org> <4A5733A3.20409@freebsd.org> Date: Fri, 10 Jul 2009 22:39:18 +0800 X-Google-Sender-Auth: 1d0406cc236a3d8d Message-ID: From: Adrian Chadd To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Brampton , freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 14:39:19 -0000 2009/7/10 Andriy Gapon : >> Another problem with this is that on a multicore machine each core may >> have different TSC values. Has anyone thought how to address this >> issue? Could we calculate the offset of each core from core0, and then >> ensure the offset is applied to the tsc value when it is needed? > > Yes. The actual code accounts for inter-CPU/core TSC skew. Pardon the stupid question, but how does Solaris deal with this? Adrian From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 14:41:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC8761065697 for ; Fri, 10 Jul 2009 14:41:41 +0000 (UTC) (envelope-from stringflow@gmail.com) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mx1.freebsd.org (Postfix) with ESMTP id 5A8F98FC08 for ; Fri, 10 Jul 2009 14:41:41 +0000 (UTC) (envelope-from stringflow@gmail.com) Received: by ewy27 with SMTP id 27so235576ewy.43 for ; Fri, 10 Jul 2009 07:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=tyBC8Az2Cvi5Z6GZqq+r4DATaYBDccWxQKmFBzmKPT4=; b=hG+h4Se/KJNITxAYiGA9FSY+km77SN8F7N4dYsV46ofbkqHsr+DRNFjs7I+AUG7qA+ yv9UKq+Fv54CU68pD8cge9EySyKvm30o3craQjU7Dg7VV/Akrqz+uiFocrI46fnpkgoa 9ADe4STywe5Ofg1Rt3gjxjACRWkq2DbzYRESw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=aBPLsRolDa/VXjtHdEkXi+Q6AF0pLmX9PLJFbQLFZI5dhQ8wQi+r+aWk57wFtlB2Yp fdcImfWbEdxRHRvuAOEWqP9tcWEyPzIEdzAIxrjDU2OHv5VLyWqOoali+Nf7ypnMx22P 84WhOkSitXYFyyHKZeKqaT5MWPYJ9L3089xtE= MIME-Version: 1.0 Received: by 10.210.17.14 with SMTP id 14mr1247944ebq.36.1247236900492; Fri, 10 Jul 2009 07:41:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2009 22:41:40 +0800 Message-ID: From: kevin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Benjamin.Close@clearchain.com Subject: Re: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 14:41:42 -0000 On Fri, Jul 10, 2009 at 9:39 PM, kevin wrote: > Hi, > I notice iwn's firmware hasn't been updated for a long time.Is there any > plan to import newer version iwn firmware ? current version is > iwlwifi-4965-ucode-4.44.17 in the source tree, while latest version is > iwlwifi-4965-ucode-228.61.2.24. > > http://www.intellinuxwireless.org/?n=downloads&f=ucodes_4965 > > > > > > Thanks, > Kevin > > well i test the firmware, I find iwlwifi-4965-ucode-4.44.1.20 works well ,but iwlwifi-4965-ucode-228.61.2.24 does not. iwlwifi-4965-ucode-4.44.1.* seems does not compatible with iwlwifi-4965-ucode-228.61.2.* . Sorry for reply myself. Thanks, Kevin From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 14:42:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EBF810656D2; Fri, 10 Jul 2009 14:42:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2C1668FC1F; Fri, 10 Jul 2009 14:42:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6AEg4Mr059393; Fri, 10 Jul 2009 10:42:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6AEg4x6025992; Fri, 10 Jul 2009 10:42:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1E4C17302F; Fri, 10 Jul 2009 10:42:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090710144204.1E4C17302F@freebsd-current.sentex.ca> Date: Fri, 10 Jul 2009 10:42:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 14:42:08 -0000 TB --- 2009-07-10 13:46:27 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-10 13:46:27 - starting HEAD tinderbox run for mips/mips TB --- 2009-07-10 13:46:27 - cleaning the object tree TB --- 2009-07-10 13:46:48 - cvsupping the source tree TB --- 2009-07-10 13:46:48 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-07-10 13:46:57 - building world TB --- 2009-07-10 13:46:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-10 13:46:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-10 13:46:57 - TARGET=mips TB --- 2009-07-10 13:46:57 - TARGET_ARCH=mips TB --- 2009-07-10 13:46:57 - TZ=UTC TB --- 2009-07-10 13:46:57 - __MAKE_CONF=/dev/null TB --- 2009-07-10 13:46:57 - cd /src TB --- 2009-07-10 13:46:57 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 10 13:46:58 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wl,-EL -o bsdlabel bsdlabel.o geom_bsd_enc.o -lgeom -lbsdxml -lsbuf gzip -cn /src/sbin/bsdlabel/bsdlabel.8 > bsdlabel.8.gz ===> sbin/camcontrol (all) cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'ataidentify': /src/sbin/camcontrol/camcontrol.c:1195: warning: cast increases required alignment of target type /src/sbin/camcontrol/camcontrol.c:1196: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /src/sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-10 14:42:03 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-10 14:42:03 - ERROR: failed to build world TB --- 2009-07-10 14:42:03 - 2566.90 user 306.38 system 3336.03 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 15:40:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8932E106564A for ; Fri, 10 Jul 2009 15:40:53 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5AD0F8FC0A for ; Fri, 10 Jul 2009 15:40:51 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA07149; Fri, 10 Jul 2009 18:40:50 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A576101.7050905@freebsd.org> Date: Fri, 10 Jul 2009 18:40:49 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Adrian Chadd References: <4A562960.3010801@freebsd.org> <4A5733A3.20409@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Brampton , freebsd-current@freebsd.org Subject: Re: dtrace users opinion solicited (timestamps) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:40:53 -0000 on 10/07/2009 17:39 Adrian Chadd said the following: > 2009/7/10 Andriy Gapon : >>> Another problem with this is that on a multicore machine each core may >>> have different TSC values. Has anyone thought how to address this >>> issue? Could we calculate the offset of each core from core0, and then >>> ensure the offset is applied to the tsc value when it is needed? >> Yes. The actual code accounts for inter-CPU/core TSC skew. > > Pardon the stupid question, but how does Solaris deal with this? Not sure what exactly is 'this' in your question. If you mean the whole issue of TSC frequency changing, then my impression from looking at the following file is that they do it very simple - they don't. http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/i86pc/os/timestamp.c I.e. they always use the same frequency for tick->nsec conversion as was passed to tsc_hrtimeinit. Honestly, I was a little bit surprised by this, I expected to find some machinery to catch frequency changes and to track time and tick of the last change. After some googling it seems that they disable any power management that may affect TSC frequency if CPU doesn't have invariant TSC capability. E.g.: http://opensolaris.org/jive/thread.jspa?messageID=389358 http://archive.netbsd.se/?ml=opensolaris-discuss&a=2008-05&t=7477884 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 15:42:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16B76106567F for ; Fri, 10 Jul 2009 15:42:51 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout024.mac.com (asmtpout024.mac.com [17.148.16.99]) by mx1.freebsd.org (Postfix) with ESMTP id F25AF8FC21 for ; Fri, 10 Jul 2009 15:42:50 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp024.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMK00BVEOZC4780@asmtp024.mac.com> for freebsd-current@freebsd.org; Fri, 10 Jul 2009 08:42:50 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> Date: Fri, 10 Jul 2009 08:42:48 -0700 Message-id: <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> To: "Paul B. Mahol" , John Marshall X-Mailer: Apple Mail (2.1068) Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:42:51 -0000 On Jul 10, 2009, at 4:33 AM, Paul B. Mahol wrote: >>>>> Today I had a nasty surprise when I fired up bsdlabel to >>>>> increase the >>>>> size of a swap partition. I booted the system off the 7.2-RELEASE >>>>> live >>>>> filesystem CD and its bsdlabel displayed "normal" labels. I >>>>> used the >>>>> bsdlabel off the 7.2 livefs CD to edit the label. *snip* > There is one not so trivial solution. Recreating labels with gpart(8) Well, as stated, a bsdlabel from 7.2-RELEASE does not complain. Let's not yet assume the disk label is broken and instead look at the tool. John: Can you send me the output of "gpart show da0" and "gpart show da0s1". Could you also send me (or make available for download) a binary dump of sectors 0 (the MBR), 63 and 64 (the disklabel in slice 1). If it's the tool, I'll see about fixing it... Thanks, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 15:49:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87A5E1065673; Fri, 10 Jul 2009 15:49:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 49EF18FC1A; Fri, 10 Jul 2009 15:49:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6AFmwDM071815; Fri, 10 Jul 2009 11:48:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n6AFmwFQ018657; Fri, 10 Jul 2009 11:48:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 75DF97302F; Fri, 10 Jul 2009 11:48:58 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090710154858.75DF97302F@freebsd-current.sentex.ca> Date: Fri, 10 Jul 2009 11:48:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 15:49:02 -0000 TB --- 2009-07-10 14:42:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-10 14:42:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-07-10 14:42:04 - cleaning the object tree TB --- 2009-07-10 14:42:53 - cvsupping the source tree TB --- 2009-07-10 14:42:53 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-07-10 14:43:05 - building world TB --- 2009-07-10 14:43:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-10 14:43:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-10 14:43:05 - TARGET=sparc64 TB --- 2009-07-10 14:43:05 - TARGET_ARCH=sparc64 TB --- 2009-07-10 14:43:05 - TZ=UTC TB --- 2009-07-10 14:43:05 - __MAKE_CONF=/dev/null TB --- 2009-07-10 14:43:05 - cd /src TB --- 2009-07-10 14:43:05 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 10 14:43:07 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/camcontrol/camcontrol.c /src/sbin/camcontrol/util.c /src/sbin/camcontrol/modeedit.c echo camcontrol: /obj/sparc64/src/tmp/usr/lib/libc.a /obj/sparc64/src/tmp/usr/lib/libcam.a /obj/sparc64/src/tmp/usr/lib/libsbuf.a /obj/sparc64/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'ataidentify': /src/sbin/camcontrol/camcontrol.c:1195: warning: cast increases required alignment of target type /src/sbin/camcontrol/camcontrol.c:1196: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-10 15:48:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-10 15:48:58 - ERROR: failed to build world TB --- 2009-07-10 15:48:58 - 3068.37 user 314.34 system 4014.02 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 16:18:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2930D1065670 for ; Fri, 10 Jul 2009 16:18:41 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C81178FC0A for ; Fri, 10 Jul 2009 16:18:40 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=kvzwvKvJI1+uclAAqnmJWDMFXWXXUj+9u9mJaz1/R2nKpxbd39Y97qMCXWGjAKhPE5mmhMS74KxHPCyUG6q9mjVdhmxgPJ+6jCdmIzS4e/HM2RfBH3NfP+90acNZt8dMD/oyDadTszjm7N0DTleG04i9xhjr+6Ps4dcyXZxap6w=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPInz-000NVC-KP; Fri, 10 Jul 2009 20:18:35 +0400 Date: Fri, 10 Jul 2009 20:18:33 +0400 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> Sender: rea-fbsd@codelabs.ru Cc: John Marshall , freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:18:41 -0000 Marcel, good day. Fri, Jul 10, 2009 at 08:42:48AM -0700, Marcel Moolenaar wrote: > On Jul 10, 2009, at 4:33 AM, Paul B. Mahol wrote: > > >>>>> Today I had a nasty surprise when I fired up bsdlabel to > >>>>> increase the > >>>>> size of a swap partition. I booted the system off the 7.2-RELEASE > >>>>> live > >>>>> filesystem CD and its bsdlabel displayed "normal" labels. I > >>>>> used the > >>>>> bsdlabel off the 7.2 livefs CD to edit the label. > > *snip* > > > There is one not so trivial solution. Recreating labels with gpart(8) > > Well, as stated, a bsdlabel from 7.2-RELEASE does not complain. > Let's not yet assume the disk label is broken and instead look > at the tool. > > John: > Can you send me the output of "gpart show da0" and "gpart show da0s1". > Could you also send me (or make available for download) a binary dump > of sectors 0 (the MBR), 63 and 64 (the disklabel in slice 1). > > If it's the tool, I'll see about fixing it... For me, it seem to be the kernel who messes up the stuff. What I see in the "BSD" geom class are two entities, ad4s2a (!) and ufsid/47cc[...] (?!), as seen by the 'sysctl -b kern.geom.confxml'. Everything starts fine -- ad4s2 and ad4s3 are attached and create 6 providers each inside g_bsd_taste. But then ad4s2a creates another 6 providers inside g_bsd_taste and they are named ad4s2a{a,b,c,d,e,f} and I also have devices ufsid/47cc[...]{a,b,c,d,e,f}. Normal devices (ad4s2{a-f}) are here too, so mount works. But since ad4s2 isn't in a BSD class, bsdlabel is unable to determine the mbroffset and produces offsets from the beginning of a disk, without MBR offset fixup. Seems like the main devices are disappearing from the BSD class, thus allowing their children who sit on the offset 0 from the parent to attach as BSD disklabel parts. Need to add some more debugging printfs to the kernel and to glance over the code for some more time to get the idea on what's going on ;)) By the way, John, the output from the 'sysctl -b kern.geom.confxml' will be helpful too. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 16:33:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B81A3106566C for ; Fri, 10 Jul 2009 16:33:18 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout026.mac.com (asmtpout026.mac.com [17.148.16.101]) by mx1.freebsd.org (Postfix) with ESMTP id 9E29B8FC0C for ; Fri, 10 Jul 2009 16:33:18 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp026.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMK00DQ2RBA5J20@asmtp026.mac.com> for freebsd-current@freebsd.org; Fri, 10 Jul 2009 09:33:14 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> Date: Fri, 10 Jul 2009 09:33:10 -0700 Message-id: <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> To: rea-fbsd@codelabs.ru X-Mailer: Apple Mail (2.1068) Cc: John Marshall , freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:33:19 -0000 On Jul 10, 2009, at 9:18 AM, Eygene Ryabinkin wrote: > Everything starts fine -- ad4s2 and ad4s3 are attached and create 6 > providers each inside g_bsd_taste. Please don't use GEOM_BSD. It's obsolete. I haven't removed the code out of conservatism, but consider it dead and gone. As a special warning: you should not have both GEOM_PART_BSD and GEOM_BSD. My gut feeling tells me that you have both and that's why you have the mess you're having. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 16:49:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68705106566B; Fri, 10 Jul 2009 16:49:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2582A8FC13; Fri, 10 Jul 2009 16:49:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6AGnkHB079504; Fri, 10 Jul 2009 12:49:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6AGnkLX031690; Fri, 10 Jul 2009 12:49:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 728B27302F; Fri, 10 Jul 2009 12:49:46 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090710164946.728B27302F@freebsd-current.sentex.ca> Date: Fri, 10 Jul 2009 12:49:46 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp1.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:49:50 -0000 TB --- 2009-07-10 15:48:58 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-10 15:48:58 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-07-10 15:48:58 - cleaning the object tree TB --- 2009-07-10 15:49:29 - cvsupping the source tree TB --- 2009-07-10 15:49:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-07-10 15:49:39 - building world TB --- 2009-07-10 15:49:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-10 15:49:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-10 15:49:39 - TARGET=sun4v TB --- 2009-07-10 15:49:39 - TARGET_ARCH=sparc64 TB --- 2009-07-10 15:49:39 - TZ=UTC TB --- 2009-07-10 15:49:39 - __MAKE_CONF=/dev/null TB --- 2009-07-10 15:49:39 - cd /src TB --- 2009-07-10 15:49:39 - /usr/bin/make -B buildworld >>> World build started on Fri Jul 10 15:49:40 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/camcontrol/camcontrol.c /src/sbin/camcontrol/util.c /src/sbin/camcontrol/modeedit.c echo camcontrol: /obj/sun4v/src/tmp/usr/lib/libc.a /obj/sun4v/src/tmp/usr/lib/libcam.a /obj/sun4v/src/tmp/usr/lib/libsbuf.a /obj/sun4v/src/tmp/usr/lib/libutil.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'ataidentify': /src/sbin/camcontrol/camcontrol.c:1195: warning: cast increases required alignment of target type /src/sbin/camcontrol/camcontrol.c:1196: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /obj/sun4v/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-10 16:49:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-10 16:49:46 - ERROR: failed to build world TB --- 2009-07-10 16:49:46 - 3053.54 user 311.44 system 3647.67 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 16:55:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 403F9106564A for ; Fri, 10 Jul 2009 16:55:05 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id DFD598FC24 for ; Fri, 10 Jul 2009 16:55:04 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=Ojwjk5OHNj21rxqQ+hFvhyLPM0ADYMMmPlmqivB78gInxYIGsNqelglsVa7IrXo7DxnoU/XGOByZahEbNhuqD1zNyB/RQqrGTJpBrGoicHaG0+/DJVasUok1MlW5+TSKlCzmxjrYSqgDj0XB+AgGqvdU2uMqJLSi9wm5aPel1Sk=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPJNH-0001dY-Rf; Fri, 10 Jul 2009 20:55:03 +0400 Date: Fri, 10 Jul 2009 20:55:01 +0400 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, John Marshall Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:55:05 -0000 Fri, Jul 10, 2009 at 09:33:10AM -0700, Marcel Moolenaar wrote: > > On Jul 10, 2009, at 9:18 AM, Eygene Ryabinkin wrote: > > > Everything starts fine -- ad4s2 and ad4s3 are attached and create 6 > > providers each inside g_bsd_taste. > > Please don't use GEOM_BSD. It's obsolete. I haven't removed > the code out of conservatism, but consider it dead and gone. I had used it (you guessed right) because only it provides the "read mbroffset" verb. At least I hadn't found another class that gives it. And bsdlabel wants this offset. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 17:15:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7365C106566B for ; Fri, 10 Jul 2009 17:15:44 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout029.mac.com (asmtpout029.mac.com [17.148.16.104]) by mx1.freebsd.org (Postfix) with ESMTP id 588928FC14 for ; Fri, 10 Jul 2009 17:15:44 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp029.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMK004XHT9TW160@asmtp029.mac.com> for freebsd-current@freebsd.org; Fri, 10 Jul 2009 10:15:30 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Fri, 10 Jul 2009 10:15:27 -0700 Message-id: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> To: rea-fbsd@codelabs.ru X-Mailer: Apple Mail (2.1068) Cc: freebsd-current@freebsd.org, John Marshall Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:15:44 -0000 On Jul 10, 2009, at 9:55 AM, Eygene Ryabinkin wrote: > Fri, Jul 10, 2009 at 09:33:10AM -0700, Marcel Moolenaar wrote: >> >> On Jul 10, 2009, at 9:18 AM, Eygene Ryabinkin wrote: >> >>> Everything starts fine -- ad4s2 and ad4s3 are attached and create 6 >>> providers each inside g_bsd_taste. >> >> Please don't use GEOM_BSD. It's obsolete. I haven't removed >> the code out of conservatism, but consider it dead and gone. > > I had used it (you guessed right) because only it provides > the "read mbroffset" verb. At least I hadn't found another > class that gives it. And bsdlabel wants this offset. There is no need for the verb. bsdlabel should use the same logic the kernel is using: if the C partition has a non-zero offset, then the label is absolute and you can subtract that offset from all partitions to make the label relative. The verb is badly named BTTW, because it's (as usual) biased towards PCs and assumes that the BSD label is nested underneath an MBR if it's nested. In fact, the mbroffset verb is implememented in terms of 2 attributes: MBR::offset and PC98::offset. This to compensate for the PC bias. However, it's still broken: try putting a BSD disklabel inside a GPT partition and see what bsdlabel(8) says then... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 17:18:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F7181065672 for ; Fri, 10 Jul 2009 17:18:47 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 211CC8FC13 for ; Fri, 10 Jul 2009 17:18:47 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n6AHIkf9042411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 10:18:46 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A5777F6.5040700@freebsd.org> Date: Fri, 10 Jul 2009 10:18:46 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090705) MIME-Version: 1.0 To: kevin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:18:47 -0000 kevin wrote: > Hi, > I notice iwn's firmware hasn't been updated for a long time.Is there any > plan to import newer version iwn firmware ? current version is > iwlwifi-4965-ucode-4.44.17 in the source tree, while latest version is > iwlwifi-4965-ucode-228.61.2.24. > > http://www.intellinuxwireless.org/?n=downloads&f=ucodes_4965 > Not sure why you want newer firmware. If it's for newer chip support then that requires driver changes and is non-trivial. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 17:26:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D09106564A; Fri, 10 Jul 2009 17:26:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id E832A8FC16; Fri, 10 Jul 2009 17:26:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by yxe11 with SMTP id 11so1732484yxe.3 for ; Fri, 10 Jul 2009 10:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WY+qwd+UNXudxVYPE0OSh3uKjAKFjPy+MvazvPCGy+M=; b=Q/JfMUQXpVjWIMuQzPD2QvwdPTv6sxlaEdBWpJG2KD8NixldvI982CW7mzLxxPYy0B +vLCjF6LHdWv5X3Lbxl4SPKvCldyLJqIxN2jukIOAjhqlXkVqVmEWGhUrxSFjpj6qEeW SjQ4mz1u1UtiBg1suoSiil2Fxy3aG4lWZAeHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fkG2bQ7jU6EuiXVdZN2KC7MKC83BT+sxuMBbFEGlOnyamt8cePMpft8bXH5GvLFrIW DcV/81Ao+VMT7wUOPikevO/6H5UxBaEGQiLGw9cdUR182UNO9uiJRX/te1lx5gIDfonR 70U6/K0wRtm1W3Hj2mo3tYST8V5SrIVVpqTqM= MIME-Version: 1.0 Received: by 10.100.142.19 with SMTP id p19mr3016538and.13.1247246796319; Fri, 10 Jul 2009 10:26:36 -0700 (PDT) In-Reply-To: <58c737d70907100058u263ab795g442c62d67ba2345f@mail.gmail.com> References: <58c737d70907082058s4e97223fuc0bdbdfaabc3a0a5@mail.gmail.com> <20090709153940.4544bfa8.stas@FreeBSD.org> <58c737d70907091052g7a6f962jf87e94974f7e46aa@mail.gmail.com> <2a41acea0907091135j12f4c0efn963859f8def1d9cd@mail.gmail.com> <2a41acea0907091713v6291f7dbt33b61c10ee7db893@mail.gmail.com> <58c737d70907100058u263ab795g442c62d67ba2345f@mail.gmail.com> Date: Fri, 10 Jul 2009 10:26:36 -0700 Message-ID: <2a41acea0907101026j65c16017kfb57cbd77c72577c@mail.gmail.com> From: Jack Vogel To: Chris Ruiz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Stanislav Sedov , freebsd-current@freebsd.org Subject: Re: no em0 with r195477 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:26:37 -0000 Good news, we have repro'd the failure this morning, so I am looking into it and hope to have a resolution soon. Jack On Fri, Jul 10, 2009 at 12:58 AM, Chris Ruiz wrote: > On Thu, Jul 9, 2009 at 7:13 PM, Jack Vogel wrote: > > I have tried to reproduce this and cannot, can you tell me more detail= s > > about > > this hardware, is it off-the-shelf or something non-production, etc etc= . > > > > Did an install of a stock ICH9 system with this NIC, and have seen no > > such checksum failure, everything works fine :( > > I've never had any problems with my network controller before now > (driver version 6.9.9 works) so this is indeed strange. This is an > Intel=AE Desktop Board DQ35JO (1), so the nic is built in. This is off > the shelf two year old equipment used for a home server, nothing > spectacular. > > Thanks, > > Chris > > (1) http://www.intel.com/support/motherboards/desktop/dq35jo/ > From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 17:49:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA72D106564A; Fri, 10 Jul 2009 17:49:36 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6870E8FC18; Fri, 10 Jul 2009 17:49:36 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: by vwj2 with SMTP id 2so864660vwj.3 for ; Fri, 10 Jul 2009 10:49:35 -0700 (PDT) MIME-Version: 1.0 Sender: andy@fud.org.nz Received: by 10.220.46.20 with SMTP id h20mr3236576vcf.78.1247246401210; Fri, 10 Jul 2009 10:20:01 -0700 (PDT) Date: Fri, 10 Jul 2009 10:20:01 -0700 X-Google-Sender-Auth: 2365364d915e1af8 Message-ID: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> From: Andrew Thompson To: usb@freebsd.org, current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: USB polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 17:49:37 -0000 Hi, The one usb task that is still an issue for 8.0 is the polling support. The code needs to call into the host controller driver to check if the usb descriptor has been marked as done and call the completion callback. I am now traveling so cant look at it, if anyone wants to have a look it would be fantastic. This is needed for places where a usb keyboard is used and interrupts are disabled (root mount, DDB). regards, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 18:03:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EEA8106564A for ; Fri, 10 Jul 2009 18:03:57 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id DB44C8FC12 for ; Fri, 10 Jul 2009 18:03:56 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n6AI3qW1009225 for ; Fri, 10 Jul 2009 20:03:52 +0200 Received: from ubm.mine.nu ([85.181.46.239] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 10 Jul 2009 20:03:52 +0200 Date: Fri, 10 Jul 2009 20:03:52 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090710200352.72ef6804.ubm@u-boot-man.de> In-Reply-To: <20090708225048.ec9d9cad.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 10 Jul 2009 18:14:25 +0000 Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:03:57 -0000 On Wed, 8 Jul 2009 22:50:48 +0200 Marc "UBM" Bocklet wrote: > On Wed, 8 Jul 2009 19:26:42 +0200 > Marc "UBM" Bocklet wrote: > > > > > Hiho! :-) > > > > I just put a Highpoint RocketRaid 2322 in our file server. There are > > no drives connected to it yet. > > > > I'm running: > > > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 > > 15:23:12 CEST 2009 > > > > Since I put the 2322 in, the machine hangs late in the boot process > > with above message. It continues to wait until: > > > > run interrupt driven hooks: still waiting for xpt_config (300 > > seconds) and then theres nothing. No panic, keyboard still works, I > > can still scroll through dmesg, but nothing more. > > > > Before it the hptrr(4) attaches, there's the following message: > > > > xpt_dev async called. > > > > I searched the archives and found some references to firewire, but > > the machine in question has no firewire controller. > > > > Is there anything else I can do to debug this? > > > > For the record, the card is PCIe 4x, but I put it in the PCIe 16x > > slot. The card seems to work fine though, I can access its BIOS and > > its recognized by the FreeBSD driver. > > > > I'm also running with the new ahci driver. > > for the record: verbose boot shows no additional info. further info: removing the highpoint controller makes the problem disappear. Is there any additional info I should/can provide? Bye Marc From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 18:15:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6C5106568E for ; Fri, 10 Jul 2009 18:15:25 +0000 (UTC) (envelope-from stringflow@gmail.com) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6D63F8FC15 for ; Fri, 10 Jul 2009 18:15:24 +0000 (UTC) (envelope-from stringflow@gmail.com) Received: by ewy27 with SMTP id 27so374076ewy.43 for ; Fri, 10 Jul 2009 11:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TNS80TMrwvvmIbj2dr6xIJtjYgW+d/q3RAgGWLvjMWE=; b=Wbj+dHqbetJJnCMPwvLdpezJTF+/Klo5Vomk3tC1gHreibO5OixMzFPos6r19Y7KIU NdOGA1fCJh50pe3TIfSuSqYprMWf2IcVJfGohMjusb/wjeJAhfPYg4hD4haYG+AJcBMa 9C0jadjNBZ/wQuY+v0M2NaCkKUaxgqIUiiLTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fZf71IDqB0eIOMDRbAWnwAj9MrEpIOj9ljqVmfu1o4vA6s4ioVa048e7TkNkWKlTth 3H7wys3JZrBeN+JkOC6ekCOa+iJ2qOB/j6Gj7hd5GPicXgih7Wxc/WI1L2aZzSWEwAjA wDiWSgrgDyZH1kaRwCveuNqphnkAz23OiMC/A= MIME-Version: 1.0 Received: by 10.210.43.11 with SMTP id q11mr1573082ebq.15.1247249722581; Fri, 10 Jul 2009 11:15:22 -0700 (PDT) In-Reply-To: <4A5777F6.5040700@freebsd.org> References: <4A5777F6.5040700@freebsd.org> Date: Sat, 11 Jul 2009 02:15:22 +0800 Message-ID: From: kevin To: Sam Leffler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:15:25 -0000 On Sat, Jul 11, 2009 at 1:18 AM, Sam Leffler wrote: > kevin wrote: > >> Hi, >> I notice iwn's firmware hasn't been updated for a long time.Is there any >> plan to import newer version iwn firmware ? current version is >> iwlwifi-4965-ucode-4.44.17 in the source tree, while latest version is >> iwlwifi-4965-ucode-228.61.2.24. >> >> http://www.intellinuxwireless.org/?n=downloads&f=ucodes_4965 >> >> > Not sure why you want newer firmware. If it's for newer chip support then > that requires driver changes and is non-trivial. > > Sam > > iwn driver works well when system up.but it is not so robust.it will stop transfer data and throw some errors in these conditions: 1 . mount nfs via wireless network,if i transfer a lot of data.it may stop receiving data after some time. 2 . wireless network is busy, then some one reboot the wireless AP.it may throw some errors and stop working. 3 . Find wireless network works slow and switch to Ethernet,.if try /etc/rc.d/netif restart, it may throw some errors and stop working. all these are fixed by reboot system(reload iwn and iwnfw dose not work at most time). i also find iwn driver printe a lot of microcode error related messages when it failed(not easy to reproduce it). No official Change Log, i just notice the *description *in gentoo bug#202818. Thanks, Kevin From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 18:27:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3526106566C for ; Fri, 10 Jul 2009 18:27:19 +0000 (UTC) (envelope-from beat@chruetertee.ch) Received: from marvin.chruetertee.ch (marvin.chruetertee.ch [217.150.245.55]) by mx1.freebsd.org (Postfix) with ESMTP id 5CF338FC13 for ; Fri, 10 Jul 2009 18:27:19 +0000 (UTC) (envelope-from beat@chruetertee.ch) Received: from daedalus.network.local (249-166.3-85.cust.bluewin.ch [85.3.166.249]) (authenticated bits=0) by marvin.chruetertee.ch (8.14.3/8.14.3) with ESMTP id n6AIAuMd037670 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 10 Jul 2009 18:10:57 GMT (envelope-from beat@chruetertee.ch) Message-ID: <4A578470.8080600@chruetertee.ch> Date: Fri, 10 Jul 2009 20:12:00 +0200 From: =?ISO-8859-1?Q?Beat_G=E4tzi?= User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 10 Jul 2009 18:45:01 +0000 Subject: tmpfs panic: wrong vnode type 0xffffff008547ab10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:27:19 -0000 Hi, I tried to run my tinderbox with the build directory on tmpfs but the system panics with wrong vnode type 0xffffff008547ab10. This panic is reproducible when mounting the build directory with tmpfs and trying to build a port like gcc or openoffice with tinderbox. System was updated today: FreeBSD tindi.chruetertee.ch 8.0-BETA1 FreeBSD 8.0-BETA1 #1: Fri Jul 10 09:35:41 CEST 2009 root@tindi.chruetertee.ch:/usr/obj/usr/src/sys/GENERIC amd64 I know tmpfs is still experimental but maybe someone would like to have a look at this panic. crashinfo is available here: http://tmp.chruetertee.ch/core.txt.1 Thanks, Beat Backtrace: (kgdb) bt #0 doadump () at pcpu.h:223 #1 0xffffffff80577043 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff805774cc in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff801d1c17 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801d20c1 in db_command (last_cmdp=0xffffffff80bcfaa0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801d2310 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801d42b9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff805a6d85 in kdb_trap (type=3, code=0, tf=0xffffff80ed19d0e0) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff8084eaf1 in trap (frame=0xffffff80ed19d0e0) at /usr/src/sys/amd64/amd64/trap.c:613 #9 0xffffffff80834993 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #10 0xffffffff805a6f5d in kdb_enter (why=0xffffffff809454c9 "panic", msg=0xa
) at cpufunc.h:63 #11 0xffffffff805774db in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #12 0xffffffff805f4742 in cache_enter (dvp=0xffffff0085086938, vp=0xffffff008547ab10, cnp=0xffffff80ed19d918) at /usr/src/sys/kern/vfs_cache.c:703 #13 0xffffffff81226255 in tmpfs_lookup (v=Variable "v" is not available. ) at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vnops.c:181 #14 0xffffffff805f59a0 in vfs_cache_lookup (ap=Variable "ap" is not available. ) at vnode_if.h:80 #15 0xffffffff80897775 in VOP_LOOKUP_APV (vop=0xffffffff8122c080, a=0xffffff80ed19d450) at vnode_if.c:123 #16 0xffffffff805fc57d in lookup (ndp=0xffffff80ed19d8c0) at vnode_if.h:54 #17 0xffffffff805fd537 in namei (ndp=0xffffff80ed19d8c0) at /usr/src/sys/kern/vfs_lookup.c:259 #18 0xffffffff80613d33 in vn_open_cred (ndp=0xffffff80ed19d8c0, flagp=0xffffff80ed19d9c8, cmode=0, vn_open_flags=Variable "vn_open_flags" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:188 #19 0xffffffff805f844f in vop_stdvptocnp (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:727 #20 0xffffffff805f492e in vn_vptocnp_locked (vp=0xffffff80ed19dab0, cred=0xffffff000498e600, buf=0xffffff0002a30000 "ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­Þ"..., buflen=0xffffff80ed19daac) at vnode_if.h:1544 #21 0xffffffff805f4bae in vn_fullpath1 (td=0xffffff0004d0c720, vp=0xffffff0085086938, rdir=0xffffff00042efce8, buf=0xffffff0002a30000 "ÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­ÞÞÀ­Þ"..., retbuf=0xffffff80ed19db10, buflen=1023) at /usr/src/sys/kern/vfs_cache.c:1172 #22 0xffffffff805f4f84 in kern___getcwd (td=0xffffff0004d0c720, buf=0x7fffffffe350
, bufseg=UIO_USERSPACE, buflen=1024) at /usr/src/sys/kern/vfs_cache.c:937 #23 0xffffffff8084e4af in syscall (frame=0xffffff80ed19dc80) at /usr/src/sys/amd64/amd64/trap.c:984 #24 0xffffffff80834c71 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 #25 0x0000000800935cac in ?? () From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 18:50:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A98A106568C for ; Fri, 10 Jul 2009 18:50:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id D6BAA8FC25 for ; Fri, 10 Jul 2009 18:50:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 941A641C67E; Fri, 10 Jul 2009 20:50:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id qb-sT08B11pf; Fri, 10 Jul 2009 20:50:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 76ABB41C62F; Fri, 10 Jul 2009 20:50:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id A47764448E6; Fri, 10 Jul 2009 18:48:56 +0000 (UTC) Date: Fri, 10 Jul 2009 18:48:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Marc UBM Bocklet In-Reply-To: <20090710200352.72ef6804.ubm@u-boot-man.de> Message-ID: <20090710184743.Q245@maildrop.int.zabbadoz.net> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:50:09 -0000 On Fri, 10 Jul 2009, Marc UBM Bocklet wrote: > On Wed, 8 Jul 2009 22:50:48 +0200 > Marc "UBM" Bocklet wrote: > >> On Wed, 8 Jul 2009 19:26:42 +0200 >> Marc "UBM" Bocklet wrote: >> >>> >>> Hiho! :-) >>> >>> I just put a Highpoint RocketRaid 2322 in our file server. There are >>> no drives connected to it yet. >>> >>> I'm running: >>> >>> FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 >>> 15:23:12 CEST 2009 >>> >>> Since I put the 2322 in, the machine hangs late in the boot process >>> with above message. It continues to wait until: >>> >>> run interrupt driven hooks: still waiting for xpt_config (300 >>> seconds) and then theres nothing. No panic, keyboard still works, I >>> can still scroll through dmesg, but nothing more. >>> >>> Before it the hptrr(4) attaches, there's the following message: >>> >>> xpt_dev async called. >>> >>> I searched the archives and found some references to firewire, but >>> the machine in question has no firewire controller. >>> >>> Is there anything else I can do to debug this? >>> >>> For the record, the card is PCIe 4x, but I put it in the PCIe 16x >>> slot. The card seems to work fine though, I can access its BIOS and >>> its recognized by the FreeBSD driver. >>> >>> I'm also running with the new ahci driver. >> >> for the record: verbose boot shows no additional info. > > further info: removing the highpoint controller makes the problem > disappear. > > Is there any additional info I should/can provide? hmm I have see similar symptoms with aacp when booting from CD (that I told a few people about privately). I have some logs and will try to produce more Monday morning. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 18:55:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EF541065670 for ; Fri, 10 Jul 2009 18:55:18 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 27B888FC13 for ; Fri, 10 Jul 2009 18:55:17 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n6AItGGc042972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jul 2009 11:55:16 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A578E94.5010303@freebsd.org> Date: Fri, 10 Jul 2009 11:55:16 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090705) MIME-Version: 1.0 To: kevin References: <4A5777F6.5040700@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:55:18 -0000 kevin wrote: > > > On Sat, Jul 11, 2009 at 1:18 AM, Sam Leffler > wrote: > > kevin wrote: > > Hi, > I notice iwn's firmware hasn't been updated for a long > time.Is there any > plan to import newer version iwn firmware ? current version is > iwlwifi-4965-ucode-4.44.17 in the source tree, while latest > version is > iwlwifi-4965-ucode-228.61.2.24. > > http://www.intellinuxwireless.org/?n=downloads&f=ucodes_4965 > > > > Not sure why you want newer firmware. If it's for newer chip > support then that requires driver changes and is non-trivial. > > Sam > > iwn driver works well when system up.but it is not so robust.it > will stop transfer data and throw some errors in > these conditions: > 1 . mount nfs via wireless network,if i transfer a lot of data.it > may stop receiving data after some time. > 2 . wireless network is busy, then some one reboot the wireless AP.it > may throw some errors and stop working. > 3 . Find wireless network works slow and switch to Ethernet,.if try > /etc/rc.d/netif restart, it may throw some errors and stop working. > > > all these are fixed by reboot system(reload iwn and iwnfw dose not > work at most time). i also find iwn driver printe a lot of microcode > error related messages when it failed(not easy to reproduce it). > > No official Change Log, i just notice the *description *in gentoo > bug#202818. I don't see any of the above issues w/ the 4965 card I have but I don't use it often. Given how little information you've provided it's unlikely anyone can help you diagnose your problems and even less likely changing the fw would matter. If you want to pursue these problems I suggest you file a PR with details but to be honest I'm not aware of anyone actively working on the driver. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 18:59:33 2009 Return-Path: Delivered-To: FreeBSD-Current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FA3F1065672 for ; Fri, 10 Jul 2009 18:59:33 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 07CF98FC0C for ; Fri, 10 Jul 2009 18:59:32 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by vwj2 with SMTP id 2so902021vwj.3 for ; Fri, 10 Jul 2009 11:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=0knQ+P5R9vgV0yTnUmnWRK5o7phcTHHxp1gErr+rH5s=; b=Ir3beJTlahu95xOWF2UqXIeE4HCayB48SbMXlOD2bRevczajpWHYsBSTvFfAw+NO2z 5I+7aiSCTCcRP4NIKlfc1g3hTLfnH3eNEmyQ52JfKGQ64uYdMPCQnMGQchmJQ5AIKMZu uXVgnxXI4I5kYQSrCuuXlKu0nQzX/4O9ncviY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=WpeQxTrocrqa9/DdS1u5Wi+ysA9074LrjtPi5pywRK+3IEW8O5slX+Pr8fa22ZDTcb tChHPEKrHBg/8G30DGtjfBtBGXKWdx3tJNAJr19LVT0GkuFxIUwqYv7B0c45viK9BxIE bVAC5q/9KJtkfVGhu6O6uGA/EDzHLvI25TtlE= MIME-Version: 1.0 Received: by 10.220.85.6 with SMTP id m6mr3448030vcl.69.1247252372406; Fri, 10 Jul 2009 11:59:32 -0700 (PDT) Date: Fri, 10 Jul 2009 13:59:32 -0500 Message-ID: <790a9fff0907101159w495b644dge4a4bd81de0bda9b@mail.gmail.com> From: Scot Hetzel To: FreeBSD-Current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: How to create ZFS on Root using MBR slices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:59:33 -0000 I'm re-installing my laptop, and want to install it using a ZFS Root. This system's Hardrive consists of 3 Slices: ad0s1 - Windows XP ad0s2 - Quick Play ad0s3 - FreeBSD I then installed FreeBSD using the Fixit option from a custom 8.0-CURRENT CD (w/loader built with ZFS support) as follows. -------------------------------------------------------------------------------------------------------------- Creating ZFS Root w/MBR Slices 1. Boot FreeBSD install CD/DVD 2. Choose Fixit option in sysinstall 3. Create Slice using gpart Fixit# gpart show ad0 => 63 625142385 ad0 MBR (289G) 63 209712447 1 !7 (100G) 209712510 417690 2 !136 (204M) 210130200 415012248 - free - (198G) Fixit# gpart add -b 210130200 -s 415012248 -t freebsd ad0 ad0s3 added Fixit# gpart show ad0 => 63 625142385 ad0 MBR (289G) 63 209712447 1 !7 (100G) 209712510 417690 2 !136 (204M) 210130200 415012248 3 freebsd (198G) 4. Create partitions (ad0s3a and ad0s3b) Fixit# gpart show ad0s3 => 0 415012248 ad0s3 BSD (198G) 0 415012248 ad0s3 - free - (198G) Fixit# gpart add -i 1 -b 16 -s 406626318 -t freebsd-zfs ad0s3 ad0s3a added Fixit# gpart show ad0s3 => 0 415012248 ad0s3 BSD (198G) 0 16 - free - (8.0K) 16 406631405 1 freebsd-zfs (194G) 406631421 8380827 - free - (4.0G) Fixit# gpart add -i 2 -b 406626334 -s 8380811 -t freebsd=swap ad0s3 ad0s3b added Fixit# gpart show ad0s3 => 0 415012248 ad0s3 BSD (198G) 0 16 - free - (8.0K) 16 406631405 1 freebsd-zfs (194G) 406631421 8380827 2 freebsd-swap (4.0G) 5. load zfs kernel module kldload /mnt2/boot/kernel/opensolaris.ko kldload /mnt2/boot/kernel/zfs.ko 6. Create Zpool zpool create zroot /dev/ad0s3a zpool set bootfs=zroot zroot 7. Create filesystem hierarchy zfs create -o compression=on -o exec=off -o setuid=off zroot/tmp zfs create zroot/usr zfs create -o compression=on -o setuid=off zroot/usr/ports zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/distfiles zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/packages zfs create -o compression=on -o exec=off -o setuid=off zroot/usr/src zfs create zroot/var zfs create -o compression=on -o exec=off -o setuid=off zroot/var/crash zfs create -o exec=off -o setuid=off zroot/var/db zfs create -o compression=on -o exec=on -o setuid=off zroot/var/db/pkg zfs create -o exec=off -o setuid=off zroot/var/empty zfs create -o compression=on -o exec=off -o setuid=off zroot/var/log zfs create -o compression=on -o exec=off -o setuid=off zroot/var/mail zfs create -o exec=off -o setuid=off zroot/var/run zfs create -o compression=on -o exec=off -o setuid=off zroot/var/tmp 8. install FreeBSD to zroot cd /dist/8.0-20090628-SNAP export DESTDIR=/zroot for dir in base catpages dict doc games info lib32 manpages ports; do (cd $dir ; ./install.sh) ; done cd src ; ./install.sh all cd ./kernel ; ./install.sh dv8135nr ; ./install.sh generic 9. create rc.conf, loader.conf, src.conf echo 'zfs_enable="YES"' > /zroot/etc/rc.conf echo 'LOADER_ZFS_SUPPORT=YES' >> /zroot/etc/src.conf echo 'zfs_load="YES"' >> /zroot/boot/loader.conf echo 'vfs.root.mountfrom="zfs:zroot"' >> /zroot/boot/loader.conf 10. change root password chroot /zroot passwd exit 11. create zpool.cache mkdir /boot/zfs zpool export zroot && zpool import zroot cp /boot/zfs/zpool.cache /zroot/boot/zfs/zpool.cache 12. export LD_LIBRARY_PATH export LD_LIBRARY_PATH=/mnt2/lib 13. Change mount points for zroot pool zfs set mountpoint=legacy zroot zfs set mountpoint=/tmp zroot/tmp zfs set mountpoint=/usr zroot/usr zfs set mountpoint=/var zroot/var 14. Install boot Manager fdisk -B -b /boot/boot0 ad0 15. Install ZFS boot dd if=/mnt2/boot/zfsboot of=/dev/ad0s3 count=1 dd if=/mnt2/boot/zfsboot of=/dev/ad0s3 skip=1 seek=1024 -------------------------------------------------------------------------------------------------------------- When I reboot the system, it says that it is unable to locate the ZFS partition. Is there anything wrong with the above install procedure for creating a ZFS Root MBR Slice install? Scot From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:01:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9FBA106566B; Fri, 10 Jul 2009 19:01:48 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 464B18FC16; Fri, 10 Jul 2009 19:01:48 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:45621 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MPLLl-0007fh-4v; Fri, 10 Jul 2009 21:01:39 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 8E192F9973; Fri, 10 Jul 2009 21:01:34 +0200 (CEST) Message-Id: From: Thomas Backman To: FreeBSD current In-Reply-To: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 21:01:33 +0200 References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MPLLl-0007fh-4v. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MPLLl-0007fh-4v b688837e5904323df4ea64d43091b07b Cc: freebsd-fs@freebsd.org Subject: Reproducible ZFS panic, w/ script (Was: "New" ZFS crash on FS (pool?) unmount/export) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:01:49 -0000 On Jun 20, 2009, at 09:11, Thomas Backman wrote: > I just ran into this tonight. Not sure exactly what triggered it - > the box stopped responding to pings at 02:07AM and it has a cron > backup job using zfs send/recv at 02:00, so I'm guessing it's > related, even though the backup probably should have finished before > then... Hmm. Anyway. > > r194478. > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x288 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff805a4989 > stack pointer = 0x28:0xffffff803e8b57e0 > frame pointer = 0x28:0xffffff803e8b5840 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 57514 (zpool) > panic: from debugger > cpuid = 0 > Uptime: 10h22m13s > Physical memory: 2027 MB > > (kgdb) bt > ... > #9 0xffffffff80887fb2 in trap (frame=0xffffff803e8b5730) at /usr/ > src/sys/amd64/amd64/trap.c:345 > #10 0xffffffff8086e007 in calltrap () at /usr/src/sys/amd64/amd64/ > exception.S:223 > #11 0xffffffff805a4989 in _sx_xlock_hard (sx=0xffffff0043557d50, > tid=18446742975830720512, opts=Variable "opts" is not available. > ) > at /usr/src/sys/kern/kern_sx.c:575 > #12 0xffffffff805a52fe in _sx_xlock (sx=Variable "sx" is not > available. > ) at sx.h:155 > #13 0xffffffff80fe2995 in zfs_freebsd_reclaim () from /boot/kernel/ > zfs.ko > #14 0xffffffff808cefca in VOP_RECLAIM_APV (vop=0xffffff0043557d38, > a=0xffffff0043557d50) at vnode_if.c:1926 > #15 0xffffffff80626f6e in vgonel (vp=0xffffff00437a7938) at > vnode_if.h:830 > #16 0xffffffff8062b528 in vflush (mp=0xffffff0060f2a000, rootrefs=0, > flags=0, td=0xffffff0061528000) > at /usr/src/sys/kern/vfs_subr.c:2450 > #17 0xffffffff80fdd3a8 in zfs_umount () from /boot/kernel/zfs.ko > #18 0xffffffff8062420a in dounmount (mp=0xffffff0060f2a000, > flags=1626513408, td=Variable "td" is not available. > ) > at /usr/src/sys/kern/vfs_mount.c:1287 > #19 0xffffffff80624975 in unmount (td=0xffffff0061528000, > uap=0xffffff803e8b5c00) > at /usr/src/sys/kern/vfs_mount.c:1172 > #20 0xffffffff8088783f in syscall (frame=0xffffff803e8b5c90) at /usr/ > src/sys/amd64/amd64/trap.c:984 > #21 0xffffffff8086e290 in Xfast_syscall () at /usr/src/sys/amd64/ > amd64/exception.S:364 > #22 0x000000080104e49c in ?? () > Previous frame inner to this frame (corrupt stack?) > > BTW, I got a (one) "force unmount is experimental" on the console. > On regular shutdown I usually get one per filesystem, it seems (at > least 10) and this pool should contain exactly as many filesystems > as the root pool since it's a copy of it. On running the backup > script manually post-crash, though, I didn't get any. OK, I've finally written a script that reproduces this panic for me every time (6-7 tries in a row should be good enough, plus one on another box). It would be great to have a few testers - and if you do test it, PLEASE report your results here - positive or negative! The main aim is, of course, to provide ZFS devs with their own core dumps, DDB consoles and whatnot to possibly resolve this issue. It requires: * bash (or something compatible, for the script itself) * a box you're willing to crash. ;) * ~200MB free on your /root/ partition (or just edit the paths at the top of the ugly hack of a script.) If you use ggatel with silly high numbers (1482 and 1675 - chosen since they're unlikely to be used), again, edit at the top. * The libzfs_sendrecv.c patch - see http://lists.freebsd.org/pipermail/freebsd-current/2009-May/006814.html or fetch the patch from my server (if it's down, it's for less than 2 minutes - my modem restarts every 181 minutes atm...): http://exscape.org/temp/libzfs_sendrecv.patch Here's a oneliner to fetch, patch, compile and install: cd /usr/src && fetch http://exscape.org/temp/libzfs_sendrecv.patch && patch -p0 < libzfs_sendrecv.patch && cd /usr/src/cddl/lib/libzfs && make && make install No reboot required (nor do you need a reboot to revert, see the end of the mail). PLEASE NOTE that without this patch, you'll just get a segfault and then an infinite loop of backups (since send/recv doesn't work in HEAD since at least february, I'm guessing since ZFS v13). Too bad that the patch is needed, since I suspect quite a few testers will bail out there... If not (great!), here's the script to wreck havoc: http://exscape.org/temp/zfs_clone_panic.sh After fetching the above, just run the script like "bash zfs_clone_panic.sh crash" and you should have a panic in about 20 seconds. The other possiblee arguments are mostly there because I'm too lazy to clean it up now that it "works". Back to the panic: The problem appears to be related to clones somehow - the first two times I ran in to this panic (in real use) was when messing with clone/ promote... so that's what this script does. Here's the backtrace it produces, and some info (show lockedvnods, if that helps at all): kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8036df39 stack pointer = 0x28:0xffffff803ea6d7e0 frame pointer = 0x28:0xffffff803ea6d840 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 16367 (zpool) 0xffffff000510fce8: tag zfs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xffffff0002cd8bc0 flags () lock type zfs: EXCL by thread 0xffffff0024c5d000 (pid 16367) 0xffffff00050dc3b0: tag zfs, type VDIR usecount 0, writecount 0, refcount 1 mountedhere 0 flags (VI_DOOMED) VI_LOCKed lock type zfs: EXCL by thread 0xffffff0024c5d000 (pid 16367) panic: from debugger ... ... boot, panic, trap etc ... #10 0xffffffff805d36a7 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #11 0xffffffff8036df39 in _sx_xlock_hard (sx=0xffffff005d11a8e8, tid=18446742974814867456, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_sx.c:575 #12 0xffffffff8036e8ae in _sx_xlock (sx=Variable "sx" is not available. ) at sx.h:155 #13 0xffffffff80b889e5 in zfs_freebsd_reclaim () from /boot/kernel/ zfs.ko #14 0xffffffff8062447a in VOP_RECLAIM_APV (vop=0xffffff005d11a8d0, a=0xffffff005d11a8e8) at vnode_if.c:1926 #15 0xffffffff803f3b0e in vgonel (vp=0xffffff00050dc3b0) at vnode_if.h: 830 #16 0xffffffff803f80c8 in vflush (mp=0xffffff0002cd8bc0, rootrefs=0, flags=0, td=0xffffff0024c5d000) at /usr/src/sys/kern/vfs_subr.c:2449 #17 0xffffffff80b833d8 in zfs_umount () from /boot/kernel/zfs.ko #18 0xffffffff803f0d3a in dounmount (mp=0xffffff0002cd8bc0, flags=47025088, td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:1289 #19 0xffffffff803f1568 in unmount (td=0xffffff0024c5d000, uap=0xffffff803ea6dc00) at /usr/src/sys/kern/vfs_mount.c:1174 #20 0xffffffff805ed4cf in syscall (frame=0xffffff803ea6dc90) at /usr/src/sys/amd64/amd64/trap.c:984 #21 0xffffffff805d3930 in Xfast_syscall () at /usr/src/sys/amd64/ amd64/exception.S:364 #22 0x000000080104e9ac in ?? () Previous frame inner to this frame (corrupt stack?) Regards, Thomas PS. A oneliner to get back to the non-patched state, if you're using SVN (if not, sorry): cd /usr/src && svn revert cddl/contrib/opensolaris/lib/libzfs/common/ libzfs_sendrecv.c && cd /usr/src/cddl/lib/libzfs && make && make install DS. Hope this helps track this down, as I spent quite a while on finding the root cause (the clones, in one way or another), writing the script, this mail, etc. From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:04:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FFA010656C5 for ; Fri, 10 Jul 2009 19:04:52 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 08A918FC20 for ; Fri, 10 Jul 2009 19:04:51 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id n6AITdxO009977 for ; Fri, 10 Jul 2009 13:29:40 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4A578893.1030609@missouri.edu> Date: Fri, 10 Jul 2009 13:29:39 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090702 SeaMonkey/1.1.17 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: RELENG_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:04:52 -0000 When RELENG_8 comes out, is there an announcement made? Is it safe to assume that it will come out at the same time as RELEASE-8.0, or does it come out earlier? From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:04:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAEDB10656C1; Fri, 10 Jul 2009 19:04:52 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7B5228FC12; Fri, 10 Jul 2009 19:04:52 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id n6AISNWo009973; Fri, 10 Jul 2009 13:28:24 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4A578847.5060201@missouri.edu> Date: Fri, 10 Jul 2009 13:28:23 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090702 SeaMonkey/1.1.17 MIME-Version: 1.0 To: kevin References: <4A5777F6.5040700@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sam Leffler , freebsd-current@freebsd.org Subject: Re: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:04:53 -0000 kevin wrote: > On Sat, Jul 11, 2009 at 1:18 AM, Sam Leffler wrote: > >> kevin wrote: >> >>> Hi, >>> I notice iwn's firmware hasn't been updated for a long time.Is there any >>> plan to import newer version iwn firmware ? current version is >>> iwlwifi-4965-ucode-4.44.17 in the source tree, while latest version is >>> iwlwifi-4965-ucode-228.61.2.24. >>> >>> http://www.intellinuxwireless.org/?n=downloads&f=ucodes_4965 >>> >>> >> Not sure why you want newer firmware. If it's for newer chip support then >> that requires driver changes and is non-trivial. >> >> Sam >> >> iwn driver works well when system up.but it is not so robust.it will stop > transfer data and throw some errors in these conditions: > 1 . mount nfs via wireless network,if i transfer a lot of data.it may stop > receiving data after some time. > 2 . wireless network is busy, then some one reboot the wireless AP.it may > throw some errors and stop working. > 3 . Find wireless network works slow and switch to Ethernet,.if try > /etc/rc.d/netif restart, it may throw some errors and stop working. > > > all these are fixed by reboot system(reload iwn and iwnfw dose not work at > most time). i also find iwn driver printe a lot of microcode error related > messages when it failed(not easy to reproduce it). > > No official Change Log, i just notice the *description *in gentoo > bug#202818. I have had the same experiences. They are not that frequent, so I can live with it, but if someone were to fix it, that would be great. From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:10:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FE981065676 for ; Fri, 10 Jul 2009 19:10:29 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id BE9048FC1A for ; Fri, 10 Jul 2009 19:10:28 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 9050F78E3F; Fri, 10 Jul 2009 23:10:26 +0400 (MSD) Message-ID: <4A579226.3080400@haruhiism.net> Date: Fri, 10 Jul 2009 23:10:30 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stephen Montgomery-Smith References: <4A578893.1030609@missouri.edu> In-Reply-To: <4A578893.1030609@missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RELENG_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:10:29 -0000 Stephen Montgomery-Smith wrote: > When RELENG_8 comes out, is there an announcement made? Is it safe to > assume that it will come out at the same time as RELEASE-8.0, or does > it come out earlier? A message is posted to the commit log after the tag is created. For RELENG_7, it happened shortly before BETA2, iirc. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:25:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B261A106566B; Fri, 10 Jul 2009 19:25:41 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 6BBC08FC22; Fri, 10 Jul 2009 19:25:41 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:43500 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MPLix-0002we-5H; Fri, 10 Jul 2009 21:25:37 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 92DF311E9F0; Fri, 10 Jul 2009 21:25:35 +0200 (CEST) Message-Id: <45291598-D091-4E90-B968-22E59BEB3846@exscape.org> From: Thomas Backman To: FreeBSD current In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 21:25:34 +0200 References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MPLix-0002we-5H. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MPLix-0002we-5H d61ea09685ba684f741fc63673280140 Cc: freebsd-fs@freebsd.org Subject: Re: Reproducible ZFS panic, w/ script (Was: "New" ZFS crash on FS (pool?) unmount/export) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:25:42 -0000 On Jul 10, 2009, at 21:01, Thomas Backman wrote: > OK, I've finally written a script that reproduces this panic for me > every time (6-7 tries in a row should be good enough, plus one on > another box). It would be great to have a few testers - and if you > do test it, PLEASE report your results here - positive or negative! > The main aim is, of course, to provide ZFS devs with their own core > dumps, DDB consoles and whatnot to possibly resolve this issue. > [...] > Back to the panic: > The problem appears to be related to clones somehow - the first two > times I ran in to this panic (in real use) was when messing with > clone/promote... so that's what this script does. Damnit. Very sorry for the noise, but I just noticed that it IS NOT related to the clones. It crashes with the clone/promote lines (#77-78) commented out, too... Now I'm stumped as to where the issue is, I hope the previous mail can help track it down. A very similar setup runs every night, and it "only" crashes about one time in 10 or so. This crashes *every* time and I don't really see the difference between the commands the scripts run. Oh well... Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:27:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606871065673; Fri, 10 Jul 2009 19:27:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id 00A2F8FC24; Fri, 10 Jul 2009 19:27:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so573354and.13 for ; Fri, 10 Jul 2009 12:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uP3vPsKsWUB9ojOKhaG4bPYmyX9PDs6vzTSyugPrcAc=; b=i7eo2LL4SyIzM0OwEJ8kHo59EKz1jitBapP6KLgQExA+SmvlznNUHtfAvrs77hdjYW 5LE7kEmMghGDVWt7AqaPkHT4q6o8GbMrrcPUzzDKxlQckDdv6yo6hEsRNJSJiMSYYlA0 7qRu000lzTtT9E3wGy8iVvF+DZPnFipuz6sgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jYXpMJv7rmiv4ajZqOSfqXDyrSbK5VcJJXQXYtq+0UuIg5Is1Ptp0Hb3m3ZyCTbGgX U+z7TW7Dwj2JVkAiHKCo3qV/IUGvjRUlAuEqQQIUUA7JBwk5SVQaMyKan4ncTvuBcR9W A5lEoERfCx9LKl6szwjMMNEcWayGb56idZwFw= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.254.12 with SMTP id b12mr3210057ani.43.1247254064410; Fri, 10 Jul 2009 12:27:44 -0700 (PDT) In-Reply-To: <45291598-D091-4E90-B968-22E59BEB3846@exscape.org> References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> <45291598-D091-4E90-B968-22E59BEB3846@exscape.org> Date: Fri, 10 Jul 2009 12:27:44 -0700 X-Google-Sender-Auth: 85fa16ab9ade5e38 Message-ID: <3c1674c90907101227ueab78eem6f8c5c7fdf0337cc@mail.gmail.com> From: Kip Macy To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: Reproducible ZFS panic, w/ script (Was: "New" ZFS crash on FS (pool?) unmount/export) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:27:46 -0000 "zfs export" does a forced unmount. We may not be properly handling dangling references. -Kip On Fri, Jul 10, 2009 at 12:25 PM, Thomas Backman wrote: > On Jul 10, 2009, at 21:01, Thomas Backman wrote: >> >> OK, I've finally written a script that reproduces this panic for me every >> time (6-7 tries in a row should be good enough, plus one on another box). It >> would be great to have a few testers - and if you do test it, PLEASE report >> your results here - positive or negative! >> The main aim is, of course, to provide ZFS devs with their own core dumps, >> DDB consoles and whatnot to possibly resolve this issue. >> [...] >> Back to the panic: >> The problem appears to be related to clones somehow - the first two times >> I ran in to this panic (in real use) was when messing with clone/promote... >> so that's what this script does. > > Damnit. Very sorry for the noise, but I just noticed that it IS NOT related > to the clones. It crashes with the clone/promote lines (#77-78) commented > out, too... > Now I'm stumped as to where the issue is, I hope the previous mail can help > track it down. > A very similar setup runs every night, and it "only" crashes about one time > in 10 or so. This crashes *every* time and I don't really see the difference > between the commands the scripts run. Oh well... > > Regards, > Thomas > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 19:44:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04B761065679 for ; Fri, 10 Jul 2009 19:44:28 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 873DD8FC25 for ; Fri, 10 Jul 2009 19:44:27 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm24 with SMTP id 24so901381fxm.43 for ; Fri, 10 Jul 2009 12:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=LMYGU6KdA//iAoPVJoIFbGoc9JlsIcpjmA7JCf+vhJ0=; b=pBCxi44JREjZUvhZIAVL6RoYVgjqUwcRV35tYAvJ28+bjnayQzJmL0uu9AHMzWYEJD psuB5oU9Jws45wz6KJWiPs0oDZtotFt54TjIRtl1jEqcaZFHQMXiceTMiXnBp9yuMOFd An/F5ILt64sScmn9lzSPpD4eukpBLfa5BS/IM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CM7qWqamzRZ3zQuxH4UQfzePkBo+GIyhJ7M4HN7CeATYkxd6ah9nf02iDIrir3LJdi pN0vZUOCOTW4t/V0H5dfeA0yuMfgEvczl2xi5iYN2j4v7fHoXl7XqhPH27IBZfNV/61L 2igyo5vX4TnuZkxXb/Qw8/p1tQiHecaPMtMBQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.122.15 with SMTP id j15mr1353994far.10.1247255066508; Fri, 10 Jul 2009 12:44:26 -0700 (PDT) In-Reply-To: <4A578470.8080600@chruetertee.ch> References: <4A578470.8080600@chruetertee.ch> Date: Fri, 10 Jul 2009 21:44:26 +0200 X-Google-Sender-Auth: b5c815e0236c89e9 Message-ID: <3bbf2fe10907101244v267421fq1e215ca07cf3e53d@mail.gmail.com> From: Attilio Rao To: =?UTF-8?Q?Beat_G=C3=A4tzi?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: tmpfs panic: wrong vnode type 0xffffff008547ab10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 19:44:28 -0000 2009/7/10 Beat G=C3=A4tzi : > Hi, > > I tried to run my tinderbox with the build directory on tmpfs but the > system panics with wrong vnode type 0xffffff008547ab10. > > This panic is reproducible when mounting the build directory with tmpfs > and trying to build a port like gcc or openoffice with tinderbox. Sorry, tmpfs lookup is broken and can lead to incorrect vnodes handling. tmpfs should be considered experimental until expressly changed (I guess we should stress-out that). Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 20:01:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 477AA106568A; Fri, 10 Jul 2009 20:01:30 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id F16368FC19; Fri, 10 Jul 2009 20:01:29 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:55549 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MPMHJ-0005mt-57; Fri, 10 Jul 2009 22:01:08 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 3FED21386E2; Fri, 10 Jul 2009 22:01:05 +0200 (CEST) Message-Id: From: Thomas Backman To: Kip Macy In-Reply-To: <3c1674c90907101227ueab78eem6f8c5c7fdf0337cc@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 10 Jul 2009 22:01:04 +0200 References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> <45291598-D091-4E90-B968-22E59BEB3846@exscape.org> <3c1674c90907101227ueab78eem6f8c5c7fdf0337cc@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MPMHJ-0005mt-57. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MPMHJ-0005mt-57 c319037c8c265a456fa9b1f910fe5d59 Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: Reproducible ZFS panic, w/ script (Was: "New" ZFS crash on FS (pool?) unmount/export) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:01:30 -0000 On Jul 10, 2009, at 21:27, Kip Macy wrote: > "zfs export" does a forced unmount. We may not be properly handling > dangling references. > > -Kip > > On Fri, Jul 10, 2009 at 12:25 PM, Thomas > Backman wrote: >> On Jul 10, 2009, at 21:01, Thomas Backman wrote: >> ... Just one more thing to add for me today: the crash always happens when exporting the slave. Constant send/recv loops multiple times a second, no sweat. import/export of both pools multiple times a second, without any send/recv in between them, no sweat. Combined, however, it panics on "zpool export crashtestslave". (I verified this twice, once by changing stress() to simply run loads of incremental backups for a for a few minutes, break, and export the pools manually. Both times, the master pool was no problem, and it immediately panics on exporting the slave.) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 20:07:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBFF61065674 for ; Fri, 10 Jul 2009 20:07:51 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from cauchy.math.missouri.edu (cauchy.math.missouri.edu [128.206.184.213]) by mx1.freebsd.org (Postfix) with ESMTP id 840298FC18 for ; Fri, 10 Jul 2009 20:07:51 +0000 (UTC) (envelope-from stephen@missouri.edu) Received: from laptop3.gateway.2wire.net (cauchy.math.missouri.edu [128.206.184.213]) by cauchy.math.missouri.edu (8.14.3/8.14.3) with ESMTP id n6AK7oeO010588; Fri, 10 Jul 2009 15:07:50 -0500 (CDT) (envelope-from stephen@missouri.edu) Message-ID: <4A579F96.7070908@missouri.edu> Date: Fri, 10 Jul 2009 15:07:50 -0500 From: Stephen Montgomery-Smith User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1.22) Gecko/20090702 SeaMonkey/1.1.17 MIME-Version: 1.0 To: Kamigishi Rei References: <4A578893.1030609@missouri.edu> <4A579226.3080400@haruhiism.net> In-Reply-To: <4A579226.3080400@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RELENG_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:07:52 -0000 Kamigishi Rei wrote: > Stephen Montgomery-Smith wrote: >> When RELENG_8 comes out, is there an announcement made? Is it safe to >> assume that it will come out at the same time as RELEASE-8.0, or does >> it come out earlier? > A message is posted to the commit log after the tag is created. > For RELENG_7, it happened shortly before BETA2, iirc. Thank you. Where do I find the commit log? If I were to subscribe to the cvs-projects mailing list, would this provide this information? Stephen From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 20:11:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D053106564A for ; Fri, 10 Jul 2009 20:11:56 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp03.sth.basefarm.net (ch-smtp03.sth.basefarm.net [80.76.149.214]) by mx1.freebsd.org (Postfix) with ESMTP id 493AD8FC12 for ; Fri, 10 Jul 2009 20:11:56 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:58519 helo=falcon.midgard.homeip.net) by ch-smtp03.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MPM8f-0004jz-BR for freebsd-current@freebsd.org; Fri, 10 Jul 2009 21:52:11 +0200 Received: (qmail 34040 invoked from network); 10 Jul 2009 21:52:07 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 10 Jul 2009 21:52:07 +0200 Received: (qmail 44013 invoked by uid 1001); 10 Jul 2009 21:52:07 +0200 Date: Fri, 10 Jul 2009 21:52:07 +0200 From: Erik Trulsson To: Stephen Montgomery-Smith Message-ID: <20090710195207.GA43998@owl.midgard.homeip.net> References: <4A578893.1030609@missouri.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A578893.1030609@missouri.edu> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1MPM8f-0004jz-BR. X-Scan-Signature: ch-smtp03.sth.basefarm.net 1MPM8f-0004jz-BR 1185823d553afffe472ba610007513b0 Cc: freebsd-current@freebsd.org Subject: Re: RELENG_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:11:56 -0000 On Fri, Jul 10, 2009 at 01:29:39PM -0500, Stephen Montgomery-Smith wrote: > When RELENG_8 comes out, is there an announcement made? There usually isn't any special announcement just for the creation of a new cvs/svn branch. > Is it safe to > assume that it will come out at the same time as RELEASE-8.0, or does it > come out earlier? The RELENG_8 branch will be created earlier, likely several weeks (or more) before the 8.0 release is finished. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 20:21:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1251C106566B for ; Fri, 10 Jul 2009 20:21:59 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id C08E38FC0A for ; Fri, 10 Jul 2009 20:21:58 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id F419178F58; Sat, 11 Jul 2009 00:21:56 +0400 (MSD) Message-ID: <4A57A2E8.9090009@haruhiism.net> Date: Sat, 11 Jul 2009 00:22:00 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stephen Montgomery-Smith References: <4A578893.1030609@missouri.edu> <4A579226.3080400@haruhiism.net> <4A579F96.7070908@missouri.edu> In-Reply-To: <4A579F96.7070908@missouri.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RELENG_8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:21:59 -0000 Stephen Montgomery-Smith wrote: > Thank you. Where do I find the commit log? If I were to subscribe to > the cvs-projects mailing list, would this provide this information? Branch notices for RELENG appear in /usr/src/UPDATING, so you might just check that file. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 20:52:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE4CB1065670 for ; Fri, 10 Jul 2009 20:52:54 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from magic3.magicbooks.org (cl-190.dus-01.de.sixxs.net [IPv6:2a01:198:200:bd::2]) by mx1.freebsd.org (Postfix) with ESMTP id 536628FC13 for ; Fri, 10 Jul 2009 20:52:54 +0000 (UTC) (envelope-from cavac@magicbooks.org) Received: from mail.magicbooks.org (localhost [127.0.0.1]) by magic3.magicbooks.org (8.14.3/8.14.3) with ESMTP id n6AKq8Y1029304; Fri, 10 Jul 2009 22:52:31 +0200 (CEST) (envelope-from cavac@magicbooks.org) Received: from 85.124.105.180 (SquirrelMail authenticated user cavac) by mail.magicbooks.org with HTTP; Fri, 10 Jul 2009 22:52:43 +0200 (CEST) Message-ID: <5346.85.124.105.180.1247259163.squirrel@mail.magicbooks.org> In-Reply-To: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> Date: Fri, 10 Jul 2009 22:52:43 +0200 (CEST) From: "Rene Schickbauer" To: "Ken Smith" User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: freebsd-current Subject: Re: FreeBSD 8.0-BETA1 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:52:55 -0000 > > The first public test build of the FreeBSD 8.0-RELEASE test cycle is now > available, 8.0-BETA1. Thaaaank you all! That is really wonderfull news! > People with the resources to do so (test machines...) are encouraged to > give 8.0-BETA1 a try. Works on my EEE PC 901 on the secondary drive (32 Gig / Patriot) quite nicely. So good in fact, that i didn't bother to re-install windows as a backup system this time after the little snag i hit last week, see relevant blog entries: In a few weeks time i'll probably get hold of a HP 16 core Intel 8-16 Gig Ram Server with 4 SAS Raid-1 Arrays for probably a few months for testing. I might be able to "accidently" install Beta1 or Beta2 on it (my company is big on windows..). > Debugging support (WITNESS, malloc debugging, etc.) are also still > turned on and those tend to cause a performance hit. As my EEE PC is currently somewhat slow on compiling... How much would i gain from turning these off? Or would this be a rather bad idea at the moment? > As far as we know > there are no known issues that would cause data corruption or anything > like that, just the issues with performance and potential for changes > caused by ongoing work. There *may* be a bug in sysinstall (called from the running system) in trying to configure an ex-windows partition as a second disk slice. But this time i'm not going to test it until *after* i backed up my system, which will be sometime next week... > 8.0-BETA1--memstick.img > > If you copy that to a USB memory stick newer machines should be able to > boot from it and use it to install from. My prayers have been heard! No more use-once-pollute-earth-forever plastic disks! Thank you, thank you thank you! LLAP & LG Rene -- Overview of my personality: Hackerkey: http://tinyurl.com/nocj7c From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 20:53:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64DE8106566C for ; Fri, 10 Jul 2009 20:53:11 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 387058FC13 for ; Fri, 10 Jul 2009 20:53:11 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 89B693AFE82; Fri, 10 Jul 2009 16:53:10 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 10 Jul 2009 16:53:10 -0400 X-Sasl-enc: pB4KQZ5dPqHS/SAC3dWjviq0dkc3deZiSAgnbfAIX0Vp 1247259190 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 226582175; Fri, 10 Jul 2009 16:53:09 -0400 (EDT) Message-ID: <4A57A9FE.7090605@incunabulum.net> Date: Fri, 10 Jul 2009 21:52:14 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Mattia Rossi References: <1246926782.11597.23.camel@bauer.cse.buffalo.edu> <4A54FB33.8060705@fgznet.ch> <1247107223.31816.7.camel@bauer.cse.buffalo.edu> <4A563C65.20402@fgznet.ch> <4A56A263.4020307@swin.edu.au> In-Reply-To: <4A56A263.4020307@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Vlc services discovery (SAP) panics kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 20:53:11 -0000 Mattia Rossi wrote: > I've tried to use vlc 1.0.0 (goldeneye) - it was also happening with > previous versions. > Every time I try SAP service discovery the system freezes. > > Trying on the command line gave me a Fatal error 12 message, page > fault while in kernel mode. We need to see a kernel backtrace to help you out; if you can't get a crash dump, you might need to transcribe it by hand. thanks, BMS From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 21:13:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B3A5106564A for ; Fri, 10 Jul 2009 21:13:35 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id C59E98FC13 for ; Fri, 10 Jul 2009 21:13:34 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by vwj2 with SMTP id 2so965262vwj.3 for ; Fri, 10 Jul 2009 14:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=bPokYR561h4QlTSqjF1HvruZZsoATI+vq9pcW/GDFZk=; b=IUDTolvufp/ch8CKcmZpOxFtMaNfMtgFHZyCKMQ/tXl9EUShf/dbUftwGxcokdgdIt i3QZ4W9upcuR0kKZmLkOAMJU9Rp2CAP/tgXYpFw3b84kwgd8LHh7LVHLyaOZy2Zx/Cnp XsZY6z/36XW7MsywOgJkf/9YsBdv4ya6Ax0Sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=xZtcBtVTJ14xsJqqAeozRWHuQxxoY7gDg4KRWLCWKQ+8nFCoNEU7Z195AO93jZwZbH 205/3tGKJ96uzqCwS1t28nwubOocRHZebpwUKC6PIVtKZR34ribyTR5wiCV+Wr88nF3R yQLsWz7J8Cusny846RSC3kTGpW4pkctMGM/ro= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.81.69 with SMTP id w5mr3657039vck.23.1247259006153; Fri, 10 Jul 2009 13:50:06 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Fri, 10 Jul 2009 22:49:46 +0200 X-Google-Sender-Auth: e899043b3b1322ef Message-ID: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 21:13:35 -0000 Hi, I meet a problem with the 8.0 Beta1 (amd64 and i386) on an Asus K8N4-E motherboard: During the kernel load, my system hang (no dump, no error message). The last messages are (hand copy): ohci0: irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: SMM does not respond, resetting usbus0: reset timeout ohci0: USB init failed device_attach: ohci0 attach returned 6 ehci0: irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] How can I found more technical information where the system hang ? This system works great with FreeBSD 7.2. Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Fri Jul 10 22:20:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7A0910656B4 for ; Fri, 10 Jul 2009 22:20:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id C83098FC18 for ; Fri, 10 Jul 2009 22:20:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n6AM7e96006401 for ; Fri, 10 Jul 2009 15:07:40 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Jul 2009 15:07:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-BETA1 - for the record - different paths followed by IPv4and IPv6 for 'local' connections Thread-Index: AcoBWrJ+I+9bnFsRRUabMfoqrB4rsgATKDg1AADdYZ0= References: <4A5734C3.3000806@restart.be> From: "Li, Qing" To: Subject: FW: 8.0-BETA1 - for the record - different paths followed by IPv4and IPv6 for 'local' connections X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 22:20:09 -0000 -----Original Message----- From: owner-freebsd-stable@freebsd.org on behalf of Li, Qing Sent: Fri 7/10/2009 2:51 PM To: Henri Hennebert; freebsd-stable@freebsd.org; freebsd-st@freebsd.org Subject: RE: 8.0-BETA1 - for the record - different paths followed by = IPv4and IPv6 for 'local' connections =20 Hi, Please try patch-7-10 in my home directory = http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the = patch=20 but turned out I didn't. > > On 8.0-BETA1 there is an assymetry: > > netstat -rn display >=20 > 192.168.24.1 link#3 > .... > no entry for 2001:41d0:2:2d29:1:1:: >=20 This is by design as part of the new architecture in 8.0, which = maintains=20 the L2 ARP/ND6 and L3 routing tables separately. -- Qing -----Original Message----- From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 = and IPv6 for 'local' connections =20 Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when=20 connecting with firefox to a local apache server using the global=20 unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [root@avoriaz ~]# ifconfig em0 em0: flags=3D8843 metric 0 mtu = 1500 options=3D19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [root@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if=3D"em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [root@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [root@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.1 00:1d:60:ad:2a:ce .... 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 .... no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone 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" _______________________________________________ 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 owner-freebsd-current@FreeBSD.ORG Fri Jul 10 23:01:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C49ED1065670 for ; Fri, 10 Jul 2009 23:01:19 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 54FE48FC08 for ; Fri, 10 Jul 2009 23:01:19 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fxm24 with SMTP id 24so965386fxm.43 for ; Fri, 10 Jul 2009 16:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QDwv2/v5GExFu4nGHdbY2xZ+bnjY8nXu8Ljs7bJJRxw=; b=ZjJSXYX3Wu+E9+aZACbjhOSVk6qZ5/Ii+HLUUpSAuKoSRgcCVJQj4tB23niWpRhIr1 k+0DGSX7mlkqW8azHmRoAlTyH0kPBI7xX42rx46LbulH+xfnfFK1v0tRKVPSZx38LaZA xownVTBzQzOA7/23J3QD7GhOyHgaHj5zpwcNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FUm7Ku81wK+sXkviVUdKfpIpEZlE7zdckHFUOMxHAKX0GpC0fQ0Fkb3AiVpw+M3tT5 mjNv6T5+zzBzVUCAS6xtNQ4uq6YaeoJP4FNwo2w1nBLsuC0IuBdmNQkRrQdw1ZVngkpB IXlGBiXypbgxJ3h1DthCMZrtyydgarmiaFzws= MIME-Version: 1.0 Received: by 10.204.114.140 with SMTP id e12mr2421927bkq.68.1247266878398; Fri, 10 Jul 2009 16:01:18 -0700 (PDT) In-Reply-To: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> Date: Fri, 10 Jul 2009 19:01:18 -0400 Message-ID: <4ad871310907101601h16bb09d1l570f3190f0147db8@mail.gmail.com> From: Glen Barber To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 23:01:20 -0000 Hi, Oliver 2009/7/10 Olivier Cochard-Labb=E9 : > Hi, > > I meet a problem with the 8.0 Beta1 (amd64 and i386) on an Asus K8N4-E > motherboard: > During the kernel load, my system hang (no dump, no error message). > The last messages are (hand copy): > ohci0: irq 21 at device 2.0 on pci0 > ohci0: [ITHREAD] > usbus0: SMM does not respond, resetting > usbus0: reset timeout > ohci0: USB init failed > device_attach: ohci0 attach returned 6 > ehci0: irq 22 at device 2.1 on pci0 > ehci0: [ITHREAD] > > How can I found more technical information where the system hang ? > Are you booting to install or booting an existing installation? If the latter, boot with verbose logging. > This system works great with FreeBSD 7.2. > --=20 Glen Barber From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 02:11:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A04B7106566B for ; Sat, 11 Jul 2009 02:11:07 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 568528FC16 for ; Sat, 11 Jul 2009 02:11:07 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by vwj2 with SMTP id 2so1057147vwj.3 for ; Fri, 10 Jul 2009 19:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mdL5m/Cl2FD6rwXxUgn797sxsplwWPts928h/oQy3Nc=; b=syP7p82OnWQPJCHMCaPMvx2xz/K2/e8L79/B6HEt7FIiMb9cO8zbcE/3yDc5IiNJCK JIXQ/MdjwXhCGj9QsjN/A8mW+exh235euJTPZGUwAOcloBY2LhW3UoM03doKd19YSwOb 62ZCuwH1N50jK8139iVZ5wjCqbKwyjJjDMgUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nNaeKt+mReTBvpmCS0hTGxV1b92fQ6rLF4b0EImIQeYOrOJoktdBRVU+Oy/Mw9ZTP/ GmQxnIoJlsWj3GdHuHVe6vgfkwxVaV+OAF2nI3xVlfjUJcyoFClttXek6+iH7B1EV6Mn j/TCnw03XDE+t47/kgpz2X0I02T7O8R0Wizbc= MIME-Version: 1.0 Received: by 10.220.45.80 with SMTP id d16mr3855966vcf.93.1247278265201; Fri, 10 Jul 2009 19:11:05 -0700 (PDT) In-Reply-To: <20090710211809.GA84773@crodrigues.org> References: <790a9fff0907101159w495b644dge4a4bd81de0bda9b@mail.gmail.com> <20090710211809.GA84773@crodrigues.org> Date: Fri, 10 Jul 2009 21:11:05 -0500 Message-ID: <790a9fff0907101911y7143ed4bnbb050d78ebc21558@mail.gmail.com> From: Scot Hetzel To: Craig Rodrigues Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current Subject: Re: How to create ZFS on Root using MBR slices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 02:11:07 -0000 On Fri, Jul 10, 2009 at 4:18 PM, Craig Rodrigues wrote: > On Fri, Jul 10, 2009 at 01:59:32PM -0500, Scot Hetzel wrote: >> Is there anything wrong with the above install procedure for creating >> a ZFS Root MBR Slice install? > > There are some examples here: > > http://wiki.freebsd.org/ZFSOnRoot > > They are not *quite* what you did, i.e. > example 1 uses a UFS file system to contain /boot > example 2 uses GPT partitioning, not MBR > > Is the stuff there close at all to what you tried? > > -- > Craig Rodrigues > rodrigc@crodrigues.org > I originally had a UFS root, with ZFS /usr and I wanted to go for a complete ZFS solution, no UFS /boot. I was thinking of using the GPT partitioning, but didn't know how to convert my existing MBR drive to a GPT drive and still be able to tripple boot betweeen FreeBSD, Windows XP, and Quick Play. To create my steps to create a ZFS-Only MBR install, I used ideas presented from several sources: 1. ZFSOnRoot w/UFS Boot example 2. ZFS-Only System GPT example 3. FreeBSD root on ZFS http://74.125.155.132/search?q=cache:DzGFvHEH2NwJ:yds.coolrat.org/zfsboot.shtml+zfsboot+freebsd&cd=1&hl=en&ct=clnk&gl=us 4. Booting Freebsd from a root ZFS pool w/standard MBR and partition table http://www.clearchain.com/blog/posts/booting-freebsd-from-a-root-zfs-pool-using-a-standard-mbr-and-partition-table The only thing that wasn't clear is how to write the zfsboot to the drive. Do I need to write zfsboot to ad0, ad0s1, ad0s3? Do I need to skip the first 16 sectors on ad0s3 to save room for zfsboot? Scot From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 03:27:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 968A2106566C; Sat, 11 Jul 2009 03:27:17 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D35688FC0C; Sat, 11 Jul 2009 03:27:16 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl139-187.kln.forthnet.gr [77.49.10.187]) (authenticated bits=0) by igloo.linux.gr (8.14.3/8.14.3/Debian-9) with ESMTP id n6B3EMfc006236; Sat, 11 Jul 2009 06:14:27 +0300 Received: by kobe.laptop (Postfix, from userid 1000) id 9391DBFE5; Sat, 11 Jul 2009 06:14:21 +0300 (EEST) From: Giorgos Keramidas To: kevin References: <4A5777F6.5040700@freebsd.org> Date: Sat, 11 Jul 2009 06:14:20 +0300 In-Reply-To: (kevin's message of "Sat, 11 Jul 2009 02:15:22 +0800") Message-ID: <874otjq5bn.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n6B3EMfc006236 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.837, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.56, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Sam Leffler , freebsd-current@freebsd.org Subject: Re: About iwn firmware X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 03:27:17 -0000 On Sat, 11 Jul 2009 02:15:22 +0800, kevin wrote: >> iwn driver works well when system up.but it is not so robust.it will stop > transfer data and throw some errors in these conditions: > 1 . mount nfs via wireless network,if i transfer a lot of data.it may stop > receiving data after some time. > 2 . wireless network is busy, then some one reboot the wireless AP.it may > throw some errors and stop working. > 3 . Find wireless network works slow and switch to Ethernet,.if try > /etc/rc.d/netif restart, it may throw some errors and stop working. > > all these are fixed by reboot system(reload iwn and iwnfw dose not work at > most time). i also find iwn driver printe a lot of microcode error related > messages when it failed(not easy to reproduce it). > > No official Change Log, i just notice the *description *in gentoo > bug#202818. Gentoo bugs refer to a different kernel altogether, so they are not really very useful, unless they also affect the BSD kernel in a reproducible manner. If you can reproduce some of these bugs with _FreeBSD_, however, please report them and include /var/log/messages output, any dmesg output that could help track the bugs, and/or even kernel backtraces. From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 05:00:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12949106566B for ; Sat, 11 Jul 2009 05:00:53 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B73028FC0A for ; Sat, 11 Jul 2009 05:00:52 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by vwj2 with SMTP id 2so1096421vwj.3 for ; Fri, 10 Jul 2009 22:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=mOCfdsamDjj0GHvMeVQJW0Old3beQq6XyrC9T61C3Wk=; b=nzdKOy4VtNLSXfL5VpDBiM7BRZ0b9Mhl6ODxCTdaq+sLxxp0RbyNmuOvqCYLt6h1cp bLpka2RBqkv/0wSowR9PpzYOUrquUv4Dp61bai65gB+B4ROyiqf+0vcW4W8k2BI3gbGm 8ryxJNiSLK6IIPf8wAlMHqH9XDVe74CCjBO/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=k6BzVnsd07+a+FLa9FaFFCKtlhBBo0fdLZQ4SH/qTkkOhO/qSBILLjm1n/A4DUrCWE P36LIaeUfxlJ/duHuEU8HcYFlFjs83X8Yn/7SSo6wc9Gq6pynUAn9aF3w7T3oC9BIne+ m+rJaJPq9xmXepzpoVmP1aw2PmRFxTpoLGhQw= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.98.194 with SMTP id r2mr4035333vcn.49.1247288452086; Fri, 10 Jul 2009 22:00:52 -0700 (PDT) In-Reply-To: <4ad871310907101601h16bb09d1l570f3190f0147db8@mail.gmail.com> References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> <4ad871310907101601h16bb09d1l570f3190f0147db8@mail.gmail.com> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 11 Jul 2009 07:00:32 +0200 X-Google-Sender-Auth: 231a0f554c343446 Message-ID: <3131aa530907102200h48a556d4i230d583379e35c06@mail.gmail.com> To: Glen Barber Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 05:00:53 -0000 > Are you booting to install or booting an existing installation? =A0If > the latter, boot with verbose logging. > I try to boot from existing installation. here is the verbose logging output (only the last lines): ohci0: irq 21 at device 2.0 on pci0 ohci0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x80000000 ioapci0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 49 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: SMM does not respond, resetting usbus0: reset timeout ohci0: USB init failed device_attach: ohci0 attach returned 6 ehci0: irq 22 at device 2.1 on pci0 ehci0: Lazy allocation of 0x4000 bytes rid 0x10 type 3 at 0x80000000 ehci0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0x80000000 ioapci0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 49 ehci0: [MPSAFE] ehci0: [ITHREAD] From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 06:29:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 495881065672 for ; Sat, 11 Jul 2009 06:29:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id CF3608FC08 for ; Sat, 11 Jul 2009 06:29:13 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bE4xNkVESV0A:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=kes4b6NSFCV0Un9aDoAA:9 a=LbNQ6WI4OGb9dEsaBO9oJuzQWlkA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 221944211; Sat, 11 Jul 2009 08:29:12 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 11 Jul 2009 08:28:49 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> <4ad871310907101601h16bb09d1l570f3190f0147db8@mail.gmail.com> <3131aa530907102200h48a556d4i230d583379e35c06@mail.gmail.com> In-Reply-To: <3131aa530907102200h48a556d4i230d583379e35c06@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907110828.51190.hselasky@c2i.net> Cc: Olivier =?iso-8859-1?q?Cochard-Labb=E9?= , Glen Barber Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 06:29:14 -0000 On Saturday 11 July 2009 07:00:32 Olivier Cochard-Labb=E9 wrote: > usbus0: SMM does not respond, resetting > usbus0: reset timeout > ohci0: USB init failed Looks like something is wrong. What are your BIOS USB settings? =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 08:24:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 975AA106564A for ; Sat, 11 Jul 2009 08:24:19 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 15CDA8FC08 for ; Sat, 11 Jul 2009 08:24:18 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6B8OEuV068989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Jul 2009 18:24:15 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247300655; bh=1/v3/AVgCLBOEMLiScpaezZhPCzq3FzCAr2uzEgIc2w=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=eZGoPXpu3x4n5MvXAAaq2JxC5BkK1fDM9x+SmCOWMuO1gQz+gDEM4/SElYHqyZnDr gL/3qF7fuJIlSxUmxL/U8YrQyx6W05gV9mQXMooEpof42wxuJ5YSyFXPLCDDMT+Dj8 P19XuKX0yC48Q76NvMC7OVl8XskFGMlN2cO/2e7E= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6B8OEe1038185 for ; Sat, 11 Jul 2009 18:24:14 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6B8OEP2038184 for freebsd-current@freebsd.org; Sat, 11 Jul 2009 18:24:14 +1000 (AEST) (envelope-from john) Date: Sat, 11 Jul 2009 18:24:14 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090711082414.GM32316@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6lCXDTVICvIQMz0h" Content-Disposition: inline In-Reply-To: <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 08:24:19 -0000 --6lCXDTVICvIQMz0h Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 10 Jul 2009, 08:42 -0700, Marcel Moolenaar wrote: >=20 > Can you send me the output of "gpart show da0" and "gpart show da0s1". > Could you also send me (or make available for download) a binary dump > of sectors 0 (the MBR), 63 and 64 (the disklabel in slice 1). I have backed out the inclusion of GEOM_BSD in the kernel and no longer have the WARNING messages appearing in dmesg. This "gpart show da0" agrees with fdisk. rwsrv05# gpart show da0 =3D> 63 142263891 da0 MBR (68G) 63 16002 3 !18 (7.8M) 16065 33543720 1 freebsd [active] (16G) 33559785 67103505 2 freebsd (32G) 100663290 41592285 4 freebsd (20G) 142255575 8379 - free - (4.1M) This "gpart show da0s1" (and da0s2) agrees with the 7.2 bsdlabel. rwsrv05# gpart show da0s1 =3D> 0 33543720 da0s1 BSD (16G) 0 1048576 1 freebsd-ufs (512M) 1048576 8388608 2 freebsd-swap (4.0G) 9437184 4194304 5 freebsd-ufs (2.0G) 13631488 19912232 6 freebsd-ufs (9.5G) rwsrv05# gpart show da0s2 =3D> 0 67103505 da0s2 BSD (32G) 0 33554432 4 freebsd-ufs (16G) 33554432 33549073 5 freebsd-ufs (16G) The requested binary sector dumps and sysctl output; and other bsdlabel and fdisk outputs are available here: ftp://ftp4.riverwillow.net.au/8b1/ --=20 John Marshall --6lCXDTVICvIQMz0h Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpYTC0ACgkQw/tAaKKahKKUtQCeIuwcLOMM4xi8neL7AbCEV0j3 xnwAoJZRkAMTI+dXwXT3rZefRfsvWnaM =kfNL -----END PGP SIGNATURE----- --6lCXDTVICvIQMz0h-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 09:10:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D320106566C for ; Sat, 11 Jul 2009 09:10:58 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id A09CA8FC08 for ; Sat, 11 Jul 2009 09:10:57 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6B9ApUr070474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 11 Jul 2009 19:10:51 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1247303451; bh=cW2DgM+QCiM2HEwZgujUhNKJasMT+rD+7TrqoXW5/Qg=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=XsVvXCIndOFSxwBjgMJsIDKMPpSzJlJQxVu+XIGH6iC3SdzjFFq/s5log3wK9CIU2 +7KNCwuPP+zuu02Clkui4uhai9/5wnbhuTy1r8S53175PgeDiB+hBKlLd9sZQETVcK Y6bUYHt/CTOnRZprpuDQPRSAFrSW7dWtOYTKBX8o= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id n6B9AoN2038319 for ; Sat, 11 Jul 2009 19:10:50 +1000 (AEST) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id n6B9AoFh038318 for freebsd-current@freebsd.org; Sat, 11 Jul 2009 19:10:50 +1000 (AEST) (envelope-from john) Date: Sat, 11 Jul 2009 19:10:50 +1000 From: John Marshall To: freebsd-current@freebsd.org Message-ID: <20090711091050.GN32316@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> <1247214510.2437.1693.camel@strangepork.london.mintel.ad> <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> <20090710132429.GA55190@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ublo+h3cBgJ33ahC" Content-Disposition: inline In-Reply-To: <20090710132429.GA55190@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 09:10:58 -0000 --Ublo+h3cBgJ33ahC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 10 Jul 2009, 16:24 +0300, Kostik Belousov wrote: > > Thank you, I see what is going on. Please, try the following patch. Thank you Kostik, I applied your patch to vm_map.c and rebuilt the kernel. Now the process crashes instead - but I think it is getting beyond the point where it was hanging. (gdb) core ntpd.core Core was generated by `ntpd'. Program terminated with signal 11, Segmentation fault. Loaded symbols for /lib/libm.so.5 Loaded symbols for /lib/libcrypto.so.5 Loaded symbols for /lib/libkvm.so.4 Loaded symbols for /usr/lib/libelf.so.1 Loaded symbols for /usr/lib/librt.so.1 Loaded symbols for /lib/libmd.so.4 Loaded symbols for /lib/libc.so.7 Loaded symbols for /libexec/ld-elf.so.1 #0 0x28091f3f in _rtld_thread_init () from /libexec/ld-elf.so.1 (gdb) bt #0 0x28091f3f in _rtld_thread_init () from /libexec/ld-elf.so.1 #1 0x2808360b in dlsym () from /libexec/ld-elf.so.1 #2 0x28083fd6 in dlopen () from /libexec/ld-elf.so.1 #3 0x2831b3a8 in _nsdbtaddsrc () from /lib/libc.so.7 #4 0x28315546 in __ns_samedomain () from /lib/libc.so.7 #5 0x283159f8 in _nsyyparse () from /lib/libc.so.7 #6 0x2831ac8a in nsdispatch () from /lib/libc.so.7 #7 0x2830d2c9 in getservbyname_r () from /lib/libc.so.7 #8 0x2830d31b in getservbyname_r () from /lib/libc.so.7 #9 0x2830cc84 in gethostname () from /lib/libc.so.7 #10 0x2830cd87 in getservbyname () from /lib/libc.so.7 #11 0x28309cf3 in freeaddrinfo () from /lib/libc.so.7 #12 0x28309d38 in freeaddrinfo () from /lib/libc.so.7 #13 0x2830b7c6 in getaddrinfo () from /lib/libc.so.7 #14 0x0804bf53 in getnetnum () #15 0x0804c5dc in getconfig () #16 0x08052565 in ntpdmain () #17 0x08052750 in main () (gdb)=20 I rebuilt ntpd on the patched kernel and it still produces this crash. --=20 John Marshall --Ublo+h3cBgJ33ahC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpYVxoACgkQw/tAaKKahKIe1QCeNSEb9x+WvbJdN6Vu/8Zwoc49 WFQAoIkkBfhZzAVwEGQQ7cnX1HLgOyIc =YZLL -----END PGP SIGNATURE----- --Ublo+h3cBgJ33ahC-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 09:47:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB17C106566B for ; Sat, 11 Jul 2009 09:47:00 +0000 (UTC) (envelope-from astadtler@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id 4BEFE8FC14 for ; Sat, 11 Jul 2009 09:46:59 +0000 (UTC) (envelope-from astadtler@gmail.com) Received: by bwz21 with SMTP id 21so1065244bwz.43 for ; Sat, 11 Jul 2009 02:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=m+zatIl3xHU+yOp4WPtXjvc/t+bBGbA04gxyRjEK/YA=; b=oLoUNPcJOhDeW88S18/5pqEmtrTKnnejN9PgwDF2H77lI0nPKsEU6z0v7olyQk5/bH 50l9VAIehwJU2Z2jB4nraRXfcbeN/w3YcdR1VbtvD7lecIhssnGJt9kGiNiBD7dDKJCS fQZ3/Rm6MtQ+5xX2rBML5F/sGxv5fnRgEwZyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vo3DsIUP+2b9WysGLJTjZt98zKIFSwCLvVrkOTS3Ls0Z1z/0nG48eJCRzA6dlSWgtP 7Z4hgiLmapIswHQxktZxKktTbmYZc+71TjtRQaIFZiElPdIbIHzOk6URBO24XxAp5MkU dL17uCyDGKuc3XGCbI0pyPYHjlXBxIOMNicoY= MIME-Version: 1.0 Received: by 10.204.57.73 with SMTP id b9mr2805812bkh.45.1247305171094; Sat, 11 Jul 2009 02:39:31 -0700 (PDT) Date: Sat, 11 Jul 2009 04:39:31 -0500 Message-ID: <61f56a3b0907110239h54e78666wca9e7e29930ceddf@mail.gmail.com> From: Andrew Stadtler To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 09:47:01 -0000 Using GENERIC kernel with 8.0-BETA1 #2 dmesg with trace: http://pastebin.com/m4423908c ------------------------------------------ Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xffffffff811846a0 frame pointer = 0x28:0xffffffff811846f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) ----------------------------------------- Booting with ACPI disabled gives me this error: ----------------------------------------- Trying to mount root from zfs:zfsroot/root ROOT MOUNT ERROR: If you have invalid mount options, reboot, and try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove the invalid options from /etc/fstab Loader varaibles vfs.root.mountfrom="zfs:zfsroot/zfsroot" vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ----------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 10:03:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 928201065677 for ; Sat, 11 Jul 2009 10:03:44 +0000 (UTC) (envelope-from astadtler@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 174E78FC1A for ; Sat, 11 Jul 2009 10:03:43 +0000 (UTC) (envelope-from astadtler@gmail.com) Received: by fxm24 with SMTP id 24so1081896fxm.43 for ; Sat, 11 Jul 2009 03:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=DV/kvdHBoVKaghifS2fhm9qOvKkZmQjR2dwEj6KwKJE=; b=O8zUShJNWlM24om+Q2W+WZMXEnVDYhH4kNkLvnKtnWJ5JdIcP6+NnV7BRJmwkaRoJ3 ssPGvp5SdSCQ62zLlUuBHRSSfy9ypI29mGWQXFaFnoZ/MAKH0GUVLIG/N1ki/QARecWD 9hOez1r+DstqBPXCpcAD+VuDUhsorhOUTqxQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=OWlh+hRffuhrcbmYqutJe9l3sm8h3dwcnoquDjdKtGetoacBC3s4ELbtTmz8Rv+9XX VcYWXsJJte6Jb+Z8iwEO48Utn+P9zjVUaCxAWBnyuNIAFt20if2L4cP0t11/9SkU32MV Sv5Ohp92lr2ZkF5KKst6YMDTb+Ed82HSt/zmE= MIME-Version: 1.0 Received: by 10.204.119.129 with SMTP id z1mr2842109bkq.67.1247304903045; Sat, 11 Jul 2009 02:35:03 -0700 (PDT) Date: Sat, 11 Jul 2009 04:35:02 -0500 Message-ID: <61f56a3b0907110235y26a3980as5cd7c9f2ee74627d@mail.gmail.com> From: Andrew Stadtler To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 10:03:44 -0000 Using GENERIC kernel with 8.0-BETA1 #2 dmesg with trace: http://pastebin.com/m4423908c ------------------------------------------ Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read instruction, page not present instruction pointer = 0x20:0x0 stack pointer = 0x28:0xffffffff811846a0 frame pointer = 0x28:0xffffffff811846f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) ----------------------------------------- Booting with ACPI disabled gives me this error: ----------------------------------------- Trying to mount root from zfs:zfsroot/root ROOT MOUNT ERROR: If you have invalid mount options, reboot, and try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove the invalid options from /etc/fstab Loader varaibles vfs.root.mountfrom="zfs:zfsroot/zfsroot" vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ----------------------------------------- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 08:32:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB494106566C for ; Sat, 11 Jul 2009 08:32:41 +0000 (UTC) (envelope-from beat@chruetertee.ch) Received: from marvin.chruetertee.ch (marvin.chruetertee.ch [217.150.245.55]) by mx1.freebsd.org (Postfix) with ESMTP id 60FAD8FC12 for ; Sat, 11 Jul 2009 08:32:41 +0000 (UTC) (envelope-from beat@chruetertee.ch) Received: from daedalus.network.local (186-166.79-83.cust.bluewin.ch [83.79.166.186]) (authenticated bits=0) by marvin.chruetertee.ch (8.14.3/8.14.3) with ESMTP id n6B8Wdea062912 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 11 Jul 2009 08:32:40 GMT (envelope-from beat@chruetertee.ch) Message-ID: <4A584E67.3010202@chruetertee.ch> Date: Sat, 11 Jul 2009 10:33:43 +0200 From: =?UTF-8?B?QmVhdCBHw6R0emk=?= User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Attilio Rao References: <4A578470.8080600@chruetertee.ch> <3bbf2fe10907101244v267421fq1e215ca07cf3e53d@mail.gmail.com> In-Reply-To: <3bbf2fe10907101244v267421fq1e215ca07cf3e53d@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sat, 11 Jul 2009 12:05:30 +0000 Cc: freebsd-current@freebsd.org Subject: Re: tmpfs panic: wrong vnode type 0xffffff008547ab10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 08:32:42 -0000 Attilio Rao wrote: > 2009/7/10 Beat Gätzi : >> Hi, >> >> I tried to run my tinderbox with the build directory on tmpfs but the >> system panics with wrong vnode type 0xffffff008547ab10. >> >> This panic is reproducible when mounting the build directory with tmpfs >> and trying to build a port like gcc or openoffice with tinderbox. > > Sorry, tmpfs lookup is broken and can lead to incorrect vnodes handling. > tmpfs should be considered experimental until expressly changed (I > guess we should stress-out that). I see. Thanks for the information. Beat From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 08:59:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF664106566B for ; Sat, 11 Jul 2009 08:59:32 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mail.gmx.com (unknown [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id C6C038FC13 for ; Sat, 11 Jul 2009 08:59:31 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: (qmail invoked by alias); 11 Jul 2009 08:59:28 -0000 Received: from p54B1EB34.dip.t-dialin.net (EHLO [127.0.0.1]) [84.177.235.52] by mail.gmx.com (mp-eu002) with SMTP; 11 Jul 2009 10:59:28 +0200 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX18qCG9/DxsqUDeAIJJQKycHwYum9ui1smD9yhhcMt FfGC+ZJik7bs9x Message-ID: <4A58546A.2040802@gmx.com> Date: Sat, 11 Jul 2009 10:59:22 +0200 From: Christof Schulze User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 CC: FreeBSD Current References: <11167f520907091015l35827121r30b848922425d840@mail.gmail.com> In-Reply-To: <11167f520907091015l35827121r30b848922425d840@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.47 X-Mailman-Approved-At: Sat, 11 Jul 2009 12:06:16 +0000 Subject: Re: FreeBSD 8 BETA1 DHCP trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 08:59:33 -0000 Sam Fourman Jr. schrieb: > Hello list, > > I have had issues obtaining DHCP address on Asus dual nic motherboards > with kernels built after ~ 6-6-2009 (eg nfe0 will not dhcp just times > out but nfe1 will work) > I played with my hardware for a bit before I noticed it was a FreeBSD bug. > sure enough revert back to a 6-1-2009 kernel and nfe0 and 1 dhcp again. > I experience the same on a RELENG_7 that was compiled early july. Christof > Sam Fourman Jr. > > > sfourman@ ~/.wine/drive_c/Program Files/World of Warcraft]$ dmesg > Copyright (c) 1992-2009 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 8.0-BETA1 #0: Tue Jul 7 21:47:44 CDT 2009 > sfourman@:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.64-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 > Features=0xbfebfbff > Features2=0x408e3bd > AMD Features=0x20100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 4294967296 (4096 MB) > avail memory = 3135557632 (2990 MB) > ACPI APIC Table: <022609 APIC1009> > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 1 package(s) x 4 core(s) > 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 > kbd1 at kbdmux0 > acpi0: <022609 XSDT1009> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of fec00000, 1000 (3) failed > acpi0: reservation of fee00000, 1000 (3) failed > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bff00000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 25000000 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > 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) > pci0: at device 1.0 (no driver attached) > pci0: at device 1.1 (no driver attached) > pci0: at device 1.2 (no driver attached) > pci0: at device 1.3 (no driver attached) > pci0: at device 1.4 (no driver attached) > pci0: at device 1.5 (no driver attached) > pci0: at device 1.6 (no driver attached) > pci0: at device 1.7 (no driver attached) > pcib1: irq 16 at device 2.0 on pci0 > pci1: on pcib1 > vgapci0: port 0xdc00-0xdc7f mem > 0xfa000000-0xfaffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq > 16 at device 0.0 on pci1 > nvidia0: on vgapci0 > vgapci0: child nvidia0 requested pci_enable_busmaster > vgapci0: child nvidia0 requested pci_enable_io > vgapci0: child nvidia0 requested pci_enable_io > nvidia0: [GIANT-LOCKED] > nvidia0: [ITHREAD] > pcib2: irq 17 at device 4.0 on pci0 > pci2: on pcib2 > pci0: at device 9.0 (no driver attached) > isab0: port 0x2f00-0x2f7f at device 10.0 on pci0 > isa0: on isab0 > pci0: at device 10.1 (no driver attached) > ohci0: mem 0xf7ffb000-0xf7ffbfff irq > 22 at device 11.0 on pci0 > ohci0: [ITHREAD] > usbus0: on ohci0 > ehci0: mem 0xf7ffac00-0xf7ffacff > irq 23 at device 11.1 on pci0 > ehci0: [ITHREAD] > usbus1: EHCI version 1.0 > usbus1: on ehci0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 13.0 on > pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > atapci1: port > 0xc400-0xc407,0xc080-0xc083,0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb88f > mem 0xf7ff9000-0xf7ff9fff irq 21 at device 14.0 on pci0 > atapci1: [ITHREAD] > ata2: on atapci1 > ata2: [ITHREAD] > ata3: on atapci1 > ata3: [ITHREAD] > atapci2: port > 0xb800-0xb807,0xb480-0xb483,0xb400-0xb407,0xb080-0xb083,0xb000-0xb00f > mem 0xf7ff8000-0xf7ff8fff irq 22 at device 14.1 on pci0 > atapci2: [ITHREAD] > ata4: on atapci2 > ata4: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > atapci3: port > 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f > mem 0xf7ff7000-0xf7ff7fff irq 23 at device 14.2 on pci0 > atapci3: [ITHREAD] > ata6: on atapci3 > ata6: [ITHREAD] > ata7: on atapci3 > ata7: [ITHREAD] > pcib3: at device 15.0 on pci0 > pci3: on pcib3 > fwohci0: port 0xec00-0xec7f mem > 0xfbfff800-0xfbffffff irq 18 at device 7.0 on pci3 > fwohci0: [ITHREAD] > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:1e:8c:00:01:af:44:a4 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0xbcbb0000 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:1e:8c:af:44:a4 > fwe0: Ethernet address: 02:1e:8c:af:44:a4 > fwip0: on firewire0 > fwip0: Firewire address: 00:1e:8c:00:01:af:44:a4 @ 0xfffe00000000, > S400, maxrec 2048 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: fwohci_intr_core: BUS reset > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > hdac0: mem > 0xf7ff0000-0xf7ff3fff irq 21 at device 15.1 on pci0 > hdac0: HDA Driver Revision: 20090624_0136 > hdac0: [ITHREAD] > nfe0: port 0xa080-0xa087 mem > 0xf7ff6000-0xf7ff6fff,0xf7ffa800-0xf7ffa8ff,0xf7ffa400-0xf7ffa40f irq > 20 at device 17.0 on pci0 > miibus0: on nfe0 > e1000phy0: PHY 1 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe0: Ethernet address: 00:23:54:96:dd:8d > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe0: [FILTER] > nfe1: port 0xa000-0xa007 mem > 0xf7ff5000-0xf7ff5fff,0xf7ffa000-0xf7ffa0ff,0xf7ff4c00-0xf7ff4c0f irq > 20 at device 18.0 on pci0 > miibus1: on nfe1 > e1000phy1: PHY 2 on miibus1 > e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > nfe1: Ethernet address: 00:23:54:96:de:2f > nfe1: [FILTER] > nfe1: [FILTER] > nfe1: [FILTER] > nfe1: [FILTER] > nfe1: [FILTER] > nfe1: [FILTER] > nfe1: [FILTER] > nfe1: [FILTER] > pcib4: at device 19.0 on pci0 > pci4: on pcib4 > pcib5: at device 22.0 on pci0 > pci5: on pcib5 > pcib6: at device 23.0 on pci0 > pci6: on pcib6 > pcib7: at device 24.0 on pci0 > pci7: on pcib7 > acpi_button0: on acpi0 > ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found > Package, expected Buffer 20090521 nspredef-1051 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq > 2 on acpi0 > fdc0: [FILTER] > atrtc1: port 0x70-0x71 on acpi0 > cpu0: on acpi0 > ACPI Warning: Incorrect checksum in table [OEMB] - CA, should be C2 > 20090521 tbutils-275 > 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 > pmtimer0 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > atrtc0: at port 0x70 irq 8 on isa0 > atrtc0: Warning: Couldn't map I/O. > atrtc0: Warning: Couldn't map Interrupt. > ppc0: parallel port not found. > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) > firewire0: bus manager 0 > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 480Mbps High Speed USB v2.0 > ad4: 152627MB at ata2-master SATA300 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ad6: 152627MB at ata3-master SATA300 > GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). > ad10: 238475MB at ata5-master SATA300 > acd0: DVDR at ata6-master SATA150 > acd1: DVDR at ata7-master SATA150 > hdac0: HDA Codec #0: Analog Devices AD1988B > pcm0: at cad 0 nid 1 on hdac0 > pcm1: at cad 0 nid 1 on hdac0 > pcm2: at cad 0 nid 1 on hdac0 > GEOM: ad6s1: geometry does not match label (255h,63s != 16h,63s). > uhub0: 10 ports with 10 removable, self powered > SMP: AP CPU #1 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #2 Launched! > WARNING: WITNESS option enabled, expect reduced performance. > Root mount waiting for: usbus1 > uhub1: 10 ports with 10 removable, self powered > Root mount waiting for: usbus1 > ugen0.2: at usbus0 > uhub2: 2> on usbus0 > ugen1.2: at usbus1 > Trying to mount root from ufs:/dev/ad6s1a > uhub2: 4 ports with 2 removable, bus powered > ugen0.3: at usbus0 > ukbd0: addr 3> on usbus0 > kbd2 at ukbd0 > uhid0: addr 3> on usbus0 > ugen0.4: at usbus0 > ums0: addr 4> on usbus0 > ums0: 8 buttons and [XYZ] coordinates ID=0 > ugen0.5: at usbus0 > hid_get_item:304: Number of items truncated to 255 > hid_get_item:304: Number of items truncated to 255 > uhid1: 5> on usbus0 > hid_get_item:304: Number of items truncated to 255 > hid_get_item:304: Number of items truncated to 255 > hid_get_item:304: Number of items truncated to 255 > lock order reversal: > 1st 0xc7826270 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1054 > 2nd 0xc7827df4 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper(c0c5c064,e9884818,c08b5f35,c08a6cdb,c0c5eef9,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a6cdb,c0c5eef9,c6d30910,c6d30840,e9884874,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c5eef9,c7827df4,c0c4dec5,c6d30840,c0c6617e,...) at > _witness_debugger+0x25 > witness_checkorder(c7827df4,9,c0c6617e,823,0,...) at witness_checkorder+0x839 > __lockmgr_args(c7827df4,80100,c7827e10,0,0,...) at __lockmgr_args+0x7a7 > vop_stdlock(e988497c,c08b5cdb,c0c4e0f6,80100,c7827d9c,...) at vop_stdlock+0x62 > VOP_LOCK1_APV(c0d39660,e988497c,c7677764,c0d76700,c7827d9c,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c7827d9c,80100,c0c6617e,823,8,...) at _vn_lock+0x5e > vget(c7827d9c,80100,c76776c0,15e,c0c4e018,...) at vget+0xb9 > devfs_allocv(c7431480,c7619000,e9884a14,9d,c0f17a58,...) at devfs_allocv+0x102 > devfs_root(c7619000,80000,e9884c30,42c,0,...) at devfs_root+0x4a > vfs_donmount(c76776c0,0,c7437300,c7437300,bfbfde39,...) at vfs_donmount+0x14bb > nmount(c76776c0,e9884cf8,c,c76776c0,c0d3f3b8,...) at nmount+0x75 > syscall(e9884d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x33ce7d3b, esp = > 0xbfbfde0c, ebp = 0xbfbfe368 --- > nfe1: link state changed to DOWN > nfe1: link state changed to UP > lock order reversal: > 1st 0xdad11570 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 > 2nd 0xc747c200 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper(c0c5c064,e991c860,c08b5f35,c08a6cdb,c0c5eef9,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a6cdb,c0c5eef9,c6d2cf60,c6d30978,e991c8bc,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c5eef9,c747c200,c0c7f0d0,c6d30978,c0c7ed69,...) at > _witness_debugger+0x25 > witness_checkorder(c747c200,9,c0c7ed69,11d,0,...) at witness_checkorder+0x839 > _sx_xlock(c747c200,0,c0c7ed69,11d,c7823414,...) at _sx_xlock+0x85 > ufsdirhash_acquire(dad11510,e991c9d4,3c,db78b5e4,e991c98c,...) at > ufsdirhash_acquire+0x35 > ufsdirhash_add(c7823414,e991c9d4,5e4,e991c978,e991c97c,...) at > ufsdirhash_add+0x13 > ufs_direnter(c78c2754,c7cf2c90,e991c9d4,e991cbdc,0,...) at ufs_direnter+0x729 > ufs_makeinode(e991cbdc,e991cb48,e991cc00,e991cb1c,c0ba7255,...) at > ufs_makeinode+0x4f8 > ufs_create(e991cc00,e991cc14,e991cb48,e991cb48,0,...) at ufs_create+0x30 > VOP_CREATE_APV(c0d5dc60,e991cc00,e991cbdc,e991cb48,c7a857fc,...) at > VOP_CREATE_APV+0xa5 > uipc_bind(c7a7c9a8,c7682180,c78ad6c0,e991cc60,c08e1e02,...) at uipc_bind+0x32e > sobind(c7a7c9a8,c7682180,c78ad6c0,c7682180,c7532188,...) at sobind+0x23 > kern_bind(c78ad6c0,3,c7682180,c7682180,8094884,...) at kern_bind+0xc2 > bind(c78ad6c0,e991ccf8,c,c0c5f78a,c0d3d5c0,...) at bind+0x46 > syscall(e991cd38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (104, FreeBSD ELF32, bind), eip = 0x33d9bdff, esp = > 0xbfbfe85c, ebp = 0xbfbfe958 --- > lock order reversal: > 1st 0xc838b164 ufs (ufs) @ /usr/src/sys/kern/vfs_syscalls.c:3496 > 2nd 0xdadbd5c0 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:6170 > 3rd 0xc838b058 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper(c0c5c064,eb9ed8c0,c08b5f35,c08a6cdb,c0c5ef12,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a6cdb,c0c5ef12,c6d2cf60,c6d30910,eb9ed91c,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c5ef12,c838b058,c0c51b6a,c6d30910,c0c6617e,...) at > _witness_debugger+0x25 > witness_checkorder(c838b058,9,c0c6617e,823,0,...) at witness_checkorder+0x839 > __lockmgr_args(c838b058,80100,c838b074,0,0,...) at __lockmgr_args+0x7a7 > ffs_lock(eb9eda2c,c08b5cdb,c0c65671,80100,c838b000,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0d5dc60,eb9eda2c,c83ab0a4,c0d76700,c838b000,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c838b000,80100,c0c6617e,823,4,...) at _vn_lock+0x5e > vget(c838b000,80100,c83ab000,50,0,...) at vget+0xb9 > vfs_hash_get(c761ea10,11606,80000,c83ab000,eb9edb88,...) at vfs_hash_get+0xe6 > ffs_vgetf(c761ea10,11606,80000,eb9edb88,1,...) at ffs_vgetf+0x49 > softdep_sync_metadata(c838b10c,0,c0c7e9e2,146,0,...) at > softdep_sync_metadata+0x5ba > ffs_syncvnode(c838b10c,1,c83c7e58,dad,c838b1b4,...) at ffs_syncvnode+0x3e2 > ffs_fsync(eb9edc5c,eb9edcf8,0,eb9edc5c,eb9edc80,...) at ffs_fsync+0x27 > VOP_FSYNC_APV(c0d5dc60,eb9edc5c,c0c67206,dad,0,...) at VOP_FSYNC_APV+0xa5 > fsync(c83ab000,eb9edcf8,4,c0c7d380,c0d3d4c4,...) at fsync+0x1df > syscall(eb9edd38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (95, FreeBSD ELF32, fsync), eip = 0x341ec127, esp = > 0xbfbfe19c, ebp = 0xbfbfe1b8 --- > lock order reversal: > 1st 0xc7a6b52c filedesc structure (filedesc structure) @ > /usr/src/sys/kern/kern_descrip.c:1088 > 2nd 0xc8439488 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4091 > KDB: stack backtrace: > db_trace_self_wrapper(c0c5c064,e99b1a2c,c08b5f35,c08a6cdb,c0c5eef9,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a6cdb,c0c5eef9,c6d2d238,c6d30910,e99b1a88,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c5eef9,c8439488,c0c51b6a,c6d30910,c0c6617e,...) at > _witness_debugger+0x25 > witness_checkorder(c8439488,9,c0c6617e,ffb,c84394a4,...) at > witness_checkorder+0x839 > __lockmgr_args(c8439488,80400,c84394a4,0,0,...) at __lockmgr_args+0x7a7 > ffs_lock(e99b1b98,4,0,80400,c8439430,...) at ffs_lock+0x8a > VOP_LOCK1_APV(c0d5dc60,e99b1b98,c0c53d5d,c0d76700,c8439430,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(c8439430,80400,c0c6617e,ffb,e99b1bf4,...) at _vn_lock+0x5e > vfs_knllock(c8439430,0,c0c53d5d,696,c836b4c8,...) at vfs_knllock+0x29 > knlist_remove_kq(0,e99b1c14,c0900ee9,c8438580,c836b4c8,...) at > knlist_remove_kq+0x85 > knlist_remove(c8438580,c836b4c8,0,e99b1c40,c0844625,...) at knlist_remove+0x1b > filt_vfsdetach(c836b4c8,0,c0c53d5d,777,19,...) at filt_vfsdetach+0x39 > knote_fdclose(c7995240,12b9,c0c538a5,440,c7a6b52c,...) at knote_fdclose+0xf5 > kern_close(c7995240,12b9,e99b1d2c,c0b998e3,c7995240,...) at kern_close+0xd2 > close(c7995240,e99b1cf8,4,c0c5f78a,c0d3cb08,...) at close+0x1a > syscall(e99b1d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x33f7a9e3, esp = > 0xbfbfe6bc, ebp = 0xbfbfe6d8 --- > acquiring duplicate lock of same type: "ftlk" > 1st ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:177 > 2nd ftlk @ /usr/src/sys/modules/linux/../../compat/linux/linux_futex.c:203 > KDB: stack backtrace: > db_trace_self_wrapper(c0c5c064,eba20b58,c08b5f35,c08a6cdb,c0c5edec,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a6cdb,c0c5edec,c1104957,c6d30ec0,eba20bb4,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c5edec,c1104993,c1104957,cb,0,...) at _witness_debugger+0x25 > witness_checkorder(c7d2fc00,9,c1104957,cb,0,...) at witness_checkorder+0x469 > _sx_xlock(c7d2fc00,0,c1104957,cb,0,...) at _sx_xlock+0x85 > futex_get0(c0ee7cf0,c862b9a4,c0ee7cf0,c0d44960,c0c9133c,...) at futex_get0+0x116 > linux_sys_futex(c862b900,eba20cf8,eba20d18,eba20d1c,c1107f40,...) at > linux_sys_futex+0x6f > syscall(eba20d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (240, Linux ELF, linux_sys_futex), eip = 0x34399533, esp = > 0xbfbfbeec, ebp = 0x4000001 --- > lock order reversal: > 1st 0xc7a6b52c filedesc structure (filedesc structure) @ > /usr/src/sys/kern/kern_descrip.c:1088 > 2nd 0xcc545ce8 pseudofs (pseudofs) @ /usr/src/sys/kern/vfs_subr.c:4091 > KDB: stack backtrace: > db_trace_self_wrapper(c0c5c064,e99b1a34,c08b5f35,c08a6cdb,c0c5eef9,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08a6cdb,c0c5eef9,c6d2d238,c6d30b80,e99b1a90,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c5eef9,cc545ce8,c0c4e978,c6d30b80,c0c6617e,...) at > _witness_debugger+0x25 > witness_checkorder(cc545ce8,9,c0c6617e,ffb,cc545d04,...) at > witness_checkorder+0x839 > __lockmgr_args(cc545ce8,80400,cc545d04,0,0,...) at __lockmgr_args+0x7a7 > vop_stdlock(e99b1b98,4,0,80400,cc545c90,...) at vop_stdlock+0x62 > VOP_LOCK1_APV(c0d3a320,e99b1b98,c0c53d5d,c0d76700,cc545c90,...) at > VOP_LOCK1_APV+0xb5 > _vn_lock(cc545c90,80400,c0c6617e,ffb,e99b1bf4,...) at _vn_lock+0x5e > vfs_knllock(cc545c90,0,c0c53d5d,696,c7e16154,...) at vfs_knllock+0x29 > knlist_remove_kq(0,e99b1c14,c0900ee9,c9358580,c7e16154,...) at > knlist_remove_kq+0x85 > knlist_remove(c9358580,c7e16154,0,e99b1c40,c0844625,...) at knlist_remove+0x1b > filt_vfsdetach(c7e16154,0,c0c53d5d,777,1,...) at filt_vfsdetach+0x39 > knote_fdclose(c7995240,2061,c0c538a5,440,c7a6b52c,...) at knote_fdclose+0xf5 > kern_close(c7995240,2061,e99b1d2c,c0b998e3,c7995240,...) at kern_close+0xd2 > close(c7995240,e99b1cf8,4,c0c796fe,c0d3cb08,...) at close+0x1a > syscall(e99b1d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (6, FreeBSD ELF32, close), eip = 0x33f7a9e3, esp = > 0xbfbfe67c, ebp = 0xbfbfe698 --- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 12:42:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E80D5106564A for ; Sat, 11 Jul 2009 12:42:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 801968FC18 for ; Sat, 11 Jul 2009 12:42:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n6BCg6pA083086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Jul 2009 15:42:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n6BCg6Ux006501 for ; Sat, 11 Jul 2009 15:42:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6BCg6CT006500 for freebsd-current@freebsd.org; Sat, 11 Jul 2009 15:42:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 11 Jul 2009 15:42:06 +0300 From: Kostik Belousov To: freebsd-current@freebsd.org Message-ID: <20090711124206.GF55190@deviant.kiev.zoral.com.ua> References: <20090709060556.GA27373@rwpc12.mby.riverwillow.net.au> <20090709073054.GB27373@rwpc12.mby.riverwillow.net.au> <20090709085242.GC27373@rwpc12.mby.riverwillow.net.au> <20090709142121.GS55190@deviant.kiev.zoral.com.ua> <20090710035849.GB31950@rwpc12.mby.riverwillow.net.au> <1247214510.2437.1693.camel@strangepork.london.mintel.ad> <20090710114234.GF32316@rwpc12.mby.riverwillow.net.au> <20090710132429.GA55190@deviant.kiev.zoral.com.ua> <20090711091050.GN32316@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4fo3mGi7Q6pk/+I3" Content-Disposition: inline In-Reply-To: <20090711091050.GN32316@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: Process stuck in vmmaps on 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 12:42:12 -0000 --4fo3mGi7Q6pk/+I3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 11, 2009 at 07:10:50PM +1000, John Marshall wrote: > On Fri, 10 Jul 2009, 16:24 +0300, Kostik Belousov wrote: > > > > Thank you, I see what is going on. Please, try the following patch. >=20 > Thank you Kostik, >=20 > I applied your patch to vm_map.c and rebuilt the kernel. Now the > process crashes instead - but I think it is getting beyond the point > where it was hanging. >=20 > (gdb) core ntpd.core > Core was generated by `ntpd'. > Program terminated with signal 11, Segmentation fault. > Loaded symbols for /lib/libm.so.5 > Loaded symbols for /lib/libcrypto.so.5 > Loaded symbols for /lib/libkvm.so.4 > Loaded symbols for /usr/lib/libelf.so.1 > Loaded symbols for /usr/lib/librt.so.1 > Loaded symbols for /lib/libmd.so.4 > Loaded symbols for /lib/libc.so.7 > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x28091f3f in _rtld_thread_init () from /libexec/ld-elf.so.1 > (gdb) bt > #0 0x28091f3f in _rtld_thread_init () from /libexec/ld-elf.so.1 > #1 0x2808360b in dlsym () from /libexec/ld-elf.so.1 > #2 0x28083fd6 in dlopen () from /libexec/ld-elf.so.1 > #3 0x2831b3a8 in _nsdbtaddsrc () from /lib/libc.so.7 > #4 0x28315546 in __ns_samedomain () from /lib/libc.so.7 > #5 0x283159f8 in _nsyyparse () from /lib/libc.so.7 > #6 0x2831ac8a in nsdispatch () from /lib/libc.so.7 > #7 0x2830d2c9 in getservbyname_r () from /lib/libc.so.7 > #8 0x2830d31b in getservbyname_r () from /lib/libc.so.7 > #9 0x2830cc84 in gethostname () from /lib/libc.so.7 > #10 0x2830cd87 in getservbyname () from /lib/libc.so.7 > #11 0x28309cf3 in freeaddrinfo () from /lib/libc.so.7 > #12 0x28309d38 in freeaddrinfo () from /lib/libc.so.7 > #13 0x2830b7c6 in getaddrinfo () from /lib/libc.so.7 > #14 0x0804bf53 in getnetnum () > #15 0x0804c5dc in getconfig () > #16 0x08052565 in ntpdmain () > #17 0x08052750 in main () > (gdb)=20 >=20 > I rebuilt ntpd on the patched kernel and it still produces this crash. This is obviously different issue. Besiddes, backtrace does not make much sense. You need to rebuild and install lib/libc, lib/libthr and libexec/rtld-elf with debugging symbols. Easiest way to do this is to enter into each listed src/ subdirectory and do make obj make clean make depend make all install DEBUG_FLAGS=3D-g and then start ntpd again and get the backtrace, might by "bt full" will be more informative. BTW, do you use NIS ? --4fo3mGi7Q6pk/+I3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpYiJ4ACgkQC3+MBN1Mb4h/yQCdFcFikuCXhDT1vZAHzF4taV9Q 8dcAoKNoxRi2tD2QUT04wwrMgMYNHLXi =H2XQ -----END PGP SIGNATURE----- --4fo3mGi7Q6pk/+I3-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 12:49:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1285F1065673 for ; Sat, 11 Jul 2009 12:49:50 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id EF2758FC13 for ; Sat, 11 Jul 2009 12:49:48 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6BCZrJS016286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 11 Jul 2009 14:35:54 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <128E7C52-CCBD-4BAF-A4AE-1D914A3968CB@lassitu.de> From: Stefan Bethke To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 14:35:53 +0200 X-Mailer: Apple Mail (2.935.3) Subject: ppp triggers GPF panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 12:49:50 -0000 Yesterday's -current, amd64, C2D, 4 GB RAM. Full dmesg below. Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff802fc2ce stack pointer = 0x28:0xffffff8000037b10 frame pointer = 0x28:0xffffff8000037b30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (swi1: netisr 0) [thread pid 12 tid 100007 ] Stopped at _mtx_lock_sleep+0x4e: movl 0x288(%rcx),%esi Didn't capture anything else there. This happened when my ADSL link was forced down (24h connection reset). After fixing the file system (UFS2 + softupdates on /), I got another "panic: spin lock held too long" on rebooting. Then, the GPF panic happened again as ppp was trying to establish the connection: Fatal trap 9: general protection fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xffffffff802fc2f5 stack pointer = 0x28:0xffffff80750a0540 frame pointer = 0x28:0xffffff80750a0560 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 726 (ppp) [thread pid 726 tid 100098 ] Stopped at _mtx_lock_sleep+0x75: movl 0x288(%r9),%r8d db> bt Tracing pid 726 tid 100098 td 0xffffff0002194ab0 _mtx_lock_sleep() at _mtx_lock_sleep+0x75 _mtx_lock_flags() at _mtx_lock_flags+0x43 netisr_queue_internal() at netisr_queue_internal+0x4f netisr_queue_src() at netisr_queue_src+0x3c rt_newaddrmsg() at rt_newaddrmsg+0x1d1 rtinit() at rtinit+0x3c0 in_ifinit() at in_ifinit+0x2f0 in_control() at in_control+0xf12 ifioctl() at ifioctl+0xfc1 kern_ioctl() at kern_ioctl+0xf6 ioctl() at ioctl+0xfd syscall() at syscall+0x19e Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80128ef5c, rsp = 0x7fffffffd928, rbp = 0x7fffffffdcb0 --- db> ps pid ppid pgrp uid state wmesg wchan cmd 1685 1684 1685 1000 Ss+ ttyin 0xffffff00023e04a8 bash 1684 1682 1682 1000 S select 0xffffff0002f18540 sshd 1682 1596 1682 0 Ss sbwait 0xffffff000218f144 sshd 1681 1578 1578 80 S accept 0xffffff0002aaddae httpd 1680 1578 1578 80 S accept 0xffffff0002aaddae httpd 1679 1578 1578 80 S accept 0xffffff0002aaddae httpd 1678 1578 1578 80 S accept 0xffffff0002aaddae httpd 1677 1578 1578 80 S accept 0xffffff0002aaddae httpd 1676 1 1676 0 Ss+ ttyin 0xffffff0001f998a8 getty 1675 1 1675 0 Ss+ ttyin 0xffffff0001fa1ca8 getty 1674 1 1674 0 Ss+ ttyin 0xffffff0001fa88a8 getty 1673 1 1673 0 Ss+ ttyin 0xffffff0001fa18a8 getty 1672 1 1672 0 Ss+ ttyin 0xffffff0001fa70a8 getty 1671 1 1671 0 Ss+ ttyin 0xffffff0001fa7ca8 getty 1670 1 1670 0 Ss+ ttyin 0xffffff0001fa80a8 getty 1669 1 1669 0 Ss+ ttyin 0xffffff0001f9fca8 getty 1668 1 1668 0 Ss+ ttyin 0xffffff0001fa74a8 getty 1666 1664 27 0 S+ nanslp 0xffffffff807b5328 sleep 1665 1 27 0 S+ piperd 0xffffff0002ba7b60 logger 1664 1 27 0 S+ wait 0xffffff000278c460 sh 1643 1 1643 0 Ss select 0xffffff00027df7c0 inetd 1610 1 1610 0 Ss nanslp 0xffffffff807b5328 cron 1598 1121 1598 0 Ss (threaded) sshguard 100142 S nanslp 0xffffffff807b5328 sshguard 100056 S piperd 0xffffff0002762888 initial thread 1596 1 1596 0 Ss select 0xffffff00026ef840 sshd 1578 1 1578 0 Ss select 0xffffff0002702040 httpd 1539 1 1539 0 Ss select 0xffffff0002027540 avahi- dnsconfd 1534 1 1534 558 Ss select 0xffffff0002900840 avahi- daemon 1529 1 1529 556 Ss select 0xffffff0002c47440 dbus- daemon 1517 1 1517 0 Ss select 0xffffff00027001c0 iscsi- target 1512 1 1512 0 S+ select 0xffffff00020a8940 afpd 1496 1 1496 0 Ss nanslp 0xffffffff807b5328 openvpn 1483 1 1483 0 Ss nanslp 0xffffffff807b5328 openvpn 1470 1 1470 136 Ss select 0xffffff00028e7240 dhcpd 1344 1 1344 0 Ss rpcsvc 0xffffff00020a90a0 NLM: master 1331 1 1331 0 Ss select 0xffffff00027df940 rpc.statd 1318 1317 1317 0 S (threaded) nfsd 100126 S rpcsvc 0xffffff0002901720 nfsd: service 100125 S rpcsvc 0xffffff00020329a0 nfsd: service 100124 S rpcsvc 0xffffff0002032ca0 nfsd: service 100101 S rpcsvc 0xffffff0002901b20 nfsd: master 1317 1 1317 0 Ss select 0xffffff00029012c0 nfsd 1302 1 1302 0 Ss select 0xffffff0002901cc0 mountd 1298 1 1298 0 Ss select 0xffffff0002901940 rpcbind 1233 0 0 0 SL mdwait 0xffffff0002760000 [md0] 1193 1 1193 53 Ss (threaded) named 100110 S kqread 0xffffff000288c400 named 100109 S ucond 0xffffff00027ac300 named 100108 S ucond 0xffffff00027ac280 named 100107 S ucond 0xffffff00027ac200 named 100106 S sigwait 0xffffff80750c8a68 named 1121 1 1121 0 Ss bo_wwait 0xffffff00029d68d8 syslogd 908 1 908 0 Ss select 0xffffff00024f8c40 devd 740 0 0 0 SL (threaded) ng_queue 100105 D sleep 0xffffffff80c39f30 [ng_queue1] 100092 D sleep 0xffffffff80c39f30 [ng_queue0] 726 1 726 0 Rs CPU 1 ppp 151 0 0 0 SL tx->tx_s 0xffffff0002397238 [txg_thread_enter] 150 0 0 0 SL tx->tx_q 0xffffff0002397258 [txg_thread_enter] 149 0 0 0 SL vgeom:io 0xffffff00020b1a90 [vdev:worker label/d] 148 0 0 0 SL vgeom:io 0xffffff00020b2710 [vdev:worker label/d] 147 0 0 0 SL vgeom:io 0xffffff00020a9410 [vdev:worker label/d] 146 0 0 0 SL tq->tq_d 0xffffff000155f720 [spa_zio] 145 0 0 0 SL tq->tq_d 0xffffff000155f840 [spa_zio] 144 0 0 0 SL tq->tq_d 0xffffff000155f960 [spa_zio] 143 0 0 0 SL tq->tq_d 0xffffff000155fa80 [spa_zio] 142 0 0 0 SL tq->tq_d 0xffffff000155fba0 [spa_zio] 141 0 0 0 SL tq->tq_d 0xffffff000155fcc0 [spa_zio] 140 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 139 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 138 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 137 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 136 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 135 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 134 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 133 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 132 0 0 0 SL tq->tq_d 0xffffff0001560600 [spa_zio] 131 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 130 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 129 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 128 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 127 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 126 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 125 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 124 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 123 0 0 0 SL tq->tq_d 0xffffff0001560180 [spa_zio] 122 0 0 0 SL tq->tq_d 0xffffff00015602a0 [spa_zio] 121 0 0 0 SL tq->tq_d 0xffffff00015603c0 [spa_zio] 26 0 0 0 SL m:w1 0xffffff0002074a00 [g_mirror diesel_swa] 25 0 0 0 SL gwrite 0xffffff0002023000 [g_mirror diesel_roo] 24 0 0 0 SL flowclea 0xffffffff807b5004 [flowcleaner] 23 0 0 0 SL sdflush 0xffffffff807e88d8 [softdepflush] 22 0 0 0 SL vlruwt 0xffffff0002034000 [vnlru] 21 0 0 0 SL vacv 0xffffffff80a48d40 [vaclean] 20 0 0 0 SL syncer 0xffffffff807d98a0 [syncer] 19 0 0 0 SL psleep 0xffffffff807d93c8 [bufdaemon] 18 0 0 0 SL pgzero 0xffffffff807ea2ec [pagezero] 17 0 0 0 SL psleep 0xffffffff807e9688 [vmdaemon] 16 0 0 0 SL psleep 0xffffffff807e964c [pagedaemon] 15 0 0 0 SL l2arc_fe 0xffffffff80a52620 [l2arc_feed_thread] 14 0 0 0 SL arc_recl 0xffffffff80a4a040 [arc_reclaim_thread] 9 0 0 0 SL pftm 0xffffffff80b25d20 [pfpurge] 8 0 0 0 SL waiting_ 0xffffffff807dcd60 [sctp_iterator] 7 0 0 0 SL ccb_scan 0xffffffff80799be0 [xpt_thrd] 13 0 0 0 SL - 0xffffffff807b5004 [yarrow] 6 0 0 0 SL tq->tq_d 0xffffff0001560060 [system_taskq] 5 0 0 0 SL tq->tq_d 0xffffff0001560060 [system_taskq] 4 0 0 0 SL - 0xffffffff807b17e8 [g_down] 3 0 0 0 SL - 0xffffffff807b17e0 [g_up] 2 0 0 0 SL - 0xffffffff807b17d0 [g_event] 12 0 0 0 WL (threaded) intr 100030 I [irq1: atkbd0] 100029 I [swi0: uart] 100028 I [irq19: atapci0+] 100026 I [irq9: acpi0] 100025 I [swi6: task queue] 100024 I [swi6: Giant taskq] 100022 I [swi5: +] 100021 I [swi2: cambio] 100008 I [swi3: vm] 100007 I [swi1: netisr 0] 100006 I [swi4: clock] 100005 I [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 Run CPU 0 [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 SLs wait 0xffffff00014ce8c0 [init] 10 0 0 0 SL audit_wo 0xffffffff807e7c30 [audit] 0 0 0 0 SLs (threaded) kernel 100027 D - 0xffffff0001620400 [em0 taskq] 100023 D - 0xffffff00015afa80 [thread taskq] 100019 D - 0xffffff0001540780 [kqueue taskq] 100018 D - 0xffffff0001540800 [acpi_task_2] 100017 D - 0xffffff0001540800 [acpi_task_1] 100016 D - 0xffffff0001540800 [acpi_task_0] 100012 D - 0xffffff00014ca200 [firmware taskq] 100000 D sched 0xffffffff807b18e0 [swapper] db> Full dmesg: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #5 r195556: Fri Jul 10 19:12:08 CEST 2009 root@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL module_register: module probe already exists! Module probe failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.78-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 =0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4008845312 (3823 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) 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/ ACPI Warning: 32/64X FACS address mismatch in FADT - BDB69F40/ 0BDB6FE40, using 32 20090521 tbfadt-586 ioapic0 irqs 0-23 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 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf1c0-0xf1c7 mem 0xd0000000-0xd03fffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 agp0: f on vgapci0 agp0: detected 32764k stolen memory agp0: apertre size is 256M vgapci1: mem 0xd0400000-0xd04fffff at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) em0: port 0xf100-0xf11f mem 0xd0500000-0xd051ffff,0xd0524000-0xd0524fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:c0:7d:8c:50 pci0: at device 26.0 (no driver attached) pci0: at device 26.1 (no driver attached) pci0: at device 26.2 (no driver attached) pci0: at device 26.7 (no driver attached) pci0: at device 27.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib1: at device 30.0 on pci0 pci1: on pcib1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf1b0-0xf1b7,0xf1a0-0xf1a3,0xf190-0xf197,0xf180-0xf183,0xf020-0xf03f mem 0xd0525000-0xd05257ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xf170-0xf177,0xf160-0xf163,0xf150-0xf157,0xf140-0xf143,0xf130-0xf13f, 0xf120-0xf12f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata8: on atapci1 ata8: [ITHREAD] ata9: on atapci1 ata9: [ITHREAD] acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (38400,n,8,1) atrtc0: port 0x70-0x71 irq 8 on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a0a2006000a20 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on pu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a0a2006000a20 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xcc800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 13 ZFS storage pool version 13 ad4: 953869MB at ata2-master SATA300 ad6: 953869MB at ata3-master SATA300 ad8: 953869MB at ata4-master SATA300 SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/diesel_root launched (3/3). GEOM_MIRROR: Device mirror/diesel_swap launched (3/3). Trying to mount root from ufs:/dev/mirror/diesel_root -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 12:49:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E883106564A for ; Sat, 11 Jul 2009 12:49:51 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 931B08FC15 for ; Sat, 11 Jul 2009 12:49:50 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6BCXRPO016181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 11 Jul 2009 14:33:27 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <596C18F0-5F5F-44EF-A88D-122FEC6A0FCD@lassitu.de> From: Stefan Bethke To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 14:33:27 +0200 X-Mailer: Apple Mail (2.935.3) Subject: panic: spin lock held too long on reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 12:49:51 -0000 Got another one of these. -current from yesterday, amd64. Full dmesg below. # reboot Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 done All buffers synced. GEOM_MIRROR: Device diesel_root: provider mirror/diesel_root destroyed. GEOM_MIRROR: Device diesel_root destroyed. Uptime: 11m40s GEOM_MIRROR: Device diesel_swap: provider mirror/diesel_swap destroyed. GEOM_MIRROR: Device diesel_swap destroyed. Rebooting... cpu_reset: Stopping other CPUs spin lock 0xffffffff807bc6c0 (sched lock 1) held by 0xffffff00014d1ab0 (tid 100002) too long panic: spin lock held too long cpuid = 0 KDB: enter: panic [thread pid 161 tid 100100 ] Stopped at kdb_enter+0x3d: movq $0,0x4a0cf0(%rip) db:0:kdb.enter.panic> textdump set textdump set db:0:kdb.enter.panic> capture on db:0:kdb.enter.panic> run lockinfo db:1:lockinfo> show locks No such command db:1:locks> show alllocks No such command db:1:alllocks> show lockedvnods Locked vnodes db:0:kdb.enter.panic> show pcpu cpuid = 0 dynamic pcpu = 0x406c52 curthread = 0xffffff000217b390: pid 161 "reboot" curpcb = 0xffffff80750aad40 fpcurthread = none idlethread = 0xffffff00014d1390: pid 11 "idle: cpu0" curpmap = 0 tssp = 0xffffffff80822980 commontssp = 0xffffffff80822980 rsp0 = 0xffffff80750aad40 gs32p = 0xffffffff808217b8 ldt = 0xffffffff808217f8 tss = 0xffffffff808217e8 db:0:kdb.enter.panic> bt Tracing pid 161 tid 100100 td 0xffffff000217b390 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at _mtx_lock_spin+0x9e _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 sched_balance_group() at sched_balance_group+0xe8 sched_balance_group() at sched_balance_group+0x25b sched_balance() at sched_balance+0xa2 sched_clock() at sched_clock+0xf6 statclock() at statclock+0xbd lapic_handle_timer() at lapic_handle_timer+0x197 Xtimerint() at Xtimerint+0x8c --- interrupt, rip = 0xffffffff8055c5d4, rsp = 0xffffff80750aaa90, rbp = 0xffffff80750aaab0 --- DELAY() at DELAY+0x64 cpu_reset() at cpu_reset+0xdd boot() at boot+0x2e6 reboot() at reboot+0x68 syscall() at syscall+0x19e Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x80078f85c, rsp = 0x7fffffffece8, rbp = 0 --- db:0:kdb.enter.panic> ps pid ppid pgrp uid state wmesg wchan cmd 161 1 161 0 R+ CPU 0 reboot 141 0 0 0 SL tx->tx_s 0xffffff000242f638 [txg_thread_enter] 140 0 0 0 SL tx->tx_q 0xffffff000242f658 [txg_thread_enter] 139 0 0 0 SL vgeom:io 0xffffff00024d1210 [vdev:worker label/d] 138 0 0 0 SL vgeom:io 0xffffff00024d1310 [vdev:worker label/d] 137 0 0 0 SL vgeom:io 0xffffff0002445c10 [vdev:worker label/d] 136 0 0 0 SL tq->tq_d 0xffffff000155f600 [spa_zio] 135 0 0 0 SL tq->tq_d 0xffffff000155f720 [spa_zio] 134 0 0 0 SL tq->tq_d 0xffffff000155f840 [spa_zio] 133 0 0 0 SL tq->tq_d 0xffffff000155f960 [spa_zio] 132 0 0 0 SL tq->tq_d 0xffffff000155fa80 [spa_zio] 131 0 0 0 SL tq->tq_d 0xffffff000155fba0 [spa_zio] 130 0 0 0 SL tq->tq_d 0xffffff000155fcc0 [spa_zio] 129 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 128 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 127 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 126 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 125 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 124 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 123 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 122 0 0 0 SL tq->tq_d 0xffffff000155fde0 [spa_zio] 121 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 120 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 119 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 118 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 117 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 116 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 115 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 114 0 0 0 SL tq->tq_d 0xffffff00015604e0 [spa_zio] 113 0 0 0 SL tq->tq_d 0xffffff0001560180 [spa_zio] 112 0 0 0 SL tq->tq_d 0xffffff00015602a0 [spa_zio] 111 0 0 0 SL tq->tq_d 0xffffff00015603c0 [spa_zio] 26 0 0 0 SL flowclea 0xffffffff807b5004 [flowcleaner] 25 0 0 0 SL sdflush 0xffffffff807e88d8 [softdepflush] 24 0 0 0 SL kpsusp 0xffffff0002045580 [vnlru] 23 0 0 0 SL vacv 0xffffffff80a48d40 [vaclean] 22 0 0 0 SL kpsusp 0xffffff000202b120 [syncer] 21 0 0 0 SL kpsusp 0xffffff000202b580 [bufdaemon] 20 0 0 0 SL pgzero 0xffffffff807ea2ec [pagezero] 19 0 0 0 SL psleep 0xffffffff807e9688 [vmdaemon] 18 0 0 0 SL psleep 0xffffffff807e964c [pagedaemon] 15 0 0 0 SL l2arc_fe 0xffffffff80a52620 [l2arc_feed_thread] 14 0 0 0 RL [arc_reclaim_thread] 9 0 0 0 SL pftm 0xffffffff80b25d20 [pfpurge] 8 0 0 0 SL waiting_ 0xffffffff807dcd60 [sctp_iterator] 7 0 0 0 SL ccb_scan 0xffffffff80799be0 [xpt_thrd] 13 0 0 0 RL [yarrow] 6 0 0 0 SL tq->tq_d 0xffffff0001560060 [system_taskq] 5 0 0 0 SL tq->tq_d 0xffffff0001560060 [system_taskq] 4 0 0 0 SL - 0xffffffff807b17e8 [g_down] 3 0 0 0 SL - 0xffffffff807b17e0 [g_up] 2 0 0 0 SL - 0xffffffff807b17d0 [g_event] 12 0 0 0 LL (threaded) intr 100030 I [irq1: atkbd0] 100029 I [swi0: uart] 100028 I [irq19: atapci0+] 100026 I [irq9: acpi0] 100025 I [swi6: task queue] 100024 I [swi6: Giant taskq] 100022 I [swi5: +] 100021 I [swi2: cambio] 100008 I [swi3: vm] 100007 I [swi1: netisr 0] 100006 I [swi4: clock] 100005 L *Giant 0xffffff000138be40 [swi4: clock] 11 0 0 0 RL (threaded) idle 100004 CanRun [idle: cpu0] 100003 CanRun [idle: cpu1] 1 0 1 0 RLs CPU 1 [init] 10 0 0 0 SL audit_wo 0xffffffff807e7c30 [audit] 0 0 0 0 SLs (threaded) kernel 100027 D - 0xffffff0001620400 [em0 taskq] 100023 D - 0xffffff00015afa80 [thread taskq] 100019 D - 0xffffff0001540780 [kqueue taskq] 100018 D - 0xffffff0001540800 [acpi_task_2] 100017 D - 0xffffff0001540800 [acpi_task_1] 100016 D - 0xffffff0001540800 [acpi_task_0] 100012 D - 0xffffff00014ca200 [firmware taskq] 100000 D sched 0xffffffff807b18e0 [swapper] 17 1 0 0 ZL [g_mirror diesel_swa] db:0:kdb.enter.panic> alltrace Tracing command reboot pid 161 tid 100100 td 0xffffff000217b390 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at _mtx_lock_spin+0x9e _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x72 sched_balance_group() at sched_balance_group+0xe8 sched_balance_group() at sched_balance_group+0x25b sched_balance() at sched_balance+0xa2 sched_clock() at sched_clock+0xf6 statclock() at statclock+0xbd lapic_handle_timer() at lapic_handle_timer+0x197 Xtimerint() at Xtimerint+0x8c --- interrupt, rip = 0xffffffff8055c5d4, rsp = 0xffffff80750aaa90, rbp = 0xffffff80750aaab0 --- DELAY() at DELAY+0x64 cpu_reset() at cpu_reset+0xdd boot() at boot+0x2e6 reboot() at reboot+0x68 syscall() at syscall+0x19e Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (55, FreeBSD ELF64, reboot), rip = 0x80078f85c, rsp = 0x7fffffffece8, rbp = 0 --- Tracing command txg_thread_enter pid 141 tid 100070 td 0xffffff000218eab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x12b txg_thread_wait() at txg_thread_wait+0x3c txg_sync_thread() at txg_sync_thread+0xf4 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807507dd30, rbp = 0 --- Tracing command txg_thread_enter pid 140 tid 100076 td 0xffffff00021c9000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 txg_thread_wait() at txg_thread_wait+0x79 txg_quiesce_thread() at txg_quiesce_thread+0xb5 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807502ed30, rbp = 0 --- Tracing command vdev:worker label/d pid 139 tid 100073 td 0xffffff000218e000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807501fd30, rbp = 0 --- Tracing command vdev:worker label/d pid 138 tid 100077 td 0xffffff00021c8ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075033d30, rbp = 0 --- Tracing command vdev:worker label/d pid 137 tid 100083 td 0xffffff00021c6390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd vdev_geom_worker() at vdev_geom_worker+0xa3 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075051d30, rbp = 0 --- Tracing command spa_zio pid 136 tid 100084 td 0xffffff00021c6000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075056d30, rbp = 0 --- Tracing command spa_zio pid 135 tid 100048 td 0xffffff00020d2390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fa2d30, rbp = 0 --- Tracing command spa_zio pid 134 tid 100050 td 0xffffff00020cfab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074facd30, rbp = 0 --- Tracing command spa_zio pid 133 tid 100066 td 0xffffff000218fab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074ffcd30, rbp = 0 --- Tracing command spa_zio pid 132 tid 100068 td 0xffffff000218f390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075006d30, rbp = 0 --- Tracing command spa_zio pid 131 tid 100046 td 0xffffff00020d2ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074f98d30, rbp = 0 --- Tracing command spa_zio pid 130 tid 100067 td 0xffffff000218f720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075001d30, rbp = 0 --- Tracing command spa_zio pid 129 tid 100054 td 0xffffff00020cf000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fc0d30, rbp = 0 --- Tracing command spa_zio pid 128 tid 100055 td 0xffffff0002034ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fc5d30, rbp = 0 --- Tracing command spa_zio pid 127 tid 100056 td 0xffffff00020f6720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fcad30, rbp = 0 --- Tracing command spa_zio pid 126 tid 100047 td 0xffffff00020d2720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074f9dd30, rbp = 0 --- Tracing command spa_zio pid 125 tid 100085 td 0xffffff0002169ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807505bd30, rbp = 0 --- Tracing command spa_zio pid 124 tid 100086 td 0xffffff0002169720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075060d30, rbp = 0 --- Tracing command spa_zio pid 123 tid 100062 td 0xffffff0002168ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fe8d30, rbp = 0 --- Tracing command spa_zio pid 122 tid 100051 td 0xffffff00020cf720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fb1d30, rbp = 0 --- Tracing command spa_zio pid 121 tid 100052 td 0xffffff00020cf390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fb6d30, rbp = 0 --- Tracing command spa_zio pid 120 tid 100049 td 0xffffff00020d2000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fa7d30, rbp = 0 --- Tracing command spa_zio pid 119 tid 100078 td 0xffffff00021c8720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075038d30, rbp = 0 --- Tracing command spa_zio pid 118 tid 100087 td 0xffffff0002169390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075065d30, rbp = 0 --- Tracing command spa_zio pid 117 tid 100063 td 0xffffff0002168720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8074fedd30, rbp = 0 --- Tracing command spa_zio pid 116 tid 100079 td 0xffffff00021c8390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807503dd30, rbp = 0 --- Tracing command spa_zio pid 115 tid 100081 td 0xffffff00021c6ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075047d30, rbp = 0 --- Tracing command spa_zio pid 114 tid 100091 td 0xffffff00024d8720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075079d30, rbp = 0 --- Tracing command spa_zio pid 113 tid 100090 td 0xffffff00024d8ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8075074d30, rbp = 0 --- Tracing command spa_zio pid 112 tid 100089 td 0xffffff00024d9000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807506fd30, rbp = 0 --- Tracing command spa_zio pid 111 tid 100088 td 0xffffff00024d9390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff807506ad30, rbp = 0 --- Tracing command flowcleaner pid 26 tid 100045 td 0xffffff0001622ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 flowtable_cleaner() at flowtable_cleaner+0x139 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c90d30, rbp = 0 --- Tracing command softdepflush pid 25 tid 100044 td 0xffffff0002031000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 softdep_flush() at softdep_flush+0x259 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c8bd30, rbp = 0 --- Tracing command vnlru pid 24 tid 100043 td 0xffffff0002031390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd kproc_suspend_check() at kproc_suspend_check+0x62 vnlru_proc() at vnlru_proc+0x40 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c86d30, rbp = 0 --- Tracing command vaclean pid 23 tid 100042 td 0xffffff0002031720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x12b vn_rele_async_cleaner() at vn_rele_asyn_cleaner+0x119 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c81d30, rbp = 0 --- Tracing command syncer pid 22 tid 100041 td 0xffffff0002031ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd kproc_suspend_check() at kproc_suspend_check+0x62 sched_sync() at sched_sync+0x3ae fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c7cd30, rbp = 0 --- Tracing command bufdaemon pid 21 tid 100040 td 0xffffff0002032000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd kproc_suspend_check() at kproc_suspend_check+0x62 buf_daemon() at buf_daemon+0x83 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c77d30, rbp = 0 --- Tracing command pagezero pid 20 tid 100039 td 0xffffff0002032390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 vm_pagezero() at vm_pagezero+0x73 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c72d30, rbp = 0 --- Tracing command vmdaemon pid 19 tid 100038 td 0xffffff0002032720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd vm_daemon() at vm_daemon+0x4d fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c6dd30, rbp = 0 --- Tracing command pagedaemon pid 18 tid 100037 td 0xffffff0002032ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 vm_pageout() at vm_pageout+0x806 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c68d30, rbp = 0 --- Tracing command l2arc_feed_thread pid 15 tid 100034 td 0xffffff00015aeab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x12b l2arc_feed_thread() at l2arc_feed_thread+0x169 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c59d30, rbp = 0 --- Tracing command arc_reclaim_thread pid 14 tid 100033 td 0xffffff0001621000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _cv_timedwait() at _cv_timedwait+0x12b arc_reclaim_thread() at arc_reclaim_thread+0x2ba fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c54d30, rbp = 0 --- Tracing command pfpurge pid 9 tid 100032 td 0xffffff0001621390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 pf_purge_thread() at pf_purge_thread+0x63 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c4fd30, rbp = 0 --- Tracing command sctp_iterator pid 8 tid 100031 td 0xffffff0001621720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd sctp_iterator_thread() at sctp_iterator_thread+0x54 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c4ad30, rbp = 0 --- Tracing command xpt_thrd pid 7 tid 100020 td 0xffffff00015ae000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd xpt_scanner_thread() at xpt_scanner_thread+0x38 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000078d30, rbp = 0 --- Tracing command yarrow pid 13 tid 100015 td 0xffffff00014eb720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 random_kthread() at random_kthread+0x1ad fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800005fd30, rbp = 0 --- Tracing command system_taskq pid 6 tid 100014 td 0xffffff00014ebab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800005ad30, rbp = 0 --- Tracing command system_taskq pid 5 tid 100013 td 0xffffff00014ed000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 taskq_thread() at taskq_thread+0x33b fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000055d30, rbp = 0 --- Tracing command g_down pid 4 tid 100011 td 0xffffff00014d2390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep3() at _sleep+0x2c7 g_io_schedule_down() at g_io_schedule_down+x227 g_down_procbody() at g_down_procbody+0x58 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800004bd30, rbp = 0 --- Tracing command g_up pid 3 tid 100010 td 0xffffff00014d2720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 g_io_schedule_up() at g_io_schedule_up+0xfe g_up_procbody() at g_up_procbody+0x58 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000046d30, rbp = 0 --- Tracing command g_event pid 2 tid 100009 td 0xffffff00014d2ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 g_event_procbody() at g_event_procbody+0x8a fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000041d30, rbp = 0 --- Tracing command intr pid 12 tid 100030 td 0xffffff0001621ab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100029 td 0xffffff0001622000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 ithread_loop() at ithread_loop+0x1bf fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8072c3dd30, rbp = 0 --- Tracing command intr pid 12 tid 100028 td 0xffffff0001622390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 ithread_loop() at ithread_loop+0x1bf fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80000a0d30, rbp = 0 --- Tracing command intr pid 12 tid 100026 td 0xffffff00014ed720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100025 td 0xffffff00014edab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 ithread_loop() at ithread_loop+0x1bf fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000091d30, rbp = 0 --- Tracing command intr pid 12 tid 100024 td 0xffffff00015ac000 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100022 td 0xffffff00015ac720 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100021 td 0xffffff00015acab0 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100008 td 0xffffff00014e0000 fork_trampolinme() at fork_trampoline Tracing command intr pid 12 tid 10000 td 0xffffff00014e0390 fork_trampoline() at fork_trampoline Tracing command intr pid 12 tid 100006 td 0xffffff00014e0720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 ithread_loop() at ithread_loop+0x1bf fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000032d30, rbp = 0 --- Tracing command intr pid 12 tid 100005 td 0xffffff00014d1000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 turnstile_wait() at turnstile_wait+0x1b5 _mtx_lock_sleep() at _mtx_lock_sleep+0xb0 _mtx_lock_flags() at _mtx_lock_flags+0x43 softclock() at softclock+0x24d intr_event_execute_handlers() at intr_event_execute_handlers+0x67 ithread_loop() at ithread_loop+0x8e fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800002dd30, rbp = 0 --- Tracing command idle pid 11 tid 100004 td 0xffffff00014d1390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sched_idletd() at sched_idletd+0x24c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000028d30, rbp = 0 --- Tracing command idle pid 11 tid 100003 td 0xffffff00014d1720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sched_idletd() at sched_idletd+0x24c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000023d30, rbp = 0 --- Tracing command init pid 1 tid 100002 td 0xffffff00014d1ab0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x269 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0xffffffff802fc81c, rsp = 0xffffff8000013fe0, rbp = 0xffffff800001ea80 --- _thread_lock_flags() at _thread_lock_flags+0x10c signotify() at signotify+0xdf tdsignal() at tdsignal+0x195 trapsignal() at trapsignal+0x12f trap() at trap+0x254 calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x4007d0, rsp = 0x7fffffffe3a8, rbp = 0x401d40 --- Tracing command audit pid 10 tid 100001 td 0xffffff00014d2000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _cv_wait() at _cv_wait+0x111 audit_worker() at audit_worker+0x31c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000019d30, rbp = 0 --- Tracing command kernel pid 0 tid 100027 td 0xffffff0001622720 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 msleep_spin() at msleep_spin+0x152 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800009bd30, rbp = 0 --- Tracing command kernel pid 0 tid 100023 td 0xffffff00015ac390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000087d30, rbp = 0 --- Tracing command kernel pid 0 tid 100019 td 0xffffff00015ae390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000073d30, rbp = 0 --- Tracing command kernel pid 0 tid 100018 td 0xffffff00014e0ab0 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 msleep_spin() at msleep_spin+0x152 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff800006ed30, rbp = 0 --- Tracing command kernel pid 0 tid 100017 td 0xffffff00014eb000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 msleep_spin() at msleep_spin+0x152 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000069d30, rbp = 0 --- Tracing command kernel pid 0 tid 100016 td 0xffffff00014eb390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 msleep_spin() at msleep_spin+0x152 taskqueue_thread_loop() at taskqueue_thread_loop+0x5c fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000064d30, rbp = 0 --- Tracing command kernel pid 0 tid 100012 td 0xffffff00014ed390 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_wait() at sleepq_wait+0x44 _sleep() at _sleep+0x2dd taskqueue_thread_loop() at taskqueue_thread_loop+0xaa fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8000050d30, rbp = 0 --- Tracing command kernel pid 0 tid 100000 td 0xffffffff807b1d40 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x170 sleepq_timedwait() at sleepq_timedwait+0x42 _sleep() at _sleep+0x2c7 scheduler() at scheduler+0x27c mi_startup() at mi_startup+0x59 btext() at btext+0x2c db:0:kdb.enter.panic> capture off db:0:kdb.enter.panic> call doadump Cannot dump. Device not defined or unavailable. = 0x30 db:0:kdb.enter.panic> reset Full dmesg: GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA1 #5 r195556: Fri Jul 10 19:12:08 CEST 2009 root@diesel.lassitu.de:/usr/obj/usr/src/sys/DIESEL module_register: module probe already exists! Module probe failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2666.78-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 =0x8e39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4008845312 (3823 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) 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/ ACPI Warning: 32/64X FACS address mismatch in FADT - BDB69F40/ 0BDB6FE40, using 32 20090521 tbfadt-586 ioapic0 irqs 0-23 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 0x408-0x40b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xf1c0-0xf1c7 mem 0xd0000000-0xd03fffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0 agp0: f on vgapci0 agp0: detected 32764k stolen memory agp0: apertre size is 256M vgapci1: mem 0xd0400000-0xd04fffff at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) em0: port 0xf100-0xf11f mem 0xd0500000-0xd051ffff,0xd0524000-0xd0524fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:c0:7d:8c:50 pci0: at device 26.0 (no driver attached) pci0: at device 26.1 (no driver attached) pci0: at device 26.2 (no driver attached) pci0: at device 26.7 (no driver attached) pci0: at device 27.0 (no driver attached) pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pci0: at device 29.7 (no driver attached) pcib1: at device 30.0 on pci0 pci1: on pcib1 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf1b0-0xf1b7,0xf1a0-0xf1a3,0xf190-0xf197,0xf180-0xf183,0xf020-0xf03f mem 0xd0525000-0xd05257ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci1: port 0xf170-0xf177,0xf160-0xf163,0xf150-0xf157,0xf140-0xf143,0xf130-0xf13f, 0xf120-0xf12f irq 19 at device 31.5 on pci0 atapci1: [ITHREAD] ata8: on atapci1 ata8: [ITHREAD] ata9: on atapci1 ata9: [ITHREAD] acpi_button0: on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (38400,n,8,1) atrtc0: port 0x70-0x71 irq 8 on acpi0 cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a0a2006000a20 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on pu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a0a2006000a20 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xcc800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec ZFS filesystem version 13 ZFS storage pool version 13 ad4: 953869MB at ata2-master SATA300 ad6: 953869MB at ata3-master SATA300 ad8: 953869MB at ata4-master SATA300 SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/diesel_root launched (3/3). GEOM_MIRROR: Device mirror/diesel_swap launched (3/3). Trying to mount root from ufs:/dev/mirror/diesel_root -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 12:54:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEACD1065674 for ; Sat, 11 Jul 2009 12:54:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 5C14A8FC17 for ; Sat, 11 Jul 2009 12:54:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6BCs1te016722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 11 Jul 2009 14:54:02 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <7C636440-4F5D-47B0-BE20-D417B054B1F6@lassitu.de> From: Stefan Bethke To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 14:54:01 +0200 X-Mailer: Apple Mail (2.935.3) Subject: Unrecoverable UFS error but only with gmirror X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 12:54:04 -0000 gmirror and/or ufs got into an odd state after a panic, where fsck could not fix errors on the mirror device, but each member filesystem was fine. Even after destroying the mirror, fixing all three member file systems with fsck, and recreating the mirror with just a single member fsck found the same errors on the mirror device. I ended up newfs'ing the mirror and copying all data over from one of the old mirror members (and then reattaching the two other members), and all seems to be OK now, but it's still puzzling to me where those errors originated from. Blow by blow account below. Stefan I'm running my root fs (UFS with softupdates) on a three disk gmirror: # gmirror status Name Status Components mirror/diesel_root COMPLETE ad6p2 ad8p2 ad4p2 mirror/diesel_swap DEGRADED ad6p3 ad8p3 ad4p3 After a panic, fsck could not fix the root fs: Trying to mount root from ufs:/dev/mirror/diesel_root WARNING: / was not properly dismounted /: mount pending error: blocks 52 files 4 Entropy harvesting: interrupts ethernet point_to_point kickstart. /dev/mirror/diesel_root: CANNOT READ BLK: 8388576 /dev/mirror/diesel_root: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY. Automatic file system check failed; help! ERRORJOul 11 03:10:47 init: /bin/sh on /etc/rc terminated abnormally, ng to single user mode Enter full pathname of shell or RETURN for /bin/sh: GEOM_MIRROR: Device diesel_root: rebuilding provider ad6p2 finished. GEOM_MIRROR: Device diesel_root: rebuilding provider ad4p2 finished. # fsck -y ** /dev/mirror/diesel_root ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes CANNOT READ BLK: 8388576 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8388607, ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts UNREF FILE I=424146 OWNER=root MODE=140666 SIZE=0 MTIME=Jul 10 22:00 2009 CLEAR? yes ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 118582 files, 1357018 used, 672013 free (31549 frags, 80058 blocks, 1.6% fragmentation) ***** FILE SYSTEM STILL DIRTY ***** ***** FILE SYSTEM WAS MODIFIED ***** ***** PL/: reload pending error: blocks 52 files 4 EASE RERUN FSCK ***** # fsck -y ** /dev/mirror/diesel_root ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes CANNOT READ BLK: 8388576 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8388607, ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1a18582 files, 1357018 used, 672013 free (31549 frags, 80058 bloc6% fragmen/: reload pending error: blocks 52 files 4 tation) ***** FILE SYSTEM STILL DIRTY ***** ***** PLEASE RERUN FSCK ***** # dd if=/dev/mirror/diesel_root bs=1m of=/dev/null 4095+1 records in 4095+1 records out 4294966784 bytes transferred in 36.500572 secs (117668479 bytes/sec) However, I could read the whole mirror device with dd without problems. Also note the absence of any i/o errors. So I detached one of the mirrors and ran fsck on the raw partition: # gmirror remove diesel_root ad8p2 # GEOM_MIRROR: Device diesel_root: provider ad8p2 destroyed. # fsck -t ufs -y /dev/ad8p2 ** /dev/ad8p2 ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 118582 files, 1357018 used, 672013 free (31549 frags, 80058 blocks, 1.6% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** Odd. So I decided to boot off that partition, and try and fix the filesystem by recreating the mirror based from a single, good partition: # gmirror remove diesel_root ad4p2 # gmirror remove diesel_root ad6p2 # gmirror remove diesel_root ad8p2 # fsck -t ufs -y /dev/ad4p2 # gmirror label diesel_root ad4p2 # fsck -t ufs -y /dev/mirror/diesel_root ** /dev/mirror/diesel_root ** Last Mounted on / ** Phase 1 - Check Blocks and Sizes CANNOT READ BLK: 8388576 UNEXPECTED SOFT UPDATE INCONSISTENCY CONTINUE? yes THE FOLLOWING DISK SECTORS COULD NOT BE READ: 8388607, ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 118582 files, 1357018 used, 672013 free (31549 frags, 80058 blocks, 1.6% fragmentation) ***** FILE SYSTEM MARKED DIRTY ***** ***** PLEASE RERUN FSCK ***** # gmirror status Name Status Components mirror/diesel_swap COMPLETE ad4p3 ad6p3 ad8p3 mirror/diesel_root COMPLETE ad4p2 At which point I decided to newfs the mirror and copy all data over from one of the other (former) mirror members. That turned out to work without problems. -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 13:00:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516ED106564A for ; Sat, 11 Jul 2009 13:00:03 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 03D5E8FC18 for ; Sat, 11 Jul 2009 13:00:02 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (unknown [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id D0C0578F53; Sat, 11 Jul 2009 17:00:00 +0400 (MSD) Message-ID: <4A588CD4.40304@haruhiism.net> Date: Sat, 11 Jul 2009 17:00:04 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stefan Bethke References: <128E7C52-CCBD-4BAF-A4AE-1D914A3968CB@lassitu.de> In-Reply-To: <128E7C52-CCBD-4BAF-A4AE-1D914A3968CB@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: CURRENT: Traps in netisr_queue_internal and in netisr itself (Was: ppp triggers GPF panic) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 13:00:03 -0000 Stefan Bethke wrote: > Yesterday's -current, amd64, C2D, 4 GB RAM. Full dmesg below. This is not ppp's fault. It's completely the same case as for my every-2-hours panics - a bug in netisr, and it is currently being looked into. See an example below: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x131e288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80586325 stack pointer = 0x28:0xffffff803beef490 frame pointer = 0x28:0xffffff803beef4c0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 0 (dummynet) trap number = 12 panic: page fault cpuid = 0 Uptime: 1h55m42s #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff80595163 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff805955bc in panic (fmt=Variable "fmt" is not available.) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff8085e18d in trap_fatal (frame=0xc, eva=Variable "eva" is not available.) at /usr/src/sys/amd64/amd64/trap.c:852 #4 0xffffffff8085ee25 in trap (frame=0xffffff803beef3e0) at /usr/src/sys/amd64/amd64/trap.c:345 #5 0xffffffff80844cc3 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #6 0xffffffff80586325 in _mtx_lock_sleep (m=0xffffffff80e61863, tid=18446742974219441952, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #7 0xffffffff8058647e in _mtx_lock_flags (m=Variable "m" is not available.) at /usr/src/sys/kern/kern_mutex.c:203 #8 0xffffffff80642bd5 in netisr_queue_internal (proto=1, m=0xffffff00441f0c00, cpuid=Variable "cpuid" is not available.) at /usr/src/sys/net/netisr.c:830 #9 0xffffffff80642cb9 in netisr_queue_src (proto=1, source=Variable "source" is not available.) at /usr/src/sys/net/netisr.c:860 #10 0xffffffff8063ec30 in if_simloop (ifp=0xffffff000314b800, m=0xffffff00441f0c00, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #11 0xffffffff8063ed86 in looutput (ifp=0xffffff000314b800, m=0xffffff00441f0c00, dst=0xffffff803beef640, ro=Variable "ro" is not available.) at /usr/src/sys/net/if_loop.c:296 #12 0xffffffff8069dfd7 in ip_output (m=0xffffff00441f0c00, opt=Variable "opt" is not available.) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 13:06:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9381B106566B for ; Sat, 11 Jul 2009 13:06:13 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 45D448FC12 for ; Sat, 11 Jul 2009 13:06:13 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by vwj2 with SMTP id 2so1190651vwj.3 for ; Sat, 11 Jul 2009 06:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=o538nMatabc7YewG8NP7DEYSyas2gndWAGPKjynz/PI=; b=CwOMVOUrF6Bc+aDN10wJkf1WbP2nvsvNIt8/MdtaIArHASoPxJkt5j20k60NnQya9v n2XmBKog+VifQldNKGS5WfFd68sTFyZPOrED3Qt59af2Hd0a6seAyBm4Tcydset/G5si UKUXwqEQtOpgXPp7Tw7AKyYGMhCyF+Fj0UVVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LGnISE7tF8cqN+6UJCpHRgTDg5xEKkOAutIHam4zTdSQpBDbp109eAhuioKAti7T4h w/es5GjZbItg895ZJuwovrjoNfdhzPHalIFr/VM0Rf3SjP3eVoSq9cZm4IkxUwU7CVtL IlHifMXvx8DSfQtiqdj4Dr6DFdEqymW0aDQYU= MIME-Version: 1.0 Received: by 10.220.90.144 with SMTP id i16mr4486162vcm.14.1247317572518; Sat, 11 Jul 2009 06:06:12 -0700 (PDT) In-Reply-To: <790a9fff0907101911y7143ed4bnbb050d78ebc21558@mail.gmail.com> References: <790a9fff0907101159w495b644dge4a4bd81de0bda9b@mail.gmail.com> <20090710211809.GA84773@crodrigues.org> <790a9fff0907101911y7143ed4bnbb050d78ebc21558@mail.gmail.com> Date: Sat, 11 Jul 2009 08:06:12 -0500 Message-ID: <790a9fff0907110606t61da8ebbufa5575d12d949ca@mail.gmail.com> From: Scot Hetzel To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: [SOLVED]Re: How to create ZFS on Root using MBR slices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 13:06:13 -0000 I was able to re-solve this problem with creating a ZFS root using a partition on a slice. The hint came from a message sent by Doug Rabson in response to the 'ZFS boot on zfs mirror' discussion on the FreeBSD-Stable list. On Tue, May 26, 2009 at 12:06 PM, Doug Rabson wrote: > > On Tue, 26 May 2009 19:57:03 +0300, Andriy Gapon wrote: >> on 26/05/2009 19:42 George Hartzell said the following: >>> I'm still confused about the two parts of zfsboot and what's magical >>> about seeking to 1024. >> >> Can't help with answer to this, but cc-ing the one who can (I think). >> I am interested too :-) > > This is due to the primitive DOS boot sequence. Basically the BIOS loads > the first sector of the partition and executes it. For zfsboot, that is the > first 512 bytes of /boot/zfsboot. The next stage of the bootstrap is tucked > away in a convenient hole in the ZFS on-disk formwat which is located just > after the ZFS metadata - this is the seek=1024 part. The first 512 byte > part is a tiny assembler program that loads the rest into memory and > executes it. The second part is large enough and smart enough to understand > the ZFS filesystem format directly and it loads /boot/loader directly from > the filesystem and transfers control to that. The third stage > (/boot/loader) is what puts up the boot menu and loads the kernel etc. Thanks Doug for a great explanation. Below is the revised instructions for creating a ZFS Root w/MBR, Slices, and Partitions Scot --------------------------------------------------------------------------------------------------------------------------- Creating ZFS Root ZFS Root w/MBR, Slices, and Partitions 1. Boot FreeBSD install CD/DVD 2. Choose Fixit option in sysinstall 3. Create Slice using gpart Fixit# gpart show ad0 => 63 625142385 ad0 MBR (289G) 63 209712447 1 !7 (100G) 209712510 417690 2 !136 (204M) 210130200 415012248 - free - (198G) Fixit# gpart add -b 210130200 -s 415012248 -t freebsd ad0 ad0s3 added Fixit# gpart show ad0 => 63 625142385 ad0 MBR (289G) 63 209712447 1 !7 (100G) 209712510 417690 2 !136 (204M) 210130200 415012248 3 freebsd (198G) 4. Create partitions (ad0s3a and ad0s3b) Fixit# gpart show ad0s3 => 0 415012248 ad0s3 BSD (198G) 0 415012248 ad0s3 - free - (198G) Fixit# gpart add -i 1 -b 0 -s 40663421 -t freebsd-zfs ad0s3 ad0s3a added Fixit# gpart show ad0s3 => 0 415012248 ad0s3 BSD (198G) 406631421 1 freebsd-zfs (194G) 406631421 8380827 - free - (4.0G) Fixit# gpart add -i 2 -b 406626334 -s 8380811 -t freebsd=swap ad0s3 ad0s3b added Fixit# gpart show ad0s3 => 0 415012248 ad0s3 BSD (198G) 406631421 1 freebsd-zfs (194G) 406631421 8380827 2 freebsd-swap (4.0G) 5. load zfs kernel module kldload /mnt2/boot/kernel/opensolaris.ko kldload /mnt2/boot/kernel/zfs.ko 6. Create Zpool zpool create zroot /dev/ad0s3a zpool set bootfs=zroot zroot 7. Create filesystem hierarchy zfs create -o compression=on -o exec=off -o setuid=off zroot/tmp zfs create zroot/usr zfs create -o compression=on -o setuid=off zroot/usr/ports zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/distfiles zfs create -o compression=off -o exec=off -o setuid=off zroot/usr/ports/packages zfs create -o compression=on -o exec=off -o setuid=off zroot/usr/src zfs create zroot/var zfs create -o compression=on -o exec=off -o setuid=off zroot/var/crash zfs create -o exec=off -o setuid=off zroot/var/db zfs create -o compression=on -o exec=on -o setuid=off zroot/var/db/pkg zfs create -o exec=off -o setuid=off zroot/var/empty zfs create -o compression=on -o exec=off -o setuid=off zroot/var/log zfs create -o compression=on -o exec=off -o setuid=off zroot/var/mail zfs create -o exec=off -o setuid=off zroot/var/run zfs create -o compression=on -o exec=off -o setuid=off zroot/var/tmp 8. install FreeBSD to zroot cd /dist/8.0-20090628-SNAP export DESTDIR=/zroot for dir in base catpages dict doc games info lib32 manpages ports; do (cd $dir ; ./install.sh) ; done cd src ; ./install.sh all cd ./kernel ; ./install.sh dv8135nr ; ./install.sh generic cd /zroot/boot ; cp -rp GENERIC/* ../kernel 9. create rc.conf, loader.conf, src.conf echo 'zfs_enable="YES"' > /zroot/etc/rc.conf echo 'LOADER_ZFS_SUPPORT=YES' >> /zroot/etc/src.conf echo 'zfs_load="YES"' >> /zroot/boot/loader.conf echo 'vfs.root.mountfrom="zfs:zroot"' >> /zroot/boot/loader.conf 10. change root password chroot /zroot passwd exit 11. create zpool.cache mkdir /boot/zfs zpool export zroot && zpool import zroot cp /boot/zfs/zpool.cache /zroot/boot/zfs/zpool.cache 12. export LD_LIBRARY_PATH export LD_LIBRARY_PATH=/mnt2/lib 13. Change mount points for zroot pool zfs set mountpoint=legacy zroot zfs set mountpoint=/tmp zroot/tmp zfs set mountpoint=/usr zroot/usr zfs set mountpoint=/var zroot/var 14. Install boot Manager fdisk -B -b /boot/boot0 ad0 15. Install ZFS boot - Install the boot1 stage on the drive: dd if=/mnt2/boot/zfsboot of=/dev/ad0s3 count=1 Install the boot2 zfs stage into the convienient hole in the ZFS filesystem on-disk format which is located just after the ZFS metadata (this is the seek=1024). dd if=/mnt2/boot/zfsboot of=/dev/ad0s3a skip=1 seek=1024 From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 13:30:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 933C1106566C for ; Sat, 11 Jul 2009 13:30:44 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1B58FC14 for ; Sat, 11 Jul 2009 13:30:43 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n6BDUg9k078720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jul 2009 15:30:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n6BDUVws007813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jul 2009 15:30:31 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n6BDUVrP076173; Sat, 11 Jul 2009 15:30:31 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n6BDUUs0076172; Sat, 11 Jul 2009 15:30:30 +0200 (CEST) (envelope-from ticso) Date: Sat, 11 Jul 2009 15:30:30 +0200 From: Bernd Walter To: Stefan Bethke Message-ID: <20090711133030.GA76026@cicely7.cicely.de> References: <7C636440-4F5D-47B0-BE20-D417B054B1F6@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7C636440-4F5D-47B0-BE20-D417B054B1F6@lassitu.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.040, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: FreeBSD Current Subject: Re: Unrecoverable UFS error but only with gmirror X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 13:30:44 -0000 On Sat, Jul 11, 2009 at 02:54:01PM +0200, Stefan Bethke wrote: > gmirror and/or ufs got into an odd state after a panic, where fsck > could not fix errors on the mirror device, but each member filesystem > was fine. Even after destroying the mirror, fixing all three member > file systems with fsck, and recreating the mirror with just a single > member fsck found the same errors on the mirror device. You've created the partitions without mirror? The member drives are one block larger than the mirrored and if the filesystem tries to use it under mirror it will fail. The easiest way to avoid is to create the gmirror and then setup your partitions on the mirror. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 13:39:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59420106566B for ; Sat, 11 Jul 2009 13:39:40 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id EBBE38FC22 for ; Sat, 11 Jul 2009 13:39:39 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6BDdbRj018016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Jul 2009 15:39:38 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <2AAF9560-BD5C-4BB7-9AA6-D8F10853CF2D@lassitu.de> From: Stefan Bethke To: ticso@cicely.de In-Reply-To: <20090711133030.GA76026@cicely7.cicely.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 15:39:37 +0200 References: <7C636440-4F5D-47B0-BE20-D417B054B1F6@lassitu.de> <20090711133030.GA76026@cicely7.cicely.de> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD Current Subject: Re: Unrecoverable UFS error but only with gmirror X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 13:39:40 -0000 Am 11.07.2009 um 15:30 schrieb Bernd Walter: > On Sat, Jul 11, 2009 at 02:54:01PM +0200, Stefan Bethke wrote: >> gmirror and/or ufs got into an odd state after a panic, where fsck >> could not fix errors on the mirror device, but each member filesystem >> was fine. Even after destroying the mirror, fixing all three member >> file systems with fsck, and recreating the mirror with just a single >> member fsck found the same errors on the mirror device. > > You've created the partitions without mirror? > The member drives are one block larger than the mirrored and if the > filesystem tries to use it under mirror it will fail. > The easiest way to avoid is to create the gmirror and then setup > your partitions on the mirror. No, I've newfs'ed the mirror device, not the disk partitions, so that shouldn't be the problem. Unless gmirror fails to subtract the metadata sector from the mirror device. Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 13:59:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCAD51065672 for ; Sat, 11 Jul 2009 13:59:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 555508FC13 for ; Sat, 11 Jul 2009 13:59:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm24 with SMTP id 24so1144238fxm.43 for ; Sat, 11 Jul 2009 06:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=rL5lfapBVgU3OcudgHLVD73hZlTovSe2cunD+vUFN0M=; b=FiMfI+ho5Xam6SGD+Rby696ZIHylszQndffWngn5nd3Go71xUH6FkyfNitLyXUp0+a /AB1ZXGiZ1NjvkptKv2ntK/XEUV5yrmtQoqzgEjNepemBqzEDVqFk2FXKp4Tqf+ZKxX3 AGtQUo3CiJ2rnlRlHY8QZWyHgF9Qm+mJnqHBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MnYBmVeie6BV4yWBADK6j1So7FNcBX0FRBiniDcZWO7Zln3vhDPX7FEoFsIsf6FaRi 1+ET5HrkG0rtJifzot9cReYxGPqFLFV4dN5lKN/o0MI5QHnhKJlZPJCpPHdScnjSgBF6 Kw5eQntbFhnqQ62xkg/7t7xCQcDIyAyRV8lVA= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.105.7 with SMTP id r7mr1548995fao.8.1247320739180; Sat, 11 Jul 2009 06:58:59 -0700 (PDT) In-Reply-To: <596C18F0-5F5F-44EF-A88D-122FEC6A0FCD@lassitu.de> References: <596C18F0-5F5F-44EF-A88D-122FEC6A0FCD@lassitu.de> Date: Sat, 11 Jul 2009 15:58:59 +0200 X-Google-Sender-Auth: 6224fd03b8f98417 Message-ID: <3bbf2fe10907110658j7a5de4am90cff95ef69e8141@mail.gmail.com> From: Attilio Rao To: Stefan Bethke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: panic: spin lock held too long on reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 13:59:01 -0000 2009/7/11 Stefan Bethke : > Got another one of these. > > -current from yesterday, amd64. Full dmesg below. Try disabling STOP_NMI. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 14:08:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1D35106564A; Sat, 11 Jul 2009 14:08:49 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2BC8FC15; Sat, 11 Jul 2009 14:08:49 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:52658 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MPdFd-0000Yg-3F; Sat, 11 Jul 2009 16:08:31 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 0A8405ECFC; Sat, 11 Jul 2009 16:08:29 +0200 (CEST) Message-Id: From: Thomas Backman To: Kip Macy In-Reply-To: <3c1674c90907101227ueab78eem6f8c5c7fdf0337cc@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 16:08:26 +0200 References: <72163521-40BF-4764-8B74-5446A88DFBF8@exscape.org> <45291598-D091-4E90-B968-22E59BEB3846@exscape.org> <3c1674c90907101227ueab78eem6f8c5c7fdf0337cc@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MPdFd-0000Yg-3F. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MPdFd-0000Yg-3F d1f60bc2a28a5c5ed1e432016c4e6079 Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: Reproducible ZFS panic, w/ script (Was: "New" ZFS crash on FS (pool?) unmount/export) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:08:50 -0000 On Jul 10, 2009, at 21:27, Kip Macy wrote: > "zfs export" does a forced unmount. We may not be properly handling > dangling references. > > -Kip A bit more digging: [root@chaos ~]# bash zfs_crash.sh initial [root@chaos ~]# bash zfs_crash.sh stress ## with the unmount part (line 107) **commented out** I then let the above run for say 20 seconds to create a bunch of snapshots (ignoring errors; in my own script I added a random number to the snapshot name to avoid collisions), and then: [root@chaos ~]# zpool export crashtestmaster [root@chaos ~]# zfs list NAME USED AVAIL REFER MOUNTPOINT crashtestslave 20.3M 40.7M 20K /crashtestslave/ crashtestslave crashtestslave/test_cloned 19.8M 40.7M 19.8M /crashtestslave/ crashtestslave/test_cloned crashtestslave/test_orig 0 40.7M 19.8M /crashtestslave/ crashtestslave/test_orig tank 5.67G 59.3G 18K none tank/root 616M 59.3G 224M / tank/... [root@chaos ~]# zfs unmount crashtestslave/test_orig [root@chaos ~]# zfs unmount crashtestslave/test_cloned [root@chaos ~]# zfs unmount crashtestslave ... panic here. Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803a5682 stack pointer = 0x28:0xffffff803ea09980 frame pointer = 0x28:0xffffff803ea099b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 5099 (zfs) 0xffffff002ac4a938: tag zfs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0xffffff00068be8d0 flags () lock type zfs: EXCL by thread 0xffffff0006f13390 (pid 5099) BT: ... #9 0xffffffff805edc42 in trap (frame=0xffffff803ea098d0) at /usr/src/ sys/amd64/amd64/trap.c:345 #10 0xffffffff805d36a7 in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:223 #11 0xffffffff803a5682 in propagate_priority (td=0xffffff0027174ab0) at /usr/src/sys/kern/subr_turnstile.c:194 #12 0xffffffff803a64ec in turnstile_wait (ts=Variable "ts" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:738 #13 0xffffffff80355101 in _mtx_lock_sleep (m=0xffffff002ca6d9f8, tid=18446742974314394512, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:447 #14 0xffffffff803f7893 in vfs_msync (mp=0xffffff00068be8d0, flags=1) at /usr/src/sys/kern/vfs_subr.c:3179 #15 0xffffffff803f0c7e in dounmount (mp=0xffffff00068be8d0, flags=0, td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:1263 #16 0xffffffff803f1568 in unmount (td=0xffffff0006f13390, uap=0xffffff803ea09c00) at /usr/src/sys/kern/vfs_mount.c:1174 #17 0xffffffff805ed4cf in syscall (frame=0xffffff803ea09c90) at /usr/ src/sys/amd64/amd64/trap.c:984 #18 0xffffffff805d3930 in Xfast_syscall () at /usr/src/sys/amd64/amd64/ exception.S:364 #19 0x0000000800f4b9ac in ?? () Previous frame inner to this frame (corrupt stack?) NOT the same backtrace as before (nothing after dounmount() is the same as the zpool export panic), and this time from zfs unmount, not zpool export. I tried it again, and got another backtrace(!) - it "ends" (or begins, depending on your view) with propagate_priority(), turnstile_wait() and _mtx_lock_sleep() in both cases, though. Here's the second, which happened while doing the same as above - initial, stress and then manually zfs unmount the them. "zfs unmount crashtestslave" (the root fs) is what panics yet again: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff803aa722 stack pointer = 0x28:0xffffff8000025a60 frame pointer = 0x28:0xffffff8000025a90 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 12 (swi4: clock) ... #8 0xffffffff805f1fcd in trap_fatal (frame=0xffffff80000259b0, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #9 0xffffffff805f2e22 in trap (frame=0xffffff80000259b0) at /usr/src/ sys/amd64/amd64/trap.c:345 #10 0xffffffff805d87c7 in calltrap () at /usr/src/sys/amd64/amd64/ exception.S:224 #11 0xffffffff803aa722 in propagate_priority (td=0xffffff00296ce390) at /usr/src/sys/kern/subr_turnstile.c:194 #12 0xffffffff803ab58c in turnstile_wait (ts=Variable "ts" is not available. ) at /usr/src/sys/kern/subr_turnstile.c:738 #13 0xffffffff8035a1c1 in _mtx_lock_sleep (m=0xffffffff808a1de0, tid=18446742974234830624, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:447 #14 0xffffffff8037ea92 in softclock (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/kern_timeout.c:376 #15 0xffffffff803417b0 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1165 #16 0xffffffff80342d1e in ithread_loop (arg=0xffffff000231e6a0) at / usr/src/sys/kern/kern_intr.c:1178 #17 0xffffffff8033ebb8 in fork_exit (callout=0xffffffff80342c90 , arg=0xffffff000231e6a0, frame=0xffffff8000025c80) at /usr/src/sys/kern/kern_fork.c:842 #18 0xffffffff805d8c9e in fork_trampoline () at /usr/src/sys/amd64/ amd64/exception.S:561 #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000001 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () Note that the active process is *not* zfs this time. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 14:20:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6D55106564A for ; Sat, 11 Jul 2009 14:20:06 +0000 (UTC) (envelope-from freebsd@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id 4092D8FC16 for ; Sat, 11 Jul 2009 14:20:06 +0000 (UTC) (envelope-from freebsd@xtaz.co.uk) Received: from xtaz.co.uk (tao.xtaz.co.uk [192.168.1.2]) by mail.xtaz.co.uk (Postfix) with ESMTP id 34102B07674 for ; Sat, 11 Jul 2009 15:03:00 +0100 (BST) MIME-Version: 1.0 Date: Sat, 11 Jul 2009 15:03:00 +0100 From: Matt Smith To: Message-ID: X-Sender: freebsd@xtaz.co.uk User-Agent: RoundCube Webmail/0.2.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Subject: Disk devices changed after upgrade to current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:20:07 -0000 I have just upgraded my system from 7.2 to 8.0 using a source based upgrade. After rebooting it for the first time the server unfortunately failed to come back up. I had a look at the console and found that it was failing to find the root device and prompting me for it. By manually entering it I managed to boot the server and could then see the problem. In the 7.2 fstab my root partition and swap space were ad4s1a and ad4s1b but after booting the 8.0 kernel these seem to have changed to ad4a and ad4b so I set the new names in the fstab and it's now working fine. I read through the UPDATING file before I did this but I couldn't see any warnings that this may occur. The only entry that's possibly relevant is 20090320 talking about GEOM_PART. My question is is this change expected behavior or has my system done something strange? If it's expected then I think a warning could be needed for when more people decide to do this upgrade after 8 is released. Also I'm seeing a lot of messages logged to syslog saying "kernel: NMI ISA 3c, EISA 0" and "kernel: kernel trap 19 with interrupts disabled" over and over again. I commented out most of the usual debugging stuff from the kernel file whilst I was making my own kernel but these messages are obviously coming from somewhere else. Can somebody point me to what I need to change to disable these apparent debugging messages? Other than that everything is working well so far. Good work! Regards, Matt. From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 14:23:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B52F0106566B for ; Sat, 11 Jul 2009 14:23:16 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6EBBE8FC0A for ; Sat, 11 Jul 2009 14:23:16 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 6B2FD78F53; Sat, 11 Jul 2009 18:23:14 +0400 (MSD) Message-ID: <4A58A056.3020002@haruhiism.net> Date: Sat, 11 Jul 2009 18:23:18 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Matt Smith References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Disk devices changed after upgrade to current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:23:16 -0000 Matt Smith wrote: > I have just upgraded my system from 7.2 to 8.0 using a source based > upgrade. After rebooting it for the first time the server unfortunately > failed to come back up. I had a look at the console and found that it was > failing to find the root device and prompting me for it. By manually > entering it I managed to boot the server and could then see the problem. > > In the 7.2 fstab my root partition and swap space were ad4s1a and ad4s1b > but after booting the 8.0 kernel these seem to have changed to ad4a and > ad4b so I set the new names in the fstab and it's now working fine. I read > through the UPDATING file before I did this but I couldn't see any warnings > that this may occur. The only entry that's possibly relevant is 20090320 > talking about GEOM_PART. > If you check June'09 archives, you'll find out that there already was a question about this, coming from a person with FreeBSD installed on a dangerously dedicated disk. Are you sure you aren't using a DDD (a drive that has no DOS/GPT partition tables, just the bsdlabel)? -- Kamigishi Rei From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 14:41:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AD5A106564A for ; Sat, 11 Jul 2009 14:41:28 +0000 (UTC) (envelope-from freebsd@xtaz.co.uk) Received: from mail.xtaz.co.uk (xtaz.co.uk [87.194.206.163]) by mx1.freebsd.org (Postfix) with ESMTP id 095E08FC0A for ; Sat, 11 Jul 2009 14:41:27 +0000 (UTC) (envelope-from freebsd@xtaz.co.uk) Received: from xtaz.co.uk (tao.xtaz.co.uk [192.168.1.2]) by mail.xtaz.co.uk (Postfix) with ESMTP id 8F124B07674; Sat, 11 Jul 2009 15:41:26 +0100 (BST) MIME-Version: 1.0 Date: Sat, 11 Jul 2009 15:41:26 +0100 From: Matt Smith To: Kamigishi Rei In-Reply-To: <4A58A056.3020002@haruhiism.net> References: <4A58A056.3020002@haruhiism.net> Message-ID: X-Sender: freebsd@xtaz.co.uk User-Agent: RoundCube Webmail/0.2.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Cc: freebsd-current@freebsd.org Subject: Re: Disk devices changed after upgrade to current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:41:28 -0000 On Sat, 11 Jul 2009 18:23:18 +0400, Kamigishi Rei wrote: >> > If you check June'09 archives, you'll find out that there already was a > question about this, coming from a person with FreeBSD installed on a > dangerously dedicated disk. > Are you sure you aren't using a DDD (a drive that has no DOS/GPT > partition tables, just the bsdlabel)? Ahhh. I have just found the thread you are referring to in the archives. That explains it I think. I do indeed have a dangerously dedicated disk because I only run the one O/S on it and never need it to be compatible with anything else. So it looks like 7.x did things wrongly and now in 8 it's working as designed. Thanks for this. Matt. From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 14:47:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6862F106566B for ; Sat, 11 Jul 2009 14:47:22 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 0A41D8FC12 for ; Sat, 11 Jul 2009 14:47:21 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by vwj2 with SMTP id 2so1216556vwj.3 for ; Sat, 11 Jul 2009 07:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=5FbDqQAfmmIsY0oUPxiqe56s6sr3OgIX1e3y3GMKRI4=; b=oIDsYUpCvEFnqQuz13SR+btYd/kMK9XB9MZ778DdZ2IvKlluZepZ6tkxTv7NEFZjpY sC6ZLmTwUWpd7oxuih0unRfz1Ftg6XXqUxpk+iYdT/ms/COYXgUGwVuu1Xt+4/dPMRZm 53UrjL5ub8cx7HeZYFUCVGlZ7Ix5QWvdWpAWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=asMxGn+LYi6Y4/ufzHb0uabMX+72lcU8Jizpnm8q4q2Kh4EV85BSVfyZG4y4CTRNc5 WbAVabYrzRhobejEuzkWbT+iTsoBtD6AoT5gUGJFguX+aQLhKLH7MvqMApVAix8oiizB /Jq7rGeys3mJlehnSFnQT6DEktO72+L0HX3ys= MIME-Version: 1.0 Received: by 10.220.100.1 with SMTP id w1mr4588355vcn.10.1247323641346; Sat, 11 Jul 2009 07:47:21 -0700 (PDT) In-Reply-To: <790a9fff0907110606t61da8ebbufa5575d12d949ca@mail.gmail.com> References: <790a9fff0907101159w495b644dge4a4bd81de0bda9b@mail.gmail.com> <20090710211809.GA84773@crodrigues.org> <790a9fff0907101911y7143ed4bnbb050d78ebc21558@mail.gmail.com> <790a9fff0907110606t61da8ebbufa5575d12d949ca@mail.gmail.com> Date: Sat, 11 Jul 2009 09:47:21 -0500 Message-ID: <790a9fff0907110747t7187fba6h7fdb82a40f57d489@mail.gmail.com> From: Scot Hetzel To: freebsd-current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [SOLVED]Re: How to create ZFS on Root using MBR slices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:47:22 -0000 I created a page on the FreeBSD wiki with these instructions. http://wiki.freebsd.org/ZFSOnRootWithZFSboot Scot From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 14:56:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C52AF106566C for ; Sat, 11 Jul 2009 14:56:08 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id 680E08FC0C for ; Sat, 11 Jul 2009 14:56:08 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: (qmail 28699 invoked by uid 60001); 11 Jul 2009 14:29:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247322566; bh=46ZtZuBDb1ituTTIFCpR4fm1MO4Wd1XnIYddYN8H8vY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=JfozgsMmypcl4eUnNoFNdPjE+sTh6foC72aFT5bANNuf2IvCGnVW/6Hou7G+e7vM1mgT09z1/lZwS8ecwvNOhBkSVePP8kPLVSvKj4DItrYeMrD7JEj4mZRiN5I3kuk3mv4fQ1+vj2MJUbSohmmAzOG+JxCB3pSLkOGOKwKMvpM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RC29S5T+JP9DyCMR2bOYsQFoQFWv6YiZYQcHOejWK8n2jusOwOafNvDawIwXrN9Pb4+LzdYWSORCQTAoUEePqvGugTAkOE4CUrGPTh6QGUwZCy/oT+u9Z1CvYfdByyi158MJ1VRghOYQ+lamPx6A6bvSSAryUTjYrfvWiDw6Suk=; Message-ID: <245714.27770.qm@web63908.mail.re1.yahoo.com> X-YMail-OSG: 2vDngM4VM1nI0xkeQAsVrVSR3sjMgkWXBoe5SbFkHYH05k1cB94yXwfMJxCoX_kPk9lYYlDKZKeU5ehutL5dIQhmyr1wEPyUcLlp7Io4BijHs1A5SctclE.oppK8i0Wl0jaf3gOwlOTNw5UPji88fDxtbD.ddncOn..ELJMmcTpgszPMdehV5HWtf.5QDXzpll4Nohsk4hAD_SY_mGEWnvXWcsKXRvo4MGnjrwW6DTnMOiolMkyO_CfiPujq8gF_ezzJ8swwid3Kp.w7ZtaT7GPHLNudRZMROer7roy7MtSHPe_qqHXwIzLHjQ-- Received: from [66.176.162.245] by web63908.mail.re1.yahoo.com via HTTP; Sat, 11 Jul 2009 07:29:26 PDT X-Mailer: YahooMailClassic/5.4.17 YahooMailWebService/0.7.289.15 Date: Sat, 11 Jul 2009 07:29:26 -0700 (PDT) From: Barney Cordoba To: Matt Smith , Kamigishi Rei MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Disk devices changed after upgrade to current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 14:56:09 -0000 =0A=0A--- On Sat, 7/11/09, Kamigishi Rei wrote:=0A= =0A> From: Kamigishi Rei =0A> Subject: Re: Disk devi= ces changed after upgrade to current=0A> To: "Matt Smith" =0A> Cc: freebsd-current@freebsd.org=0A> Date: Saturday, July 11, 2009, = 10:23 AM=0A> Matt Smith wrote:=0A> > I have just upgraded my system from 7.= 2 to 8.0 using a=0A> source based=0A> > upgrade. After rebooting it for the= first time the=0A> server unfortunately=0A> > failed to come back up. I ha= d a look at the console=0A> and found that it was=0A> > failing to find the= root device and prompting me for=0A> it. By manually=0A> > entering it I m= anaged to boot the server and could=0A> then see the problem.=0A> > =0A> > = In the 7.2 fstab my root partition and swap space were=0A> ad4s1a and ad4s1= b=0A> > but after booting the 8.0 kernel these seem to have=0A> changed to = ad4a and=0A> > ad4b so I set the new names in the fstab and it's now=0A> wo= rking fine. I read=0A> > through the UPDATING file before I did this but I= =0A> couldn't see any warnings=0A> > that this may occur. The only entry th= at's possibly=0A> relevant is 20090320=0A> > talking about GEOM_PART.=0A> >= =A0=A0=A0=0A> If you check June'09 archives, you'll find out that there=0A>= already was a question about this, coming from a person with=0A> FreeBSD i= nstalled on a dangerously dedicated disk.=0A> Are you sure you aren't using= a DDD (a drive that has no=0A> DOS/GPT partition tables, just the bsdlabel= )?=0A> =0A> --=0A> Kamigishi Rei=0A=0AThis, unfortunately, is a common prob= lem. There are devices detected in 8 that are not detected in 7 (or vice ve= rsa). You can try disabling acpi but that causes different problems. I wasn= 't able to get 7 and 8 synced in terms of detecting disks no matter what se= ttings I used.=0A=0ABarney=0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 15:10:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C20A106566B; Sat, 11 Jul 2009 15:10:42 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.freebsd.org (Postfix) with ESMTP id CDA8F8FC12; Sat, 11 Jul 2009 15:10:41 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=vYXrHWlrNuCLr8PUXtYA:9 a=JS0FUPc30KwD7OHMkYvszT0tOGIA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe08.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1275067602; Sat, 11 Jul 2009 17:10:40 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 11 Jul 2009 17:10:16 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> In-Reply-To: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907111710.18843.hselasky@c2i.net> Cc: usb@freebsd.org, Andrew Thompson Subject: Re: USB polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 15:10:43 -0000 On Friday 10 July 2009 19:20:01 Andrew Thompson wrote: > Hi, > > The one usb task that is still an issue for 8.0 is the polling > support. The code needs to call into the host controller driver to > check if the usb descriptor has been marked as done and call the > completion callback. I am now traveling so cant look at it, if anyone > wants to have a look it would be fantastic. This is needed for places > where a usb keyboard is used and interrupts are disabled (root mount, > DDB). Hi, Probably we can implement USB polling with minimal transfer support. That basically means: - no timeouts - no automatic clear-stall Only support for ukbd and umass. Shouldn't be too hard. What is more hard, is that the sys/dev/usb/input/ukbd.c driver has to get away from using the Giant lock. Last time I looked at that it was impossible because the whole keyboard layer was under Giant. Has anything changed here? If not the USB keyboard will only work if kdb_enter() is called when Giant is locked! --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 15:47:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01B3F1065670 for ; Sat, 11 Jul 2009 15:47:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 645968FC0C for ; Sat, 11 Jul 2009 15:47:37 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n6BFlZPx086813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Jul 2009 17:47:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n6BFlOJF012877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Jul 2009 17:47:24 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n6BFlOqF076483; Sat, 11 Jul 2009 17:47:24 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n6BFlOVk076482; Sat, 11 Jul 2009 17:47:24 +0200 (CEST) (envelope-from ticso) Date: Sat, 11 Jul 2009 17:47:24 +0200 From: Bernd Walter To: Stefan Bethke Message-ID: <20090711154724.GC76026@cicely7.cicely.de> References: <7C636440-4F5D-47B0-BE20-D417B054B1F6@lassitu.de> <20090711133030.GA76026@cicely7.cicely.de> <2AAF9560-BD5C-4BB7-9AA6-D8F10853CF2D@lassitu.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2AAF9560-BD5C-4BB7-9AA6-D8F10853CF2D@lassitu.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.040, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: FreeBSD Current , ticso@cicely.de Subject: Re: Unrecoverable UFS error but only with gmirror X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 15:47:38 -0000 On Sat, Jul 11, 2009 at 03:39:37PM +0200, Stefan Bethke wrote: > Am 11.07.2009 um 15:30 schrieb Bernd Walter: > > >On Sat, Jul 11, 2009 at 02:54:01PM +0200, Stefan Bethke wrote: > >>gmirror and/or ufs got into an odd state after a panic, where fsck > >>could not fix errors on the mirror device, but each member filesystem > >>was fine. Even after destroying the mirror, fixing all three member > >>file systems with fsck, and recreating the mirror with just a single > >>member fsck found the same errors on the mirror device. > > > >You've created the partitions without mirror? > >The member drives are one block larger than the mirrored and if the > >filesystem tries to use it under mirror it will fail. > >The easiest way to avoid is to create the gmirror and then setup > >your partitions on the mirror. > > No, I've newfs'ed the mirror device, not the disk partitions, so that > shouldn't be the problem. Unless gmirror fails to subtract the > metadata sector from the mirror device. I see - normally this should work fine then. But you get read problem and I asume you wouldn't ask if you also see hardware errors. So this is likely accessing a block, which is not part of the volume. Of course a bad UFS metadata can point to non existing data as well. I would still verify the sizes - is the block far out of volume range, or just a bit? Is the underlying paritioning Ok? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 16:10:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9A4FF106564A for ; Sat, 11 Jul 2009 16:10:09 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from xps.daemonology.net (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx2.freebsd.org (Postfix) with SMTP id 329C0150252 for ; Sat, 11 Jul 2009 16:10:09 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: (qmail 7448 invoked from network); 11 Jul 2009 16:10:08 -0000 Received: from unknown (HELO xps.daemonology.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2009 16:10:08 -0000 Message-ID: <4A58B960.8050204@freebsd.org> Date: Sat, 11 Jul 2009 09:10:08 -0700 From: Colin Percival User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: FreeBSD Current , FreeBSD Stable X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD 8.0-BETA1 available via FreeBSD Update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 16:10:10 -0000 Hi all, The FreeBSD Update bits for FreeBSD 8.0-BETA1 are now available. Sorry for the delay. I've posted a step-by-step guide to my blog at http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html and I'm asking people to leave comments on that page if they encounter any problems -- I'm aware of two systems already which didn't manage to reboot after installing 8.0-BETA1 kernels, so this is definitely a case of "here be dragons". -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 16:45:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2EE7106566C for ; Sat, 11 Jul 2009 16:45:38 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4EE8FC08 for ; Sat, 11 Jul 2009 16:45:38 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by vwj2 with SMTP id 2so1247476vwj.3 for ; Sat, 11 Jul 2009 09:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=vcjmaQrs8l9lwSK/i1/DBSEZ05loCB2gmMyz+FG9GQ0=; b=Y/BzZMyO0bcSBQQe90oLKVEauA+NytDC4Sx6R52KaF5SyG4RVuT3quqhkBuNlYoHaP vg7x8luVa2LZsxnUClSpSvLlOKEaF4RXf7bkr6x9ymQHMYuS5+lXY062nkDYQqRV3i7p c5xsjr2Qox9n0vpMqnBWp5IOOCkhdtinzZaRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=vovgqi0fbWjUO9awTIU5DcvKIytn049qJJM6Ncjsspxvb+5EM7qypz3ZsMoPipzyHi lADLupM3Y6rLQMrIiNeW5bLTTKPrOYCz1RzIYBUf8oEzMYm+EDQy1tEc+LNrg4qP7hJW VH0kN+EcpTqhsSJzcRsHcWOW6uvQvCTd7HYOc= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.75.70 with SMTP id x6mr4637734vcj.87.1247330736164; Sat, 11 Jul 2009 09:45:36 -0700 (PDT) In-Reply-To: <200907110828.51190.hselasky@c2i.net> References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> <4ad871310907101601h16bb09d1l570f3190f0147db8@mail.gmail.com> <3131aa530907102200h48a556d4i230d583379e35c06@mail.gmail.com> <200907110828.51190.hselasky@c2i.net> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 11 Jul 2009 18:45:16 +0200 X-Google-Sender-Auth: 0e0bc0c8eb609200 Message-ID: <3131aa530907110945s1b4be03cmec7480f9dc792917@mail.gmail.com> To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Glen Barber Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 16:45:39 -0000 > > Looks like something is wrong. What are your BIOS USB settings? > > Advanced =3D> Onboard Device Configuration =3D> USB Configuration USB Controller :=A0Enabled USB 2.0 Controller : Enabled USB Legacy support: Enabled This PC boot without problem on a FreeBSD 7.0 Regards, Olivier From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 16:55:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 755B91065673 for ; Sat, 11 Jul 2009 16:55:55 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-bw0-f221.google.com (mail-bw0-f221.google.com [209.85.218.221]) by mx1.freebsd.org (Postfix) with ESMTP id ED9DC8FC13 for ; Sat, 11 Jul 2009 16:55:54 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by bwz21 with SMTP id 21so1179248bwz.43 for ; Sat, 11 Jul 2009 09:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H808eYZFdLzHwLCkN9+4HErCqtO8OC2hrdqWRu0ojdY=; b=ni75fJARar8T68cPIG/3pOvcd1Qs67j5Q7knu+DFqWVOC3QAn4mByNbwmhu+bqAMJH KF6l9OJ9+HdQ2enoxlPPolbufUn507LJagOk3U8gOjF7qRWn0THkjtavnpjeW7Hlb/Pd i6Z1ZBJ4Ha2FH71M+lnoDcR/8kllrXE2IAWB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QfuedQ4fUD9fF8qbyOtOQW1BQwH54eZJoIABhPWNn9343D2E+lgEsanZKg4z085VNJ k+F80K/qWZO8hXZYS8fRZT8x6ibkm4qjtyyEzO0eex5IKDCOE50u4ZZ+z7eYWgURWAy/ ErHiw25s6Z32fRMzLsjpqmbxJd6RAodOEo+fQ= MIME-Version: 1.0 Received: by 10.204.79.144 with SMTP id p16mr3260306bkk.4.1247331353939; Sat, 11 Jul 2009 09:55:53 -0700 (PDT) In-Reply-To: <3131aa530907110945s1b4be03cmec7480f9dc792917@mail.gmail.com> References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> <4ad871310907101601h16bb09d1l570f3190f0147db8@mail.gmail.com> <3131aa530907102200h48a556d4i230d583379e35c06@mail.gmail.com> <200907110828.51190.hselasky@c2i.net> <3131aa530907110945s1b4be03cmec7480f9dc792917@mail.gmail.com> Date: Sat, 11 Jul 2009 12:55:53 -0400 Message-ID: <4ad871310907110955y2717cdd8ja06c95ecdff722b4@mail.gmail.com> From: Glen Barber To: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 16:55:56 -0000 2009/7/11 Olivier Cochard-Labb=E9 : >> >> Looks like something is wrong. What are your BIOS USB settings? >> >> > > Advanced =3D> Onboard Device Configuration =3D> USB Configuration > USB Controller :=A0Enabled > USB 2.0 Controller : Enabled > USB Legacy support: Enabled > > This PC boot without problem on a FreeBSD 7.0 > The USB stack was rewritten for 8.0. Try disabling one at a time to see which is causing the problem (assuming it's not the controller causing it). --=20 Glen Barber From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 17:00:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71BF71065670 for ; Sat, 11 Jul 2009 17:00:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 05D618FC1A for ; Sat, 11 Jul 2009 17:00:32 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=bE4xNkVESV0A:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=aahKj1odiu0_-FSkkHgA:9 a=G1DjHIqO073CqpAJ4BNZnEfSj90A:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1277414915; Sat, 11 Jul 2009 19:00:31 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 11 Jul 2009 19:00:08 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> <200907110828.51190.hselasky@c2i.net> <3131aa530907110945s1b4be03cmec7480f9dc792917@mail.gmail.com> In-Reply-To: <3131aa530907110945s1b4be03cmec7480f9dc792917@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907111900.11210.hselasky@c2i.net> Cc: Olivier =?iso-8859-1?q?Cochard-Labb=E9?= , Glen Barber Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 17:00:33 -0000 On Saturday 11 July 2009 18:45:16 Olivier Cochard-Labb=E9 wrote: > > Looks like something is wrong. What are your BIOS USB settings? > > Advanced =3D> Onboard Device Configuration =3D> USB Configuration > USB Controller : Enabled > USB 2.0 Controller : Enabled > USB Legacy support: Enabled > > This PC boot without problem on a FreeBSD 7.0 Are you seeing the same error message on FreeBSD 7.0 if you boot with=20 bootverbose? On Saturday 11 July 2009 07:00:32 Olivier Cochard-Labb=E9 wrote: > usbus0: SMM does not respond, resetting > usbus0: reset timeout > ohci0: USB init failed =2D-HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 17:24:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C311D106566C for ; Sat, 11 Jul 2009 17:24:56 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: from mail-ew0-f227.google.com (mail-ew0-f227.google.com [209.85.219.227]) by mx1.freebsd.org (Postfix) with ESMTP id 575968FC12 for ; Sat, 11 Jul 2009 17:24:56 +0000 (UTC) (envelope-from sullrich@gmail.com) Received: by ewy27 with SMTP id 27so778680ewy.43 for ; Sat, 11 Jul 2009 10:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=rHcQbkQf0zvCzt7Vl+3qaIq/6LrrvrgejPBc0p+yYZ8=; b=Gq6BEiEwMuuwh52/dDGybHKUfj87zMjdZQfjKy2LSy2TmGC4hOCaECj5Yrg413Grlj loQRQDuG2GbLM/GM43mEyhBp16ZNRos5WfHPQHpm/Gcq1QiqbFsqY0A+uzUs/zI9Yg/x 7R51rifSY1u5O/GqkEfARtdExwBfxObU9kXIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=dL3u8y9ha3IjnYqM5ELTabN0HHmzppJ9x+bfZeDuQLfMRwjfPtm65PbItwl6RJ3bIs sltdSUu60uozp9mjUDsIQ8Z7pBg84Mf1EVvqEtKdu1i6Ox8OdSfk73drv0EYJXNchGVr kz/lmjjBzYTFjrGAaDIHHsZ4N8cLhPJKkLKYw= MIME-Version: 1.0 Received: by 10.210.58.13 with SMTP id g13mr936666eba.39.1247333095316; Sat, 11 Jul 2009 10:24:55 -0700 (PDT) From: Scott Ullrich Date: Sat, 11 Jul 2009 13:24:34 -0400 Message-ID: To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Flowtables -- any tuning hints? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 17:24:57 -0000 Hello Freebsd-current@ folks, I see with the commit "svn commit: r191259 - head/sys/netinet" flowtables have been added.. Cool! Does anyone have any tuning hints for this addition -- specifically how much memory does the hash table consume? Or better yet does any documentation exist for this newly added feature? Looking for an easy way to calculate max flows for the amount of memory installed in a FreeBSD machine. Thanks in advance, Scott From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 17:45:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E23D1065672 for ; Sat, 11 Jul 2009 17:45:30 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B2F1D8FC08 for ; Sat, 11 Jul 2009 17:45:29 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by vwj2 with SMTP id 2so1262614vwj.3 for ; Sat, 11 Jul 2009 10:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=eGD0rp0Cd5DwZoDFaemecdrPpco4ooMmwvTyf8Xhvrg=; b=IGtYpvi2YSZZ6G0riFCSMxYi+xI8k3YgJD2qPPS3FW3KCtx++6cc8cwHKTwLRfFWtC +cNQUfUprk8wCsY5MsM7josYWV8bab/1kXedIshHuC2Aql6Y1SChy+ZkPG71miusmQNI Cn3m92DuRuYlLaMkiA5oeCYoFz6UYPzuiTk70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=e6XoFWulvNDwNAUR6fW3wRLKr9WOAQ+St2L6DXFHzcBVW+ZsyP4pqzRmL2WdULh3AR n3qeigdRd/olNfKPrAdnmo+UOFTkkP5qzhGrEV+VXQEM1NAUmvMuO8+AEyA+/vx4fN0N UNxm2ZUTGKmETK0sy9Seor5+NmLhbVBJj1wVE= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.83.201 with SMTP id g9mr4760314vcl.42.1247334329133; Sat, 11 Jul 2009 10:45:29 -0700 (PDT) In-Reply-To: <200907111900.11210.hselasky@c2i.net> References: <3131aa530907101349tac49804n86243e1c2bd055f6@mail.gmail.com> <200907110828.51190.hselasky@c2i.net> <3131aa530907110945s1b4be03cmec7480f9dc792917@mail.gmail.com> <200907111900.11210.hselasky@c2i.net> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 11 Jul 2009 19:45:09 +0200 X-Google-Sender-Auth: 975cfd374b00e82b Message-ID: <3131aa530907111045y5a71d24ah2e9f2664f8a7fd17@mail.gmail.com> To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Glen Barber Subject: Re: [8.0 Beta 1] Hang after loading USB ehci drivers on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 17:45:30 -0000 > > Are you seeing the same error message on FreeBSD 7.0 if you boot with > bootverbose? > There is only the "SSM does not respond, resetting" message for ohci0 with FreeBSD 7.0-RC3: ohci0: mem 0xd3103000-0xd3103ff irq 11 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xd3103000 ioapic0: routing intpin 11 (PCI IRQ 11) to vector 48 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SSM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xd3104000-0xd31040ff irq 10 at device 2.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xd3104000 ioapic0: routing intpin 10 (PCI IRQ 10) to vector 49 ehci: [GIANT-LOCKED] ehci: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1:=A0 on usb1 uhub1: 10 ports with 10 removable, self powered If I disable the USB 2.0 controller in the BIOS: The system can continue to load the kernel, but I still can't boot because I meet another problem related to "ata0: reiniting channel" and "ad0: FAILURE - READ_DMA timed out LBA=3D512", but I will create another thread for this problem :-( Olivier From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 18:15:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D47E1065670 for ; Sat, 11 Jul 2009 18:15:25 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id E429F8FC19 for ; Sat, 11 Jul 2009 18:15:24 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=nsAgiMTHD2GiP04PEO4lxdGmx5qFWzynyJ2/ovNaOza+A6MzOa9MQz70eKoobeyHm27/c3GhCBOp2yBvtDt4fg3i+1HcaQVPlCHqLWPlJs7LVlX6XeKvOLcryln8cRrHupwf3m0OhYNoqav5jTHjGNgCwyXnCgZW3SOdxksLz30=; Received: from amnesiac.at.no.dns (ppp85-141-163-216.pppoe.mtu-net.ru [85.141.163.216]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPh6X-000Ex6-6Z; Sat, 11 Jul 2009 22:15:21 +0400 Date: Sat, 11 Jul 2009 22:15:19 +0400 From: Eygene Ryabinkin To: Marcel Moolenaar , freebsd-current@freebsd.org Message-ID: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline In-Reply-To: <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> Sender: rea-fbsd@codelabs.ru Cc: John Marshall Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 18:15:25 -0000 --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline G'day. Fri, Jul 10, 2009 at 10:15:27AM -0700, Marcel Moolenaar wrote: > There is no need for the verb. bsdlabel should use the same > logic the kernel is using: if the C partition has a non-zero > offset, then the label is absolute and you can subtract that > offset from all partitions to make the label relative. OK, the attached patch should solve the issue in the bsdlabel: it really uses the offset of the 'c' partition to make offsets to be relative. Sat, Jul 11, 2009 at 06:24:14PM +1000, John Marshall wrote: > > Can you send me the output of "gpart show da0" and "gpart show da0s1". > > Could you also send me (or make available for download) a binary dump > > of sectors 0 (the MBR), 63 and 64 (the disklabel in slice 1). > > I have backed out the inclusion of GEOM_BSD in the kernel and no longer > have the WARNING messages appearing in dmesg. Yes, sorry -- it was my fault to advise to include it. Please, try the attached patch -- it should heal bsdlabel and it will show/use the proper offsets everywhere. Works fine for me -- offsets for 7.x and 8.x are the same. Fri, Jul 10, 2009 at 09:33:10AM -0700, Marcel Moolenaar wrote: > Please don't use GEOM_BSD. It's obsolete. I haven't removed > the code out of conservatism, but consider it dead and gone. > > As a special warning: you should not have both GEOM_PART_BSD > and GEOM_BSD. My gut feeling tells me that you have both and > that's why you have the mess you're having. Then I would add a bit stronger warning about the GEOM_BSD into /usr/src/UPDATING -- the current one (from 20090320) is rather mild in respect of the obsoletenness of GEOM_BSD. And since GEOM_PART_* seem to be included by-default, it will produce the mess I had seen when GEOM_BSD is included too. It will be good to embed the checks for incompatible options into config(8). I'll draft the needed patches for config(8). -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --V0207lvV8h4k8FAm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="obtain-slice-offset-from-disklabel.diff" Content-Transfer-Encoding: quoted-printable =46rom fb4d6d8676700caf861d164003339fb1609e05db Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Sat, 11 Jul 2009 14:53:11 +0400 Subject: [PATCH] bsdlabel: obtain slice offset from the disklabel itself Don't use offset from MBR that is obtained by the geom(4): not any system has MBR and so on ;)) Partition 'c' holds offset, so it is used -- this corresponds to the current kernel behaviour. Signed-off-by: Eygene Ryabinkin --- sbin/bsdlabel/bsdlabel.c | 28 ++++++++-------------------- 1 files changed, 8 insertions(+), 20 deletions(-) diff --git a/sbin/bsdlabel/bsdlabel.c b/sbin/bsdlabel/bsdlabel.c index 1cb9995..5aa97df 100644 --- a/sbin/bsdlabel/bsdlabel.c +++ b/sbin/bsdlabel/bsdlabel.c @@ -118,7 +118,6 @@ static int installboot; /* non-zero if we should instal= l a boot program */ static int allfields; /* present all fields in edit */ static char const *xxboot; /* primary boot */ =20 -static off_t mbroffset; #ifndef LABELSECTOR #define LABELSECTOR -1 #endif @@ -388,6 +387,7 @@ writelabel(void) struct gctl_req *grq; char const *errstr; struct disklabel *lp =3D &lab; + off_t sliceoffset; =20 if (disable_write) { warnx("write to disk label supressed - label was as follows:"); @@ -401,9 +401,10 @@ writelabel(void) lp->d_checksum =3D dkcksum(lp); if (installboot) readboot(); + sliceoffset =3D lab.d_partitions[RAW_PART].p_offset; for (i =3D 0; i < lab.d_npartitions; i++) if (lab.d_partitions[i].p_size) - lab.d_partitions[i].p_offset +=3D mbroffset; + lab.d_partitions[i].p_offset +=3D sliceoffset; bsd_disklabel_le_enc(bootarea + labeloffset + labelsoffset * secsize, lp); if (alphacksum) { @@ -481,8 +482,7 @@ readlabel(int flag) { int f, i; int error; - struct gctl_req *grq; - char const *errstr; + off_t sliceoffset; =20 f =3D open(specname, O_RDONLY); if (f < 0) @@ -510,22 +510,10 @@ readlabel(int flag) =20 if (is_file) return(0); - grq =3D gctl_get_handle(); - gctl_ro_param(grq, "verb", -1, "read mbroffset"); - gctl_ro_param(grq, "class", -1, "BSD"); - gctl_ro_param(grq, "geom", -1, pname); - gctl_rw_param(grq, "mbroffset", sizeof(mbroffset), &mbroffset); - errstr =3D gctl_issue(grq); - if (errstr !=3D NULL) { - mbroffset =3D 0; - gctl_free(grq); - return (error); - } - mbroffset /=3D lab.d_secsize; - if (lab.d_partitions[RAW_PART].p_offset =3D=3D mbroffset) - for (i =3D 0; i < lab.d_npartitions; i++) - if (lab.d_partitions[i].p_size) - lab.d_partitions[i].p_offset -=3D mbroffset; + sliceoffset =3D lab.d_partitions[RAW_PART].p_offset; + for (i =3D 0; i < lab.d_npartitions; i++) + if (lab.d_partitions[i].p_size) + lab.d_partitions[i].p_offset -=3D sliceoffset; return (error); } =20 --=20 1.6.3.1 --V0207lvV8h4k8FAm-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 18:17:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0973106566C for ; Sat, 11 Jul 2009 18:17:49 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id A8C258FC0C for ; Sat, 11 Jul 2009 18:17:49 +0000 (UTC) (envelope-from cochard@gmail.com) Received: by vwj2 with SMTP id 2so1270692vwj.3 for ; Sat, 11 Jul 2009 11:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=yJ2A6WwRUdx/slYqA10A1iNhMrJ3JplEpu2fYJAFeGU=; b=uEIOECSnUo7ZgvFCs8ltu8t20S9lntXjAVThxJAJDoONM2RUDJyuC0Z91uuoDHz5af j4vZJAbB4DrkzRYet/KKnSTpKayi9fTNLiQ+AeaPaZYycqyYDLhalKl4bnMJ+dPrcASX k2UkFdGvtf6VpqR2CRsvFBY0mGmA0ZQOdN7zA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:content-transfer-encoding; b=L2vPPR8Dmc9P1J92maa6Nom890CLW6iHqmJv+/cwcqpRyEbi5EsGWHqjDnOAimr8/h yA5rUo3wYZ+3eVN7bbphU0ZyiBP5w/5gGgMTIMTJjE+k3kx+CjKe5jRu5kV5wHhpQ6d0 ASs3aGm1dsBFBkpkZdb7HCHgPRHdYSsDwKrWo= MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.220.45.133 with SMTP id e5mr4836330vcf.28.1247336269070; Sat, 11 Jul 2009 11:17:49 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 11 Jul 2009 20:17:29 +0200 X-Google-Sender-Auth: 1b3e6fc96ace4fb7 Message-ID: <3131aa530907111117v47eeca1cgae03861d3d9cd172@mail.gmail.com> To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [8.0 Beta 1] Can't use my PATA disk (failure - read_dma48) on Asus K8N4-E X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 18:17:50 -0000 Hi, I meet a second problem when trying to upgrade my system from 7.0-RC3 to 8.0 Beta 1. The new 8.0 Beta1 kernel can't access to my PATA hard drive (which works great under FreeBSD 7.0-RC3). I've got lot's of theses error messages: ad0: FAILURE - READ_DMA48 timed out LBA=586072364 ad0: TIMEOUT - READ_DMA retrying (1 retries left) LBA= ata0: reiniting channel... Need I hand copy all the verbose messages for giving you more information ? Thanks, Olivier From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 18:45:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FF51106566C for ; Sat, 11 Jul 2009 18:45:16 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 026058FC13 for ; Sat, 11 Jul 2009 18:45:15 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n6BIip1m046107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jul 2009 04:45:05 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A58DD8D.3090308@freebsd.org> Date: Sat, 11 Jul 2009 19:44:29 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Stefan Bethke References: <128E7C52-CCBD-4BAF-A4AE-1D914A3968CB@lassitu.de> In-Reply-To: <128E7C52-CCBD-4BAF-A4AE-1D914A3968CB@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_20,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: FreeBSD Current Subject: Re: ppp triggers GPF panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 18:45:16 -0000 Stefan Bethke wrote: > Yesterday's -current, amd64, C2D, 4 GB RAM. Full dmesg below. > > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xffffffff802fc2ce > stack pointer = 0x28:0xffffff8000037b10 > frame pointer = 0x28:0xffffff8000037b30 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (swi1: netisr 0) > [thread pid 12 tid 100007 ] > Stopped at _mtx_lock_sleep+0x4e: movl 0x288(%rcx),%esi > > Didn't capture anything else there. This happened when my ADSL link was > forced down (24h connection reset). > > After fixing the file system (UFS2 + softupdates on /), I got another > "panic: spin lock held too long" on rebooting. > > Then, the GPF panic happened again as ppp was trying to establish the > connection: 1. Do you have a crash dump? 2. Can you try find a sequence of events to deterministically reproduce this? Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 18:58:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD1511065672 for ; Sat, 11 Jul 2009 18:58:42 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 7375D8FC21 for ; Sat, 11 Jul 2009 18:58:42 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n6BIwbbV011345 for ; Sat, 11 Jul 2009 20:58:38 +0200 Received: from ubm.mine.nu ([85.181.54.158] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 11 Jul 2009 20:58:37 +0200 Date: Sat, 11 Jul 2009 20:58:37 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090711205837.46b11405.ubm@u-boot-man.de> In-Reply-To: <20090710200352.72ef6804.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 11 Jul 2009 19:37:03 +0000 Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 18:58:43 -0000 On Fri, 10 Jul 2009 20:03:52 +0200 Marc "UBM" Bocklet wrote: > On Wed, 8 Jul 2009 22:50:48 +0200 > Marc "UBM" Bocklet wrote: > > > On Wed, 8 Jul 2009 19:26:42 +0200 > > Marc "UBM" Bocklet wrote: > > > > > > > > Hiho! :-) > > > > > > I just put a Highpoint RocketRaid 2322 in our file server. There > > > are no drives connected to it yet. > > > > > > I'm running: > > > > > > FreeBSD xxx 8.0-CURRENT FreeBSD 8.0-CURRENT #15: Sat Jul 4 > > > 15:23:12 CEST 2009 > > > > > > Since I put the 2322 in, the machine hangs late in the boot > > > process with above message. It continues to wait until: > > > > > > run interrupt driven hooks: still waiting for xpt_config (300 > > > seconds) and then theres nothing. No panic, keyboard still works, > > > I can still scroll through dmesg, but nothing more. > > > > > > Before it the hptrr(4) attaches, there's the following message: > > > > > > xpt_dev async called. > > > > > > I searched the archives and found some references to firewire, but > > > the machine in question has no firewire controller. > > > > > > Is there anything else I can do to debug this? > > > > > > For the record, the card is PCIe 4x, but I put it in the PCIe 16x > > > slot. The card seems to work fine though, I can access its BIOS > > > and its recognized by the FreeBSD driver. > > > > > > I'm also running with the new ahci driver. > > > > for the record: verbose boot shows no additional info. > > further info: removing the highpoint controller makes the problem > disappear. Another followup: it also makes no difference if there's an actual device attached to the controller. I'll try reverting the ahci patch next and see if that changes anything. Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 19:48:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39A2C106564A for ; Sat, 11 Jul 2009 19:48:49 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id F03A88FC15 for ; Sat, 11 Jul 2009 19:48:48 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: by vwj2 with SMTP id 2so1291042vwj.3 for ; Sat, 11 Jul 2009 12:48:48 -0700 (PDT) MIME-Version: 1.0 Sender: andy@fud.org.nz Received: by 10.220.92.204 with SMTP id s12mr4827845vcm.30.1247339848376; Sat, 11 Jul 2009 12:17:28 -0700 (PDT) In-Reply-To: <200907111710.18843.hselasky@c2i.net> References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <200907111710.18843.hselasky@c2i.net> Date: Sat, 11 Jul 2009 20:17:28 +0100 X-Google-Sender-Auth: b0072311eaa0d757 Message-ID: <1280352d0907111217r5c218cdctf158dbfc588da304@mail.gmail.com> From: Andrew Thompson To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: USB polling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 19:48:50 -0000 2009/7/11 Hans Petter Selasky : > On Friday 10 July 2009 19:20:01 Andrew Thompson wrote: >> Hi, >> >> The one usb task that is still an issue for 8.0 is the polling >> support. The code needs to call into the host controller driver to >> check if the usb descriptor has been marked as done and call the >> completion callback. I am now traveling so cant look at it, if anyone >> wants to have a look it would be fantastic. This is needed for places >> where a usb keyboard is used and interrupts are disabled (root mount, >> DDB). > > Hi, > > Probably we can implement USB polling with minimal transfer support. That > basically means: > > - no timeouts > - no automatic clear-stall > > Only support for ukbd and umass. > > Shouldn't be too hard. Thats pretty much what we need, at least for 8.0. Andrew From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 20:39:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9145F10656E4 for ; Sat, 11 Jul 2009 20:39:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 743B68FC12 for ; Sat, 11 Jul 2009 20:39:04 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMM00DEXXD37F10@asmtp023.mac.com> for freebsd-current@freebsd.org; Sat, 11 Jul 2009 13:39:04 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Sat, 11 Jul 2009 13:39:03 -0700 Message-id: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> To: rea-fbsd@codelabs.ru X-Mailer: Apple Mail (2.1070) Cc: freebsd-current@freebsd.org, John Marshall Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:39:04 -0000 On Jul 11, 2009, at 11:15 AM, Eygene Ryabinkin wrote: > > OK, the attached patch should solve the issue in the bsdlabel: > it really uses the offset of the 'c' partition to make offsets > to be relative. Yes, that's the idea. I would add a safety check though: even though the 'c' partition is defined and reserved to mean the whole disk, there's nothing preventing creative souls from using the 'c' partition for something else. I would add a check to make sure that the offset of the 'c' partition is less than or equal to any of the offsets in the partition table before subtracting. >> As a special warning: you should not have both GEOM_PART_BSD >> and GEOM_BSD. My gut feeling tells me that you have both and >> that's why you have the mess you're having. > > Then I would add a bit stronger warning about the GEOM_BSD into > /usr/src/UPDATING -- the current one (from 20090320) is rather mild in > respect of the obsoletenness of GEOM_BSD. And since GEOM_PART_* > seem to > be included by-default, it will produce the mess I had seen when > GEOM_BSD is included too. It will be good to embed the checks for > incompatible options into config(8). I'll draft the needed patches > for config(8). I think It's better to remove the options (and code) altogether. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 21:16:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83E6E10657CD for ; Sat, 11 Jul 2009 21:16:32 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 8B3A08FC12 for ; Sat, 11 Jul 2009 21:16:32 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=FZfrNccfafQ+rFuLpsoIlt3sZK4TDJgxecQDfrwtCxDQ/A4EdmsuQxPZtA23kaGp/bWQ7Z1RNraAjD95d1PmQpRAzD1e8uPCvWfaugMo7G1MC+uKt8pLlYeQf+eaXWgwt1ZUyL6yS6gCS/fPDErC/b96a3u4avp64NqDoqAQ36I=; Received: from amnesiac.at.no.dns (ppp85-141-163-216.pppoe.mtu-net.ru [85.141.163.216]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPjvp-00099C-Bn; Sun, 12 Jul 2009 01:16:29 +0400 Date: Sun, 12 Jul 2009 01:16:28 +0400 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, John Marshall Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 21:16:33 -0000 Sat, Jul 11, 2009 at 01:39:03PM -0700, Marcel Moolenaar wrote: > > OK, the attached patch should solve the issue in the bsdlabel: > > it really uses the offset of the 'c' partition to make offsets > > to be relative. > > Yes, that's the idea. I would add a safety check though: > even though the 'c' partition is defined and reserved to > mean the whole disk, there's nothing preventing creative > souls from using the 'c' partition for something else. I > would add a check to make sure that the offset of the 'c' > partition is less than or equal to any of the offsets in > the partition table before subtracting. ...and the end of partition 'c' lies not below the end any other partition on this disk (so two checks will ensure that all other partitions are strictly enclosed within 'c') -- creative souls can make 'c' to come physically first (but not from the start of the slice or even at the start of the slice; the degree of creativeness differs by-case). If there will be no such check, then, technically, there will be no problems -- we will add the same offset later when we'll be writing the label, but semantically this will be better. Am I missing something? > >> As a special warning: you should not have both GEOM_PART_BSD > >> and GEOM_BSD. My gut feeling tells me that you have both and > >> that's why you have the mess you're having. > > > > Then I would add a bit stronger warning about the GEOM_BSD into > > /usr/src/UPDATING -- the current one (from 20090320) is rather mild in > > respect of the obsoletenness of GEOM_BSD. And since GEOM_PART_* > > seem to > > be included by-default, it will produce the mess I had seen when > > GEOM_BSD is included too. It will be good to embed the checks for > > incompatible options into config(8). I'll draft the needed patches > > for config(8). > > I think It's better to remove the options (and code) altogether. In this particular case -- yes. But I'll try to equip config(4) the means of saying -- hey, options 1, 2 and (3 or 4) are incompatible. And I am inclined to code this night more than sleep ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 21:26:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133AD106568A for ; Sat, 11 Jul 2009 21:26:33 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id C8F2F8FC2F for ; Sat, 11 Jul 2009 21:26:32 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 5E51E63317E; Sat, 11 Jul 2009 23:26:31 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 12E7FBF01; Sat, 11 Jul 2009 23:26:37 +0200 (CEST) Date: Sat, 11 Jul 2009 23:26:35 +0200 From: Patrick Lamaiziere To: Hans Petter Selasky Message-ID: <20090711232635.24b28f1f@baby-jane.lamaiziere.net> In-Reply-To: <200907072039.27811.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <20090706161154.06abb3cd@baby-jane.lamaiziere.net> <200907061750.39084.hselasky@c2i.net> <200907072039.27811.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 21:26:33 -0000 Le Tue, 7 Jul 2009 20:39:26 +0200, Hans Petter Selasky a =E9crit : > There was a small bug in my patch. Could you post-patching edit=20 > /sys/dev/serial/ulpt.c >=20 > urlpt_open(struct usb_fifo *fifo, int fflags) > ulpt_open(struct usb_fifo *fifo, int fflags) Well, as I must use the unlpt device, I think this does not change anything.=20 If I understand well, with /dev/unlpt0, ulpt.c calls unlpt_open(), not ulpt_open() nor unlpt_open()? Just in case, I've tried to change unlpt_open() with static int unlpt_open(struct usb_fifo *fifo, int fflags) { struct ulpt_softc *sc =3D usb_fifo_softc(fifo); if (sc->sc_fflags & fflags) { return (EBUSY); } /* set defrag write mode */ if (fflags & FWRITE) { printf("unlpt_open: using defrag write mode\n"); usb_fifo_set_write_defrag(fifo, 1); } ... But the printer hangs after the first job (the data led on the printer stay on): unlpt_open: using defrag write mode ulpt_write_callback:237: state=3D0x0 actlen=3D0 ulpt_write_callback:237: state=3D0x1 actlen=3D32768 ulpt_write_callback:237: state=3D0x1 actlen=3D32768 ulpt_write_callback:237: state=3D0x1 actlen=3D32768 Thanks. From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 22:13:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B55A1065675 for ; Sat, 11 Jul 2009 22:13:31 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id E45988FC12 for ; Sat, 11 Jul 2009 22:13:30 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 62BD93988A; Sun, 12 Jul 2009 00:13:28 +0200 (SAST) Message-ID: <4A590E7F.8000208@phat.za.net> Date: Sun, 12 Jul 2009 00:13:19 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , John Marshall , freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 22:13:31 -0000 Hi, Eygene Ryabinkin wrote: > Please, try the attached patch -- it should heal bsdlabel and it will > show/use the proper offsets everywhere. Works fine for me -- offsets > for 7.x and 8.x are the same. I've seen the reported problem on my BETA1 systems too. I've also noticed this in my bootup dmesg: GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). These systems were partitioned and installed using BETA1's sysinstall. Out of curiosity I repartitioned and reinstalled fresh from a 7.2-RELEASE CD. No GEOM warning, and bsdlabel didn't complain. I extracted the 8.0-BETA1 kernel from CD and booted that in single user mode. The GEOM warning above didn't occur, but (7.2's) bsdlabel complained in the same way. Is it possible sysinstall is a culprit in all this? Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 20:23:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C18C1065673 for ; Sat, 11 Jul 2009 20:23:09 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 02E848FC0C for ; Sat, 11 Jul 2009 20:23:08 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n6BKN4eg014943 for ; Sat, 11 Jul 2009 22:23:04 +0200 Received: from ubm.mine.nu ([85.181.47.100] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 11 Jul 2009 22:23:04 +0200 Date: Sat, 11 Jul 2009 22:23:04 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090711222304.fc99056a.ubm@u-boot-man.de> In-Reply-To: <20090711205837.46b11405.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 11 Jul 2009 22:14:07 +0000 Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 20:23:09 -0000 On Sat, 11 Jul 2009 20:58:37 +0200 Marc "UBM" Bocklet wrote: > On Fri, 10 Jul 2009 20:03:52 +0200 > Marc "UBM" Bocklet wrote: [...] > Another followup: it also makes no difference if there's an actual > device attached to the controller. I'll try reverting the ahci patch > next and see if that changes anything. enabling or disabling the ahci patch makes no difference, neither does disabling the onboard usb controller in the bios. For further reference, this is also a Gigabye mainboard. I'm thinking about "downgrading" FreeBSD on that machine to maybe find out where the trouble started. Can I safely csup back to a certain date and then buildkernel, installworld the usual way or are there any caveats? Bye Marc From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 22:22:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85330106566C for ; Sat, 11 Jul 2009 22:22:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 326EE8FC16 for ; Sat, 11 Jul 2009 22:22:54 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:Content-Transfer-Encoding:In-Reply-To:Sender; b=LGKphKejqjNg7jke/5zkM3AKkj6hUON8l1hf3fUtSVbsmhdzasG6HaxjpjHW3SM8i2TcrCi9/5vy3kO1pYWYdQWBgKVD4uSUDeedUM8J/i68RS0yBHvSXleXlhXbaJRQgYl7o1OanhBvHYxxogITMN1bjxTv3A4HSgTFlpQC3G0=; Received: from amnesiac.at.no.dns (ppp85-141-163-216.pppoe.mtu-net.ru [85.141.163.216]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPky5-000GS8-4c; Sun, 12 Jul 2009 02:22:53 +0400 Date: Sun, 12 Jul 2009 02:22:52 +0400 From: Eygene Ryabinkin To: Aragon Gouveia Message-ID: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> <4A590E7F.8000208@phat.za.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <4A590E7F.8000208@phat.za.net> Sender: rea-fbsd@codelabs.ru Cc: Marcel Moolenaar , John Marshall , freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 22:22:54 -0000 Aragon, good day. Sun, Jul 12, 2009 at 12:13:19AM +0200, Aragon Gouveia wrote: > Eygene Ryabinkin wrote: > > Please, try the attached patch -- it should heal bsdlabel and it will > > show/use the proper offsets everywhere. Works fine for me -- offsets > > for 7.x and 8.x are the same. >=20 > I've seen the reported problem on my BETA1 systems too. I've also > noticed this in my bootup dmesg: >=20 > GEOM: ad4s2: geometry does not match label (255h,63s !=3D 16h,63s). Different and mostly harmful (as per UPDATING, 20090320) problem. > These systems were partitioned and installed using BETA1's sysinstall. >=20 > Out of curiosity I repartitioned and reinstalled fresh from a > 7.2-RELEASE CD. No GEOM warning, and bsdlabel didn't complain. bsdlabel is run on the 7.x, I suppose. That's expected that it will be consistent with sysinstall. > I extracted the 8.0-BETA1 kernel from CD and booted that in single user > mode. The GEOM warning above didn't occur, but (7.2's) bsdlabel > complained in the same way. >=20 > Is it possible sysinstall is a culprit in all this? No, the problem is that bsdlabel is missing the so-called "MBR offset" =66rom GEOM, because in 8.x GEOM_PART_* are used and they have no such geom verb (and anyway, 8.x's bsdlabel queries BSD geoms for it, not the PART_BSD ones). You'll need to patch bsdlabel (on 8.x) with the patch I had posted to this thread earlier today (and expanded patch, that should not make a difference for your setup, will be posted a bit later). If you'll happen to test the patch, please, report back. --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 23:03:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F86C106566B for ; Sat, 11 Jul 2009 23:03:41 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f224.google.com (mail-fx0-f224.google.com [209.85.220.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9A7BE8FC08 for ; Sat, 11 Jul 2009 23:03:40 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fxm24 with SMTP id 24so1282826fxm.43 for ; Sat, 11 Jul 2009 16:03:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.117.16 with SMTP id o16mr3510389bkq.100.1247353419394; Sat, 11 Jul 2009 16:03:39 -0700 (PDT) In-Reply-To: <790a9fff0907110606t61da8ebbufa5575d12d949ca@mail.gmail.com> References: <790a9fff0907101159w495b644dge4a4bd81de0bda9b@mail.gmail.com> <20090710211809.GA84773@crodrigues.org> <790a9fff0907101911y7143ed4bnbb050d78ebc21558@mail.gmail.com> <790a9fff0907110606t61da8ebbufa5575d12d949ca@mail.gmail.com> Date: Sun, 12 Jul 2009 01:03:39 +0200 Message-ID: <367b2c980907111603t74766651gf52310d38dc48dd2@mail.gmail.com> From: Olivier SMEDTS To: Scot Hetzel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current Subject: Re: [SOLVED]Re: How to create ZFS on Root using MBR slices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 23:03:41 -0000 2009/7/11 Scot Hetzel : > I was able to re-solve this problem with creating a ZFS root using a > partition on a slice. =A0The hint came from a message sent by Doug > Rabson in response to the 'ZFS boot on zfs mirror' discussion on the > FreeBSD-Stable list. > > On Tue, May 26, 2009 at 12:06 PM, Doug Rabson wrote: >> >> On Tue, 26 May 2009 19:57:03 +0300, Andriy Gapon wrote= : >>> on 26/05/2009 19:42 George Hartzell said the following: >>>> I'm still confused about the two parts of zfsboot and what's magical >>>> about seeking to 1024. >>> >>> Can't help with answer to this, but cc-ing the one who can (I think). >>> I am interested too :-) >> >> This is due to the primitive DOS boot sequence. Basically the BIOS loads >> the first sector of the partition and executes it. For zfsboot, that is = the >> first 512 bytes of /boot/zfsboot. The next stage of the bootstrap is tuc= ked >> away in a convenient hole in the ZFS on-disk formwat which is located ju= st >> after the ZFS metadata - this is the seek=3D1024 part. The first 512 byt= e >> part is a tiny assembler program that loads the rest into memory and >> executes it. The second part is large enough and smart enough to underst= and >> the ZFS filesystem format directly and it loads /boot/loader directly fr= om >> the filesystem and transfers control to that. The third stage >> (/boot/loader) is what puts up the boot menu and loads the kernel etc. > > Thanks Doug for a great explanation. > > Below is the revised instructions for creating a ZFS Root w/MBR, > Slices, and Partitions > > Scot > > -------------------------------------------------------------------------= -------------------------------------------------- > > Creating ZFS Root ZFS Root w/MBR, Slices, and Partitions > > 1. Boot FreeBSD install CD/DVD > > 2. Choose Fixit option in sysinstall > > 3. Create Slice using gpart > > Fixit# gpart show ad0 > =3D> =A0 =A0 =A0 63 =A0625142385 =A0ad0 =A0MBR =A0(289G) > =A0 =A0 =A0 =A0 63 =A0209712447 =A0 =A01 =A0!7 =A0(100G) > =A0209712510 =A0 =A0 417690 =A0 =A02 =A0!136 =A0(204M) > =A0210130200 =A0415012248 =A0 =A0 =A0 - free - =A0(198G) > > > Fixit# gpart add -b 210130200 =A0-s 415012248 -t freebsd ad0 > ad0s3 added > > Fixit# gpart show ad0 > =3D> =A0 =A0 =A0 63 =A0625142385 =A0ad0 =A0MBR =A0(289G) > =A0 =A0 =A0 =A0 63 =A0209712447 =A0 =A01 =A0!7 =A0(100G) > =A0209712510 =A0 =A0 417690 =A0 =A02 =A0!136 =A0(204M) > =A0210130200 =A0415012248 =A0 =A0 3 =A0freebsd =A0(198G) > > 4. Create partitions (ad0s3a and ad0s3b) > > Fixit# gpart show ad0s3 > =3D> =A0 =A0 =A0 =A00 =A0415012248 =A0ad0s3 =A0BSD =A0(198G) > =A0 =A0 =A0 =A0 =A00 =A0415012248 =A0ad0s3 =A0- free - =A0(198G) > > Fixit# gpart add -i 1 -b 0 -s 40663421 -t freebsd-zfs ad0s3 > ad0s3a added > > Fixit# gpart show ad0s3 > =3D> =A0 =A0 =A0 =A00 =A0415012248 =A0ad0s3 =A0BSD =A0(198G) > =A0406631421 =A0 =A0 =A01 =A0freebsd-zfs =A0(194G) > =A0406631421 =A0 =A08380827 =A0 =A0 =A0 =A0 - free - =A0(4.0G) > > Fixit# gpart add -i 2 -b 406626334 -s 8380811 -t freebsd=3Dswap ad0s3 > ad0s3b added > > Fixit# gpart show ad0s3 > =3D> =A0 =A0 =A0 =A00 =A0415012248 =A0ad0s3 =A0BSD =A0(198G) > =A0406631421 =A0 =A0 =A01 =A0freebsd-zfs =A0(194G) > =A0406631421 =A0 =A08380827 =A0 =A0 =A02 =A0freebsd-swap =A0(4.0G) > > 5. load zfs kernel module > > kldload /mnt2/boot/kernel/opensolaris.ko > kldload /mnt2/boot/kernel/zfs.ko > > 6. Create Zpool > > zpool create zroot /dev/ad0s3a > zpool set bootfs=3Dzroot zroot > > 7. Create filesystem hierarchy > > zfs create -o compression=3Don =A0 =A0-o exec=3Doff =A0 =A0 -o setuid=3Do= ff =A0 zroot/tmp > > zfs create =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zroot/usr > zfs create -o compression=3Don =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-o = setuid=3Doff =A0 zroot/usr/ports > zfs create -o compression=3Doff =A0 -o exec=3Doff =A0 =A0 -o > setuid=3Doff =A0 =A0 =A0zroot/usr/ports/distfiles > zfs create -o compression=3Doff =A0 -o exec=3Doff =A0 =A0 -o setuid=3Doff= =A0 zroot/usr/ports/packages > zfs create -o compression=3Don =A0 =A0-o exec=3Doff =A0 =A0 -o setuid=3Do= ff =A0 zroot/usr/src > > zfs create =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zroot/var > zfs create -o compression=3Don =A0 =A0-o exec=3Doff =A0 =A0 -o setuid=3Do= ff =A0 zroot/var/crash > zfs create =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-o exec=3Doff =A0 = =A0 -o setuid=3Doff =A0 zroot/var/db > zfs create -o compression=3Don =A0 =A0-o exec=3Don =A0 =A0 =A0-o setuid= =3Doff =A0 zroot/var/db/pkg > zfs create =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-o exec=3Doff =A0 = =A0 -o setuid=3Doff =A0 zroot/var/empty > zfs create -o compression=3Don =A0 =A0-o exec=3Doff =A0 =A0 -o setuid=3Do= ff =A0 zroot/var/log > zfs create -o compression=3Don =A0 =A0-o exec=3Doff =A0 =A0 -o setuid=3Do= ff =A0 zroot/var/mail > zfs create =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-o exec=3Doff =A0 = =A0 -o setuid=3Doff =A0 zroot/var/run > zfs create -o compression=3Don =A0 =A0-o exec=3Doff =A0 =A0 -o setuid=3Do= ff =A0 zroot/var/tmp > > 8. install FreeBSD to zroot > > cd /dist/8.0-20090628-SNAP > export DESTDIR=3D/zroot > for dir in base catpages dict doc games info lib32 manpages ports; do > (cd $dir ; ./install.sh) ; done > cd src ; ./install.sh all > cd ./kernel ; ./install.sh dv8135nr ; ./install.sh generic > cd /zroot/boot ; cp -rp GENERIC/* ../kernel > > 9. create rc.conf, loader.conf, src.conf > > echo 'zfs_enable=3D"YES"' > /zroot/etc/rc.conf > > echo 'LOADER_ZFS_SUPPORT=3DYES' >> /zroot/etc/src.conf > > echo 'zfs_load=3D"YES"' >> /zroot/boot/loader.conf > echo 'vfs.root.mountfrom=3D"zfs:zroot"' >> /zroot/boot/loader.conf > > 10. change root password > > chroot /zroot > passwd > exit > > 11. create zpool.cache > > mkdir /boot/zfs > zpool export zroot && zpool import zroot > cp /boot/zfs/zpool.cache /zroot/boot/zfs/zpool.cache > > 12. export LD_LIBRARY_PATH > > export LD_LIBRARY_PATH=3D/mnt2/lib > > 13. Change mount points for zroot pool > > zfs set mountpoint=3Dlegacy zroot > zfs set mountpoint=3D/tmp zroot/tmp > zfs set mountpoint=3D/usr zroot/usr > zfs set mountpoint=3D/var zroot/var > > 14. Install boot Manager > > fdisk -B -b /boot/boot0 ad0 > > 15. Install ZFS boot > > - Install the boot1 stage on the drive: > > dd if=3D/mnt2/boot/zfsboot of=3D/dev/ad0s3 count=3D1 > > Install the boot2 zfs stage into the convienient hole in the ZFS > filesystem on-disk format which is located just after the ZFS metadata > (this is the seek=3D1024). > > dd if=3D/mnt2/boot/zfsboot of=3D/dev/ad0s3a skip=3D1 seek=3D1024 Can you successfuly boot this ZFS-Only FreeBSD on MBR slices ? I tried the zfsboot trick few months ago and it didn't work for me. And it still doesn't work, I'm stuck at the loader with no prompt. I tried both with a BSD partition (freebsd-zfs type) and without, directly on the MBR slice. --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 23:07:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFD2A106566C for ; Sat, 11 Jul 2009 23:07:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id D32E98FC1C for ; Sat, 11 Jul 2009 23:07:58 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMN00KZ349A7700@asmtp023.mac.com> for freebsd-current@freebsd.org; Sat, 11 Jul 2009 16:07:58 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Sat, 11 Jul 2009 16:07:57 -0700 Message-id: References: <20090710042106.GC31950@rwpc12.mby.riverwillow.net.au> <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> <4A590E7F.8000208@phat.za.net> To: rea-fbsd@codelabs.ru X-Mailer: Apple Mail (2.1070) Cc: Aragon Gouveia , John Marshall , freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 23:07:59 -0000 On Jul 11, 2009, at 3:22 PM, Eygene Ryabinkin wrote: > Aragon, good day. > > Sun, Jul 12, 2009 at 12:13:19AM +0200, Aragon Gouveia wrote: >> Eygene Ryabinkin wrote: >>> Please, try the attached patch -- it should heal bsdlabel and it >>> will >>> show/use the proper offsets everywhere. Works fine for me -- >>> offsets >>> for 7.x and 8.x are the same. >> >> I've seen the reported problem on my BETA1 systems too. I've also >> noticed this in my bootup dmesg: >> >> GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). > > Different and mostly harmful (as per UPDATING, 20090320) problem. I think you meant to say harmless and not harmful. >> >> Is it possible sysinstall is a culprit in all this? > > No, the problem is that bsdlabel is missing the so-called "MBR offset" > from GEOM, because in 8.x GEOM_PART_* are used and they have no such > geom verb (and anyway, 8.x's bsdlabel queries BSD geoms for it, not > the > PART_BSD ones). Actually, yes. This is a problem in sysinstall. The "MBR offset" you're talking about does not relate to the geometry of a device. It relates to offsets in the disk label. The warning Aragon talks about is the result of having the underlying disk report 16 heads and 63 sectors/track, whereas the BSD disklabel itself contain values of 255 for heads and 63 for sectors/track. This means that the BSD disklabel was constructed with values that do not correspond to what the disk reports. This is where sysinstall comes into the picture. Note that it's also possible that the underlying disk changes geometry. If I install over USB onto a SATA disk (using a USB to SATA converter) and then later install the SATA disk in a machine and connected to a SATA controller, the geometry may change. In the first case the disk is accessed as daX and in the second case the disk is accessed as adX. SCSI/CAM and ATA do not agree on default geometries AFAICT... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 23:12:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78F55106564A for ; Sat, 11 Jul 2009 23:12:22 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 01F5C8FC1D for ; Sat, 11 Jul 2009 23:12:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=B8mMPVDNsYcAcywv9B3lRNun6QYIwddK+XXDPzQwYX9q60YO3yqBre9liXxOhHXU7VLx8defw1colFr8aZbzY9rLlpffwuA6RxYKGpur3023E2Q+kUxjEShFBG5WMsfwEN87JRlW3YTk3yyWmbhhLVJEqg8s6hLgk1afJcWr+YU=; Received: from amnesiac.at.no.dns (ppp85-141-163-216.pppoe.mtu-net.ru [85.141.163.216]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPljw-000M39-CC; Sun, 12 Jul 2009 03:12:20 +0400 Date: Sun, 12 Jul 2009 03:12:19 +0400 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: References: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="t0UkRYy7tHLRMCai" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, John Marshall Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 23:12:22 -0000 --t0UkRYy7tHLRMCai Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sun, Jul 12, 2009 at 01:16:28AM +0400, Eygene Ryabinkin wrote: > Sat, Jul 11, 2009 at 01:39:03PM -0700, Marcel Moolenaar wrote: > > Yes, that's the idea. I would add a safety check though: > > even though the 'c' partition is defined and reserved to > > mean the whole disk, there's nothing preventing creative > > souls from using the 'c' partition for something else. I > > would add a check to make sure that the offset of the 'c' > > partition is less than or equal to any of the offsets in > > the partition table before subtracting. > > ...and the end of partition 'c' lies not below the end any other > partition on this disk (so two checks will ensure that all other > partitions are strictly enclosed within 'c') -- creative souls can make > 'c' to come physically first (but not from the start of the slice or > even at the start of the slice; the degree of creativeness differs > by-case). If there will be no such check, then, technically, there > will be no problems -- we will add the same offset later when we'll be > writing the label, but semantically this will be better. Am I missing > something? OK, changed the patch to make the described checks. And to fix the error with the previous patch -- it will set the offset for writes to zero, so it is better to use this patch variant for doing label writes and never use the previous one for label modifications. Though it was doing the proper thing for reads. But anyway, bsdlabel won't let you write the label (old, patched with bad patch, patched with the current patch), since it wants to do it via the BSD class and our slicer is PART. Another patch will be submitted ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # --t0UkRYy7tHLRMCai Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="obtain-slice-offset-from-disklabel.diff" Content-Transfer-Encoding: quoted-printable =46rom b9f68a246d79b2d4b8150cf83d8d978118f0a27e Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Sat, 11 Jul 2009 14:53:11 +0400 Subject: [PATCH] bsdlabel: obtain slice offset from the disklabel itself Don't use offset from MBR that is obtained by the geom(4): not any system has MBR and so on ;)) Partition 'c' holds offset, so it is used -- this corresponds to the current kernel behaviour. Extra sanity checks are made to be sure that 'c' really encloses all other partitions. Signed-off-by: Eygene Ryabinkin --- sbin/bsdlabel/bsdlabel.c | 69 +++++++++++++++++++++++++++++++++---------= --- 1 files changed, 50 insertions(+), 19 deletions(-) diff --git a/sbin/bsdlabel/bsdlabel.c b/sbin/bsdlabel/bsdlabel.c index 1cb9995..37db8b5 100644 --- a/sbin/bsdlabel/bsdlabel.c +++ b/sbin/bsdlabel/bsdlabel.c @@ -93,6 +93,7 @@ static int getasciipartspec(char *, struct disklabel *, i= nt, int); static int checklabel(struct disklabel *); static void usage(void); static struct disklabel *getvirginlabel(void); +static int deduce_slice_offset(struct disklabel *, off_t *); =20 #define DEFEDITOR _PATH_VI #define DEFPARTITIONS 8 @@ -118,7 +119,8 @@ static int installboot; /* non-zero if we should instal= l a boot program */ static int allfields; /* present all fields in edit */ static char const *xxboot; /* primary boot */ =20 -static off_t mbroffset; +static off_t sliceoffset; + #ifndef LABELSECTOR #define LABELSECTOR -1 #endif @@ -344,6 +346,42 @@ makelabel(const char *type, struct disklabel *lp) bzero(lp->d_packname, sizeof(lp->d_packname)); } =20 +/* + * Determine if the offset of the 'c' partition can be used + * as the start of the slice (for example, to convert absolute + * partition offsets to the relative ones). + * + * Check is simple: + * - partition 'c' must enclose all other partitions with non-zero + * sizes. + * + * Return values: + * - 0 if everything is OK; + * - one-based number of the first partition that has problems. + */ +static int +deduce_slice_offset(struct disklabel *lbl, off_t *offset) +{ + int i; + off_t c_offset =3D lbl->d_partitions[RAW_PART].p_offset; + off_t c_size =3D lbl->d_partitions[RAW_PART].p_size; + off_t p_offset =3D 0; + off_t p_size =3D 0; + + for (i =3D 0; i < lbl->d_npartitions; i++) { + p_size =3D lbl->d_partitions[i].p_size; + if (!p_size) + continue; + p_offset =3D lbl->d_partitions[i].p_offset; + if (p_offset < c_offset || + p_offset + p_size > c_offset + c_size) + return i + 1; + } + + *offset =3D c_offset; + return 0; +} + static void readboot(void) { @@ -401,9 +439,10 @@ writelabel(void) lp->d_checksum =3D dkcksum(lp); if (installboot) readboot(); + for (i =3D 0; i < lab.d_npartitions; i++) if (lab.d_partitions[i].p_size) - lab.d_partitions[i].p_offset +=3D mbroffset; + lab.d_partitions[i].p_offset +=3D sliceoffset; bsd_disklabel_le_enc(bootarea + labeloffset + labelsoffset * secsize, lp); if (alphacksum) { @@ -481,8 +520,6 @@ readlabel(int flag) { int f, i; int error; - struct gctl_req *grq; - char const *errstr; =20 f =3D open(specname, O_RDONLY); if (f < 0) @@ -510,22 +547,16 @@ readlabel(int flag) =20 if (is_file) return(0); - grq =3D gctl_get_handle(); - gctl_ro_param(grq, "verb", -1, "read mbroffset"); - gctl_ro_param(grq, "class", -1, "BSD"); - gctl_ro_param(grq, "geom", -1, pname); - gctl_rw_param(grq, "mbroffset", sizeof(mbroffset), &mbroffset); - errstr =3D gctl_issue(grq); - if (errstr !=3D NULL) { - mbroffset =3D 0; - gctl_free(grq); - return (error); + + sliceoffset =3D 0; + i =3D deduce_slice_offset(&lab, &sliceoffset); + if (i !=3D 0) { + warn("partition '%c' isn't fully enclosed by the partition 'c'", + (char)('a' + i - 1)); } - mbroffset /=3D lab.d_secsize; - if (lab.d_partitions[RAW_PART].p_offset =3D=3D mbroffset) - for (i =3D 0; i < lab.d_npartitions; i++) - if (lab.d_partitions[i].p_size) - lab.d_partitions[i].p_offset -=3D mbroffset; + for (i =3D 0; i < lab.d_npartitions; i++) + if (lab.d_partitions[i].p_size) + lab.d_partitions[i].p_offset -=3D sliceoffset; return (error); } =20 --=20 1.6.3.1 --t0UkRYy7tHLRMCai-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 23:39:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25E73106564A for ; Sat, 11 Jul 2009 23:39:10 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id C81F28FC12 for ; Sat, 11 Jul 2009 23:39:09 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=MX+Hm3nQoCbDMVua7ZpHDV+AHlrgZBKn1sfcSgswedHMsYkH8Y5escAkY2hCrKmcF6WImEofBAtneDgXboY85XsPjfn2LugwtZqzYt1HLLSrSHCj5puB4wupQ1c4vP5kZwqWwiMRYZvuLag79eZioS3jFHzfTZ94oJ/mzLr89so=; Received: from amnesiac.at.no.dns (ppp85-141-163-216.pppoe.mtu-net.ru [85.141.163.216]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MPm9q-000P7G-Dl; Sun, 12 Jul 2009 03:39:06 +0400 Date: Sun, 12 Jul 2009 03:39:05 +0400 From: Eygene Ryabinkin To: Marcel Moolenaar Message-ID: References: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> <4A590E7F.8000208@phat.za.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: Aragon Gouveia , John Marshall , freebsd-current@freebsd.org Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 23:39:10 -0000 Sat, Jul 11, 2009 at 04:07:57PM -0700, Marcel Moolenaar wrote: > On Jul 11, 2009, at 3:22 PM, Eygene Ryabinkin wrote: > > Different and mostly harmful (as per UPDATING, 20090320) problem. > > I think you meant to say harmless and not harmful. Yes, sorry. > >> Is it possible sysinstall is a culprit in all this? > > > > No, the problem is that bsdlabel is missing the so-called "MBR offset" > > from GEOM, because in 8.x GEOM_PART_* are used and they have no such > > geom verb (and anyway, 8.x's bsdlabel queries BSD geoms for it, not > > the > > PART_BSD ones). > > Actually, yes. This is a problem in sysinstall. The "MBR offset" > you're talking about does not relate to the geometry of a device. > It relates to offsets in the disk label. OK, you're right -- I was talking only about the strange offsets inside bsdlabel and warnings that come from these offsets. Aragon should see them if he tries to run bsdlabel from 8.0-BETA1 on the properly partitioned disks with slices that do not start at 0. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 23:48:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 649A5106566C for ; Sat, 11 Jul 2009 23:48:35 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id 491418FC15 for ; Sat, 11 Jul 2009 23:48:35 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KMN00CHV64YU880@asmtp030.mac.com> for freebsd-current@freebsd.org; Sat, 11 Jul 2009 16:48:35 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Sat, 11 Jul 2009 16:48:34 -0700 Message-id: <4C84C6D2-0FEE-46F0-813B-244CA98DB5FC@mac.com> References: <20090710071023.GB32316@rwpc12.mby.riverwillow.net.au> <20090710112631.GE32316@rwpc12.mby.riverwillow.net.au> <3a142e750907100433y307f9b2bya1dc54953bdf5de2@mail.gmail.com> <0B1F6799-2FAC-4C01-A978-42E247979CAB@mac.com> <1z5niluEh3OBPNSdMbOMyoEwzX4@CWODRlDR5RMqbkBfR0/UzHcfNhE> <267A655F-13A6-4D79-A933-3A78854AC5FD@mac.com> To: rea-fbsd@codelabs.ru X-Mailer: Apple Mail (2.1070) Cc: FreeBSD Current Subject: Re: 8.0-BETA1 bsdlabel broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 23:48:35 -0000 On Jul 11, 2009, at 4:12 PM, Eygene Ryabinkin wrote: > > But anyway, bsdlabel won't let you write the label (old, patched with > bad patch, patched with the current patch), since it wants to do it > via > the BSD class and our slicer is PART. Another patch will be > submitted ;)) The best approach is to have bsdlabel go over the partitions and compare those with the XML of the GEOM stack. Then, on a partition basis, you invoke g_part gctlreqs to modify, delete and/or add partitions. When bootcode is to be installed, you invoke a gctlreq for that separately. This approach also works for fdisk(8). FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 11 23:51:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35080106564A for ; Sat, 11 Jul 2009 23:51:43 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id C91088FC08 for ; Sat, 11 Jul 2009 23:51:42 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6BNpeNS034666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Jul 2009 01:51:41 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <6D58BB3C-85F4-44A6-A43B-F6E18F056FA4@lassitu.de> From: Stefan Bethke To: Lawrence Stewart In-Reply-To: <4A58DD8D.3090308@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 12 Jul 2009 01:51:40 +0200 References: <128E7C52-CCBD-4BAF-A4AE-1D914A3968CB@lassitu.de> <4A58DD8D.3090308@freebsd.org> X-Mailer: Apple Mail (2.935.3) Cc: FreeBSD Current Subject: Re: ppp triggers GPF panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2009 23:51:43 -0000 Am 11.07.2009 um 20:44 schrieb Lawrence Stewart: > Stefan Bethke wrote: >> Yesterday's -current, amd64, C2D, 4 GB RAM. Full dmesg below. >> Fatal trap 9: general protection fault while in kernel mode >> cpuid = 0; apic id = 00 >> instruction pointer = 0x20:0xffffffff802fc2ce >> stack pointer = 0x28:0xffffff8000037b10 >> frame pointer = 0x28:0xffffff8000037b30 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 12 (swi1: netisr 0) >> [thread pid 12 tid 100007 ] >> Stopped at _mtx_lock_sleep+0x4e: movl 0x288(%rcx),%esi >> Didn't capture anything else there. This happened when my ADSL >> link was forced down (24h connection reset). >> After fixing the file system (UFS2 + softupdates on /), I got >> another "panic: spin lock held too long" on rebooting. >> Then, the GPF panic happened again as ppp was trying to establish >> the connection: > > 1. Do you have a crash dump? Unfortunatly not. > 2. Can you try find a sequence of events to deterministically > reproduce this? Not if I can help it, this is my main gateway at home. Sorry. But I'll try collect as much info as possible if and when it happens again. Stefan -- Stefan Bethke Fon +49 151 14070811