From owner-freebsd-stable@FreeBSD.ORG Sun Jun 20 00:26:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 494A9106566B for ; Sun, 20 Jun 2010 00:26:23 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 110348FC15 for ; Sun, 20 Jun 2010 00:26:22 +0000 (UTC) Received: by iwn7 with SMTP id 7so2911078iwn.13 for ; Sat, 19 Jun 2010 17:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=86KPV9XWhd4Jepo4vFQjTwr5eZKBhV433vXhvm7SMJ0=; b=jfFYyXimpW9EM0bVWW/C05gUpe+HbSj6yRe6d0uJ6j3VNqnRJVoeba3G+u4IIP6OB+ mgG1Kc7cojZcCEbwUdvXtdX75myP8HRIGhudo/5VsnNI5USKq66VDMfgV0FelHZObgkI 0i5EddRwnvFUOYgnqluCqfz49bqrVP1T0mn88= 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=eju+iONkHN+uuiLoi94Ofb7sUGaxm9DPuajQTvg61PwRHCwvJmWqhzoGDhYSfXRQ7b Qe75P/cYxckzCs4lY5Cz1AV5RgSbMjvQIitqsPIz1FXUF9sk7q17WWESyh+hg4QZltaH 1OzZQ+vX9kcfKsmiqalpOgW/92JxKakJkb1xg= MIME-Version: 1.0 Received: by 10.231.142.158 with SMTP id q30mr3423533ibu.145.1276993582373; Sat, 19 Jun 2010 17:26:22 -0700 (PDT) Received: by 10.231.182.212 with HTTP; Sat, 19 Jun 2010 17:26:22 -0700 (PDT) In-Reply-To: <4C1D4496.10403@altadena.net> References: <4C1D4496.10403@altadena.net> Date: Sat, 19 Jun 2010 19:26:22 -0500 Message-ID: From: Brandon Gooch To: Pete Carah Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: stable@freebsd.org Subject: Re: if_em problems, both 7 and 8-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 00:26:23 -0000 On Sat, Jun 19, 2010 at 5:28 PM, Pete Carah wrote: > I cannot successfully create a vlan on if_em on either releng 7 or releng= 8; > I have seen a patch for part of > the problem (checksum offsets end up incorrect) but not all. =A0Even turn= ing > off ALL hw_xxx flags leaves one > unacceptable bug - the interface gets hard-reset any time you add or dele= te > a vlan. =A0I *know* that cisco > uses these interfaces without these problems, so it has to be possible. = =A0I > have used vlans in linux without > appearing to get the same problems, though I'm not sure the rest of the > configuration matches. > > What gives, especially since the patch for one of the problems (wrong > checksum offsets) was generated > about 6 months ago... > > We are trying to use an intel platform as a router; this is a show-stoppe= r. > =A0I could try linux though I prefer not to... Would it be possible for you to provide more details about the hardware and software setup? The Intel chip and the revision (or relevant CVS info) about the builds of 7-RELENG and 8-RELENG would be useful, perhaps the dmesg of the machine and output of `pciconf -lv`? For what it's worth, I'm using vlans on an "Intel 82566DM Gigabit Ethernet Adapter (82566DM)", on-board in my Dell Optiplex 755, all hardware options on... $ ifconfig em0 em0: flags=3D8843 metric 0 mtu 1500 options=3D219b ether 00:1e:4f:d5:84:b7 inet 10.7.0.7 netmask 0xff000000 broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT ) status: active -Brandon From owner-freebsd-stable@FreeBSD.ORG Sun Jun 20 00:34:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D0F51065789 for ; Sun, 20 Jun 2010 00:34:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 343918FC1F for ; Sun, 20 Jun 2010 00:34:18 +0000 (UTC) Received: by qyk11 with SMTP id 11so866731qyk.13 for ; Sat, 19 Jun 2010 17:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OsVeIMy7uq7/JIC/JYMIwV56yOFgIh7+oObUucl7Lpw=; b=QNx74JoFX/B52u0hzXUaDXDL/5TUbOs5F/vJqK+iyJwiY8Z9fy/YorsKrHmYrm6dpf 7eH2lJiiqejrUOVl5uW+X70UbRmhXVEzeNqpPH8TDSE28biE43r1mJL32mqmt/ZF53sb JbydlBsj9f+SFF2zzYx93tSltCPqA4eXs/tJw= 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=Dt090dY339e6N+61rxQ6uq1NTs7LwdJQmg0F1oOt4oP9dqTXrXkUBe9hairrwiQGI+ lwgufwcd3iluYOfpsYV6kNaLHTJGpHG9M2WaUlUBzjofNQpaTbAkwBTeeG9JmQxD7rOS D6JnRCuLmK7kUqrxm5JyXDAGLYIlowOSiFhFA= MIME-Version: 1.0 Received: by 10.224.26.144 with SMTP id e16mr2041041qac.190.1276994058215; Sat, 19 Jun 2010 17:34:18 -0700 (PDT) Received: by 10.229.246.65 with HTTP; Sat, 19 Jun 2010 17:34:18 -0700 (PDT) In-Reply-To: <20100619192344.GA84784@icarus.home.lan> References: <20100619192344.GA84784@icarus.home.lan> Date: Sat, 19 Jun 2010 17:34:18 -0700 Message-ID: From: Jack Vogel To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 em(4) -- input errors ("Missed Packets") X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 00:34:19 -0000 I do not believe this is a problem, a bit hard to parse the numbers on that netstat, but missed packets will happen when an interface gets lots of traffic. Keep an eye on things though. Thanks, Jack On Sat, Jun 19, 2010 at 12:23 PM, Jeremy Chadwick wrote: > Something I came across today on a RELENG_8 (8.1-PRERELEASE, amd64, > built Jun 8th) system we have: > > $ netstat -i -n -d -I em1 > Name Mtu Network Address Ipkts Ierrs Idrop Opkts > Oerrs Coll Drop > em1 1500 xx:xx:xx:xx:xx:xx 16117371 17 0 11011087 > 0 0 0 > em1 1500 xxxxxxxxx/xx xxxxxxxxxxx 16108452 - - 11024972 > - - - > > The input errors are what concerned me. I poked dev.em.1.stats and got > the following: > > em1: Excessive collisions = 0 > em1: Sequence errors = 0 > em1: Defer count = 0 > em1: Missed Packets = 17 > em1: Receive No Buffers = 0 > em1: Receive Length Errors = 0 > em1: Receive errors = 0 > em1: Crc errors = 0 > em1: Alignment errors = 0 > em1: Collision/Carrier extension errors = 0 > em1: watchdog timeouts = 0 > em1: XON Rcvd = 0 > em1: XON Xmtd = 0 > em1: XOFF Rcvd = 0 > em1: XOFF Xmtd = 0 > em1: Good Packets Rcvd = 16117349 > em1: Good Packets Xmtd = 11046837 > em1: TSO Contexts Xmtd = 17609 > em1: TSO Contexts Failed = 0 > > What exactly does "Missed Packets" mean here? How is a packet "missed"? > Said port on our switch doesn't any sign of problems: > > hp2510g# show interfaces 2 > > Status and Counters - Port Counters for port 2 > > Name : port2 > Link Status : Up > Totals (Since boot or last clear) : > Bytes Rx : 3,548,949,136 Bytes Tx : 2,613,086,119 > Unicast Rx : 182,088,023 Unicast Tx : 255,981,685 > Bcast/Mcast Rx : 14,674 Bcast/Mcast Tx : 81,852 > Errors (Since boot or last clear) : > FCS Rx : 0 Drops Rx : 0 > Alignment Rx : 0 Collisions Tx : 0 > Runts Rx : 0 Late Colln Tx : 0 > Giants Rx : 0 Excessive Colln : 0 > Total Rx Errors : 0 Deferred Tx : 0 > Rates (5 minute weighted average) : > Total Rx (bps) : 1457984 Total Tx (bps) : 1494568 > Unicast Rx (Pkts/sec) : 0 Unicast Tx (Pkts/sec) : 0 > B/Mcast Rx (Pkts/sec) : 0 B/Mcast Tx (Pkts/sec) : 0 > Utilization Rx : 00.04 % Utilization Tx : 00.04 % > > Relevant userland and kernel stuff: > > $ ifconfig em1 > em1: flags=8843 metric 0 mtu 1500 > > options=219b > ether xx:xx:xx:xx:xx:xx > inet xxxxxxxxxxx netmask xxxxxxxxxx broadcast xxxxxxxxxxx > media: Ethernet autoselect (1000baseT ) > status: active > > $ netstat -m > 2162/1678/3840 mbufs in use (current/cache/total) > 2048/1030/3078/25600 mbuf clusters in use (current/cache/total/max) > 2048/896 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/104/104/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 4636K/2895K/7532K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > $ vmstat -i > interrupt total rate > irq4: uart0 868 0 > irq6: fdc0 1 0 > irq23: uhci3 ehci1+ 332 0 > cpu0: timer 1818467717 2000 > irq256: em0 375532 0 > irq257: em1 5004095 5 > irq258: ahci0 5879898 6 > cpu1: timer 1818466783 2000 > cpu3: timer 1818466831 2000 > cpu2: timer 1818466828 2000 > Total 7285128885 8012 > > $ dmesg | grep em1 > em1: port 0x3000-0x301f mem > 0xd0300000-0xd031ffff irq 17 at device 0.0 on pci15 > em1: Using MSI interrupt > em1: [FILTER] > > $ pciconf -lvc > em1@pci0:15:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > From owner-freebsd-stable@FreeBSD.ORG Sun Jun 20 09:51:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47832106564A for ; Sun, 20 Jun 2010 09:51:12 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 044EA8FC12 for ; Sun, 20 Jun 2010 09:51:12 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OQHBG-000AlK-RR for stable@freebsd.org; Sun, 20 Jun 2010 11:51:10 +0200 Resent-From: Kurt Jaeger Resent-Date: Sun, 20 Jun 2010 11:51:10 +0200 Resent-Message-ID: <20100620095110.GA41361@home.opsec.eu> Resent-To: stable@freebsd.org Date: Sun, 20 Jun 2010 11:50:52 +0200 From: Kurt Jaeger To: Pete Carah Message-ID: <20100620095052.GJ13886@home.opsec.eu> References: <4C1D4496.10403@altadena.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C1D4496.10403@altadena.net> Cc: Subject: Re: if_em problems, both 7 and 8-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 09:51:12 -0000 Hi! > We are trying to use an intel platform as a router; this is a > show-stopper. I could try linux though I prefer not to... We use Intel if_em with vlan interfaces on FreeBSD based routers, both with i386, amd64, FreeBSD 6.x, 7.x, 8.x, on many different boards and CPUs with good results for the last 7-8 years or so. If you send a little more data (pciconf, vmstat -i, ifconfig -a), maybe we find something. -- pi@opsec.eu +49 171 3101372 10 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Jun 20 12:31:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DC051065673 for ; Sun, 20 Jun 2010 12:31:36 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id E4C468FC12 for ; Sun, 20 Jun 2010 12:31:35 +0000 (UTC) Received: by bwz8 with SMTP id 8so1134735bwz.13 for ; Sun, 20 Jun 2010 05:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=IlymJcC3vDmZt7kO7LPCCgg6gvdEhhUFQduHguDmuv0=; b=HgvAKtXV/cI/Id1L/CS0VL7ghXki2eslOIEea9WcDAJKsdyvE70HG05t3PReneI5GA gKjnXehiZ/8aw2pVjTJxxId5J3FAXGeQGPYGnLe4Y6ooBai6VPpGTHi4vGxoZb/XjVQX eWmWz9TZmgYqi18LEghurKoD2qJR6MPeka0C8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=aSrytFpvzNas1/yi7dArMHmCHYgnk/agv2ByMIvCyxA3RvZdhWcQOw5M2l4l88VVvw 78gylV5EsEIl3zxTZeDtC8RVHJ1hh51ZBnvtXJQMVCAOI0bMuxEmmZyec5waedcqUcgD K+Oe7RcDpUSUNGz7p52OHj/lT2KQZ35E3DwZo= MIME-Version: 1.0 Received: by 10.204.47.36 with SMTP id l36mr1811892bkf.32.1277037094724; Sun, 20 Jun 2010 05:31:34 -0700 (PDT) Received: by 10.204.68.142 with HTTP; Sun, 20 Jun 2010 05:31:34 -0700 (PDT) Date: Sun, 20 Jun 2010 14:31:34 +0200 Message-ID: From: David DEMELIER To: freebsd-stable Content-Type: text/plain; charset=UTF-8 Subject: Yet another problem with my laptop X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 12:31:36 -0000 Hello, I always have problems with my laptop, this time is a lot of messages while running on battery : Jun 20 14:29:51 Melon kernel: ACPI Error (uteval-0318): Method execution failed [\_SB_.BAT0._UID] (Node 0xffffff0001537760), AE_AML_NO_OPERAND There is a lot of these message in /var/log/messages, but I can't see any troubles with my battery. -- Demelier David From owner-freebsd-stable@FreeBSD.ORG Sun Jun 20 14:40:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66A33106564A for ; Sun, 20 Jun 2010 14:40:05 +0000 (UTC) (envelope-from acieroid@awesom.eu) Received: from awesom.eu (ks23738.kimsufi.com [91.121.15.173]) by mx1.freebsd.org (Postfix) with ESMTP id 32EEB8FC12 for ; Sun, 20 Jun 2010 14:40:04 +0000 (UTC) Received: by awesom.eu (Postfix, from userid 1002) id CFD01C9442; Sun, 20 Jun 2010 16:23:28 +0200 (CEST) Date: Sun, 20 Jun 2010 16:23:28 +0200 From: Quentin Stievenart To: freebsd-stable@freebsd.org Message-ID: <20100620142328.GA92472@awesom.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: bwn(4) on 8.1-RC1: connection problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 14:40:05 -0000 Hi, I've some broadcom wireless cards to test here (two BCM4318 and a BCM4312). This week I tried the BCM4318 one (the 4312 is on a netbook, I'll try it later, if the 4318 works some day). First of all, I was able to use it with ndisgen on FreeBSD 7.1, but since the 7.2, it doesn't work anymore. So, two day ago I installed a 8.1-RC1 and tried bwi(4), but a `ifconfig wlan0 scan` wasn't detecting anything. So I gave bwn(4) a try, and it detect perfectly my network, but I just can't connect to it, neither with dhclient nor with a static IP. Here's what I do to try to connect: # kldload if_bwn # kldload bwn_v4_ucode # ifconfig wlan0 create wlandev bwn0 # ifconfig wlan0 up # ifconfig wlan0 ssid myssid channel 6 wepmode on wepkey mywepkey # ifconfig wlan0 wlan0: flags=8843 metric 0 mtu 1500 ether 00:11:50:d0:2f:6f media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid myssid channel 6 (2437 MHz 11b) bssid 00:60:b3:7a:5c:29 country US authmode OPEN privacy ON deftxkey UNDEF wepkey 1:40-bit txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 1 wme # ifconfig bwn0 bwn0: flags=8843 metric 0 mtu 2290 ether 00:11:50:d0:2f:6f media: IEEE 802.11 Wireless Ethernet autoselect mode 11b status: associated Then, for the static IP: # ifconfig wlan0 inet 192.168.1.30 netmask 255.255.255.0 # route add default 192.168.1.1 # arp -a ? (192.168.1.30) at 00:11:50:d0:2f:6f on wlan0 permanent [ethernet] And I can't ping anything (except localhost and 192.168.1.30) Or, with dhcp: # dhclient wlan0 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 2 No DHCPOFFERS received. No working leases in persistent database - sleeping. Here's what pciconf -lv tells me about my card: siba_bwn0@pci0:2:2:0: class=0x028000 card=0x70011799 chip=0x431814e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom 802.11b/g (BCM4318)' class = network And a dmesg | egrep "(bwn|wlan)": siba_bwn0: mem 0xfdefc000-0xfdefdfff irq 22 at device 2.0 on pci2 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf 0x17f ver 0x2050 rev 8) bwn0: DMA (32 bits) bwn0: [FILTER] wlan0: Ethernet address: 00:11:50:d0:2f:6f bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost wlan0: link state changed to UP bwn0: need multicast update callback bwn0: RX decryption attempted (old 0 keyidx 0) bwn0: RX decryption attempted (old 0 keyidx 0) bwn0: RX decryption attempted (old 0 keyidx 0) bwn0: RX decryption attempted (old 0 keyidx 0) bwn0: RX decryption attempted (old 0 keyidx 0) Also, when I start tcpdump on wlan0, and try to ping this computer from another one, I see all the ping requests and responses on FreeBSD, but the other computer don't get any response. Does anyone knows what to do now ? Regards, Quentin Stievenart. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 21 05:21:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14420106566B for ; Mon, 21 Jun 2010 05:21:11 +0000 (UTC) (envelope-from bseklecki@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.freebsd.org (Postfix) with ESMTP id B5A348FC0A for ; Mon, 21 Jun 2010 05:21:10 +0000 (UTC) Received: from the-df5g.myhome.westell.com (pool-71-182-215-140.pitbpa.east.verizon.net [71.182.215.140]) (AUTH: LOGIN bseklecki, TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by wingspan with esmtp; Mon, 21 Jun 2010 01:11:02 -0400 id 0003F407.000000004C1EF466.00000B0A Date: Mon, 21 Jun 2010 01:10:57 -0400 (Eastern Daylight Time) From: "Brian Seklecki (Mobile)" To: Jack Vogel In-Reply-To: Message-ID: References: <1275419919.30057.50.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> <20100601193733.GA44816@icarus.home.lan> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) X-X-Sender: bseklecki@mx00.pub.collaborativefusion.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Brandon Gooch , freebsd-stable , Jeremy Chadwick Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 05:21:11 -0000 On Fri, 18 Jun 2010, Jack Vogel wrote: > Yes, the commits today are slated to get into 8.1, at least that's my > understanding. Lets hope so; its looking very promising on the systems I'm able to test on. We should ask 82541EI and Dell 9th gen PowerEdge users to test them right away. ~BAS From owner-freebsd-stable@FreeBSD.ORG Mon Jun 21 07:48:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3947A106564A for ; Mon, 21 Jun 2010 07:48:48 +0000 (UTC) (envelope-from izaera@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id C516F8FC0A for ; Mon, 21 Jun 2010 07:48:47 +0000 (UTC) Received: by wwg30 with SMTP id 30so3069601wwg.13 for ; Mon, 21 Jun 2010 00:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=Cy3f+l0qMS8yDhgQNJsq1S8uO43KEUHAI6Rn3M/XjEY=; b=ac7D1ErObXfBquRbK9shmCQfq1Un8kRaKv1J02SCrKbBlyrRA6qfuRgsjRtSA+qd9v UlX0jVm7EuDLSCee18V4vp946wSB0pYlYHntRp5IMURD68FHZHzUYYv1LHLOlQ26nGl3 222uMOjx66oT/MNPqC7wlyb8O1P7V5VkGIqWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sQfJGqq248+XGzX8koNuKUnuURmd9TkhF/5Lec68g0Bgd+Qz4FBgUJuP4j5LVGU9lZ 5ufcTNliMoMZ1KpQ3230wQ4OVjXiQwYctvlHpfXonvDkykjAZVr+z0sBIv8REpwwJnSO CGq+pNmbcsE1850QoMggpbTL+xLFtzmqGdh/w= MIME-Version: 1.0 Received: by 10.216.85.196 with SMTP id u46mr2339475wee.114.1277104867531; Mon, 21 Jun 2010 00:21:07 -0700 (PDT) Received: by 10.216.9.11 with HTTP; Mon, 21 Jun 2010 00:21:07 -0700 (PDT) Date: Mon, 21 Jun 2010 09:21:07 +0200 Message-ID: From: =?UTF-8?B?SXbDoW4gWmFlcmEgQXZlbGzDs24=?= To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Problems with EeePC 1005HA wireless (Wireless Atheros 9285) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 07:48:48 -0000 I'm new to the list, so hello everybody and pleased to meet you all. I have installed the recent 8.1 BETA 1 on an Eee PC 1005HA and I'm experiencing problems with the wireless card. It is correctly recognized and configured. I have an ath0 device and I can create an wlan0 without problems. I can even scan with wlan0 and sometimes I see my wireless router. The problem is when wpa_supplicant tries to register with the network that it fails. BTW, I have a WEP system with long key (13 hex digits). I have sniffed the wireless network with another computer and the packets seem to be all correct: the Eee PC sends correct packets to the air, and the wifi router replies them correctly, but wpa_supplicant reports "registration timed out", as if it wasn't receiving the packets. It is nevertheless very strange because around 2-3 weeks ago I had the STABLE branch installed on the same Eee PC and the wifi worked (not always, but it succedeed always when it was near the router and the PC was just being rebooted). Does anybody experience the same problem or has any hint on what could be happening? I have compiled my kernel with AH_DEBUG and ATH_DEBUG so I can also send dmesg traces if anyone can analyze them. Thanks in advance for your help, -- Ivan Zaera http://www.factoria2.com/desde/correo From owner-freebsd-stable@FreeBSD.ORG Mon Jun 21 11:46:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54E771065670 for ; Mon, 21 Jun 2010 11:46:23 +0000 (UTC) (envelope-from stark@mapper.nl) Received: from smtp-out3.tiscali.nl (smtp-out3.tiscali.nl [195.241.79.178]) by mx1.freebsd.org (Postfix) with ESMTP id 1251E8FC21 for ; Mon, 21 Jun 2010 11:46:22 +0000 (UTC) Received: from [82.170.17.27] (helo=mapper.nl) by smtp-out3.tiscali.nl with esmtp (Exim) (envelope-from ) id 1OQfSH-0004Y7-VD; Mon, 21 Jun 2010 13:46:22 +0200 Received: from [10.58.235.50] by mapper.nl with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1OQfSE-000Ci4-R8; Mon, 21 Jun 2010 13:46:19 +0200 Message-ID: <4C1F5108.8080106@mapper.nl> Date: Mon, 21 Jun 2010 13:46:16 +0200 From: Mark Stapper User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Alfred Bartsch References: <4C1B2180.1040300@mapper.nl> <4C1B4858.7040805@dssgmbh.de> <4C1C88AC.6090801@mapper.nl> In-Reply-To: <4C1C88AC.6090801@mapper.nl> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEB44D7B40E21AF202BE36748" Cc: freebsd-stable@freebsd.org Subject: Re: network deamons starting before network! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 11:46:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEB44D7B40E21AF202BE36748 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19/06/2010 11:06, Mark Stapper wrote: > On 06/18/10 12:20, Alfred Bartsch wrote: > =20 >> Mark Stapper schrieb: >> =20 >> =20 >>> Hello, >>> >>> Since updating to 8.X I noticed that network services were started >>> before the network was up! >>> I use lagg failover configuration on both my FreeBSD boxes. >>> First, boot fails on mounting my nfs-shares. >>> After entering and exiting the "rescue" shell, the system boots as no= rmal. >>> =20 >>> =20 >> Hello, >> >> adding: >> synchronous_dhclient=3D"YES" >> to /etc/rc.conf solved some similar issues for me. >> The default behaviour of getting an IP via dhcp has changed. >> =20 >> =20 > I'll try that too. > That would explain why I didn't have this problem on 7.2 > I DO like the whole netwait idea though. > But for me, the synchronous_dhclient flag should be sufficient I think.= > > =20 Worked like a charm! Thank you again Regards, Mark --------------enigEB44D7B40E21AF202BE36748 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwfUQoACgkQN9xNqOOVnWCxdACdH/AHK37YkKa+nG4Xn1kjr/0k FREAnjEega2+yuLkaJuweJcJi2l/kU51 =IgHK -----END PGP SIGNATURE----- --------------enigEB44D7B40E21AF202BE36748-- From owner-freebsd-stable@FreeBSD.ORG Mon Jun 21 20:18:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C5631065677 for ; Mon, 21 Jun 2010 20:18:18 +0000 (UTC) (envelope-from swisscheeseo@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C5FC48FC1F for ; Mon, 21 Jun 2010 20:18:17 +0000 (UTC) Received: by iwn7 with SMTP id 7so4734351iwn.13 for ; Mon, 21 Jun 2010 13:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qGX7SkqzE8/y5JGCxIiNM9KX7bbL2f8xHVbQQP6gUMo=; b=IcbnqOPoK9MHXxpIGR//Rk23IPTsYJX99QGkQbofWs1RUDyIZPoR2AuspkNHu8JBHF YPB+E9CFxEXLNfkLr4u1Cx11mOxtDmDATh5nYmUFhheiuYWyrghcLt6LOsAsdDST2K1N 5DYNdOccnWSYjApN2nkHdaa+OXMwrmy/fm7Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=Pt9vpocILC5m5xgnfF8qiwtMuqa+oVjED5skAyVaz2d8/tJF31HRu1qQVTPUTSAZUw +XIvTCEguPWd4lhw0WWLQYjZ0sRODtbr0aA7QazUjjZGSM3A0zW1TG6rMUZqQRlckOeT 4ISBs3FFQx2HIMclGe/S3YorcMnULi2RoiZr8= MIME-Version: 1.0 Received: by 10.42.2.199 with SMTP id 7mr1944359icl.12.1277149904048; Mon, 21 Jun 2010 12:51:44 -0700 (PDT) Sender: swisscheeseo@gmail.com Received: by 10.231.177.79 with HTTP; Mon, 21 Jun 2010 12:51:43 -0700 (PDT) Date: Mon, 21 Jun 2010 15:51:43 -0400 X-Google-Sender-Auth: IB2u33MiNQT-sG6sqdNyD631qxU Message-ID: From: Josh Ledford To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: help X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 20:18:18 -0000 On Mon, Jun 21, 2010 at 8:00 AM, wrot= e: > Send freebsd-stable mailing list submissions to > =A0 =A0 =A0 =A0freebsd-stable@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > =A0 =A0 =A0 =A0http://lists.freebsd.org/mailman/listinfo/freebsd-stable > or, via email, send a message with subject or body 'help' to > =A0 =A0 =A0 =A0freebsd-stable-request@freebsd.org > > You can reach the person managing the list at > =A0 =A0 =A0 =A0freebsd-stable-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-stable digest..." > > > Today's Topics: > > =A0 1. Yet another problem with my laptop (David DEMELIER) > =A0 2. bwn(4) on 8.1-RC1: connection problems (Quentin Stievenart) > =A0 3. Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT > =A0 =A0 =A0on =A0PowerEdge 1850 (Brian Seklecki (Mobile)) > =A0 4. Problems with EeePC 1005HA wireless (Wireless Atheros 9285) > =A0 =A0 =A0(Iv?n Zaera Avell?n) > =A0 5. Re: network deamons starting before network! (Mark Stapper) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Jun 2010 14:31:34 +0200 > From: David DEMELIER > Subject: Yet another problem with my laptop > To: freebsd-stable > Message-ID: > =A0 =A0 =A0 =A0 > Content-Type: text/plain; charset=3DUTF-8 > > Hello, > > I always have problems with my laptop, this time is a lot of messages > while running on battery : > > Jun 20 14:29:51 Melon kernel: ACPI Error (uteval-0318): Method > execution failed [\_SB_.BAT0._UID] (Node 0xffffff0001537760), > AE_AML_NO_OPERAND > > There is a lot of these message in /var/log/messages, but I can't see > any troubles with my battery. > > -- > Demelier David > > > ------------------------------ > > Message: 2 > Date: Sun, 20 Jun 2010 16:23:28 +0200 > From: Quentin Stievenart > Subject: bwn(4) on 8.1-RC1: connection problems > To: freebsd-stable@freebsd.org > Message-ID: <20100620142328.GA92472@awesom.eu> > Content-Type: text/plain; charset=3Dutf-8 > > Hi, > > I've some broadcom wireless cards to test here (two BCM4318 and a > BCM4312). This week I tried the BCM4318 one (the 4312 is on a netbook, > I'll try it later, if the 4318 works some day). > > First of all, I was able to use it with ndisgen on FreeBSD 7.1, but > since the 7.2, it doesn't work anymore. So, two day ago I installed a > 8.1-RC1 and tried bwi(4), but a `ifconfig wlan0 scan` wasn't detecting > anything. > > So I gave bwn(4) a try, and it detect perfectly my network, but I just > can't connect to it, neither with dhclient nor with a static IP. > Here's what I do to try to connect: > > # kldload if_bwn > # kldload bwn_v4_ucode > # ifconfig wlan0 create wlandev bwn0 > # ifconfig wlan0 up > # ifconfig wlan0 ssid myssid channel 6 wepmode on wepkey mywepkey > # ifconfig wlan0 > wlan0: flags=3D8843 metric 0 mtu > 1500 > =A0 =A0 =A0 =A0ether 00:11:50:d0:2f:6f > =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > =A0 =A0 =A0 =A0status: associated > =A0 =A0 =A0 =A0ssid myssid channel 6 (2437 MHz 11b) bssid 00:60:b3:7a:5c:= 29 > =A0 =A0 =A0 =A0country US authmode OPEN privacy ON deftxkey UNDEF wepkey = 1:40-bit > =A0 =A0 =A0 =A0txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgs= canidle 250 > =A0 =A0 =A0 =A0roam:rssi 7 roam:rate 1 wme > # ifconfig bwn0 > bwn0: flags=3D8843 metric 0 mtu 2= 290 > =A0 =A0 =A0 =A0ether 00:11:50:d0:2f:6f > =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > =A0 =A0 =A0 =A0status: associated > > Then, for the static IP: > # ifconfig wlan0 inet 192.168.1.30 netmask 255.255.255.0 > # route add default 192.168.1.1 > # arp -a > ? (192.168.1.30) at 00:11:50:d0:2f:6f on wlan0 permanent [ethernet] > > And I can't ping anything (except localhost and 192.168.1.30) > Or, with dhcp: > # dhclient wlan0 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 2 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > Here's what pciconf -lv tells me about my card: > > siba_bwn0@pci0:2:2:0: class=3D0x028000 card=3D0x70011799 chip=3D0x431814e= 4 > rev=3D0x02 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Broadcom Corporation' > =A0 =A0device =A0 =A0 =3D 'Broadcom 802.11b/g (BCM4318)' > =A0 =A0class =A0 =A0 =A0=3D network > > And a dmesg | egrep "(bwn|wlan)": > > siba_bwn0: mem 0xfdefc000-0xfdefdff= f irq 22 at device 2.0 on pci2 > bwn0 on siba_bwn0 > bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf= 0x17f ver 0x2050 rev 8) > bwn0: DMA (32 bits) > bwn0: [FILTER] > wlan0: Ethernet address: 00:11:50:d0:2f:6f > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost > wlan0: link state changed to UP > bwn0: need multicast update callback > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > > Also, when I start tcpdump on wlan0, and try to ping this computer from > another one, I see all the ping requests and responses on FreeBSD, but > the other computer don't get any response. > > Does anyone knows what to do now ? > > Regards, > > Quentin Stievenart. > > > ------------------------------ > > Message: 3 > Date: Mon, 21 Jun 2010 01:10:57 -0400 (Eastern Daylight Time) > From: "Brian Seklecki (Mobile)" > Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT > =A0 =A0 =A0 =A0on =A0PowerEdge 1850 > To: Jack Vogel > Cc: Brandon Gooch , =A0 =A0 =A0 =A0freebsd-s= table > =A0 =A0 =A0 =A0, =A0 Jeremy Chadwick > =A0 =A0 =A0 =A0 > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed > > > > On Fri, 18 Jun 2010, Jack Vogel wrote: > >> Yes, the commits today are slated to get into 8.1, at least that's my >> understanding. > > Lets hope so; its looking very promising on the systems I'm able to test > on. > > We should ask 82541EI and Dell 9th gen PowerEdge users to test them right > away. > > ~BAS > > > ------------------------------ > > Message: 4 > Date: Mon, 21 Jun 2010 09:21:07 +0200 > From: Iv?n Zaera Avell?n > Subject: Problems with EeePC 1005HA wireless (Wireless Atheros 9285) > To: freebsd-stable@freebsd.org > Message-ID: > =A0 =A0 =A0 =A0 > Content-Type: text/plain; charset=3DUTF-8 > > I'm new to the list, so hello everybody and pleased to meet you all. > > I have installed the recent 8.1 BETA 1 on an Eee PC 1005HA and I'm > experiencing problems > with the wireless card. It is correctly recognized and configured. I have= an > ath0 device and I > can create an wlan0 without problems. I can even scan with wlan0 and > sometimes I see my > wireless router. The problem is when wpa_supplicant tries to register wit= h > the network that it > fails. BTW, I have a WEP system with long key (13 hex digits). > > I have sniffed the wireless network with another computer and the packets > seem to be all > correct: the Eee PC sends correct packets to the air, and the wifi router > replies them correctly, > but wpa_supplicant reports "registration timed out", as if it wasn't > receiving the packets. > > It is nevertheless very strange because around 2-3 weeks ago I had the > STABLE branch installed > on the same Eee PC and the wifi worked (not always, but it succedeed alwa= ys > when it was near > the router and the PC was just being rebooted). > > Does anybody experience the same problem or has any hint on what could be > happening? > > I have compiled my kernel with AH_DEBUG and ATH_DEBUG so I can also send > dmesg traces > if anyone can analyze them. > > Thanks in advance for your help, > -- > Ivan Zaera > http://www.factoria2.com/desde/correo > > > ------------------------------ > > Message: 5 > Date: Mon, 21 Jun 2010 13:46:16 +0200 > From: Mark Stapper > Subject: Re: network deamons starting before network! > To: Alfred Bartsch > Cc: freebsd-stable@freebsd.org > Message-ID: <4C1F5108.8080106@mapper.nl> > Content-Type: text/plain; charset=3D"utf-8" > > On 19/06/2010 11:06, Mark Stapper wrote: >> On 06/18/10 12:20, Alfred Bartsch wrote: >> >>> Mark Stapper schrieb: >>> >>> >>>> Hello, >>>> >>>> Since updating to 8.X I noticed that network services were started >>>> before the network was up! >>>> I use lagg failover configuration on both my FreeBSD boxes. >>>> First, boot fails on mounting my nfs-shares. >>>> After entering and exiting the "rescue" shell, the system boots as nor= mal. >>>> >>>> >>> Hello, >>> >>> adding: >>> synchronous_dhclient=3D"YES" >>> to /etc/rc.conf solved some similar issues for me. >>> The default behaviour of getting an IP via dhcp has changed. >>> >>> >> I'll try that too. >> That would explain why I didn't have this problem on 7.2 >> I DO like the whole netwait idea though. >> But for me, the synchronous_dhclient flag should be sufficient I think. >> >> > Worked like a charm! > Thank you again > Regards, > Mark > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 260 bytes > Desc: OpenPGP digital signature > Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100= 621/f92b75e9/signature-0001.pgp > > ------------------------------ > > _______________________________________________ > 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" > > End of freebsd-stable Digest, Vol 362, Issue 1 > ********************************************** > From owner-freebsd-stable@FreeBSD.ORG Mon Jun 21 22:02:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DD96106566B for ; Mon, 21 Jun 2010 22:02:11 +0000 (UTC) (envelope-from matt@bubblegen.co.uk) Received: from relay.pcl-ipout01.plus.net (relay.pcl-ipout01.plus.net [212.159.7.99]) by mx1.freebsd.org (Postfix) with ESMTP id 34C2C8FC24 for ; Mon, 21 Jun 2010 22:02:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKd3H0xUXebj/2dsb2JhbACDHZtqcbIVkRyBJYEpEoFLcASQdg Received: from outmx01.plus.net ([84.93.230.227]) by relay.pcl-ipout01.plus.net with ESMTP; 21 Jun 2010 22:33:13 +0100 Received: from bubblegen.plus.com ([80.229.236.194] helo=[192.136.1.18]) by outmx01.plus.net with esmtp (Exim) id 1OQocC-0004e4-Ui; Mon, 21 Jun 2010 22:33:13 +0100 From: Matthew Lear To: Jeremy Chadwick In-Reply-To: <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> Content-Type: text/plain; charset="UTF-8" Date: Mon, 21 Jun 2010 22:33:12 +0100 Message-ID: <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:02:11 -0000 Hello Jeremy. I just wondered if you had any further thoughts on the info below. Two new disks arrived over the weekend and I'm still unsure if I'm best to replace ad0 or not... Much appreciated indeed. -- Matt On Fri, 2010-06-18 at 20:28 +0100, Matthew Lear wrote: > On Fri, 2010-06-18 at 10:42 -0700, Jeremy Chadwick wrote: > > On Fri, Jun 18, 2010 at 04:47:11PM +0100, Matthew Lear wrote: > > > Hello Jeremy, > > > Thanks very much for the feedback. > > > > > > [snip] > > > > Could you please provide the full output from "smartctl -a /dev/ad0" > > > > here? Your drive may be completely fine and you may not have to swap it > > > > at all; hard to say. > > > > > > Sure. See below: > > > {snip} > > > > Your SMART statistics look completely OK. There's nothing there that > > indicates there were any write failures or otherwise. I'll explain near > > the end of the Email how to test a range of LBAs "just in case". > > Good. That's what I thought too :-) > > > I'll take a moment to point out that the error previously seen was a > > timeout during a write transaction (WRITE_DMA48). Recap: > > > > > > > ad0: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=395032335 > > > > > ad0: FAILURE - WRITE_DMA48 status=51 error=10 LBA=395032335 > > > > > ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode > > > > The status codes shown (status=51 and error=10) are hexadecimal. I'm > > pointing this out because they aren't preceded by '0x' or '$' and it > > clarifies my next point: > > > > NID_NOT_FOUND (bit 4 set in the ATA error field) is referred to as IDNF > > per ATA6-ACS specification and onward, so I'll refer to it as that. > > (I've always wondered why FreeBSD calls this NID_NOT_FOUND; IDFN stands > > for ID Not Found, so what's with the extra "N"? I've always felt this > > is a typo...) > > > > Using the ATA8-ACS specification working draft (2007/05/21), since it's > > more recent, we see the following: > > > > Section 6.2 - Error field > > Section 6.2.4 - ID Not Found (IDNF) bit > > > > Error bit 4. The IDNF bit shall be set to one if a user-accessible > > address was not found. The IDNF bit shall be set to one if an > > address outside of the range of user-accessible addresses is > > requested when command aborted is not returned (see 4.11.3 and > > 6.2.1). > > > > Section 4.11 - Host Protected Area (HPA) feature set > > Section 4.11.3 - 28-bit and 48-bit HPA commands > > > > Any read or write command to an address above the maximum address > > specified by the SET MAX ADDRESS or SET MAX ADDRESS EXT command shall > > cause command completion with the IDNF bit set to one and ERR set to > > one, or command aborted. > > > > There's no definition of what "address" means in 6.2.4, but the most > > logical (pun intended) guess is an LBA. This error is returned by the > > disk (e.g. not a controller-induced error). I've mentioned this problem > > in the past: > > > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > > > I've always read IDNF to mean "OS requested access (read or write) to an > > LBA which is out of bounds", where "out of bounds" means "not between 0 > > and ". How exactly is that possible? Alexander, do you have > > any familiarity with this error code per ATA spec? > > > > Matthew, can you provide output from "atacontrol cap ad0"? Thanks. > > Sure thing. See below. > [root@meshuga /home/matt]# atacontrol cap ad0 > > Protocol SATA revision 2.x > device model WDC WD3200AAKS-00VYA0 > serial number WD-WCARW0164427 > firmware revision 12.01B02 > 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 no no 0/0x00 > automatic acoustic management yes no 254/0xFE 128/0x80 > [root@meshuga /home/matt]# > > > > > > Now regarding the LBA tests -- "smartctl -t select,start-end" will do > > the trick. start should be a starting LBA, end should be an ending LBA. > > The OS claims that LBA 395032335 is what was requested to be accessed > > when the failure happened, so I would recommend picking start/end ranges > > around that area. Remember that a single sector encapsulates a very > > large number of blocks (especially given sizes of disks today), so it's > > wise to pick a very large range of LBAs. I would recommend this in your > > case: > > > > smartctl -t select,390000000,410000000 /dev/ad0 > > [root@meshuga /home/matt]# smartctl -t > select,390000000-410000000 /dev/ad0 > smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 7.2-RELEASE-p4 i386] (local > build) > Copyright (C) 2002-10 by Bruce Allen, > http://smartmontools.sourceforge.net > > === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === > Sending command: "Execute SMART Selective self-test routine immediately > in off-line mode". > SPAN STARTING_LBA ENDING_LBA > 0 390000000 410000000 > Drive command "Execute SMART Selective self-test routine immediately in > off-line mode" successful. > Testing has begun. > You have mail in /var/mail/matt > [root@meshuga /home/matt]# > > ... some time passes polling status with smartctl -a /dev/ad0 ... > > [root@meshuga /home/matt]# smartctl -a /dev/ad0 > smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 7.2-RELEASE-p4 i386] (local > build) > Copyright (C) 2002-10 by Bruce Allen, > http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === > Model Family: Western Digital Caviar Blue Serial ATA family > Device Model: WDC WD3200AAKS-00VYA0 > Serial Number: WD-WCARW0164427 > Firmware Version: 12.01B02 > User Capacity: 320,072,933,376 bytes > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: Exact ATA specification draft version not indicated > Local Time is: Fri Jun 18 20:20:17 2010 BST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x84) Offline data collection activity > was suspended by an interrupting command from host. > Auto Offline Data Collection: Enabled. > Self-test execution status: ( 0) The previous self-test routine > completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: (8400) seconds. > Offline data collection > capabilities: (0x7b) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Suspend Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 2) minutes. > Extended self-test routine > recommended polling time: ( 100) minutes. > Conveyance self-test routine > recommended polling time: ( 5) minutes. > SCT capabilities: (0x303f) SCT Status supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 16 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always > - 0 > 3 Spin_Up_Time 0x0003 218 150 021 Pre-fail Always > - 2100 > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always > - 118 > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always > - 0 > 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always > - 0 > 9 Power_On_Hours 0x0032 088 088 000 Old_age Always > - 9320 > 10 Spin_Retry_Count 0x0012 100 100 051 Old_age Always > - 0 > 11 Calibration_Retry_Count 0x0012 100 100 051 Old_age Always > - 0 > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always > - 116 > 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always > - 115 > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always > - 118 > 194 Temperature_Celsius 0x0022 108 103 000 Old_age Always > - 39 > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always > - 0 > 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always > - 0 > 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age > Offline - 0 > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always > - 0 > 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age > Offline - 0 > > SMART Error Log Version: 1 > No Errors Logged > > SMART Self-test log structure revision number 1 > Num Test_Description Status Remaining > LifeTime(hours) LBA_of_first_error > # 1 Selective offline Completed without error 00% 9319 > - > # 2 Extended offline Completed without error 00% 9299 > - > # 3 Short offline Completed without error 00% 9298 > - > > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 390000000 410000000 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute > delay. > > > > I would highly recommend doing this with the disk not doing any I/O, > > though it won't hurt it (it'll just delay the scan). "smartctl -a" will > > show the state of things in the "SMART Selective self-test log" at the > > bottom, or somewhere else within the output (depends on the drive). > > > > This should, in my opinion, rule out whether or not there's a bad block > > or something along those lines within said range. Given what I believe > > IDNF represents, I would say your scan will probably come back clean. > > Also remember that the scan performed here is a *disk-level scan*; the > > disk firmware itself is doing it (the OS isn't involved). This helps > > rule out any sort of "weird" issues that the OS may be reporting ("hey > > man, LBA 8943943983492893428932489324 is bad!" "Yeah sure it is"). > > > > > The two devices in the array are on channels 0 and 1. There is indeed a > > > second drive on channel 0 (160G). As I said above, I use that as an > > > additional back up device but it's not part of the array. > > > > Okay, so executing "atacontrol detach ata0" will cause you to lose both > > ad0 and ad1. If you can live with that, then cool. > > > > > > What motherboard is this? Can you change the setting to either > > > > "Native", "Enhanced", or (even better) "AHCI"? I've seen some systems > > > > where the Serial ATA option in the BIOS has an "Auto" option, which does > > > > totally bizarre things at times. > > > > > > I think this has been covered in subsequent postings. I could try it but > > > as you say below, I'd like to resolve the disk issue first. > > > ... > > > > The atacontrol man page covers your situation: > > > > ... > > > I don't think this is the case for me since ad0 and ad2 are on seperate > > > ata channels. > > > ... > > > Indeed but my hw doesn't have hot-swap capability (at the moment!). > > > > That's the problem -- we're not sure if this really is a disk issue. > > It's been reported before, others have reported solving it by increasing > > ATA timeout values, etc... But the fact of the matter is, that error > > code is being returned by the device. > > Indeed. if I look back through my logs the error has happened quite a > few times over the course of several weeks before atacontrol took action > and offlined the drive: > > [root@meshuga /home/matt]# zcat /var/log/messages.0.bz2 | grep ad0 > Mar 14 21:17:33 meshuga kernel: ad0: 305245MB 12.01B02> at ata0-master SATA300 > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1a is > ufsid/47284adaeab4f771. > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1d is > ufsid/47284ae5159318bb. > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1e is > ufsid/47284ada8adb1df9. > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1f is > ufsid/47284adaa202995d. > Mar 14 21:17:33 meshuga kernel: ar0: disk0 READY (master) using ad0 at > ata0-master > Mar 28 17:59:59 meshuga kernel: ad0: 305245MB 12.01B02> at ata0-master SATA300 > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1a is > ufsid/47284adaeab4f771. > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1d is > ufsid/47284ae5159318bb. > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1e is > ufsid/47284ada8adb1df9. > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1f is > ufsid/47284adaa202995d. > Mar 28 17:59:59 meshuga kernel: ar0: disk0 READY (master) using ad0 at > ata0-master > May 1 03:03:23 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=20472527 > May 30 03:01:54 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=24996179 > Jun 1 03:02:47 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=27745599 > Jun 1 03:03:35 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=29127787 > Jun 1 03:03:41 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=29131871 > Jun 1 05:00:10 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=21646831 > Jun 2 03:02:02 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=25019047 > Jun 2 03:02:09 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=24262079 > Jun 2 03:02:25 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=26503067 > Jun 2 03:02:45 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=24991895 > Jun 2 03:03:22 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=26526099 > Jun 2 03:03:34 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=21229415 > Jun 2 03:03:46 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=20498839 > Jun 2 03:04:07 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=29996295 > Jun 2 03:04:14 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=27617575 > Jun 2 03:04:40 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=29939883 > Jun 2 03:04:48 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=22747195 > Jun 7 05:04:22 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=21220491 > [r > > And most recently: > > [root@meshuga /home/matt]# cat /var/log/messages | grep ad0 > Jun 13 03:01:09 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=28825859 > Jun 13 03:01:17 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > retry left) LBA=30662831 > Jun 17 05:00:58 meshuga kernel: ad0: TIMEOUT - WRITE_DMA48 retrying (1 > retry left) LBA=395032335 > Jun 17 05:00:58 meshuga kernel: ad0: FAILURE - WRITE_DMA48 > status=51 error=10 LBA=395032335 > Jun 17 05:02:20 meshuga kernel: ad0: WARNING - WRITE_DMA taskqueue > timeout - completing request directly > Jun 17 05:02:20 meshuga kernel: ad0: WARNING - WRITE_DMA48 freeing > taskqueue zombie request > > On first glance there was a single failure which has progressively got > worse... This did make me suspect there was indeed a problem with the > drive. > > > Speaking generally about disk replacements on your system -- when I say > > generally, I do mean generally and *not* in regards to the specific > > situation reported: > > > > Since there's no AHCI in use, we should just assume that a power-down of > > the system is the safest way to go about a disk replacement. Follow > > that procedure in the future and you should be fine. If you ever get a > > hot-swap backplane, you absolutely should use AHCI; hot-swap, especially > > on an Intel controller (FreeBSD is tested pretty thoroughly on Intel > > ICHxx and ESBx controllers), will work fine in that case. > > > > If you do go the AHCI route, and eventually upgrade to RELENG_8 down the > > line, I highly recommend you load kernel module ahci.ko (instead of the > > default/historic ataahci.ko). This will get you NCQ support amongst > > other things. > > > > I've actually got 8.0-RELEASE running on a similar box (no hot-swap back > plane) with AHCI. I think it's a newer generation of HP Proliant. That > runs RAID1 too. I had been contemplating upgrading motherboards to allow > hot-swap. I think I might have more than just a think about it now :-) From owner-freebsd-stable@FreeBSD.ORG Mon Jun 21 22:06:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1695C106566B for ; Mon, 21 Jun 2010 22:06:03 +0000 (UTC) (envelope-from pete@altadena.net) Received: from puffin.altadena.net (puffin.altadena.net [173.10.157.234]) by mx1.freebsd.org (Postfix) with ESMTP id D6D718FC08 for ; Mon, 21 Jun 2010 22:06:02 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=2.puffin; d=altadena.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; b=Z8swx6Gg0/8ZkX9mQzY6cu77U+sWYthQv+ATFbMKJPvuWEMlnhj0JpYMokaTzREoLCNTrq1UWetlEFQYNpGZPVLdEtgq3TouXI8efWh92LG3wXDlzdvGgvENB493BL5VEC8S9Iw8gZbbRKaHCRFLXQ2WbWhule9WuIchlmz0s48=; Received: from [2001:470:e182:3:c5f0:99fd:ae94:d9d] (port=32833 helo=port4l.altadena.net) by puffin.altadena.net with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1OQolP-000Ed6-Nq; Mon, 21 Jun 2010 17:42:43 -0400 Message-ID: <4C1FDC9F.8030007@altadena.net> Date: Mon, 21 Jun 2010 17:41:51 -0400 From: Pete Carah User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc11 Thunderbird/3.0.4 MIME-Version: 1.0 To: Brandon Gooch References: <4C1D4496.10403@altadena.net> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Kurt Jaeger Subject: Re: if_em problems, both 7 and 8-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2010 22:06:03 -0000 On 06/19/2010 08:26 PM, Brandon Gooch wrote: > On Sat, Jun 19, 2010 at 5:28 PM, Pete Carah wrote: > >> I cannot successfully create a vlan on if_em on either releng 7 or releng 8; >> I have seen a patch for part of >> the problem (checksum offsets end up incorrect) but not all. Even turning >> off ALL hw_xxx flags leaves one >> unacceptable bug - the interface gets hard-reset any time you add or delete >> a vlan. I *know* that cisco >> uses these interfaces without these problems, so it has to be possible. I >> have used vlans in linux without >> appearing to get the same problems, though I'm not sure the rest of the >> configuration matches. >> >> What gives, especially since the patch for one of the problems (wrong >> checksum offsets) was generated >> about 6 months ago... >> >> We are trying to use an intel platform as a router; this is a show-stopper. >> I could try linux though I prefer not to... >> > Would it be possible for you to provide more details about the > hardware and software setup? The Intel chip and the revision (or > relevant CVS info) about the builds of 7-RELENG and 8-RELENG would be > useful, perhaps the dmesg of the machine and output of `pciconf -lv`? > > For what it's worth, I'm using vlans on an "Intel 82566DM Gigabit > Ethernet Adapter (82566DM)", on-board in my Dell Optiplex 755, all > hardware options on... > 825{5,6,7,8,9}x and 8254x (ours are 82546EB) are totally different animals. The bug we see is definitely there for 54x; we are not the only ones seeing it - look back in the stable and net mailing-list archives for last December, a patch was sent in back then and never applied to the main tree, even -current. See PR's kern-141285 kern-141843 kern-146358 (likely related since it seems the same as 141843) and perhaps a couple more. All of those are still open and marked as not yet patched as of a half-hour ago. Also, the patch (for 141285; the author thinks it fixes 141843 also) as sent fixes some of the offload problems but not all. The problem with the interface resetting on vlan creation is there for *all* if_em devices and is independent of enabling hardware offloads; it causes a one or two second pause in forwarding (longer if you are connected to a Cisco without portfast, and their newer switches don't allow portfast on trunk ports); doesn't appear too serious until you realize how many packets per second one of these guys forwards in router service - this is a LOT of dropped packets. My reading of the reset code is such that once vlan service is enabled then there might well be problems on untagged packets sent out that same interface (not a problem in our network but we don't have any 3com switches which REQUIRE untagged management) I have successful vlan networks running on sis, fxp, and vr interfaces with absolutely no problems (well, vr in fbsd 6 required a patch to up the receive buffer size, but 7 and later is fine with all of these out of the box.) -- Pete > $ ifconfig em0 > em0: flags=8843 metric 0 mtu 1500 > options=219b > ether 00:1e:4f:d5:84:b7 > inet 10.7.0.7 netmask 0xff000000 broadcast 10.255.255.255 > media: Ethernet autoselect (1000baseT ) > status: active > > -Brandon > > From owner-freebsd-stable@FreeBSD.ORG Tue Jun 22 07:45:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55FF51065670 for ; Tue, 22 Jun 2010 07:45:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 38F118FC27 for ; Tue, 22 Jun 2010 07:45:42 +0000 (UTC) Received: from omta01.emeryville.ca.mail.comcast.net ([76.96.30.11]) by qmta04.emeryville.ca.mail.comcast.net with comcast id Yvl81e0030EPchoA4vliXc; Tue, 22 Jun 2010 07:45:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.emeryville.ca.mail.comcast.net with comcast id Yvlh1e0053S48mS8Mvlhzl; Tue, 22 Jun 2010 07:45:42 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 6272E9B425; Tue, 22 Jun 2010 00:45:41 -0700 (PDT) Date: Tue, 22 Jun 2010 00:45:41 -0700 From: Jeremy Chadwick To: Matthew Lear Message-ID: <20100622074541.GA71157@icarus.home.lan> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 07:45:43 -0000 On Mon, Jun 21, 2010 at 10:33:12PM +0100, Matthew Lear wrote: > Hello Jeremy. I just wondered if you had any further thoughts on the > info below. Two new disks arrived over the weekend and I'm still unsure > if I'm best to replace ad0 or not... > Much appreciated indeed. > -- Matt > > On Fri, 2010-06-18 at 20:28 +0100, Matthew Lear wrote: > > On Fri, 2010-06-18 at 10:42 -0700, Jeremy Chadwick wrote: > > > On Fri, Jun 18, 2010 at 04:47:11PM +0100, Matthew Lear wrote: > > > > Hello Jeremy, > > > > Thanks very much for the feedback. > > > > > > > > [snip] > > > > > Could you please provide the full output from "smartctl -a /dev/ad0" > > > > > here? Your drive may be completely fine and you may not have to swap it > > > > > at all; hard to say. > > > > > > > > Sure. See below: > > > > {snip} > > > > > > Your SMART statistics look completely OK. There's nothing there that > > > indicates there were any write failures or otherwise. I'll explain near > > > the end of the Email how to test a range of LBAs "just in case". > > > > Good. That's what I thought too :-) > > > > > I'll take a moment to point out that the error previously seen was a > > > timeout during a write transaction (WRITE_DMA48). Recap: > > > > > > > > > ad0: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=395032335 > > > > > > ad0: FAILURE - WRITE_DMA48 status=51 error=10 LBA=395032335 > > > > > > ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode > > > > > > The status codes shown (status=51 and error=10) are hexadecimal. I'm > > > pointing this out because they aren't preceded by '0x' or '$' and it > > > clarifies my next point: > > > > > > NID_NOT_FOUND (bit 4 set in the ATA error field) is referred to as IDNF > > > per ATA6-ACS specification and onward, so I'll refer to it as that. > > > (I've always wondered why FreeBSD calls this NID_NOT_FOUND; IDFN stands > > > for ID Not Found, so what's with the extra "N"? I've always felt this > > > is a typo...) > > > > > > Using the ATA8-ACS specification working draft (2007/05/21), since it's > > > more recent, we see the following: > > > > > > Section 6.2 - Error field > > > Section 6.2.4 - ID Not Found (IDNF) bit > > > > > > Error bit 4. The IDNF bit shall be set to one if a user-accessible > > > address was not found. The IDNF bit shall be set to one if an > > > address outside of the range of user-accessible addresses is > > > requested when command aborted is not returned (see 4.11.3 and > > > 6.2.1). > > > > > > Section 4.11 - Host Protected Area (HPA) feature set > > > Section 4.11.3 - 28-bit and 48-bit HPA commands > > > > > > Any read or write command to an address above the maximum address > > > specified by the SET MAX ADDRESS or SET MAX ADDRESS EXT command shall > > > cause command completion with the IDNF bit set to one and ERR set to > > > one, or command aborted. > > > > > > There's no definition of what "address" means in 6.2.4, but the most > > > logical (pun intended) guess is an LBA. This error is returned by the > > > disk (e.g. not a controller-induced error). I've mentioned this problem > > > in the past: > > > > > > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting > > > > > > I've always read IDNF to mean "OS requested access (read or write) to an > > > LBA which is out of bounds", where "out of bounds" means "not between 0 > > > and ". How exactly is that possible? Alexander, do you have > > > any familiarity with this error code per ATA spec? > > > > > > Matthew, can you provide output from "atacontrol cap ad0"? Thanks. > > > > Sure thing. See below. > > [root@meshuga /home/matt]# atacontrol cap ad0 > > > > Protocol SATA revision 2.x > > device model WDC WD3200AAKS-00VYA0 > > serial number WD-WCARW0164427 > > firmware revision 12.01B02 > > 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 no no 0/0x00 > > automatic acoustic management yes no 254/0xFE 128/0x80 > > [root@meshuga /home/matt]# > > > > > > > > > > Now regarding the LBA tests -- "smartctl -t select,start-end" will do > > > the trick. start should be a starting LBA, end should be an ending LBA. > > > The OS claims that LBA 395032335 is what was requested to be accessed > > > when the failure happened, so I would recommend picking start/end ranges > > > around that area. Remember that a single sector encapsulates a very > > > large number of blocks (especially given sizes of disks today), so it's > > > wise to pick a very large range of LBAs. I would recommend this in your > > > case: > > > > > > smartctl -t select,390000000,410000000 /dev/ad0 > > > > [root@meshuga /home/matt]# smartctl -t > > select,390000000-410000000 /dev/ad0 > > smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 7.2-RELEASE-p4 i386] (local > > build) > > Copyright (C) 2002-10 by Bruce Allen, > > http://smartmontools.sourceforge.net > > > > === START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION === > > Sending command: "Execute SMART Selective self-test routine immediately > > in off-line mode". > > SPAN STARTING_LBA ENDING_LBA > > 0 390000000 410000000 > > Drive command "Execute SMART Selective self-test routine immediately in > > off-line mode" successful. > > Testing has begun. > > You have mail in /var/mail/matt > > [root@meshuga /home/matt]# > > > > ... some time passes polling status with smartctl -a /dev/ad0 ... > > > > [root@meshuga /home/matt]# smartctl -a /dev/ad0 > > smartctl 5.39.1 2010-01-28 r3054 [FreeBSD 7.2-RELEASE-p4 i386] (local > > build) > > Copyright (C) 2002-10 by Bruce Allen, > > http://smartmontools.sourceforge.net > > > > === START OF INFORMATION SECTION === > > Model Family: Western Digital Caviar Blue Serial ATA family > > Device Model: WDC WD3200AAKS-00VYA0 > > Serial Number: WD-WCARW0164427 > > Firmware Version: 12.01B02 > > User Capacity: 320,072,933,376 bytes > > Device is: In smartctl database [for details use: -P show] > > ATA Version is: 8 > > ATA Standard is: Exact ATA specification draft version not indicated > > Local Time is: Fri Jun 18 20:20:17 2010 BST > > SMART support is: Available - device has SMART capability. > > SMART support is: Enabled > > > > === START OF READ SMART DATA SECTION === > > SMART overall-health self-assessment test result: PASSED > > > > General SMART Values: > > Offline data collection status: (0x84) Offline data collection activity > > was suspended by an interrupting command from host. > > Auto Offline Data Collection: Enabled. > > Self-test execution status: ( 0) The previous self-test routine > > completed > > without error or no self-test has ever > > been run. > > Total time to complete Offline > > data collection: (8400) seconds. > > Offline data collection > > capabilities: (0x7b) SMART execute Offline immediate. > > Auto Offline data collection on/off support. > > Suspend Offline collection upon new > > command. > > Offline surface scan supported. > > Self-test supported. > > Conveyance Self-test supported. > > Selective Self-test supported. > > SMART capabilities: (0x0003) Saves SMART data before entering > > power-saving mode. > > Supports SMART auto save timer. > > Error logging capability: (0x01) Error logging supported. > > General Purpose Logging supported. > > Short self-test routine > > recommended polling time: ( 2) minutes. > > Extended self-test routine > > recommended polling time: ( 100) minutes. > > Conveyance self-test routine > > recommended polling time: ( 5) minutes. > > SCT capabilities: (0x303f) SCT Status supported. > > SCT Feature Control supported. > > SCT Data Table supported. > > > > SMART Attributes Data Structure revision number: 16 > > Vendor Specific SMART Attributes with Thresholds: > > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE > > UPDATED WHEN_FAILED RAW_VALUE > > 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always > > - 0 > > 3 Spin_Up_Time 0x0003 218 150 021 Pre-fail Always > > - 2100 > > 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always > > - 118 > > 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always > > - 0 > > 7 Seek_Error_Rate 0x000e 200 200 051 Old_age Always > > - 0 > > 9 Power_On_Hours 0x0032 088 088 000 Old_age Always > > - 9320 > > 10 Spin_Retry_Count 0x0012 100 100 051 Old_age Always > > - 0 > > 11 Calibration_Retry_Count 0x0012 100 100 051 Old_age Always > > - 0 > > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always > > - 116 > > 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always > > - 115 > > 193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always > > - 118 > > 194 Temperature_Celsius 0x0022 108 103 000 Old_age Always > > - 39 > > 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always > > - 0 > > 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always > > - 0 > > 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age > > Offline - 0 > > 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always > > - 0 > > 200 Multi_Zone_Error_Rate 0x0008 200 200 051 Old_age > > Offline - 0 > > > > SMART Error Log Version: 1 > > No Errors Logged > > > > SMART Self-test log structure revision number 1 > > Num Test_Description Status Remaining > > LifeTime(hours) LBA_of_first_error > > # 1 Selective offline Completed without error 00% 9319 > > - > > # 2 Extended offline Completed without error 00% 9299 > > - > > # 3 Short offline Completed without error 00% 9298 > > - > > > > SMART Selective self-test log data structure revision number 1 > > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > > 1 390000000 410000000 Not_testing > > 2 0 0 Not_testing > > 3 0 0 Not_testing > > 4 0 0 Not_testing > > 5 0 0 Not_testing > > Selective self-test flags (0x0): > > After scanning selected spans, do NOT read-scan remainder of disk. > > If Selective self-test is pending on power-up, resume after 0 minute > > delay. > > > > > > > I would highly recommend doing this with the disk not doing any I/O, > > > though it won't hurt it (it'll just delay the scan). "smartctl -a" will > > > show the state of things in the "SMART Selective self-test log" at the > > > bottom, or somewhere else within the output (depends on the drive). > > > > > > This should, in my opinion, rule out whether or not there's a bad block > > > or something along those lines within said range. Given what I believe > > > IDNF represents, I would say your scan will probably come back clean. > > > Also remember that the scan performed here is a *disk-level scan*; the > > > disk firmware itself is doing it (the OS isn't involved). This helps > > > rule out any sort of "weird" issues that the OS may be reporting ("hey > > > man, LBA 8943943983492893428932489324 is bad!" "Yeah sure it is"). > > > > > > > The two devices in the array are on channels 0 and 1. There is indeed a > > > > second drive on channel 0 (160G). As I said above, I use that as an > > > > additional back up device but it's not part of the array. > > > > > > Okay, so executing "atacontrol detach ata0" will cause you to lose both > > > ad0 and ad1. If you can live with that, then cool. > > > > > > > > What motherboard is this? Can you change the setting to either > > > > > "Native", "Enhanced", or (even better) "AHCI"? I've seen some systems > > > > > where the Serial ATA option in the BIOS has an "Auto" option, which does > > > > > totally bizarre things at times. > > > > > > > > I think this has been covered in subsequent postings. I could try it but > > > > as you say below, I'd like to resolve the disk issue first. > > > > ... > > > > > The atacontrol man page covers your situation: > > > > > ... > > > > I don't think this is the case for me since ad0 and ad2 are on seperate > > > > ata channels. > > > > ... > > > > Indeed but my hw doesn't have hot-swap capability (at the moment!). > > > > > > That's the problem -- we're not sure if this really is a disk issue. > > > It's been reported before, others have reported solving it by increasing > > > ATA timeout values, etc... But the fact of the matter is, that error > > > code is being returned by the device. > > > > Indeed. if I look back through my logs the error has happened quite a > > few times over the course of several weeks before atacontrol took action > > and offlined the drive: > > > > [root@meshuga /home/matt]# zcat /var/log/messages.0.bz2 | grep ad0 > > Mar 14 21:17:33 meshuga kernel: ad0: 305245MB > 12.01B02> at ata0-master SATA300 > > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1a is > > ufsid/47284adaeab4f771. > > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1d is > > ufsid/47284ae5159318bb. > > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1e is > > ufsid/47284ada8adb1df9. > > Mar 14 21:17:33 meshuga kernel: GEOM_LABEL: Label for provider ad0s1f is > > ufsid/47284adaa202995d. > > Mar 14 21:17:33 meshuga kernel: ar0: disk0 READY (master) using ad0 at > > ata0-master > > Mar 28 17:59:59 meshuga kernel: ad0: 305245MB > 12.01B02> at ata0-master SATA300 > > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1a is > > ufsid/47284adaeab4f771. > > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1d is > > ufsid/47284ae5159318bb. > > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1e is > > ufsid/47284ada8adb1df9. > > Mar 28 17:59:59 meshuga kernel: GEOM_LABEL: Label for provider ad0s1f is > > ufsid/47284adaa202995d. > > Mar 28 17:59:59 meshuga kernel: ar0: disk0 READY (master) using ad0 at > > ata0-master > > May 1 03:03:23 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=20472527 > > May 30 03:01:54 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=24996179 > > Jun 1 03:02:47 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=27745599 > > Jun 1 03:03:35 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=29127787 > > Jun 1 03:03:41 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=29131871 > > Jun 1 05:00:10 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=21646831 > > Jun 2 03:02:02 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=25019047 > > Jun 2 03:02:09 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=24262079 > > Jun 2 03:02:25 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=26503067 > > Jun 2 03:02:45 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=24991895 > > Jun 2 03:03:22 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=26526099 > > Jun 2 03:03:34 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=21229415 > > Jun 2 03:03:46 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=20498839 > > Jun 2 03:04:07 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=29996295 > > Jun 2 03:04:14 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=27617575 > > Jun 2 03:04:40 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=29939883 > > Jun 2 03:04:48 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=22747195 > > Jun 7 05:04:22 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=21220491 > > [r > > > > And most recently: > > > > [root@meshuga /home/matt]# cat /var/log/messages | grep ad0 > > Jun 13 03:01:09 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=28825859 > > Jun 13 03:01:17 meshuga kernel: ad0: TIMEOUT - READ_DMA retrying (1 > > retry left) LBA=30662831 > > Jun 17 05:00:58 meshuga kernel: ad0: TIMEOUT - WRITE_DMA48 retrying (1 > > retry left) LBA=395032335 > > Jun 17 05:00:58 meshuga kernel: ad0: FAILURE - WRITE_DMA48 > > status=51 error=10 LBA=395032335 > > Jun 17 05:02:20 meshuga kernel: ad0: WARNING - WRITE_DMA taskqueue > > timeout - completing request directly > > Jun 17 05:02:20 meshuga kernel: ad0: WARNING - WRITE_DMA48 freeing > > taskqueue zombie request > > > > On first glance there was a single failure which has progressively got > > worse... This did make me suspect there was indeed a problem with the > > drive. > > > > > Speaking generally about disk replacements on your system -- when I say > > > generally, I do mean generally and *not* in regards to the specific > > > situation reported: > > > > > > Since there's no AHCI in use, we should just assume that a power-down of > > > the system is the safest way to go about a disk replacement. Follow > > > that procedure in the future and you should be fine. If you ever get a > > > hot-swap backplane, you absolutely should use AHCI; hot-swap, especially > > > on an Intel controller (FreeBSD is tested pretty thoroughly on Intel > > > ICHxx and ESBx controllers), will work fine in that case. > > > > > > If you do go the AHCI route, and eventually upgrade to RELENG_8 down the > > > line, I highly recommend you load kernel module ahci.ko (instead of the > > > default/historic ataahci.ko). This will get you NCQ support amongst > > > other things. > > > > > > > I've actually got 8.0-RELEASE running on a similar box (no hot-swap back > > plane) with AHCI. I think it's a newer generation of HP Proliant. That > > runs RAID1 too. I had been contemplating upgrading motherboards to allow > > hot-swap. I think I might have more than just a think about it now :-) I don't really have any other thoughts on the matter, sadly. I don't think replacing the disk makes all that much sense since there's no indication the disk itself is going bad. I'm really quite adamant about stating that up front -- there really doesn't appear to be any indication that the disk is faulty in any way. Andriy's idea that there may be LBAs written somewhere on the disk (such as within the filesystem) which refer to incorrect locations is plausible. I don't know how to verify the existence of such, however. fsdb(8) might help with this, but I'm not familiar with the utility. The recommendations I have, in no particular order, are as follows ( Meaning these are what I'd try): 1) Boot single-user and fsck -f all the filesystems that use /dev/ar0 (not a typo). There may be some underlying filesystem corruption which could explain what's going on. But AFAIK fsck doesn't check integrity of the data portions of files, only the allocation tables/structures, so this may come back clean. ZFS would be able to detect "silent corruption" of this nature. If any errors come back, please provide them. There have been cases in the past (I can provide mailing list references) where background fsck didn't catch certain things (which is why I use background_fsck="no" in rc.conf). I don't know if that problem/ordeal got fixed or not. 2) Format both disks (ad0 and ad2). dd if=/dev/zero of=/dev/adX bs=64k should be sufficient for this. You really do want to let the dd go from start to finish (we do know that metadata is stored at the end of the disk in some cases). This will take quite some time. You can do it on both disks at the same time though. 3) Try upgrading to RELENG_8 (preferably 8.1-RC1) to see if the problem continues there. I'd recommend doing item #2 above before doing this, rather than a 7.x -> 8.1 in-place upgrade. We do know for certain that GEOM has changed (e.g. "c" partition no longer exists), so I tend to advocate formatting rather than using existing filesystems. 4) Switch from ata(4) software RAID-1 to gmirror or ZFS mirror. I'm pretty sure FreeBSD can boot from both (not 100% certain on ZFS though; others can answer that). 5) Replace disk ad0. This would be my last choice, since there's no indication the disk is actually at fault nor indication of disk<->controller communication failures. Anyone else have ideas/recommendations? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Jun 22 11:18:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E600A106566C for ; Tue, 22 Jun 2010 11:18:25 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2958FC1E for ; Tue, 22 Jun 2010 11:18:25 +0000 (UTC) Received: by wwe15 with SMTP id 15so1100206wwe.13 for ; Tue, 22 Jun 2010 04:18:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=n3cRzvKnSiBLgVJe7KosBlS3ECXwJtCiCCcr6uXEm+A=; b=k0umYniSX/fuUYtmXs8sziuJv8H1g8xtHis4Zi/KE5UDNrXzS7uOqnU3QgGvWnqno7 Ms7871SE9dW2kVpCeAr5oP9pAL9myoGnQJzcgyNy4zcfhy/LcPKf+HcMWpvkiCAgwp10 /sfTEnOnC0ofzE3dG5hy6teVG2xaJWTaDfAuk= 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 :cc:content-type:content-transfer-encoding; b=NGXep0uPO2BYVNODkn5+OXkau1YGPBibJE2c+24nahatZlcKc4so6eCYG0ZDXRyB1d a8BeOnf9NDj+P6QY/Auhdg08V1oc8NhO504LlRfcXiKIujPSRAcVYvB+iFib5/3OPWua viRZW/0GvQGxcIpJSSVl5dguVasSDooqqYWBs= Received: by 10.216.171.73 with SMTP id q51mr1206626wel.29.1277205504221; Tue, 22 Jun 2010 04:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.54.135 with HTTP; Tue, 22 Jun 2010 04:18:04 -0700 (PDT) In-Reply-To: <20100620142328.GA92472@awesom.eu> References: <20100620142328.GA92472@awesom.eu> From: Paul B Mahol Date: Tue, 22 Jun 2010 11:18:04 +0000 Message-ID: To: Quentin Stievenart Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: bwn(4) on 8.1-RC1: connection problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 11:18:26 -0000 On Sun, Jun 20, 2010 at 2:23 PM, Quentin Stievenart wr= ote: > Hi, > > I've some broadcom wireless cards to test here (two BCM4318 and a > BCM4312). This week I tried the BCM4318 one (the 4312 is on a netbook, > I'll try it later, if the 4318 works some day). > > First of all, I was able to use it with ndisgen on FreeBSD 7.1, but > since the 7.2, it doesn't work anymore. So, two day ago I installed a > 8.1-RC1 and tried bwi(4), but a `ifconfig wlan0 scan` wasn't detecting > anything. > > So I gave bwn(4) a try, and it detect perfectly my network, but I just > can't connect to it, neither with dhclient nor with a static IP. > Here's what I do to try to connect: > > # kldload if_bwn > # kldload bwn_v4_ucode > # ifconfig wlan0 create wlandev bwn0 > # ifconfig wlan0 up > # ifconfig wlan0 ssid myssid channel 6 wepmode on wepkey mywepkey > # ifconfig wlan0 > wlan0: flags=3D8843 metric 0 mtu > 1500 > =A0 =A0 =A0 =A0ether 00:11:50:d0:2f:6f > =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b > =A0 =A0 =A0 =A0status: associated > =A0 =A0 =A0 =A0ssid myssid channel 6 (2437 MHz 11b) bssid 00:60:b3:7a:5c:= 29 > =A0 =A0 =A0 =A0country US authmode OPEN privacy ON deftxkey UNDEF wepkey = 1:40-bit > =A0 =A0 =A0 =A0txpower 30 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgs= canidle 250 > =A0 =A0 =A0 =A0roam:rssi 7 roam:rate 1 wme > # ifconfig bwn0 > bwn0: flags=3D8843 metric 0 mtu 2= 290 > =A0 =A0 =A0 =A0ether 00:11:50:d0:2f:6f > =A0 =A0 =A0 =A0media: IEEE 802.11 Wireless Ethernet autoselect mode 11b > =A0 =A0 =A0 =A0status: associated > > Then, for the static IP: > # ifconfig wlan0 inet 192.168.1.30 netmask 255.255.255.0 Where is weptxkey. Read manual again. > # route add default 192.168.1.1 > # arp -a > ? (192.168.1.30) at 00:11:50:d0:2f:6f on wlan0 permanent [ethernet] > > And I can't ping anything (except localhost and 192.168.1.30) > Or, with dhcp: > # dhclient wlan0 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 8 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 21 > DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 2 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > Here's what pciconf -lv tells me about my card: > > siba_bwn0@pci0:2:2:0: class=3D0x028000 card=3D0x70011799 chip=3D0x431814e= 4 > rev=3D0x02 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Broadcom Corporation' > =A0 =A0device =A0 =A0 =3D 'Broadcom 802.11b/g (BCM4318)' > =A0 =A0class =A0 =A0 =A0=3D network > > And a dmesg | egrep "(bwn|wlan)": > > siba_bwn0: mem 0xfdefc000-0xfdefdff= f irq 22 at device 2.0 on pci2 > bwn0 on siba_bwn0 > bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf= 0x17f ver 0x2050 rev 8) > bwn0: DMA (32 bits) > bwn0: [FILTER] > wlan0: Ethernet address: 00:11:50:d0:2f:6f > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost > wlan0: link state changed to UP > bwn0: need multicast update callback > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > > Also, when I start tcpdump on wlan0, and try to ping this computer from > another one, I see all the ping requests and responses on FreeBSD, but > the other computer don't get any response. > > Does anyone knows what to do now ? > > Regards, > > Quentin Stievenart. > _______________________________________________ > 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-stable@FreeBSD.ORG Tue Jun 22 16:39:35 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8015106566B for ; Tue, 22 Jun 2010 16:39:35 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.re1.yahoo.com (mrout2-b.corp.re1.yahoo.com [69.147.107.21]) by mx1.freebsd.org (Postfix) with ESMTP id 735448FC08 for ; Tue, 22 Jun 2010 16:39:35 +0000 (UTC) Received: from [127.0.0.1] (cheese.corp.yahoo.com [216.145.50.99]) by mrout2-b.corp.re1.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id o5MGcaQt071212 for ; Tue, 22 Jun 2010 09:38:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; s=serpent; d=yahoo-inc.com; c=nofws; q=dns; h=subject:from:to:content-type:date:message-id:mime-version: x-mailer:content-transfer-encoding; b=kc4GkaotaeSJuJHMv8BI1WcO2oFhQa7McwhEIiYmgY+4IsJf5R9LIdBXnCVxHPp6 From: Sean Bruno To: freebsd-stable Content-Type: text/plain; charset="UTF-8" Date: Tue, 22 Jun 2010 09:38:36 -0700 Message-ID: <1277224716.2581.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-1.fc12) Content-Transfer-Encoding: 7bit Subject: [stable 7]config -g -ppp + kgmon causes deadlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 16:39:35 -0000 Not sure where to start poking about, but I'm seeing a dead lock on my boxes when the kernel is configured with -g -ppp. The dead lock occurs when I start profiling via kgmon -p. Any one else seeing this on 7? Sean From owner-freebsd-stable@FreeBSD.ORG Tue Jun 22 19:04:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F02CD106566C for ; Tue, 22 Jun 2010 19:04:20 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id 89FA48FC1C for ; Tue, 22 Jun 2010 19:04:20 +0000 (UTC) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id o5MJ4HQD017728; Tue, 22 Jun 2010 20:04:17 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from rbpbp.gid.co.uk ([194.32.164.6]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id o5MJ4Bxm068831; Tue, 22 Jun 2010 20:04:12 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <20100622074541.GA71157@icarus.home.lan> Date: Tue, 22 Jun 2010 20:04:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1081) Cc: Matthew Lear , freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:04:21 -0000 Hi, On 22 Jun 2010, at 08:45, Jeremy Chadwick wrote: > On Mon, Jun 21, 2010 at 10:33:12PM +0100, Matthew Lear wrote: >> [tale of woe elided] >=20 > I don't really have any other thoughts on the matter, sadly. > [helpful suggestions elided] >=20 > Anyone else have ideas/recommendations? The disks sure look OK. I wouldn't rule out the controller(s), I've had = various chipsets fail in odd ways. -- Bob Bishop rb@gid.co.uk From owner-freebsd-stable@FreeBSD.ORG Tue Jun 22 19:46:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A24D9106564A for ; Tue, 22 Jun 2010 19:46:12 +0000 (UTC) (envelope-from acieroid@awesom.eu) Received: from awesom.eu (ks23738.kimsufi.com [91.121.15.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6CF438FC16 for ; Tue, 22 Jun 2010 19:46:11 +0000 (UTC) Received: by awesom.eu (Postfix, from userid 1002) id 6D134C9443; Tue, 22 Jun 2010 21:46:10 +0200 (CEST) Date: Tue, 22 Jun 2010 21:46:10 +0200 From: Quentin Stievenart To: freebsd-stable@freebsd.org Message-ID: <20100622194610.GA11116@awesom.eu> References: <20100620142328.GA92472@awesom.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Subject: Re: bwn(4) on 8.1-RC1: connection problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:46:12 -0000 On Tue, Jun 22, 2010 at 11:18:04AM +0000, Paul B Mahol wrote: > Where is weptxkey. Read manual again. Oh sorry, I missed that. Thanks. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 22 23:42:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C27F106566B for ; Tue, 22 Jun 2010 23:42:07 +0000 (UTC) (envelope-from nlmills@g.clemson.edu) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 10C8C8FC0A for ; Tue, 22 Jun 2010 23:42:06 +0000 (UTC) Received: by gxk3 with SMTP id 3so413142gxk.13 for ; Tue, 22 Jun 2010 16:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.163.13 with SMTP id l13mr5725901ane.267.1277250125496; Tue, 22 Jun 2010 16:42:05 -0700 (PDT) Received: by 10.100.47.12 with HTTP; Tue, 22 Jun 2010 16:42:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 19:42:05 -0400 Message-ID: From: Nicholas Mills To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary=0016e644d53e05028a0489a6f8dd X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: panic during boot on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nlmills@clemson.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 23:42:07 -0000 --0016e644d53e05028a0489a6f8dd Content-Type: text/plain; charset=ISO-8859-1 Oops, sent this to the wrong list. --Nick ---------- Forwarded message ---------- From: Nicholas Mills Date: Tue, Jun 22, 2010 at 7:41 PM Subject: panic during boot on 8.0-RELEASE To: freebsd-current@freebsd.org Hey all, Screenshot of panic message is attached. Machine is a VM running under Parallels Server Bare Metal 4. The cdrom device was enabled but not connected during boot. System was attempting to boot into single user mode. This occurred after a fresh install of 8.0-RELEASE. Let me know how I can provide more useful info. Thanks, Nick --0016e644d53e05028a0489a6f8dd-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 00:45:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FA2D106566C for ; Wed, 23 Jun 2010 00:45:05 +0000 (UTC) (envelope-from maier.nathan@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7BCF8FC0C for ; Wed, 23 Jun 2010 00:45:04 +0000 (UTC) Received: by iwn7 with SMTP id 7so6481170iwn.13 for ; Tue, 22 Jun 2010 17:45:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to :subject:message-id:user-agent:mime-version:content-type; bh=4i/U2LX4WLgz2wOtIaca/GSvP20auljiKCG0r7bIZP4=; b=LT51y3B4QD0ctSQDJRlPZ2pOjUq7hPeBu/8y+Pu+BzDojcZ8Aq/EFlCtW8kuqKjP8o Mj//UvWudqyr9hB/OeEzlbxfvUuaopTf0ZG+O0u+Ax05ZNwkaiw7NSWp4eNPTpo4a5hE O/rYC4mh8Fjqm8OXJYV3L7s5SuzZ0aVYWSu9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:subject:message-id:user-agent:mime-version :content-type; b=rjriXpNA5X5WtGzf0clpBu1i4b8HOieRpz7FJqlQmQXoHxgSVALrVNd/JloUVxYy/P /s/KE6yhG4kIDLLtv4gw0ofuZoh1XyXpeViA4P8v4Sa9DDwEPBznaN2QC33/0yftTGbo SpHQRvNuA3U4qOQ5fkuho6szjNtl8Dc3hwxGo= Received: by 10.231.120.150 with SMTP id d22mr7534325ibr.91.1277252401062; Tue, 22 Jun 2010 17:20:01 -0700 (PDT) Received: from [192.168.0.103] (c-24-15-68-119.hsd1.il.comcast.net [24.15.68.119]) by mx.google.com with ESMTPS id a8sm6458639ibi.23.2010.06.22.17.19.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 22 Jun 2010 17:20:00 -0700 (PDT) Date: Tue, 22 Jun 2010 19:14:05 -0500 (CDT) From: Nathan Maier X-X-Sender: root@nomos To: freebsd-stable@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 Subject: The mouse appears on screen but doesn't move. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 00:45:05 -0000 Hi, Just updated to 8.0-Release via freebsd-update from 8.0-rc1. My mouse worked well enough in the first 8.0 release after adding "Option "AllowEmptyInput" "off" from the UPDATING file. Here's Xorg.log: X.Org X Server 1.7.5 Release Date: 2010-02-16 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 8.0-RC1 i386 Current Operating System: FreeBSD nomos 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Wed May 26 05:45:12 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 Build Date: 21 June 2010 05:47:02PM Current version of pixman: 0.16.6 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 22 19:03:30 2010 (++) Using config file: "/root/xorg.conf.new" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (**) Option "AllowEmptyInput" "off" (==) Automatically adding devices (==) Automatically enabling devices (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/TTF/, /usr/local/lib/X11/fonts/OTF, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0x81def20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (--) PCI:*(0:1:5:0) 1002:9614:1043:834d ATI Technologies Inc Radeon HD 3300 Graphics rev 0, Mem @ 0xd0000000/268435456, 0xfe9f0000/65536, 0xfe800000/1048576, I/O @ 0x0000d000/256, BIOS @ 0x????????/65536 (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "radeonhd" (II) Loading /usr/local/lib/xorg/modules/drivers/radeonhd_drv.so (II) Module radeonhd: vendor="AMD GPG" compiled for 1.7.5, module version = 1.3.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 6.0 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.1, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (EE) module ABI major version (4) doesn't match the server's version (7) (II) UnloadModule: "mouse" (II) Unloading /usr/local/lib/xorg/modules/input/mouse_drv.so (EE) Failed to load module "mouse" (module requirement mismatch, 0) (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input/kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (II) RADEONHD: X driver for the following AMD GPG (ATI) graphics devices: RV505 : Radeon X1550, X1550 64bit. RV515 : Radeon X1300, X1550, X1600; FireGL V3300, V3350. RV516 : Radeon X1300, X1550, X1550 64-bit, X1600; FireMV 2250. R520 : Radeon X1800; FireGL V5300, V7200, V7300, V7350. RV530 : Radeon X1300 XT, X1600, X1600 Pro, X1650; FireGL V3400, V5200. RV535 : Radeon X1300, X1650. RV550 : Radeon X2300 HD. RV560 : Radeon X1650. RV570 : Radeon X1950, X1950 GT; FireGL V7400. R580 : Radeon X1900, X1950; AMD Stream Processor. R600 : Radeon HD 2900 GT/Pro/XT; FireGL V7600/V8600/V8650. RV610 : Radeon HD 2350, HD 2400 Pro/XT, HD 2400 Pro AGP; FireGL V4000. RV620 : Radeon HD 3450, HD 3470. RV630 : Radeon HD 2600 LE/Pro/XT, HD 2600 Pro/XT AGP; Gemini RV630; FireGL V3600/V5600. RV635 : Radeon HD 3650, HD 3670. RV670 : Radeon HD 3690, 3850, HD 3870, FireGL V7700, FireStream 9170. R680 : Radeon HD 3870 X2. M52 : Mobility Radeon X1300. M54 : Mobility Radeon X1400; M54-GL. M56 : Mobility Radeon X1600; Mobility FireGL V5200. M58 : Mobility Radeon X1800, X1800 XT; Mobility FireGL V7100, V7200. M62 : Mobility Radeon X1350. M64 : Mobility Radeon X1450, X2300. M66 : Mobility Radeon X1700, X1700 XT; FireGL V5250. M68 : Mobility Radeon X1900. M71 : Mobility Radeon HD 2300. M72 : Mobility Radeon HD 2400; Radeon E2400. M74 : Mobility Radeon HD 2400 XT. M76 : Mobility Radeon HD 2600; (Gemini ATI) Mobility Radeon HD 2600 XT. M82 : Mobility Radeon HD 3400. M86 : Mobility Radeon HD 3650, HD 3670, Mobility FireGL V5700. M88 : Mobility Radeon HD 3850, HD 3850 X2, HD 3870, HD3870 X2. RS600 : Radeon Xpress 1200, Xpress 1250. RS690 : Radeon X1200, X1250, X1270. RS740 : RS740, RS740M. RS780 : Radeon HD 3100/3200/3300 Series. R700 : Radeon R700. RV710 : Radeon HD4570, HD4350. RV730 : Radeon HD4670, HD4650. RV740 : Radeon HD4770. EXPERIMENTAL AND UNTESTED. RV770 : Radeon HD 4800 Series; Everest, K2, Denali ATI FirePro. RV790 : Radeon HD 4890. M92 : Mobility Radeon HD4330, HD4530, HD4570. EXPERIMENTAL. M93 : Mobility Radeon M93. EXPERIMENTAL AND UNTESTED. M96 : Mobility Radeon HD4600. M97 : Mobility Radeon HD4860. EXPERIMENTAL AND UNTESTED. M98 : Mobility Radeon HD4850, HD4870. (II) RADEONHD: version 1.3.0, built from dist of git branch master, commit 8cbff7bf (II) Primary Device is: PCI 01@00:05:0 (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support (==) RADEONHD(0): Depth 24, (--) framebuffer bpp 32 (**) RADEONHD(0): Selected EXA 2D acceleration. (II) RADEONHD(0): Card not in database: 0x9614:0x1043:0x834D; using generic modesetting. If - and only if - your card does not work or does not work optimally please contact radeonhd@opensuse.org to help rectify this. Use the subject: 0x9614:0x1043:0x834D: and *please* describe the problems you are seeing in your message. (--) RADEONHD(0): Detected an RS780 on an unidentified card (II) RADEONHD(0): Mapped IO @ 0xfe9f0000 to 0x286c7000 (size 0x00010000) (II) RADEONHD(0): Getting BIOS copy from legacy VBIOS location (II) RADEONHD(0): ATOM BIOS Rom: SubsystemVendorID: 0x1002 SubsystemID: 0x1002 IOBaseAddress: 0xd000 Filename: M3A78T_D_1.b BIOS Bootup Message: B27722 RS780D DDR2 200e/500m (II) RADEONHD(0): Analog TV Default Mode: 135003826 (II) RADEONHD(0): The detected amount of videoram exceeds the PCI BAR aperture. (II) RADEONHD(0): Using only 262144kB of the total 393216kB. (--) RADEONHD(0): VideoRAM: 262144 kByte (II) RADEONHD(0): Framebuffer space used by Firmware (kb): 20 (II) RADEONHD(0): Start of VRAM area used by Firmware: 0x17ffb000 (II) RADEONHD(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEONHD(0): AtomBIOS VRAM scratch base: 0x17ffb000 (WW) RADEONHD(0): rhdAtomAllocateFbScratch: FW FB scratch area 402632704 (size: 20480) extends beyond available framebuffer size 268435456 (II) RADEONHD(0): Cannot get VRAM scratch space. Allocating in main memory instead (II) RADEONHD(0): Default Engine Clock: 500000 (II) RADEONHD(0): Default Memory Clock: 400000 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Input: 13500 (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Input: 1000 (II) RADEONHD(0): Maximum Pixel Clock: 400000 (II) RADEONHD(0): Reference Clock: 14320 (II) RADEONHD(0): Found libdri 5.4.0. drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0 (II) RADEONHD(0): Found libdrm 1.3.0. (II) RADEONHD(0): Found radeon drm 1.29.0. (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEONHD(0): Reference Clock: 14320 (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f90 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 0" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f94 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f94 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 1" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f98 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f98 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 2" initialized. (II) RADEONHD(0): GPIO_I2C_Clk_Mask: 0x1f88 (II) RADEONHD(0): GPIO_I2C_Clk_Mask_Shift: 0x0 (II) RADEONHD(0): GPIO_I2C_Data_Mask: 0x1f88 (II) RADEONHD(0): GPIO_I2C_Data_Mask_Shift: 0x8 (II) RADEONHD(0): I2C bus "RHD I2C line 3" initialized. (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) RADEONHD(0): Detected VGA mode. (II) RADEONHD(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEONHD(0): Maximum Pixel ClockPLL Frequency Output: 1200000 (II) RADEONHD(0): Maximum Pixel Clock: 400000 (II) RADEONHD(0): Reference Clock: 14320 (II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00000000 (size = 0x00004000) (II) RADEONHD(0): FB: Allocated Cursor Image at offset 0x00004000 (size = 0x00004000) (II) RADEONHD(0): FirmwareInfo Revision 0104 (II) RADEONHD(0): Unused attribute: ul3DAccelerationEngineClock 0 (II) RADEONHD(0): Unused attribute: ulDriverTargetEngineClock 0 (II) RADEONHD(0): Unused attribute: ulDriverTargetMemoryClock 0 (II) RADEONHD(0): Unused attribute: ucASICMaxTemperature 0 (II) RADEONHD(0): Scary bits: Estimated MinEngineClock 250000 kHz (II) RADEONHD(0): Scary bits: Estimated MinMemoryClock 250000 kHz (II) RADEONHD(0): Default Engine Clock: 500000 (II) RADEONHD(0): Default Memory Clock: 400000 (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): Power Management: used engine clock / memory clock / core (VDDC) voltage (0: ignore) (II) RADEONHD(0): Power Management: Raw Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.000 V (II) RADEONHD(0): Maximum 0 kHz / 0 kHz / 0.000 V (II) RADEONHD(0): Default 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): PowerPlayInfo Revision 0401 (II) RADEONHD(0): Power Management: Validated Ranges (II) RADEONHD(0): Minimum 250000 kHz / 250000 kHz / 0.000 V (II) RADEONHD(0): Maximum 500000 kHz / 128000000 kHz / 28.672 V (II) RADEONHD(0): Default 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Power Management: Known Good Configurations (II) RADEONHD(0): 1 300000 kHz / 300000 kHz / 0.000 V (II) RADEONHD(0): 2 0 kHz / 128000000 kHz / 28.672 V (II) RADEONHD(0): Power Management: Final Levels (II) RADEONHD(0): Off 250000 kHz / 250000 kHz / 0.000 V (II) RADEONHD(0): Idle 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Slow2D 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Fast2D 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Slow3D 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Fast3D 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Max3D 500000 kHz / 128000000 kHz / 28.672 V (II) RADEONHD(0): User 500000 kHz / 400000 kHz / 0.000 V (II) RADEONHD(0): Connector[0] {RHD_CONNECTOR_VGA, "VGA CRT1", RHD_DDC_0, RHD_HPD_NONE, { RHD_OUTPUT_DACA, RHD_OUTPUT_NONE } } (II) RADEONHD(0): Connector[1] {RHD_CONNECTOR_DVI, "DUAL_LINK_DVI_D DFP3", RHD_DDC_1, RHD_HPD_2, { RHD_OUTPUT_KLDSKP_LVTMA, RHD_OUTPUT_NONE } } (--) RADEONHD(0): Attaching Output DAC A to Connector VGA 1 (--) RADEONHD(0): Attaching Output UNIPHY_KLDSKP_LVTMA to Connector DVI-D 1 (II) RADEONHD(0): RandR: Adding RRoutput VGA_1 for Output DAC A (II) RADEONHD(0): RandR: Adding RRoutput DVI-D_1 for Output UNIPHY_KLDSKP_LVTMA (II) RADEONHD(0): Output VGA_1 using monitor section Monitor0 (II) RADEONHD(0): Output VGA_1 has no monitor section (II) RADEONHD(0): Output DVI-D_1 has no monitor section (II) RADEONHD(0): DAC A: Sensed Output: VGA (II) RADEONHD(0): I2C device "RHD I2C line 0:ddc2" registered at address 0xA0. (WW) EDID preferred timing clock 135.00MHz exceeds claimed max 130MHz, fixing (II) RADEONHD(0): EDID data for EN7750 (II) RADEONHD(0): Manufacturer: EPI Model: 7750 Serial#: 44327 (II) RADEONHD(0): Year: 2006 Week: 23 (II) RADEONHD(0): EDID Version: 1.3 (II) RADEONHD(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEONHD(0): Sync: Separate (II) RADEONHD(0): Max Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEONHD(0): Gamma: 2.20 (II) RADEONHD(0): DPMS capabilities: Off; RGB/Color Display (II) RADEONHD(0): First detailed timing is preferred mode (II) RADEONHD(0): redX: 0.640 redY: 0.347 greenX: 0.302 greenY: 0.587 (II) RADEONHD(0): blueX: 0.143 blueY: 0.099 whiteX: 0.321 whiteY: 0.338 (II) RADEONHD(0): Supported established timings: (II) RADEONHD(0): 720x400@70Hz (II) RADEONHD(0): 640x480@60Hz (II) RADEONHD(0): 640x480@67Hz (II) RADEONHD(0): 640x480@72Hz (II) RADEONHD(0): 640x480@75Hz (II) RADEONHD(0): 800x600@56Hz (II) RADEONHD(0): 800x600@60Hz (II) RADEONHD(0): 800x600@72Hz (II) RADEONHD(0): 800x600@75Hz (II) RADEONHD(0): 832x624@75Hz (II) RADEONHD(0): 1024x768@60Hz (II) RADEONHD(0): 1024x768@70Hz (II) RADEONHD(0): 1024x768@75Hz (II) RADEONHD(0): 1280x1024@75Hz (II) RADEONHD(0): Manufacturer's mask: 0 (II) RADEONHD(0): Supported standard timings: (II) RADEONHD(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEONHD(0): Supported detailed timing: (II) RADEONHD(0): clock: 135.0 MHz Image Size: 340 x 270 mm (II) RADEONHD(0): h_active: 1280 h_sync: 1296 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEONHD(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEONHD(0): Serial No: 27966JA044327 (II) RADEONHD(0): Ranges: V min: 55 V max: 75 Hz, H min: 30 H max: 83 kHz, PixClock max 135 MHz (II) RADEONHD(0): Monitor name: EN7750 (II) RADEONHD(0): EDID (in hex): (II) RADEONHD(0): 00ffffffffffff001609507727ad0000 (II) RADEONHD(0): 1710010368221b782af596a3584d9624 (II) RADEONHD(0): 195256bfef0081800101010101010101 (II) RADEONHD(0): 010101010101bc34009851002a401090 (II) RADEONHD(0): 1300540e1100001e000000ff00323739 (II) RADEONHD(0): 36364a41303434333237000000fd0037 (II) RADEONHD(0): 4b1e530d000a202020202020000000fc (II) RADEONHD(0): 00454e373735300a2020202020200089 (II) RADEONHD(0): EDID vendor "EPI", prod id 30544 (II) RADEONHD(0): Using EDID range info for horizontal sync (II) RADEONHD(0): Using EDID range info for vertical refresh (II) RADEONHD(0): Printing DDC gathered Modelines: (II) RADEONHD(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEONHD(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEONHD(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEONHD(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEONHD(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEONHD(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEONHD(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEONHD(0): Output VGA_1 connected (II) RADEONHD(0): Output DVI-D_1 disconnected (II) RADEONHD(0): Using exact sizes for initial modes (II) RADEONHD(0): Output VGA_1 using initial mode 1280x1024 (II) RADEONHD(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. (II) RADEONHD(0): RandR 1.2 support enabled (==) RADEONHD(0): RGB weight 888 (==) RADEONHD(0): Default visual is TrueColor (II) RADEONHD(0): Using 3840x1920 Framebuffer with 3840 pitch (II) RADEONHD(0): FB: Allocated ScanoutBuffer at offset 0x00008000 (size = 0x01C20000) (**) RADEONHD(0): Display dimensions: (340, 270) mm (**) RADEONHD(0): DPI set to (286, 180) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules/libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (II) Loading sub module "exa" (II) LoadModule: "exa" (II) Loading /usr/local/lib/xorg/modules/libexa.so (II) Module exa: vendor="X.Org Foundation" compiled for 1.7.5, module version = 2.5.0 ABI class: X.Org Video Driver, version 6.0 (II) RADEONHD(0): FB: Allocated Offscreen Buffer at offset 0x01C28000 (size = 0x01998000) (II) RADEONHD(0): FB: Allocated DRI Back Buffer at offset 0x035C0000 (size = 0x01C20000) (II) RADEONHD(0): FB: Allocated DRI Depth Buffer at offset 0x051E0000 (size = 0x01C20000) (II) RADEONHD(0): FB: Allocated GART table at offset 0x0FFF0000 (size = 0x00010000, end of FB) (II) RADEONHD(0): FB: Allocated DRI Textures at offset 0x06E00000 (size = 0x09000000) (II) RADEONHD(0): Using 16 MB GART aperture (II) RADEONHD(0): Using 2 MB for the ring buffer (II) RADEONHD(0): Using 2 MB for vertex/indirect buffers (II) RADEONHD(0): Using 12 MB for GART textures (--) Depth 24 pixmap format is 32 bpp (II) RADEONHD(0): Mapped IO @ 0xfe9f0000 to 0x286c7000 (size 0x00010000) (II) RADEONHD(0): IGP sideport memory not present. (==) RADEONHD(0): Not Mapping IGP memory (II) RADEONHD(0): Mapped FB @ 0xd0000000 to 0x28c00000 (size 0x10000000) (II) RADEONHD(0): Attempting to enable power management (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:01:05.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:01:05.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEONHD(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEONHD(0): [drm] framebuffer handle = 0xd0000000 (II) RADEONHD(0): [drm] added 1 reserved context for kernel (II) RADEONHD(0): X context handle = 0x3 (II) RADEONHD(0): [drm] installed DRM signal handler (II) RADEONHD(0): [pci] 16384 kB allocated with handle 0xe8add000 (II) RADEONHD(0): [pci] ring handle = 0xe8add000 (II) RADEONHD(0): [pci] Ring mapped at 0x28892000 (II) RADEONHD(0): [pci] Ring contents 0x00000000 (II) RADEONHD(0): [pci] ring read ptr handle = 0xe8cde000 (II) RADEONHD(0): [pci] Ring read ptr mapped at 0x286f6000 (II) RADEONHD(0): [pci] Ring read ptr contents 0x00000000 (II) RADEONHD(0): [pci] vertex/indirect buffers handle = 0xe8cdf000 (II) RADEONHD(0): [pci] Vertex/indirect buffers mapped at 0x38c00000 (II) RADEONHD(0): [pci] Vertex/indirect buffers contents 0x00000000 (II) RADEONHD(0): [pci] GART texture map handle = 0xe8edf000 (II) RADEONHD(0): [pci] GART Texture map mapped at 0x38edf000 (II) RADEONHD(0): [drm] register handle = 0xfe9f0000 (II) RADEONHD(0): [dri] Visual configs initialized (II) RADEONHD(0): Attempting to set Engine Clock to 500000 (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): [DRI] installation complete (II) RADEONHD(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEONHD(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEONHD(0): [drm] dma control initialized, using IRQ 258 (II) RADEONHD(0): [drm] Initialized kernel GART heap manager, 12320768 (II) RADEONHD(0): Direct rendering enabled (II) RADEONHD(0): Using DRM Command Processor (indirect) for acceleration. (II) EXA(0): Offscreen pixmap area of 26836992 bytes (II) EXA(0): Driver registered support for the following operations: (II) Solid (II) Copy (II) Composite (RENDER acceleration) (II) UploadToScreen (II) DownloadFromScreen (==) RADEONHD(0): Backing store disabled (==) RADEONHD(0): Silken mouse enabled (II) RADEONHD(0): RandR 1.2 enabled, ignore the following RandR disabled message. (II) RADEONHD(0): On Crtc 0 Setting 75.0 Hz Mode: Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync None (II) RADEONHD(0): RHDAudioSetSupported: config 0x60040 codec 0x1 (==) RADEONHD(0): DPMS enabled (II) RADEONHD(0): Xv: Textured Video initialised. (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE record: RECORD extension enabled at configure time. record: This extension is known to be broken, disabling extension now.. record: http://bugs.freedesktop.org/show_bug.cgi?id=20500 (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) RADEONHD(0): Setting screen physical size to 338 x 270 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.1, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (EE) module ABI major version (4) doesn't match the server's version (7) (II) UnloadModule: "mouse" (II) Unloading /usr/local/lib/xorg/modules/input/mouse_drv.so (EE) Failed to load module "mouse" (module requirement mismatch, 0) (EE) No input driver matching `mouse' (**) Option "CoreKeyboard" (**) Keyboard0: always reports core events (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "XkbRules" "base" (**) Keyboard0: XkbRules: "base" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (II) config/hal: Adding input device USB Receiver (**) USB Receiver: always reports core events (**) Option "Protocol" "standard" (**) USB Receiver: Protocol: standard (**) Option "XkbRules" "base" (**) USB Receiver: XkbRules: "base" (**) Option "XkbModel" "pc105" (**) USB Receiver: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) USB Receiver: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) USB Receiver: CustomKeycodes disabled (II) XINPUT: Adding extended input device "USB Receiver" (type: KEYBOARD) (II) config/hal: Adding input device AT Keyboard (**) AT Keyboard: always reports core events (**) Option "Protocol" "standard" (**) AT Keyboard: Protocol: standard (**) Option "XkbRules" "base" (**) AT Keyboard: XkbRules: "base" (**) Option "XkbModel" "pc105" (**) AT Keyboard: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) AT Keyboard: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) AT Keyboard: CustomKeycodes disabled (II) XINPUT: Adding extended input device "AT Keyboard" (type: KEYBOARD) (II) RADEONHD(0): Attempting to disable power management (II) RADEONHD(0): Attempting to set Engine Clock to 494040 (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): Attempting to enable power management (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): On Crtc 0 Setting 75.0 Hz Mode: Modeline "1280x1024" 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync None (II) RADEONHD(0): RHDAudioSetSupported: config 0x60040 codec 0x1 (II) RADEONHD(0): Attempting to set Engine Clock to 500000 (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) RADEONHD(0): DAC A: Sensed Output: VGA (WW) EDID preferred timing clock 135.00MHz exceeds claimed max 130MHz, fixing (II) RADEONHD(0): EDID data for EN7750 (II) RADEONHD(0): Manufacturer: EPI Model: 7750 Serial#: 44327 (II) RADEONHD(0): Year: 2006 Week: 23 (II) RADEONHD(0): EDID Version: 1.3 (II) RADEONHD(0): Analog Display Input, Input Voltage Level: 0.700/0.700 V (II) RADEONHD(0): Sync: Separate (II) RADEONHD(0): Max Image Size [cm]: horiz.: 34 vert.: 27 (II) RADEONHD(0): Gamma: 2.20 (II) RADEONHD(0): DPMS capabilities: Off; RGB/Color Display (II) RADEONHD(0): First detailed timing is preferred mode (II) RADEONHD(0): redX: 0.640 redY: 0.347 greenX: 0.302 greenY: 0.587 (II) RADEONHD(0): blueX: 0.143 blueY: 0.099 whiteX: 0.321 whiteY: 0.338 (II) RADEONHD(0): Supported established timings: (II) RADEONHD(0): 720x400@70Hz (II) RADEONHD(0): 640x480@60Hz (II) RADEONHD(0): 640x480@67Hz (II) RADEONHD(0): 640x480@72Hz (II) RADEONHD(0): 640x480@75Hz (II) RADEONHD(0): 800x600@56Hz (II) RADEONHD(0): 800x600@60Hz (II) RADEONHD(0): 800x600@72Hz (II) RADEONHD(0): 800x600@75Hz (II) RADEONHD(0): 832x624@75Hz (II) RADEONHD(0): 1024x768@60Hz (II) RADEONHD(0): 1024x768@70Hz (II) RADEONHD(0): 1024x768@75Hz (II) RADEONHD(0): 1280x1024@75Hz (II) RADEONHD(0): Manufacturer's mask: 0 (II) RADEONHD(0): Supported standard timings: (II) RADEONHD(0): #0: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEONHD(0): Supported detailed timing: (II) RADEONHD(0): clock: 135.0 MHz Image Size: 340 x 270 mm (II) RADEONHD(0): h_active: 1280 h_sync: 1296 h_sync_end 1440 h_blank_end 1688 h_border: 0 (II) RADEONHD(0): v_active: 1024 v_sync: 1025 v_sync_end 1028 v_blanking: 1066 v_border: 0 (II) RADEONHD(0): Serial No: 27966JA044327 (II) RADEONHD(0): Ranges: V min: 55 V max: 75 Hz, H min: 30 H max: 83 kHz, PixClock max 135 MHz (II) RADEONHD(0): Monitor name: EN7750 (II) RADEONHD(0): EDID (in hex): (II) RADEONHD(0): 00ffffffffffff001609507727ad0000 (II) RADEONHD(0): 1710010368221b782af596a3584d9624 (II) RADEONHD(0): 195256bfef0081800101010101010101 (II) RADEONHD(0): 010101010101bc34009851002a401090 (II) RADEONHD(0): 1300540e1100001e000000ff00323739 (II) RADEONHD(0): 36364a41303434333237000000fd0037 (II) RADEONHD(0): 4b1e530d000a202020202020000000fc (II) RADEONHD(0): 00454e373735300a2020202020200089 (II) RADEONHD(0): EDID vendor "EPI", prod id 30544 (II) RADEONHD(0): Using hsync ranges from config file (II) RADEONHD(0): Using vrefresh ranges from config file (II) RADEONHD(0): Printing DDC gathered Modelines: (II) RADEONHD(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEONHD(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEONHD(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEONHD(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEONHD(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEONHD(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEONHD(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEONHD(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEONHD(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEONHD(0): Attempting to disable power management (II) RADEONHD(0): Attempting to set Engine Clock to 494040 (II) RADEONHD(0): Current Engine Clock: 494040 (WW) RADEONHD(0): AtomBIOS command table 47 does not exist (II) RADEONHD(0): Query for AtomBIOS Exec: not implemented (WW) RADEONHD(0): Unusupported SetVoltage Revision (II) UnloadModule: "kbd" (II) UnloadModule: "kbd" (II) UnloadModule: "kbd" (EE) RADEONHD(0): RHDCSStop: Command Submission backend is not active! (II) RADEONHD(0): [drm] removed 1 reserved context for kernel (II) RADEONHD(0): [drm] unmapping 8192 bytes of SAREA 0xc6824000 at 0x286f4000 (II) RADEONHD(0): [drm] Closed DRM master. Thanks for your help, Nate Maier From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 01:23:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AC8E1065674 for ; Wed, 23 Jun 2010 01:23:46 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9FC8FC1B for ; Wed, 23 Jun 2010 01:23:45 +0000 (UTC) Received: by vws14 with SMTP id 14so189422vws.13 for ; Tue, 22 Jun 2010 18:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=atENWsPYOATorqbr8cEDa93KF2Gw43HNLx5ZXxXFh7I=; b=TwnWMh0676RuUCwhtEHpNpLVwfwE0kml365qASpjllWrU9HntLMDcZ+duQSPjFrO+R +kNdRm32hxKdwDA7Vx9spnV5gShyK7lrJW5GPCkLQfKsNchiNoCGPNnFV+LLwpuFzGZ1 irCB1jRuCW6gmaKGjyK/kGdI9R5+P9o7MHGPE= 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=A6jsAwfeG8BaHw4fNRmrj6SZJtm3pFK3XSjTghJjtl/jUM5aRjdHUUAfQ7L+EC847E 3m4OaHSeNrenJtWE/FTULEJTBJDcf1X2/cIqxpzwQFL6wwVvcvdXk3PqgphpVmbGJ5QO VXBHlPhveeNrbk5qAkO49N5A1vnSnDBdRkrSE= MIME-Version: 1.0 Received: by 10.224.59.30 with SMTP id j30mr4381159qah.143.1277256225242; Tue, 22 Jun 2010 18:23:45 -0700 (PDT) Received: by 10.229.82.70 with HTTP; Tue, 22 Jun 2010 18:23:45 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Jun 2010 20:23:45 -0500 Message-ID: From: Adam Vande More To: Nathan Maier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: The mouse appears on screen but doesn't move. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 01:23:46 -0000 On Tue, Jun 22, 2010 at 7:14 PM, Nathan Maier wrote: > Hi, > Just updated to 8.0-Release via freebsd-update from 8.0-rc1. My mouse > worked well enough in the first 8.0 release after adding "Option > "AllowEmptyInput" "off" from the UPDATING file. > Here's Xorg.log: > (II) LoadModule: "mouse" > (II) Loading /usr/local/lib/xorg/modules/input/mouse_drv.so > (II) Module mouse: vendor="X.Org Foundation" > compiled for 1.6.1, module version = 1.4.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (EE) module ABI major version (4) doesn't match the server's version (7) > (II) UnloadModule: "mouse" > (II) Unloading /usr/local/lib/xorg/modules/input/mouse_drv.so > (EE) Failed to load module "mouse" (module requirement mismatch, 0) > Well I guess that would be your problem. Assuming you've updated your ports tree, something like portmaster --no-confirm -d /usr/ports/x11-drivers/xf86-input-mouse/ and restarting X should fix it although it doesn't seem like a jump from an RC to RELEASE should cause this. Did you update other parts of the system as well? -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 02:59:03 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C0F6106564A for ; Wed, 23 Jun 2010 02:59:03 +0000 (UTC) (envelope-from lioux@FreeBSD.org) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 44D718FC12 for ; Wed, 23 Jun 2010 02:59:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id 325165CCD for ; Tue, 22 Jun 2010 19:59:03 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id q+Sv7DCT4I-h for ; Tue, 22 Jun 2010 19:59:03 -0700 (PDT) Received: from 189.72.155.250 (189-72-155-250.bsace702.dsl.brasiltelecom.net.br [189.72.155.250]) by goat.gigo.com (Postfix) with ESMTPSA id 45C6F5CC1 for ; Tue, 22 Jun 2010 19:59:02 -0700 (PDT) Received: (qmail 83012 invoked by uid 1001); 22 Jun 2010 23:58:55 -0300 Message-ID: <20100623025855.82916.qmail@exxodus.fedaykin.here> Date: Tue, 22 Jun 2010 23:58:55 -0300 From: Mario Sergio Fujikawa Ferreira To: freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 02:59:03 -0000 Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl ffffffff8004667e I've already recompiled all my python ports and dependencies. I am running up to date ports (today). $ uname -a FreeBSD exxodus.fedaykin.here 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #10: Thu Jun 17 12:28:13 BRT 2010 lioux@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 These messages began this past week but I am not sure what might be to blame: latest ports or latest -STABLE. The specific python port is deluge 1.3 RC1. It was running fine before this past week of changes. Does anyone have an idea what might be causing this? Do I have to be alarmed by this? The system is reliable despite these messages. Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 03:17:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73C4B1065675 for ; Wed, 23 Jun 2010 03:17:15 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAB98FC20 for ; Wed, 23 Jun 2010 03:17:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.3/8.14.3) with ESMTP id o5N3HEBd007976; Tue, 22 Jun 2010 21:17:14 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.3/8.14.3/Submit) with ESMTP id o5N3HEqk007973; Tue, 22 Jun 2010 21:17:14 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 22 Jun 2010 21:17:14 -0600 (MDT) From: Warren Block To: Nathan Maier In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.5 (wonkity.com [127.0.0.1]); Tue, 22 Jun 2010 21:17:14 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: The mouse appears on screen but doesn't move. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 03:17:15 -0000 On Tue, 22 Jun 2010, Nathan Maier wrote: > Hi, > Just updated to 8.0-Release via freebsd-update from 8.0-rc1. My mouse > worked well enough in the first 8.0 release after adding "Option > "AllowEmptyInput" "off" from the UPDATING file. > Here's Xorg.log: > > X.Org X Server 1.7.5 > Release Date: 2010-02-16 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 8.0-RC1 i386 Current Operating System: > FreeBSD nomos 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #0: Wed May 26 05:45:12 > UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > i386 > Build Date: 21 June 2010 05:47:02PM > > Current version of pixman: 0.16.6 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 22 19:03:30 2010 > (++) Using config file: "/root/xorg.conf.new" > (==) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Card0" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (**) Option "AllowEmptyInput" "off" Remove that AEI line. If you're running hal, that's all you need to do. If you aren't running hal, use Option "AutoAddDevices" "Off" instead. Oh, and you're using radeonhd. Unless you need audio over HDMI, radeon is probably a better choice. From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 06:31:53 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 035911065672 for ; Wed, 23 Jun 2010 06:31:53 +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 0FCFD8FC17 for ; Wed, 23 Jun 2010 06:31:51 +0000 (UTC) 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 JAA13648; Wed, 23 Jun 2010 09:31:50 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ORJV0-0003Bc-5Y; Wed, 23 Jun 2010 09:31:50 +0300 Message-ID: <4C21AA54.3030404@icyb.net.ua> Date: Wed, 23 Jun 2010 09:31:48 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Mario Sergio Fujikawa Ferreira References: <20100623025855.82916.qmail@exxodus.fedaykin.here> In-Reply-To: <20100623025855.82916.qmail@exxodus.fedaykin.here> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:31:53 -0000 on 23/06/2010 05:58 Mario Sergio Fujikawa Ferreira said the following: > Hi, > > I am getting more than 4 thousand of the following messages a day: > > WARNING pid 24509 (python2.6): ioctl sign-extension ioctl ffffffff8004667e This ioctl is FIONBIO. I believe that I saw another report about it on this list recently (~1 week ago). But it was for a different software. > I've already recompiled all my python ports and dependencies. > I am running up to date ports (today). > > $ uname -a > FreeBSD exxodus.fedaykin.here 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #10: Thu Jun 17 12:28:13 BRT 2010 lioux@exxodus:/usr/obj/usr/src/sys/LIOUX amd64 > > These messages began this past week but I am not sure what > might be to blame: latest ports or latest -STABLE. I guess it would be some port. > The specific python port is deluge 1.3 RC1. It was running > fine before this past week of changes. > > Does anyone have an idea what might be causing this? Do I > have to be alarmed by this? The system is reliable despite these > messages. This messages just warns about bad programming, but in this case the ioctl is processed correctly. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 06:41:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B5B91065673 for ; Wed, 23 Jun 2010 06:41:19 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id E905C8FC0C for ; Wed, 23 Jun 2010 06:41:18 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ORJe9-000ISf-2j; Wed, 23 Jun 2010 06:41:17 +0000 Date: Wed, 23 Jun 2010 15:41:16 +0900 Message-ID: From: Randy Bush To: Mark Stapper In-Reply-To: <4C1F5108.8080106@mapper.nl> References: <4C1B2180.1040300@mapper.nl> <4C1B4858.7040805@dssgmbh.de> <4C1C88AC.6090801@mapper.nl> <4C1F5108.8080106@mapper.nl> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: network deamons starting before network! X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 06:41:19 -0000 # grep REQUIRE /etc/rc.d/ppp # REQUIRE: netif ldconfig ^^^^^^^^^ i had to add this From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 14:52:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE96106564A for ; Wed, 23 Jun 2010 14:52:50 +0000 (UTC) (envelope-from maier.nathan@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 226608FC14 for ; Wed, 23 Jun 2010 14:52:49 +0000 (UTC) Received: by iwn3 with SMTP id 3so255165iwn.13 for ; Wed, 23 Jun 2010 07:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:x-x-sender:to :subject:message-id:user-agent:mime-version:content-type; bh=e/7mLoO7/rGlx28QCOBCNWDry49CQsxKWDMKHxnQ4Gg=; b=ccay3Uf/RThgyHnnnaPm1sAZxNs9PXCKAJHmPQfQR6D5c8wM28OhMz1vOYd3Q8jPVV Sj4YBiVBa0L3hmp5qLIu+14VqaPlNz4SoTjDGQ6mqlwHwD3g0mK//FW0Db3uz2PRmYzY eCHMwOLvhBYQaOt/QD/F+ep4ZXzvS06CWaVcw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:x-x-sender:to:subject:message-id:user-agent:mime-version :content-type; b=ZKdHdXzTKktwm9WQixyqZZm5ojh5aPmhuAnQoPswEjaSf9gBBNOjaWLZ6paoQrXZZ8 2VRaeYQPCMQ6wXtlnTFyyMsWDQhsYNaMQDuOUr6T5H+Gt5IuvPiCXTqlxgtinFJ0/gy8 i24+m++MSgiQItyroTlnS9rJo9+cQcnmkrbAI= Received: by 10.231.147.143 with SMTP id l15mr9347390ibv.9.1277304769530; Wed, 23 Jun 2010 07:52:49 -0700 (PDT) Received: from [192.168.0.103] (c-24-15-68-119.hsd1.il.comcast.net [24.15.68.119]) by mx.google.com with ESMTPS id a8sm9979908ibi.17.2010.06.23.07.52.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 07:52:48 -0700 (PDT) Date: Wed, 23 Jun 2010 09:46:55 -0500 (CDT) From: Nathan Maier X-X-Sender: root@nomos To: freebsd-stable@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 Subject: Mouse appears on screen but does not move. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 14:52:50 -0000 Hi again, I am pretty sure that Adam is right about the version mismatch. I used sysinstall to update the ports tree and had to change options from 8.0-RELEASE-p3 to 8.0-RELEASE. Cvsup deleted the ports tree. Don't know if I have to change the RELENG_8 to something else. # $FreeBSD: src/share/examples/cvsup/ports-supfile,v 1.38.10.1.2.1 2009/10/25 01:10:29 kensmith Exp $ # # This file contains all of the "CVSup collections" that make up the # FreeBSD-current ports collection. # # CVSup (CVS Update Protocol) allows you to download the latest CVS # tree (or any branch of development therefrom) to your system easily # and efficiently (far more so than with sup, which CVSup is aimed # at replacing). If you're running CVSup interactively, and are # currently using an X display server, you should run CVSup as follows # to keep your CVS tree up-to-date: # # cvsup ports-supfile # # If not running X, or invoking cvsup from a non-interactive script, then # run it as follows: # # cvsup -g -L 2 ports-supfile # # You may wish to change some of the settings in this file to better # suit your system: # # host=CHANGE_THIS.FreeBSD.org # This specifies the server host which will supply the # file updates. You must change it to one of the CVSup # mirror sites listed in the FreeBSD Handbook at # http://www.freebsd.org/doc/handbook/mirrors.html. # You can override this setting on the command line # with cvsup's "-h host" option. # # base=/var/db # This specifies the root where CVSup will store information # about the collections you have transferred to your system. # A setting of "/var/db" will generate this information in # /var/db/sup. You can override the "base" setting on the # command line with cvsup's "-b base" option. This directory # must exist in order to run CVSup. # # prefix=/usr # This specifies where to place the requested files. A # setting of "/usr" will place all of the files requested # in "/usr/ports" (e.g., "/usr/ports/devel", "/usr/ports/lang"). # The prefix directory must exist in order to run CVSup. # Defaults that apply to all the collections # # IMPORTANT: Change the next line to use one of the CVSup mirror sites # listed at http://www.freebsd.org/doc/handbook/mirrors.html. *default host=cvsup5.FreeBSD.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_8 *default delete use-rel-suffix # If you seem to be limited by CPU rather than network or disk bandwidth, try # commenting out the following line. (Normally, today's CPUs are fast enough # that you want to run compression.) *default compress ## Ports Collection. # # The easiest way to get the ports tree is to use the "ports-all" # mega-collection. It includes all of the individual "ports-*" # collections, #ports-all # These are the individual collections that make up "ports-all". If you # use these, be sure to comment out "ports-all" above. # # Be sure to ALWAYS cvsup the ports-base collection if you use any of the # other individual collections below. ports-base is a mandatory collection # for the ports collection, and your ports may not build correctly if it # is not kept up to date. #ports-base #ports-accessibility #ports-arabic #ports-archivers #ports-astro #ports-audio #ports-benchmarks #ports-biology #ports-cad ##ports-chinese #ports-comms #ports-converters #ports-databases# #ports-deskutils #ports-devel #ports-dns #ports-editors #ports-emulators #ports-finance #ports-french #ports-ftp #ports-games #ports-german #ports-graphics #ports-hebrew #ports-hungarian #ports-irc #ports-japanese #ports-java #ports-korean #ports-lang #ports-mail #ports-math #ports-mbone #ports-misc #ports-multimedia #ports-net #ports-net-im #ports-net-mgmt #ports-net-p2p #ports-news #ports-palm #ports-polish #ports-ports-mgmt #ports-portuguese #ports-print #ports-russian #ports-science #ports-security #ports-shells #ports-sysutils #ports-textproc #ports-ukrainian #ports-vietnamese #ports-www ports-x11 ports-x11-clocks ports-x11-drivers ports-x11-fm ports-x11-fonts ports-x11-servers ports-x11-themes ports-x11-toolkits ports-x11-wm Will keep trying. I can't download email right now on this program, so I'm not using text from the other emails. I'll keep in mind hal and 'AEI'and 'ADD', Warren. Thanks again, -Nate From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 15:21:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D37B6106566C for ; Wed, 23 Jun 2010 15:21:08 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8D22D8FC0A for ; Wed, 23 Jun 2010 15:21:08 +0000 (UTC) Received: by gxk3 with SMTP id 3so754960gxk.13 for ; Wed, 23 Jun 2010 08:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=188LTl00ACNAwU01mv0WJ2OJGDBhZa/4FTR87J5MMkA=; b=fXv5qWl3nZa2wJhZB3XbM7aZglob3iWBbooNnJg56QuDr9arka/phfa03T/jykycKr xkgezI5dlzQ+YvibY3yihZ4r7sBRS8clXDvJY8fLecxebCHzJVE0erYOp+JbcPINT8bP oEK1RRAJU+AvvAEngfrDMpFRwzfblZ0v+DoDM= 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=T7kPAwcpDcel34VILJ7Km+v1+qYdiH+TquvkOyBZSIwo+2bAB3Y0FO4fCP53NbxKK5 hIoPvmjai3l3dOw9LnjDiCXlkyT+WKUNP52kLds1KFWyyVv+lxq1xJzquLxOTP5Hx8oW k5QHdzO8JLK4lw5ATyqNPfbvqBBrta5LgPp4I= MIME-Version: 1.0 Received: by 10.224.96.89 with SMTP id g25mr5158148qan.42.1277306467461; Wed, 23 Jun 2010 08:21:07 -0700 (PDT) Received: by 10.229.82.70 with HTTP; Wed, 23 Jun 2010 08:21:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jun 2010 10:21:07 -0500 Message-ID: From: Adam Vande More To: Nathan Maier Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Mouse appears on screen but does not move. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 15:21:09 -0000 On Wed, Jun 23, 2010 at 9:46 AM, Nathan Maier wrote: > Hi again, > I am pretty sure that Adam is right about the version mismatch. I used > sysinstall to update the ports tree and had to change options from > 8.0-RELEASE-p3 to 8.0-RELEASE. Cvsup deleted the ports tree. Don't know if > I have to change the RELENG_8 to something else. > Yeah you would want to set *default release=cvs tag=RELENG_8_0 You may also need to set the date if you want to keep only on RELEASE. If you're trying to keep your packages from that date, probably just easier to use pkg_add -r or download directly eg ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.0-release/x11-drivers/ Make sure that is your correct ARCH -- Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 16:00:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 883E31065675 for ; Wed, 23 Jun 2010 16:00:30 +0000 (UTC) (envelope-from maier.nathan@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 100F78FC0C for ; Wed, 23 Jun 2010 16:00:29 +0000 (UTC) Received: by mail-fx0-f54.google.com with SMTP id 7so3711036fxm.13 for ; Wed, 23 Jun 2010 09:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:organization:x-mailer :mime-version:content-type:content-transfer-encoding; bh=OmVp20kvGLcqg0OEhPf8AvNOSV3a6XmdnWGaGgpGX5U=; b=pfde2lZ4L6GnTzpGSRv5RxJG2fu4RD56nYKuwg4msgTPmXrXSbLANnzZBzAh204C1r REVAQFJMO/V2E0gOgf3gU6sD4RApBhGdw2IBB5JCl0L2z46ggSi0G7vD7C+tVzaNHXJY zvjFkoXekg6z3qEIsiBqaItaBx4/tc1tifwOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:organization :x-mailer:mime-version:content-type:content-transfer-encoding; b=dUhtIWh+2hRlf2eS/nOjYDe7nsz+CpKdzGOn6bq8BitCtUn+qWh8yYHkSN6vtip4BB A5ImDQIeauTwo9y9P/28jPUpMQDDj28CbU0Lj1QE9JAoux1PYUGqyNYyDI8ak7wumHhU 9gIzu1YKCi2qH49VGQsVmcI8MXsp07yvo6+Hw= Received: by 10.204.46.199 with SMTP id k7mr5804641bkf.146.1277308829602; Wed, 23 Jun 2010 09:00:29 -0700 (PDT) Received: from nomos (c-24-15-68-119.hsd1.il.comcast.net [24.15.68.119]) by mx.google.com with ESMTPS id jq1sm12928909bkb.47.2010.06.23.09.00.28 (version=SSLv3 cipher=RC4-MD5); Wed, 23 Jun 2010 09:00:29 -0700 (PDT) Date: Wed, 23 Jun 2010 10:54:41 -0500 From: Nathan Peet Maier To: freebsd-stable@freebsd.org Message-ID: <20100623105441.7cab13b2@nomos> In-Reply-To: <20100623120041.5455D10656FA@hub.freebsd.org> References: <20100623120041.5455D10656FA@hub.freebsd.org> Organization: Team Circadia X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Mouse appears on screen but does not move X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:00:30 -0000 Okay, THe mouse is working well enough. I changed my label in ports-supfile to tag=. which I found in documentation as applicable to ports supfiles. Is this different from source supfiles where "." means CURRENT release. Anyhow, after portupgrade -a, I tried xdm with 'AllowEmptyInput' 'off' and both mouse and keyboard worked. Then I changed to 'AutoAddDevices' 'off' and the mouse worked as well. 'AutoAddDevices' 'off' : (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option "CoreKeyboard" (**) Keyboard0: always reports core events (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "XkbRules" "base" (**) Keyboard0: XkbRules: "base" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (EE) config/hal: couldn't initialise context: unknown error (null) (END) 'AllowEmptyInput' 'off': (**) Option "Protocol" "auto" (**) Mouse0: Device: "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: always reports core events (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse I will be sorting 'hardware access layer' issues for myself soon. Thanks for all your help. The problem was the mismatched version numbers. This, no doubt, has prevented alot of other mismatches from popping up. -Nate Maier From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 16:05:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8786D1065672 for ; Wed, 23 Jun 2010 16:05:26 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7F98FC1B for ; Wed, 23 Jun 2010 16:05:26 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta13.emeryville.ca.mail.comcast.net with comcast id ZT201e0031smiN4ADU5RPY; Wed, 23 Jun 2010 16:05:25 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta20.emeryville.ca.mail.comcast.net with comcast id ZU5R1e0013S48mS8gU5RYk; Wed, 23 Jun 2010 16:05:25 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BC2779B425; Wed, 23 Jun 2010 09:05:24 -0700 (PDT) Date: Wed, 23 Jun 2010 09:05:24 -0700 From: Jeremy Chadwick To: Nathan Peet Maier Message-ID: <20100623160524.GA19859@icarus.home.lan> References: <20100623105441.7cab13b2@nomos> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100623105441.7cab13b2@nomos> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Mouse appears on screen but does not move X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 16:05:26 -0000 On Wed, Jun 23, 2010 at 10:54:41AM -0500, Nathan Peet Maier wrote: > I changed my label in ports-supfile to tag=. which I found in > documentation as applicable to ports supfiles. Is this different > from source supfiles where "." means CURRENT release. Correct. The tag= line for ports should always be . (period, indicating HEAD), while for src it should be whatever tag/release you want to run (RELENG_8_0 for 8.0-RELEASE, RELENG_8 for -STABLE (soon to be 8.1), or . for -CURRENT/HEAD). If you messed with any of the tag= lines in your supfiles, you should examine the contents of /var/db/sup and ensure what's in there matches what you're actually using. I can't help with your X/mouse issues. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 17:12:17 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D2991065670 for ; Wed, 23 Jun 2010 17:12:17 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 136298FC12 for ; Wed, 23 Jun 2010 17:12:16 +0000 (UTC) Received: by vws13 with SMTP id 13so884786vws.13 for ; Wed, 23 Jun 2010 10:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Ujt8F90UrbW2S2qHa3U4KqI+AtJufHrZrqNLqzv2S6w=; b=Ra5WqEkwr+HisFXsVRMl/vmoqDf7kAblUuBERdu0kjLZTCyNoYxhuZX5f3aWX5MyWU ApbHYSFAXItzAXVlwWijm4QMaK+S6sBzYVR4KhfAPEalFnSbZ7rQgHDUaLqJ0sOpj2XC 5OD16iXwA4wv9QY8l7wO8wf0i5J/XnpnycBR8= 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=U1pisxxuHc3PTBY0W6/gR4X+6WKlEJMFoJDH4rnpoo5dlZyo3yxd3ylVKgXBuzlsEm RbWVhXo0LOh/Sg8gp5T2CO3uVlBHV2cG3yJoFaxwaAFmQ7qYmihjXdFownd58mMKBgF+ cZXv6yJQbqCWlZfxYGErKu3VxeCNzKt/vA8sc= MIME-Version: 1.0 Received: by 10.220.88.194 with SMTP id b2mr4249091vcm.82.1277313136028; Wed, 23 Jun 2010 10:12:16 -0700 (PDT) Sender: sektie@gmail.com Received: by 10.220.71.13 with HTTP; Wed, 23 Jun 2010 10:12:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Jun 2010 10:12:15 -0700 X-Google-Sender-Auth: EsNm2BBsVUEpgobVKwVzC3gcKEg Message-ID: From: Randi Harper To: Adam Vande More Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Nathan Maier , freebsd-stable@freebsd.org Subject: Re: Mouse appears on screen but does not move. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 17:12:17 -0000 On Wed, Jun 23, 2010 at 8:21 AM, Adam Vande More wr= ote: > On Wed, Jun 23, 2010 at 9:46 AM, Nathan Maier wro= te: > >> Hi again, >> =A0 =A0I am pretty sure that Adam is right about the version mismatch. = =A0I used >> sysinstall to update the ports tree and had to change options from >> 8.0-RELEASE-p3 to 8.0-RELEASE. =A0Cvsup deleted the ports tree. =A0Don't= know if >> I have to change the RELENG_8 to something else. >> > Use portsnap. Don't use sysinstall to update your ports tree. -- randi > Yeah you would want to set *default release=3Dcvs tag=3DRELENG_8_0 > > You may also need to set the date if you want to keep only on RELEASE. > > If you're trying to keep your packages from that date, probably just easi= er > to use pkg_add -r or download directly eg > > ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-8.0-release/x11-dr= ivers/ > > Make sure that is your correct ARCH > > > > -- > Adam Vande More > _______________________________________________ > 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-stable@FreeBSD.ORG Wed Jun 23 18:12:25 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B8B9106566B; Wed, 23 Jun 2010 18:12:25 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9CC368FC0C; Wed, 23 Jun 2010 18:12:24 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 60636A58D14; Thu, 24 Jun 2010 02:12:23 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id E0rb4vDLgrVB; Thu, 24 Jun 2010 02:12:17 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id DFD13A58946; Thu, 24 Jun 2010 02:12:15 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Az0iAL+/E8vYMg9B28lkv1PhDd/OvZMTYf33Nn+zsjWVapO8otLM1afHrzAHxelze oFsZrr2BpKzVGaOZeioFA== Message-ID: <4C224E7C.7090806@delphij.net> Date: Wed, 23 Jun 2010 11:12:12 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100621 Thunderbird/3.0.5 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Mario Sergio Fujikawa Ferreira References: <20100623025855.82916.qmail@exxodus.fedaykin.here> In-Reply-To: <20100623025855.82916.qmail@exxodus.fedaykin.here> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:12:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > Hi, > > I am getting more than 4 thousand of the following messages a day: > > WARNING pid 24509 (python2.6): ioctl sign-extension ioctl ffffffff8004667e [...] I think we may need to check the code and patch it. Basically this means that python (or some .so modules) passed an int or unsigned int as parameter 'cmd', we need to change it to unsigned long. The warning itself should be harmless to my best of knowledge, one can probably remove the printf in kernel source code as a workaround. By the way it seems to be a POSIX violation and we didn't seem to really use so wide cmd, but I have not yet verified everything myself. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIk58AAoJEATO+BI/yjfBvaAIALLZMVxTN8xMfutobstHHEvc OMVlLcnNM4erbCpL7ThbwsyOBEc5gbNSGtK2jvE3Z82uIhM74NXoe5PwnMeN73Gy r8ShMVdfE5hhJC6HmjGx9sV/zf88dySAQ8n0uHUsIUUL0DnvEOvS7pIEs73Ozm3u Cm9+0k2re604pj3gyFOfaXnJBH8VwSk3VPtOBHGQJnpjNRoHDpT6hw0iRO4+O6UA DoGZHIXpBvM0Qb6unisNogDL1Vsg1A208JCPk96YJegH023HE1oE/jmhgqNwiA/V jZY4VcAJUG+Gpc86VGtZv+w3YIiObMTS4ohO+ktGxfxetPbF2QboIdRUnr28yyU= =Pwmz -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 18:37:48 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8ECF3106564A; Wed, 23 Jun 2010 18:37:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org, d@delphij.net Date: Wed, 23 Jun 2010 14:37:15 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <4C224E7C.7090806@delphij.net> In-Reply-To: <4C224E7C.7090806@delphij.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006231437.38694.jkim@FreeBSD.org> Cc: Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:37:48 -0000 On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > Hi, > > On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > > Hi, > > > > I am getting more than 4 thousand of the following messages a > > day: > > > > WARNING pid 24509 (python2.6): ioctl sign-extension ioctl > > ffffffff8004667e > > [...] > > I think we may need to check the code and patch it. Basically this > means that python (or some .so modules) passed an int or unsigned > int as parameter 'cmd', we need to change it to unsigned long. > > The warning itself should be harmless to my best of knowledge, one > can probably remove the printf in kernel source code as a > workaround. > > By the way it seems to be a POSIX violation and we didn't seem to > really use so wide cmd, but I have not yet verified everything > myself. Long time ago, I had a similar problem with termios TIOCGWINSZ and we patched the port like this: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain I believe it was upstream patched at the time but I won't be surprised if something similar was reintroduced. It happens when a Python internal integer type is converted to a native unsigned long. FYI... Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 18:42:13 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AADBC1065670; Wed, 23 Jun 2010 18:42:13 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id E98E28FC13; Wed, 23 Jun 2010 18:42:12 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id A0BD9A58DBC; Thu, 24 Jun 2010 02:42:11 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id UifffT0W2-Pw; Thu, 24 Jun 2010 02:42:04 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 913CCA58D33; Thu, 24 Jun 2010 02:42:00 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=Kms/vFPPl/w6pJjmqqEPMMy87+Zh5okNF0Dy0St1DUP34Bs5mFY3jgDtFQz+2OqVX KyDK/bEsoBFU1Thv7l1ew== Message-ID: <4C225572.8020602@delphij.net> Date: Wed, 23 Jun 2010 11:41:54 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100621 Thunderbird/3.0.5 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Jung-uk Kim References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <4C224E7C.7090806@delphij.net> <201006231437.38694.jkim@FreeBSD.org> In-Reply-To: <201006231437.38694.jkim@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: d@delphij.net, freebsd-stable@FreeBSD.org, Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 18:42:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/06/23 11:37, Jung-uk Kim wrote: > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: >> Hi, >> >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: >>> Hi, >>> >>> I am getting more than 4 thousand of the following messages a >>> day: >>> >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl >>> ffffffff8004667e >> >> [...] >> >> I think we may need to check the code and patch it. Basically this >> means that python (or some .so modules) passed an int or unsigned >> int as parameter 'cmd', we need to change it to unsigned long. >> >> The warning itself should be harmless to my best of knowledge, one >> can probably remove the printf in kernel source code as a >> workaround. >> >> By the way it seems to be a POSIX violation and we didn't seem to >> really use so wide cmd, but I have not yet verified everything >> myself. > > Long time ago, I had a similar problem with termios TIOCGWINSZ and we > patched the port like this: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Attic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fplain > > I believe it was upstream patched at the time but I won't be surprised > if something similar was reintroduced. It happens when a Python > internal integer type is converted to a native unsigned long. Well, only *BSD have cmd a long value so it's likely that it would be reintroduced. I have checked the 4.4BSD archive and understood that our ioctl's cmd parameter was made long around 1991 or 1992s but didn't see what it actually buy us... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIlVyAAoJEATO+BI/yjfBLgcIAKXIekJTGptB51L3XJaJL0q4 I+3nAqDcexDiTIAZ3ExDW47MNeh89fR5Iun2kgYlaOYtEEz8iFdJkrH2dgjkRGpt iBXcjuYw/rVINkvl03tovwIaDNmHjvD3NyvvTSOqmSsRnyR6Z7LACNqQr95nPzrF jJFS+AWT0QeytzhJFSAHXniR9paTsktnHTIN4XEdnYlzNIIhP8BoDgfJ3RqGJRk9 QcvZtait5JWHaGJFhGvN/j30lGsHPabt9zWqNVSHLJ9pSzfwAtW7Ihwso55/blYA JxkRUps2AfK9ZhvQ2B0eArVQLjA61HifVE1UNLrkh1KMeUPth4eIZvBZuWtJ7R8= =ZCD9 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 19:01:47 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7292B106566C; Wed, 23 Jun 2010 19:01:46 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org, d@delphij.net Date: Wed, 23 Jun 2010 15:01:37 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231437.38694.jkim@FreeBSD.org> <4C225572.8020602@delphij.net> In-Reply-To: <4C225572.8020602@delphij.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006231501.38985.jkim@FreeBSD.org> Cc: Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:01:47 -0000 On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: > On 2010/06/23 11:37, Jung-uk Kim wrote: > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > >> Hi, > >> > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > >>> Hi, > >>> > >>> I am getting more than 4 thousand of the following messages a > >>> day: > >>> > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl > >>> ffffffff8004667e > >> > >> [...] > >> > >> I think we may need to check the code and patch it. Basically > >> this means that python (or some .so modules) passed an int or > >> unsigned int as parameter 'cmd', we need to change it to > >> unsigned long. > >> > >> The warning itself should be harmless to my best of knowledge, > >> one can probably remove the printf in kernel source code as a > >> workaround. > >> > >> By the way it seems to be a POSIX violation and we didn't seem > >> to really use so wide cmd, but I have not yet verified > >> everything myself. > > > > Long time ago, I had a similar problem with termios TIOCGWINSZ > > and we patched the port like this: > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/Att > >ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text%2Fpl > >ain > > > > I believe it was upstream patched at the time but I won't be > > surprised if something similar was reintroduced. It happens when > > a Python internal integer type is converted to a native unsigned > > long. > > Well, only *BSD have cmd a long value so it's likely that it would > be reintroduced. Yes, that's what I mean. > I have checked the 4.4BSD archive and understood that our ioctl's > cmd parameter was made long around 1991 or 1992s but didn't see > what it actually buy us... Like it or not, it is too late to revert. :-( Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 19:10:59 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 6090E106566C; Wed, 23 Jun 2010 19:10:58 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 23 Jun 2010 15:10:46 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <4C225572.8020602@delphij.net> <201006231501.38985.jkim@FreeBSD.org> In-Reply-To: <201006231501.38985.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <201006231510.50863.jkim@FreeBSD.org> Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:10:59 -0000 On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote: > On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: > > On 2010/06/23 11:37, Jung-uk Kim wrote: > > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > > >> Hi, > > >> > > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > > >>> Hi, > > >>> > > >>> I am getting more than 4 thousand of the following messages > > >>> a day: > > >>> > > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl > > >>> ffffffff8004667e > > >> > > >> [...] > > >> > > >> I think we may need to check the code and patch it. Basically > > >> this means that python (or some .so modules) passed an int or > > >> unsigned int as parameter 'cmd', we need to change it to > > >> unsigned long. > > >> > > >> The warning itself should be harmless to my best of knowledge, > > >> one can probably remove the printf in kernel source code as a > > >> workaround. > > >> > > >> By the way it seems to be a POSIX violation and we didn't seem > > >> to really use so wide cmd, but I have not yet verified > > >> everything myself. > > > > > > Long time ago, I had a similar problem with termios TIOCGWINSZ > > > and we patched the port like this: > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files/A > > >tt > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=3D1.1;content-type=3Dtext%2 > > >Fpl ain > > > > > > I believe it was upstream patched at the time but I won't be > > > surprised if something similar was reintroduced. It happens > > > when a Python internal integer type is converted to a native > > > unsigned long. > > > > Well, only *BSD have cmd a long value so it's likely that it > > would be reintroduced. > > Yes, that's what I mean. > > > I have checked the 4.4BSD archive and understood that our ioctl's > > cmd parameter was made long around 1991 or 1992s but didn't see > > what it actually buy us... > > Like it or not, it is too late to revert. :-( =46rom Python 2.6.5: static PyObject * fcntl_ioctl(PyObject *self, PyObject *args) { #define IOCTL_BUFSZ 1024 int fd; /* In PyArg_ParseTuple below, we use the unsigned non-checked 'I' format for the 'code' parameter because Python turns 0x8000000 into either a large positive number (PyLong or PyInt on 64-bit platforms) or a negative number on others (32-bit PyInt) whereas the system expects it to be a 32bit bit field value regardless of it being passed as an int or unsigned long on various platforms. See the termios.TIOCSWINSZ constant across platforms for an example of thise. If any of the 64bit platforms ever decide to use more than 32bits in their unsigned long ioctl codes this will break and need special casing based on the platform being built on. */ unsigned int code; =2E.. It is still a kludge and it won't be fixed. :-( Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 19:16:45 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ACEE106566C; Wed, 23 Jun 2010 19:16:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id A08AF8FC1C; Wed, 23 Jun 2010 19:16:44 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id B33B6A58E3C; Thu, 24 Jun 2010 03:16:43 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id W-oHaYKiDLAM; Thu, 24 Jun 2010 03:16:37 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id DB429A58E3E; Thu, 24 Jun 2010 03:16:35 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type; b=XrAEtUjtp4SUh/Ixn5bnc6lELo17/Yc4uzR63GJQ5z4W5KxLw5FB+BsY069A/pbdB 8eqk4u8yus7FSQeO2Lgiw== Message-ID: <4C225D90.9020100@delphij.net> Date: Wed, 23 Jun 2010 12:16:32 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.10) Gecko/20100621 Thunderbird/3.0.5 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Jung-uk Kim References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <4C225572.8020602@delphij.net> <201006231501.38985.jkim@FreeBSD.org> <201006231510.50863.jkim@FreeBSD.org> In-Reply-To: <201006231510.50863.jkim@FreeBSD.org> X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------030000090201040702030204" Cc: d@delphij.net, freebsd-stable@FreeBSD.org, Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:16:45 -0000 This is a multi-part message in MIME format. --------------030000090201040702030204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/06/23 12:10, Jung-uk Kim wrote: > It is still a kludge and it won't be fixed. :-( Another thought - what about just hiding the printf under #ifdef DIAGNOSTIC... I don't really see any reason why we must print it out if we truncate it every time... Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMIl2QAAoJEATO+BI/yjfBpz0IAM88YOx5CVoYRCEW8EwCaW+N 5Ugks9hCvbsJgU2yLxeg5hGal0wOHKONLxaq9pXvQFybgRT9SLmna2FJLTJ6XYTu pjtjeby40mpwRTwU5rZgJ//aYgHW48kK9N/CoE63zKycYQbjLFGnZmXbel9itZzL Xnpj9kc0zlpqtk6yZd4XA+m90VrIgnMKmxeP0A5OzuWJKUBmvciqSMYEBQ0pkP03 sSiN5QIzW/gRMgYSJEsTGz5+q10ZDf0NOecuhOujLphWLzWxkq6UOqRi3JXvFaqo ajRDpGEG65r2IDd8qo4y50U0FGeHmysTFUPU3aAOzjb10LbNbmT6zX+3G1rSMFY= =A2pe -----END PGP SIGNATURE----- --------------030000090201040702030204 Content-Type: text/plain; name="sys_generic.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="sys_generic.c.diff" Index: sys/kern/sys_generic.c =================================================================== --- sys/kern/sys_generic.c (revision 209472) +++ sys/kern/sys_generic.c (working copy) @@ -628,9 +628,11 @@ caddr_t data; if (uap->com > 0xffffffff) { +#ifdef DIAGNOSTIC printf( "WARNING pid %d (%s): ioctl sign-extension ioctl %lx\n", td->td_proc->p_pid, td->td_name, uap->com); +#endif uap->com &= 0xffffffff; } com = uap->com; --------------030000090201040702030204-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 19:21:51 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 22E051065678; Wed, 23 Jun 2010 19:21:51 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org, d@delphij.net Date: Wed, 23 Jun 2010 15:21:41 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231510.50863.jkim@FreeBSD.org> <4C225D90.9020100@delphij.net> In-Reply-To: <4C225D90.9020100@delphij.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006231521.43795.jkim@FreeBSD.org> Cc: Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:21:51 -0000 On Wednesday 23 June 2010 03:16 pm, Xin LI wrote: > On 2010/06/23 12:10, Jung-uk Kim wrote: > > It is still a kludge and it won't be fixed. :-( > > Another thought - what about just hiding the printf under #ifdef > DIAGNOSTIC... I don't really see any reason why we must print it > out if we truncate it every time... Yes, I agree. Jung-uk Kim From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 19:38:36 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 8D1A91065F0D; Wed, 23 Jun 2010 19:38:35 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 23 Jun 2010 15:38:26 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231501.38985.jkim@FreeBSD.org> <201006231510.50863.jkim@FreeBSD.org> In-Reply-To: <201006231510.50863.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_zKmIM5CjiL+zUxs" Message-Id: <201006231538.27887.jkim@FreeBSD.org> Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 19:38:36 -0000 --Boundary-00=_zKmIM5CjiL+zUxs Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote: > On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote: > > On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: > > > On 2010/06/23 11:37, Jung-uk Kim wrote: > > > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > > > >> Hi, > > > >> > > > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > > > >>> Hi, > > > >>> > > > >>> I am getting more than 4 thousand of the following > > > >>> messages a day: > > > >>> > > > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl > > > >>> ffffffff8004667e > > > >> > > > >> [...] > > > >> > > > >> I think we may need to check the code and patch it. > > > >> Basically this means that python (or some .so modules) > > > >> passed an int or unsigned int as parameter 'cmd', we need to > > > >> change it to unsigned long. > > > >> > > > >> The warning itself should be harmless to my best of > > > >> knowledge, one can probably remove the printf in kernel > > > >> source code as a workaround. > > > >> > > > >> By the way it seems to be a POSIX violation and we didn't > > > >> seem to really use so wide cmd, but I have not yet verified > > > >> everything myself. > > > > > > > > Long time ago, I had a similar problem with termios > > > > TIOCGWINSZ and we patched the port like this: > > > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/files > > > >/A tt > > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=text > > > >%2 Fpl ain > > > > > > > > I believe it was upstream patched at the time but I won't be > > > > surprised if something similar was reintroduced. It happens > > > > when a Python internal integer type is converted to a native > > > > unsigned long. > > > > > > Well, only *BSD have cmd a long value so it's likely that it > > > would be reintroduced. > > > > Yes, that's what I mean. > > > > > I have checked the 4.4BSD archive and understood that our > > > ioctl's cmd parameter was made long around 1991 or 1992s but > > > didn't see what it actually buy us... > > > > Like it or not, it is too late to revert. :-( > > From Python 2.6.5: > > static PyObject * > fcntl_ioctl(PyObject *self, PyObject *args) > { > #define IOCTL_BUFSZ 1024 > int fd; > /* In PyArg_ParseTuple below, we use the unsigned non-checked 'I' > format for the 'code' parameter because Python turns 0x8000000 > into either a large positive number (PyLong or PyInt on 64-bit > platforms) or a negative number on others (32-bit PyInt) > whereas the system expects it to be a 32bit bit field value > regardless of it being passed as an int or unsigned long on > various platforms. See the termios.TIOCSWINSZ constant across > platforms for an example of thise. > > If any of the 64bit platforms ever decide to use more than > 32bits in their unsigned long ioctl codes this will break and need > special casing based on the platform being built on. > */ > unsigned int code; > ... > > It is still a kludge and it won't be fixed. :-( Please drop the attached patch in ports/lang/python26/files and test. Note I am not a Python guy, so please don't shoot me. ;-) Thanks, Jung-uk Kim --Boundary-00=_zKmIM5CjiL+zUxs Content-Type: text/plain; charset="iso-8859-1"; name="patch-Modules-fcntlmodule.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-Modules-fcntlmodule.c" --- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.000000000 -0400 +++ Modules/fcntlmodule.c 2010-06-23 15:27:42.000000000 -0400 @@ -110,7 +110,12 @@ in their unsigned long ioctl codes this will break and need special casing based on the platform being built on. */ +#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \ + defined(__OpenBSD__) + unsigned long code; +#else unsigned int code; +#endif int arg; int ret; char *str; --Boundary-00=_zKmIM5CjiL+zUxs-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 23 21:08:48 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3BCF71065670; Wed, 23 Jun 2010 21:08:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Wed, 23 Jun 2010 17:08:38 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231510.50863.jkim@FreeBSD.org> <201006231538.27887.jkim@FreeBSD.org> In-Reply-To: <201006231538.27887.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Multipart/Mixed; boundary="Boundary-00=_XfnIM7O4aHYDEjI" Message-Id: <201006231708.40032.jkim@FreeBSD.org> Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 21:08:48 -0000 --Boundary-00=_XfnIM7O4aHYDEjI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote: > On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote: > > On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote: > > > On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: > > > > On 2010/06/23 11:37, Jung-uk Kim wrote: > > > > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > > > > >> Hi, > > > > >> > > > > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > > > > >>> Hi, > > > > >>> > > > > >>> I am getting more than 4 thousand of the following > > > > >>> messages a day: > > > > >>> > > > > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl > > > > >>> ffffffff8004667e > > > > >> > > > > >> [...] > > > > >> > > > > >> I think we may need to check the code and patch it. > > > > >> Basically this means that python (or some .so modules) > > > > >> passed an int or unsigned int as parameter 'cmd', we need > > > > >> to change it to unsigned long. > > > > >> > > > > >> The warning itself should be harmless to my best of > > > > >> knowledge, one can probably remove the printf in kernel > > > > >> source code as a workaround. > > > > >> > > > > >> By the way it seems to be a POSIX violation and we didn't > > > > >> seem to really use so wide cmd, but I have not yet > > > > >> verified everything myself. > > > > > > > > > > Long time ago, I had a similar problem with termios > > > > > TIOCGWINSZ and we patched the port like this: > > > > > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil > > > > >es /A tt > > > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te > > > > >xt %2 Fpl ain > > > > > > > > > > I believe it was upstream patched at the time but I won't > > > > > be surprised if something similar was reintroduced. It > > > > > happens when a Python internal integer type is converted to > > > > > a native unsigned long. > > > > > > > > Well, only *BSD have cmd a long value so it's likely that it > > > > would be reintroduced. > > > > > > Yes, that's what I mean. > > > > > > > I have checked the 4.4BSD archive and understood that our > > > > ioctl's cmd parameter was made long around 1991 or 1992s but > > > > didn't see what it actually buy us... > > > > > > Like it or not, it is too late to revert. :-( > > > > From Python 2.6.5: > > > > static PyObject * > > fcntl_ioctl(PyObject *self, PyObject *args) > > { > > #define IOCTL_BUFSZ 1024 > > int fd; > > /* In PyArg_ParseTuple below, we use the unsigned non-checked > > 'I' format for the 'code' parameter because Python turns > > 0x8000000 into either a large positive number (PyLong or PyInt on > > 64-bit platforms) or a negative number on others (32-bit PyInt) > > whereas the system expects it to be a 32bit bit field value > > regardless of it being passed as an int or unsigned long on > > various platforms. See the termios.TIOCSWINSZ constant across > > platforms for an example of thise. > > > > If any of the 64bit platforms ever decide to use more than > > 32bits in their unsigned long ioctl codes this will break and > > need special casing based on the platform being built on. > > */ > > unsigned int code; > > ... > > > > It is still a kludge and it won't be fixed. :-( > > Please drop the attached patch in ports/lang/python26/files and > test. Note I am not a Python guy, so please don't shoot me. ;-) I found that Python guys added 'k' format since 2.3, which converts a Python integer to unsigned long. Please ignore the previous patch and try the attached patch instead. Cheers, Jung-uk Kim --Boundary-00=_XfnIM7O4aHYDEjI Content-Type: text/plain; charset="iso-8859-1"; name="patch-Modules-fcntlmodule.c" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-Modules-fcntlmodule.c" --- Modules/fcntlmodule.c.orig 2009-05-24 11:41:43.000000000 -0400 +++ Modules/fcntlmodule.c 2010-06-23 16:56:10.000000000 -0400 @@ -97,6 +97,13 @@ { #define IOCTL_BUFSZ 1024 int fd; +#if defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \ + defined(__OpenBSD__) +#define IOCTL_ULONG 1 +#endif +#ifdef IOCTL_ULONG + unsigned long code; +#else /* In PyArg_ParseTuple below, we use the unsigned non-checked 'I' format for the 'code' parameter because Python turns 0x8000000 into either a large positive number (PyLong or PyInt on 64-bit @@ -105,12 +112,9 @@ regardless of it being passed as an int or unsigned long on various platforms. See the termios.TIOCSWINSZ constant across platforms for an example of thise. - - If any of the 64bit platforms ever decide to use more than 32bits - in their unsigned long ioctl codes this will break and need - special casing based on the platform being built on. */ unsigned int code; +#endif int arg; int ret; char *str; @@ -118,7 +122,11 @@ int mutate_arg = 1; char buf[IOCTL_BUFSZ+1]; /* argument plus NUL byte */ +#ifdef IOCTL_ULONG + if (PyArg_ParseTuple(args, "O&kw#|i:ioctl", +#else if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl", +#endif conv_descriptor, &fd, &code, &str, &len, &mutate_arg)) { char *arg; @@ -169,7 +177,11 @@ } PyErr_Clear(); +#ifdef IOCTL_ULONG + if (PyArg_ParseTuple(args, "O&ks#:ioctl", +#else if (PyArg_ParseTuple(args, "O&Is#:ioctl", +#endif conv_descriptor, &fd, &code, &str, &len)) { if (len > IOCTL_BUFSZ) { PyErr_SetString(PyExc_ValueError, @@ -191,7 +203,11 @@ PyErr_Clear(); arg = 0; if (!PyArg_ParseTuple(args, +#ifdef IOCTL_ULONG + "O&k|i;ioctl requires a file or file descriptor," +#else "O&I|i;ioctl requires a file or file descriptor," +#endif " an integer and optionally an integer or buffer argument", conv_descriptor, &fd, &code, &arg)) { return NULL; @@ -209,6 +225,7 @@ } return PyInt_FromLong((long)ret); #undef IOCTL_BUFSZ +#undef IOCTL_ULONG } PyDoc_STRVAR(ioctl_doc, --Boundary-00=_XfnIM7O4aHYDEjI-- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 10:47:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41C151065673 for ; Thu, 24 Jun 2010 10:47:47 +0000 (UTC) (envelope-from alex.markelov@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7BC88FC22 for ; Thu, 24 Jun 2010 10:47:46 +0000 (UTC) Received: by wyf22 with SMTP id 22so192350wyf.13 for ; Thu, 24 Jun 2010 03:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=b0zJddBkgVO03cLoRPMu606eiormAegFK0lVeOLcnWU=; b=T97PUQQ7nYYbFFymXr65CHTbfwTBc5so0Kj5QBRtFcVwaJ0oXcPnJ0ax5TkyiGUaKB 2uRtyMs0QkBhsVdjOWajfX0BpymOFFnn4swJQTYnVbxpLFjeNtfmCk+XFABmw7OLMQ4T WHOy+Lw0//fEHcSrw3EWRXCT8Y/5t7AxEp88M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=to1FOsnsrZ2EV9OHlTD5p+9O1dwtwVQpWPH+sFZw2vf/JPGqBEOfYM6eYprtur/C17 Bn4cLD3htPCoh9qkck6mJ+ESQkoFHRPh3ZRAes4ulrbNVjANytqBd2Hqhe0VDiIy7h6t DwPzbQRpENdzlBbskMj8vOe6A8Bdoc1DUW83M= Received: by 10.227.157.81 with SMTP id a17mr8836368wbx.146.1277376465317; Thu, 24 Jun 2010 03:47:45 -0700 (PDT) Received: from dyn-9-161-170-176.mul.ie.ibm.com (gbibp9ph1--blueice2n1.emea.ibm.com [195.212.29.75]) by mx.google.com with ESMTPS id y31sm50234338wby.16.2010.06.24.03.47.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 03:47:44 -0700 (PDT) Message-Id: <4326E32B-9C38-4C7C-BDB1-8FFF1247C6B4@gmail.com> From: Alex Markelov To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 24 Jun 2010 11:47:43 +0100 X-Mailer: Apple Mail (2.936) Subject: Is there known problem with USB flash readers? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 10:47:47 -0000 Hi Guys! I have a strange problem with my flash card reader when dd'ing NanoBSD images onto a CF card. It works for some time (3-4 writes of images), then I start getting scsi error messages and dd hangs. I have to disconnect/re-connect the reader to be able to write to CF again, but sometimes even this trick doesn't work. One day it stopped working for me and since I had a deadline to meet, went to local shop and bought another one (different model and brand). It worked fine for few write iterations and then it developed the same problem. When I decided (out of desperation) to try the old one again, it worked. So, I ended up using the two and swapping between it when either of the units stopped working. First thing I though that it might be the size of the image (2 or 4GB) that I was writing with dd and it was heating up the electronics, but yesterday a friend of mine stumbled upon the same problem and when his flash reader (different brand and model to mine) stopped working, he unplugged it from the FreeBSD box, plugged it in into his Linux laptop and it worked without a problem. In his view it laid to rest my theory about components heating too much as he did it without giving it a minute of rest. I vaguely recall there were problems with USB support in stable some time ago, but I thought it was all fixed and searching the list and the Internet doesn't give me anything. Both of us were using 7-stable. I can email model of the card readers later (not home at the moment). Basically, I have two questions: 1) is it something that well known and not model related 2) is there a well known reliable model of card reader I can buy. I don't mind the price if the device is rock solid. Any pointers/ideas are greatly appreciated! Regards, Alex. -- "Openness is the foundation and preservative of friendship... Let me claim from you at all times your undisguised opinions." --- William Wilberforce PGP fingerprint: B030 9111 CE41 5C09 2710 E9E6 3120 F406 197B DA8E From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 11:47:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96E75106566B for ; Thu, 24 Jun 2010 11:47:16 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 560998FC17 for ; Thu, 24 Jun 2010 11:47:16 +0000 (UTC) Received: by iwn3 with SMTP id 3so1495236iwn.13 for ; Thu, 24 Jun 2010 04:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=D/k2pDjODk6hOWhn7IK1DMs4OPD0YlqGz9LXX8cLp2I=; b=ObICnoPRMWTSfZV9gLNREhNhckclS+iz20WR4OOs/CFaF4pZlVXjwNwyL9n0cMmGvT l758ZCWJflOzzbYvh6y9Hb9T/Tk+MVLbMaJSphFQtaQhOfqSx+Y6MtE64dtclMPuuEDI mWf2xkl0Oa7TwR4eHd3INRQIof6AHsGiu4rPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=Med46RJeFTYbnpJzPvWaUhz+cj0cFCcgPHWnB8E8x0scVXhNjnCzpEQX87hwJlvPnh npRLnXrKb7sNPN9s/AgEpPFOuYCG5yYOj1ligMtUtw4bII88MDP9/1vDJuT4rijwhw+2 rZn4S9Hu2BL81jygNs1+ieQ4TlnL0zwm9QLgc= Received: by 10.231.182.195 with SMTP id cd3mr2778805ibb.133.1277380035810; Thu, 24 Jun 2010 04:47:15 -0700 (PDT) Received: from centel.dataix.local ([99.181.128.180]) by mx.google.com with ESMTPS id d9sm16985277ibl.22.2010.06.24.04.47.13 (version=SSLv3 cipher=RC4-MD5); Thu, 24 Jun 2010 04:47:14 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C2345BF.3070300@dataix.net> Date: Thu, 24 Jun 2010 07:47:11 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.10) Gecko/20100620 Thunderbird MIME-Version: 1.0 To: nlmills@clemson.edu References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=89D8547E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nicholas Mills , freebsd-stable@freebsd.org Subject: Re: panic during boot on 8.0-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 11:47:16 -0000 On 06/22/2010 19:42, Nicholas Mills wrote: > Oops, sent this to the wrong list. > > --Nick > > ---------- Forwarded message ---------- > From: Nicholas Mills > Date: Tue, Jun 22, 2010 at 7:41 PM > Subject: panic during boot on 8.0-RELEASE > To: freebsd-current@freebsd.org > > > Hey all, > > Screenshot of panic message is attached. Machine is a VM running under > Parallels Server Bare Metal 4. The cdrom device was enabled but not > connected during boot. System was attempting to boot into single user mode. > This occurred after a fresh install of 8.0-RELEASE. > > Let me know how I can provide more useful info. > Upload the image somewhere else and provide a link to that. 8.1-RELEASE is coming at some point. You might want to try RC1 snapshots here: http://bit.ly/b7K6fI Good Luck, -- jhell From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 17:52:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7098F106564A for ; Thu, 24 Jun 2010 17:52:32 +0000 (UTC) (envelope-from matt@bubblegen.co.uk) Received: from relay.pcl-ipout01.plus.net (relay.pcl-ipout01.plus.net [212.159.7.99]) by mx1.freebsd.org (Postfix) with ESMTP id 0E0DE8FC13 for ; Thu, 24 Jun 2010 17:52:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJY4I0xUXebj/2dsb2JhbACDHZwacbB+kTaBKYE7gU1wBA Received: from outmx01.plus.net ([84.93.230.227]) by relay.pcl-ipout01.plus.net with ESMTP; 24 Jun 2010 18:52:30 +0100 Received: from bubblegen.plus.com ([80.229.236.194] helo=[192.136.1.18]) by outmx01.plus.net with esmtp (Exim) id 1ORqbG-0006Ft-0X; Thu, 24 Jun 2010 18:52:30 +0100 From: Matthew Lear To: Bob Bishop In-Reply-To: <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Jun 2010 18:52:14 +0100 Message-ID: <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Jeremy Chadwick Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 17:52:32 -0000 On Tue, 2010-06-22 at 20:04 +0100, Bob Bishop wrote: > Hi, > > On 22 Jun 2010, at 08:45, Jeremy Chadwick wrote: > > > On Mon, Jun 21, 2010 at 10:33:12PM +0100, Matthew Lear wrote: > >> [tale of woe elided] > > > > I don't really have any other thoughts on the matter, sadly. > > [helpful suggestions elided] > > > > Anyone else have ideas/recommendations? > > The disks sure look OK. I wouldn't rule out the controller(s), I've had various chipsets fail in odd ways. > Thanks Bob. I think we all thought the same. I've actually just rebooted the machine and FreeBSD no longer boots. This isn't what I was expecting at all. Something has clearly gone wrong with some file system metadata. When I commissioned the machine I installed an 'early' bootloader (apologies for perhaps using an incorrect term) which boots FreeBSD by default (F1 option) or from Drive 1 (F5). Drive 1 is the DVD drive. It appears to be the case that the early bootloader tries to boot FreeBSD and fails. I get the messages: error 1 lba 795079 Invalid format FreeBSD/i386 boot Default: 0:ad(0,a)/boot/kernel/kernel boot: error 1 lba 786815 No /boot/kernel/kernel FreeBSD/i386 boot Default: 0:ad(0,a)/boot/kernel/kernel boot: ...and I'm at a boot prompt. So, given that ad0 was the failed disk, the bootloader has failed to find specific boot data on ad0 and dropped me into a boot prompt. I'm tempted to replace the boot line with 0:ad(2,a)/boot/kernel/kernel or should that be 2:ad(0,a)/boot/kernel/kernel but I'm a little suspicious of doing anything at this point? Can anybody offer any guidance of what I can do to restore my system? I was able to shut down the machine cleanly (shutdown -p now) and despite the RAID mirror going offline, everything seemed to be behaving normally (expected I guess given that I just lost some redundancy). I'm just that little bit more worried now :-( If the disks are ok, what on earth could have happened and more importantly, how can I restore what was an operational system when I shut it down?! Puzzled.... -- Matt From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 18:13:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDE311065673; Thu, 24 Jun 2010 18:13:39 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 8672A8FC19; Thu, 24 Jun 2010 18:13:39 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id A502578C6A; Fri, 25 Jun 2010 03:13:38 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 939A778C67; Fri, 25 Jun 2010 03:13:38 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: , , Date: Fri, 25 Jun 2010 03:12:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: iSCSI boot driver version 0.1.1 for iBFT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 18:13:39 -0000 Hello, I made small device driver for the first time. It is published on my blog. Because it is written in Japanese, I try to write here. This module provides initial connection of the iSCSI target with setting via iBFT (iSCSI Boot Firmware Table). Currently, it is intended to use Intel NIC and istgt (iSCSI target). Any other cards, targets may not work. Also, I'm developing under FreeBSD 7.3. (build check under 8.1) Please refer to Microsoft website about iBFT: http://www.microsoft.com/whdc/system/platform/firmware/ibft.mspx I did't use iscsi_initiator.ko within kernel module. So, I'm creating a small version of initiator based on iscsi-2.2.4 and istgt-20100606. Now it have only one cmd holding space in the iSCSI session and use polling. It should be added the queuing/asynchronous operation :) After loading it via /boot/loader.conf, you can install to/boot from the iSCSI target as same as a local SCSI harddisk. Complex settings such as TFTP, NFS, DHCP and PXE are no longer needed. Just use /dev/da0 and so on. How to compile: isboot is a stand alone iSCSI initiator, but source code is depend on the header file of iscsi-2.2.4. You need to extract iscsi-2.2.4 before compiling isboot. # cd /usr/src # tar xvf /path/to/iscsi-2.2.4.tar.gz # tar xvf /path/to/isboot-0.1.1.tar.gz # make buildkernel # make installkernel or # cd /usr/src/sys/modules/iscsi/isboot # make obj # make depend # make all # make install After above install, you have /boot/kernel/isboot.ko. Using as module: Add isboot_load="YES" to /boot/loader.conf. Setup iSCSI target. (recommend istgt-20100407 or later) Configure NIC BIOS to connect the target. Try to boot the server. If the NIC find the target, iBFT can be found by isboot. Then, isboot create own bus for CAM device with iBFT parameters. All LUNs in the target are appeared in the bus. Once FreeBSD + isboot is booted, you can handle it by camcontrol and other normal way as same as SCSI HDD. If you want full install and boot demo, please download FreeNAS 0.7.2 5226 p4 from my blog and try it without local harddisk. FYI: FreeNAS 0.7.1 5127 (stable) includes istgt-20100407. FYI: FreeNAS 0.7.2 5226 p3 includes istgt-20100606. FYI: FreeNAS 0.7.2 5226 p4 includes istgt-20100606 + isboot-0.1.1. sysctl MIBs (read only): net.isboot.version net.isboot.nic net.isboot.device hw.ibft.nic_gateway hw.ibft.nic_prefix hw.ibft.target_lun hw.ibft.target_port hw.ibft.target_address hw.ibft.target_name hw.ibft.initiator_address hw.ibft.initiator_name Performance (read from the target): All using Intel PRO/1000 PT Server Adapter. istgt 20100606 + isboot 0.1 with header/data digest(CRC32C): # dd if=/dev/da6 of=/dev/null bs=1m count=1k 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 20.452429 secs (52499477 bytes/sec) istgt 20100606 + isboot 0.1 with header digest: # dd if=/dev/da6 of=/dev/null bs=1m count=1k 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 17.684945 secs (60715022 bytes/sec) istgt 20100606 + isboot 0.1 without digest: # dd if=/dev/da6 of=/dev/null bs=1m count=1k 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 17.508400 secs (61327239 bytes/sec) Notes/Known Issues/Limitations: bootup/reconnect time might be a little long. ifconfig(8),route(8),etc should not change booted NIC and critical path. Unload the module will cause to panic. IPv6 is not tested. DNS is not configured. Queuing is not supported at this time. CHAP is not supported at this time. Can't configure iSCSI parameter without modifing soure code. Can't reject running XPT command when the socket is lost. Can't exchange the session to iscsi_initiator.ko. The source code depend on iscsi initiator's structure. (first I tried to use it, but finally gave up) The controller such as iscontrol(8) is not provided. Documentation is not written. I'm new to the kernel land. If you have any suggestion, please tell me. Download here (the page is Japanese only): isboot-0.1.1 http://shell.peach.ne.jp/aoyama/archives/1179 FreeNAS 0.7.2 5226 p4 http://shell.peach.ne.jp/aoyama/archives/1181 FYI: danny's iscsi initiator: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.4.tar.gz Regards, Daisuke Aoyama From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 18:15:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CE3A1065676 for ; Thu, 24 Jun 2010 18:15:41 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id C8F0F8FC2A for ; Thu, 24 Jun 2010 18:15:40 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id Zpwe1e0060cZkys5EuFgDf; Thu, 24 Jun 2010 18:15:40 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta10.westchester.pa.mail.comcast.net with comcast id ZuFc1e00M3S48mS3WuFdgf; Thu, 24 Jun 2010 18:15:39 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 58A829B425; Thu, 24 Jun 2010 11:15:35 -0700 (PDT) Date: Thu, 24 Jun 2010 11:15:35 -0700 From: Jeremy Chadwick To: Matthew Lear Message-ID: <20100624181535.GA58443@icarus.home.lan> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 18:15:41 -0000 On Thu, Jun 24, 2010 at 06:52:14PM +0100, Matthew Lear wrote: > On Tue, 2010-06-22 at 20:04 +0100, Bob Bishop wrote: > > Hi, > > > > On 22 Jun 2010, at 08:45, Jeremy Chadwick wrote: > > > > > On Mon, Jun 21, 2010 at 10:33:12PM +0100, Matthew Lear wrote: > > >> [tale of woe elided] > > > > > > I don't really have any other thoughts on the matter, sadly. > > > [helpful suggestions elided] > > > > > > Anyone else have ideas/recommendations? > > > > The disks sure look OK. I wouldn't rule out the controller(s), I've had various chipsets fail in odd ways. > > > > Thanks Bob. I think we all thought the same. > I've actually just rebooted the machine and FreeBSD no longer boots. > This isn't what I was expecting at all. Something has clearly gone wrong > with some file system metadata. > > When I commissioned the machine I installed an 'early' bootloader > (apologies for perhaps using an incorrect term) which boots FreeBSD by > default (F1 option) or from Drive 1 (F5). Drive 1 is the DVD drive. I believe this is the boot0 stage of the FreeBSD bootstrap process, otherwise known as "BootMgr" during the OS installation. I tend to avoid this and pick "Standard" instead, which lets the system boot right into boot2/loader. > It appears to be the case that the early bootloader tries to boot > FreeBSD and fails. I get the messages: > > error 1 lba 795079 > Invalid format > > FreeBSD/i386 boot > Default: 0:ad(0,a)/boot/kernel/kernel > boot: > error 1 lba 786815 > No /boot/kernel/kernel > > FreeBSD/i386 boot > Default: 0:ad(0,a)/boot/kernel/kernel > boot: > > ...and I'm at a boot prompt. You're at the boot0 stage. The bootstrap stage looks wrong: this should be 0:ad(0,a)/boot/loader, not /boot/kernel/kernel. You should load the kernel from boot2/loader, not boot0. After you powered off the system, did you physically remove the ad0 disk, or is it still in the system? I would recommend taking ad0 out of the picture (power down the machine and physically unplug it), and make sure your BIOS is set to boot from the first hard disk *and* the 2nd hard disk. "Hard disk" in this context means "any disk that's part of the RAID-1 array". You want to make sure your other disks (whatever that thing is on ata0-slave, and the backup disk you have on ad1) *are not* bootable from the BIOS. If they've ever been used as bootable disks in the past, then you should have cleared the MBR on them to ensure they couldn't be booted by the BIOS. What I'm documenting here is the need to make sure that you don't boot the wrong device/disk. I'm talking about what the *BIOS* boots, not the FreeBSD boot0 bootstrap. You should keep the 2nd disk in the RAID-1 mirror connected to its current SATA port; do not move it to what ad0 was connected to. > So, given that ad0 was the failed disk, the bootloader has failed to > find specific boot data on ad0 and dropped me into a boot prompt. Actually, it's reporting an I/O error at a specific LBA, indicating it either can't load the kernel. > I'm tempted to replace the boot line with 0:ad(2,a)/boot/kernel/kernel > or should that be 2:ad(0,a)/boot/kernel/kernel but I'm a little > suspicious of doing anything at this point? I believe you want 0:ad(2,a)/boot/loader, but you'll have to enter this every time unless you follow what I wrote above (re: BIOS disk boot order). > Can anybody offer any guidance of what I can do to restore my system? I > was able to shut down the machine cleanly (shutdown -p now) and despite > the RAID mirror going offline, everything seemed to be behaving normally > (expected I guess given that I just lost some redundancy). > > I'm just that little bit more worried now :-( If the disks are ok, what > on earth could have happened and more importantly, how can I restore > what was an operational system when I shut it down?! At this point you need to make a judgement call: which are you going to spend more time doing: a) futzing around with this weird situation, or b) reinstalling everything and restoring data from backups? If I was in your shoes at this point, I'd probably choose (b) and go with installing 8.1-RC1 using gmirror for the RAID-1 capability. There isn't much else I can say about the issue, other than that proper failure testing may have caught this before it was too late. If there's anything positive to take away from this experience, it's that. :-) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 22:06:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAAB0106564A for ; Thu, 24 Jun 2010 22:06:41 +0000 (UTC) (envelope-from matt@bubblegen.co.uk) Received: from relay.pcl-ipout01.plus.net (relay.pcl-ipout01.plus.net [212.159.7.99]) by mx1.freebsd.org (Postfix) with ESMTP id 56FE18FC19 for ; Thu, 24 Jun 2010 22:06:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC5zI0zUnw4T/2dsb2JhbACDHZ0OsSqRIYEpgTuBTXAE Received: from outmx06.plus.net (HELO outmx04.plus.net) ([212.159.14.19]) by relay.pcl-ipout01.plus.net with ESMTP; 24 Jun 2010 23:06:40 +0100 Received: from bubblegen.plus.com ([80.229.236.194] helo=[192.136.1.18]) by outmx04.plus.net with esmtp (Exim) id 1ORuZD-0000yJ-IJ; Thu, 24 Jun 2010 23:06:39 +0100 From: Matthew Lear To: Jeremy Chadwick In-Reply-To: <20100624181535.GA58443@icarus.home.lan> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> <20100624181535.GA58443@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 Jun 2010 23:06:22 +0100 Message-ID: <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 22:06:42 -0000 On Thu, 2010-06-24 at 11:15 -0700, Jeremy Chadwick wrote: > On Thu, Jun 24, 2010 at 06:52:14PM +0100, Matthew Lear wrote: > > On Tue, 2010-06-22 at 20:04 +0100, Bob Bishop wrote: > > > Hi, > > > > > > On 22 Jun 2010, at 08:45, Jeremy Chadwick wrote: > > > > > > > On Mon, Jun 21, 2010 at 10:33:12PM +0100, Matthew Lear wrote: > > > >> [tale of woe elided] > > > > > > > > I don't really have any other thoughts on the matter, sadly. > > > > [helpful suggestions elided] > > > > > > > > Anyone else have ideas/recommendations? > > > > > > The disks sure look OK. I wouldn't rule out the controller(s), I've had various chipsets fail in odd ways. > > > > > > > Thanks Bob. I think we all thought the same. > > I've actually just rebooted the machine and FreeBSD no longer boots. > > This isn't what I was expecting at all. Something has clearly gone wrong > > with some file system metadata. > > > > When I commissioned the machine I installed an 'early' bootloader > > (apologies for perhaps using an incorrect term) which boots FreeBSD by > > default (F1 option) or from Drive 1 (F5). Drive 1 is the DVD drive. > > I believe this is the boot0 stage of the FreeBSD bootstrap process, > otherwise known as "BootMgr" during the OS installation. I tend to > avoid this and pick "Standard" instead, which lets the system boot right > into boot2/loader. > > > It appears to be the case that the early bootloader tries to boot > > FreeBSD and fails. I get the messages: > > > > error 1 lba 795079 > > Invalid format > > > > FreeBSD/i386 boot > > Default: 0:ad(0,a)/boot/kernel/kernel > > boot: > > error 1 lba 786815 > > No /boot/kernel/kernel > > > > FreeBSD/i386 boot > > Default: 0:ad(0,a)/boot/kernel/kernel > > boot: > > > > ...and I'm at a boot prompt. > > You're at the boot0 stage. The bootstrap stage looks wrong: this should > be 0:ad(0,a)/boot/loader, not /boot/kernel/kernel. You should load the > kernel from boot2/loader, not boot0. > > After you powered off the system, did you physically remove the ad0 > disk, or is it still in the system? > It's still in the system. Given that the disk is ok relative to SMART, I was of the [probably naive] assumption that I'd be able to boot up normally, access the array on ar0, re-sync the array and carry on as normal monitoring any further errors. > I would recommend taking ad0 out of the picture (power down the machine > and physically unplug it), and make sure your BIOS is set to boot from > the first hard disk *and* the 2nd hard disk. "Hard disk" in this > context means "any disk that's part of the RAID-1 array". You want to > make sure your other disks (whatever that thing is on ata0-slave, and > the backup disk you have on ad1) *are not* bootable from the BIOS. If > they've ever been used as bootable disks in the past, then you should > have cleared the MBR on them to ensure they couldn't be booted by the > BIOS. Understood. > > What I'm documenting here is the need to make sure that you don't boot > the wrong device/disk. I'm talking about what the *BIOS* boots, not the > FreeBSD boot0 bootstrap. > > You should keep the 2nd disk in the RAID-1 mirror connected to its > current SATA port; do not move it to what ad0 was connected to. > > > So, given that ad0 was the failed disk, the bootloader has failed to > > find specific boot data on ad0 and dropped me into a boot prompt. > > Actually, it's reporting an I/O error at a specific LBA, indicating it > either can't load the kernel. > > > I'm tempted to replace the boot line with 0:ad(2,a)/boot/kernel/kernel > > or should that be 2:ad(0,a)/boot/kernel/kernel but I'm a little > > suspicious of doing anything at this point? > > I believe you want 0:ad(2,a)/boot/loader, but you'll have to enter this > every time unless you follow what I wrote above (re: BIOS disk boot > order). Again, all understood. I gave this a whirl and saw several ad0 timeout messages at various LBA, the system boot up hung and dropped me into single user mode. atacontrol list showed no devices attached to channel 0 which I thought was rather odd. I've no idea if this is indicative of a hw failure or not. Further investigation is required. > > Can anybody offer any guidance of what I can do to restore my system? I > > was able to shut down the machine cleanly (shutdown -p now) and despite > > the RAID mirror going offline, everything seemed to be behaving normally > > (expected I guess given that I just lost some redundancy). > > > > I'm just that little bit more worried now :-( If the disks are ok, what > > on earth could have happened and more importantly, how can I restore > > what was an operational system when I shut it down?! > > At this point you need to make a judgement call: which are you going to > spend more time doing: a) futzing around with this weird situation, or > b) reinstalling everything and restoring data from backups? > > If I was in your shoes at this point, I'd probably choose (b) and go > with installing 8.1-RC1 using gmirror for the RAID-1 capability. That's probably fair enough but I'm of the opinion that I'd like to know what has happened (or rather what FreeBSD has done) to my machine. Given that the apparently faulty disk is not faulty, something (or probably more accurately, the OS) has written some absolute LBA values to disk with the intent of accessing these. Yes the disk has indicated that there is an error but as to why, well that's the question :-) IMO it's all fine and well saying upgrade to the next stable release but that's not actually finding the cause and trying to resolve the problem in a sensible manner. I'm fortunate enough that I can easily handle a bit of down time on the machine. You're absolutely right in saying that the set up should have been tested prior to commissioning. I agree completely. However, it's a server that I run at home, I'm not an IT admin, I don't mind getting my hands dirty and do try to learn from experience - hopefully! :-) > There isn't much else I can say about the issue, other than that proper > failure testing may have caught this before it was too late. If there's > anything positive to take away from this experience, it's that. :-) > Absolutely. From owner-freebsd-stable@FreeBSD.ORG Thu Jun 24 22:22:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64017106566C for ; Thu, 24 Jun 2010 22:22:43 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 10E6C8FC17 for ; Thu, 24 Jun 2010 22:22:42 +0000 (UTC) Received: by vws13 with SMTP id 13so3073297vws.13 for ; Thu, 24 Jun 2010 15:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=1PMEWGFmw0SWYmM2hPE46GKVbpkUrvfmYRV6cK3HMVY=; b=XktsRj4NBiO0vOPSOUS46zAcxdYUxva8MEUouN7HoJn8/wQop6yP6Kb5MbL6+2DWiG oR09kd7lPZLDdcJja/FNDeGXH56mvbwK3cO4K8i57UYM3+7xwkxPjjIpRfmIt6JhE6NY PQ0R1G+96wQS+TWkmvk94RvzNkeKTuSPz0Oc4= 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; b=no/VnM0KEMIeskGZa6rUv2tm6FNuTNMGiKhnHnoO6/D1dm2wtRkIkd5mGWZqHNMtN2 Gkfn+b1ZRezig+8pzh2jj+KoOuHHVLMAfJ3gd9z7SEtcntUNpFO3XGgOQBcWLHF79f/7 WxMiZ/q4FqFEhYZOxxcpnFKBmOwuoT0um8aDY= MIME-Version: 1.0 Received: by 10.224.88.25 with SMTP id y25mr2494756qal.226.1277418161900; Thu, 24 Jun 2010 15:22:41 -0700 (PDT) Received: by 10.229.82.70 with HTTP; Thu, 24 Jun 2010 15:22:41 -0700 (PDT) In-Reply-To: <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> References: <1276844904.7519.19.camel@almscliff.bubblegen.co.uk> <20100618082127.GA34578@icarus.home.lan> <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> <20100624181535.GA58443@icarus.home.lan> <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> Date: Thu, 24 Jun 2010 17:22:41 -0500 Message-ID: From: Adam Vande More To: Matthew Lear , Jeremy Chadwick , freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 22:22:43 -0000 Haven't followed the entire thread, but wanted to point out something important to remember. SMART is not a reliable indicator of failure. It's certainly better than listening to it but it picks up less than 1/2 of drive failures. Google released a study of their disks in data centers a few years ago that was fairly in depth look into drive failure rate. You might find it interesting. On 6/24/10, Matthew Lear wrote: > On Thu, 2010-06-24 at 11:15 -0700, Jeremy Chadwick wrote: >> On Thu, Jun 24, 2010 at 06:52:14PM +0100, Matthew Lear wrote: >> > On Tue, 2010-06-22 at 20:04 +0100, Bob Bishop wrote: >> > > Hi, >> > > >> > > On 22 Jun 2010, at 08:45, Jeremy Chadwick wrote: >> > > >> > > > On Mon, Jun 21, 2010 at 10:33:12PM +0100, Matthew Lear wrote: >> > > >> [tale of woe elided] >> > > > >> > > > I don't really have any other thoughts on the matter, sadly. >> > > > [helpful suggestions elided] >> > > > >> > > > Anyone else have ideas/recommendations? >> > > >> > > The disks sure look OK. I wouldn't rule out the controller(s), I've >> > > had various chipsets fail in odd ways. >> > > >> > >> > Thanks Bob. I think we all thought the same. >> > I've actually just rebooted the machine and FreeBSD no longer boots. >> > This isn't what I was expecting at all. Something has clearly gone wrong >> > with some file system metadata. >> > >> > When I commissioned the machine I installed an 'early' bootloader >> > (apologies for perhaps using an incorrect term) which boots FreeBSD by >> > default (F1 option) or from Drive 1 (F5). Drive 1 is the DVD drive. >> >> I believe this is the boot0 stage of the FreeBSD bootstrap process, >> otherwise known as "BootMgr" during the OS installation. I tend to >> avoid this and pick "Standard" instead, which lets the system boot right >> into boot2/loader. >> >> > It appears to be the case that the early bootloader tries to boot >> > FreeBSD and fails. I get the messages: >> > >> > error 1 lba 795079 >> > Invalid format >> > >> > FreeBSD/i386 boot >> > Default: 0:ad(0,a)/boot/kernel/kernel >> > boot: >> > error 1 lba 786815 >> > No /boot/kernel/kernel >> > >> > FreeBSD/i386 boot >> > Default: 0:ad(0,a)/boot/kernel/kernel >> > boot: >> > >> > ...and I'm at a boot prompt. >> >> You're at the boot0 stage. The bootstrap stage looks wrong: this should >> be 0:ad(0,a)/boot/loader, not /boot/kernel/kernel. You should load the >> kernel from boot2/loader, not boot0. >> >> After you powered off the system, did you physically remove the ad0 >> disk, or is it still in the system? >> > > It's still in the system. Given that the disk is ok relative to SMART, I > was of the [probably naive] assumption that I'd be able to boot up > normally, access the array on ar0, re-sync the array and carry on as > normal monitoring any further errors. > >> I would recommend taking ad0 out of the picture (power down the machine >> and physically unplug it), and make sure your BIOS is set to boot from >> the first hard disk *and* the 2nd hard disk. "Hard disk" in this >> context means "any disk that's part of the RAID-1 array". You want to >> make sure your other disks (whatever that thing is on ata0-slave, and >> the backup disk you have on ad1) *are not* bootable from the BIOS. If >> they've ever been used as bootable disks in the past, then you should >> have cleared the MBR on them to ensure they couldn't be booted by the >> BIOS. > > Understood. > >> >> What I'm documenting here is the need to make sure that you don't boot >> the wrong device/disk. I'm talking about what the *BIOS* boots, not the >> FreeBSD boot0 bootstrap. >> >> You should keep the 2nd disk in the RAID-1 mirror connected to its >> current SATA port; do not move it to what ad0 was connected to. >> >> > So, given that ad0 was the failed disk, the bootloader has failed to >> > find specific boot data on ad0 and dropped me into a boot prompt. >> >> Actually, it's reporting an I/O error at a specific LBA, indicating it >> either can't load the kernel. >> >> > I'm tempted to replace the boot line with 0:ad(2,a)/boot/kernel/kernel >> > or should that be 2:ad(0,a)/boot/kernel/kernel but I'm a little >> > suspicious of doing anything at this point? >> >> I believe you want 0:ad(2,a)/boot/loader, but you'll have to enter this >> every time unless you follow what I wrote above (re: BIOS disk boot >> order). > > Again, all understood. I gave this a whirl and saw several ad0 timeout > messages at various LBA, the system boot up hung and dropped me into > single user mode. atacontrol list showed no devices attached to channel > 0 which I thought was rather odd. I've no idea if this is indicative of > a hw failure or not. Further investigation is required. > >> > Can anybody offer any guidance of what I can do to restore my system? I >> > was able to shut down the machine cleanly (shutdown -p now) and despite >> > the RAID mirror going offline, everything seemed to be behaving normally >> > (expected I guess given that I just lost some redundancy). >> > >> > I'm just that little bit more worried now :-( If the disks are ok, what >> > on earth could have happened and more importantly, how can I restore >> > what was an operational system when I shut it down?! >> >> At this point you need to make a judgement call: which are you going to >> spend more time doing: a) futzing around with this weird situation, or >> b) reinstalling everything and restoring data from backups? >> >> If I was in your shoes at this point, I'd probably choose (b) and go >> with installing 8.1-RC1 using gmirror for the RAID-1 capability. > > That's probably fair enough but I'm of the opinion that I'd like to know > what has happened (or rather what FreeBSD has done) to my machine. Given > that the apparently faulty disk is not faulty, something (or probably > more accurately, the OS) has written some absolute LBA values to disk > with the intent of accessing these. Yes the disk has indicated that > there is an error but as to why, well that's the question :-) > > IMO it's all fine and well saying upgrade to the next stable release but > that's not actually finding the cause and trying to resolve the problem > in a sensible manner. I'm fortunate enough that I can easily handle a > bit of down time on the machine. You're absolutely right in saying that > the set up should have been tested prior to commissioning. I agree > completely. However, it's a server that I run at home, I'm not an IT > admin, I don't mind getting my hands dirty and do try to learn from > experience - hopefully! :-) > >> There isn't much else I can say about the issue, other than that proper >> failure testing may have caught this before it was too late. If there's >> anything positive to take away from this experience, it's that. :-) >> > > Absolutely. > > _______________________________________________ > 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" > -- Sent from my mobile device Adam Vande More From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 05:26:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05CE0106564A for ; Fri, 25 Jun 2010 05:26:19 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE2B8FC13 for ; Fri, 25 Jun 2010 05:26:18 +0000 (UTC) Received: (qmail 77050 invoked by uid 0); 25 Jun 2010 05:26:17 -0000 Received: from unknown (HELO ?10.3.2.41?) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Jun 2010 05:26:17 -0000 Date: Fri, 25 Jun 2010 01:26:16 -0400 (EDT) From: Charles Sprickman To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: amd64 mainboard compatibility list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 05:26:19 -0000 While trying to find how not to get burned like we did with some older oddball Supermicro boards, I came across this page: http://www.freebsd.org/platforms/amd64/motherboards.html There is a request up top for new submissions (there are no 8.x entries), is feedback still wanted? If so, I've got a number of "bad" boards to add. I cannot stress enough how great it would be if this were updated. I'm server shopping at the moment and after running into various SMP and ACPI issues on some SM boards, I'm quite nervous about committing to any particular model or brand. Thanks, Charles From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 06:43:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36604106566B for ; Fri, 25 Jun 2010 06:43:41 +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 F1D568FC0A for ; Fri, 25 Jun 2010 06:43:40 +0000 (UTC) Received: from baby-jane.lamaiziere.net (unknown [192.168.1.10]) by smtp.lamaiziere.net (Postfix) with ESMTP id 5ACB763307D for ; Fri, 25 Jun 2010 08:43:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id F312D2CEDB0 for ; Fri, 25 Jun 2010 08:44:27 +0200 (CEST) Date: Fri, 25 Jun 2010 08:44:26 +0200 From: Patrick Lamaiziere To: freebsd-stable@freebsd.org Message-ID: <20100625084426.27325876@davenulle.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Subject: MFC for Easy Editor (ee) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 06:43:41 -0000 Hello, Accentued and 8 bits characters are broken in ee(1) since 8.0. This is fixed in HEAD in rev 196750, is it possible to mfc the fix? http://svn.freebsd.org/viewvc/base/head/contrib/ee/?view=log&pathrev=196750 The patch applies on 8.0 and works fine here. Thanks, regards. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 07:16:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14591065672 for ; Fri, 25 Jun 2010 07:16:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id 88B2C8FC1C for ; Fri, 25 Jun 2010 07:16:47 +0000 (UTC) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta09.westchester.pa.mail.comcast.net with comcast id a7Gm1e00127AodY597GneS; Fri, 25 Jun 2010 07:16:47 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.westchester.pa.mail.comcast.net with comcast id a7Gm1e0023S48mS3f7Gmei; Fri, 25 Jun 2010 07:16:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0A3219B425; Fri, 25 Jun 2010 00:16:45 -0700 (PDT) Date: Fri, 25 Jun 2010 00:16:45 -0700 From: Jeremy Chadwick To: Adam Vande More Message-ID: <20100625071644.GA75910@icarus.home.lan> References: <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> <20100624181535.GA58443@icarus.home.lan> <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Matthew Lear , freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 07:16:48 -0000 On Thu, Jun 24, 2010 at 05:22:41PM -0500, Adam Vande More wrote: > Haven't followed the entire thread, but wanted to point out something > important to remember. SMART is not a reliable indicator of failure. > It's certainly better than listening to it but it picks up less than > 1/2 of drive failures. Google released a study of their disks in data > centers a few years ago that was fairly in depth look into drive > failure rate. You might find it interesting. Anyone who relies on "overall SMART health" to determine the status of a drive will be disappointed when they see what thresholds vendors are choosing for most attributes. But that's as far as I'll go when it comes to agreeing with the "SMART is not a reliable indicator of X" argument. Due to vendors choosing what they do, it's best to use SMART as an indicator of overall drive health *at that moment* and not as a predictive form (though I have seen it work in this case successfully, especially on SCSI disks. I'd be more than happy to provide some examples if need be). Google's study was half-ass in some regards (I remember reading it and feeling left with more questions than answers), and I'm also aware of folks like Scott Moulton who insist SMART is an unreliable method of analysis. I like Scott's work in general, but I disagree with his view of SMART. You can see some of his presentations on Youtube; look up "Shmoocon 2010 DIY Hard Drive Diagnostics". We've already done the SMART analysis for this issue -- the disk isn't showing any signs of problems from a SMART perspective. Meaning, there's no indication of bad or reallocated sectors, or any other signs of internal drive failure. There's a lot of things SMART can't catch -- drive PCB flakiness (appears as literally anything, take your pick), drive cache going bad (usually shows itself as abysmal performance), or power-related problems (though SMART can help catch this by watching at Attributes 4 and 12, assuming the drive is losing power entirely; if there's dirty power or excessive ripple, or internal drive power circuitry problems, these can appear as practically anything). All in all, replacing a drive is a completely reasonable action when there's evidence confirming the need for its replacement. I don't like replacing hardware when there's no indication replacing it will necessarily fix the problem; I'd rather understand the problem. Matthew, if you're able to take the system down for 2-3 hours, I would recommend downloading Western Digital's Data Lifeguard Diagnostics software (for DOS; you'll need a CD burner to burn the ISO) and running that on your drive. If that fails on a Long/Extended test, yep, replace the disk. Said utility tests a lot more than just SMART. If it passes the test, then we're back at square one, and you can try replacing the disk if you'd like (then boot from the 2nd disk in the RAID-1 array). My concern is that replacing it isn't going to fix anything (meaning you might have a SATA port that's going bad or the controller itself is broken). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 07:53:32 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97FAE106564A for ; Fri, 25 Jun 2010 07:53:32 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from mail.math.leidenuniv.nl (mail.math.leidenuniv.nl [132.229.231.57]) by mx1.freebsd.org (Postfix) with ESMTP id 3C41D8FC12 for ; Fri, 25 Jun 2010 07:53:31 +0000 (UTC) Received: from [132.229.231.13] (polaris.math.leidenuniv.nl [132.229.231.13]) by mail.math.leidenuniv.nl (Postfix) with ESMTP id 3527E6EEAC; Fri, 25 Jun 2010 09:53:30 +0200 (CEST) From: Marten Vijn To: Alex Markelov In-Reply-To: <4326E32B-9C38-4C7C-BDB1-8FFF1247C6B4@gmail.com> References: <4326E32B-9C38-4C7C-BDB1-8FFF1247C6B4@gmail.com> Content-Type: text/plain Date: Fri, 25 Jun 2010 09:53:30 +0200 Message-Id: <1277452410.29418.6.camel@polaris> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Is there known problem with USB flash readers? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 07:53:32 -0000 On Thu, 2010-06-24 at 11:47 +0100, Alex Markelov wrote: > Hi Guys! > > I have a strange problem with my flash card reader when dd'ing NanoBSD > images onto a CF card. It works for some time (3-4 writes of images), > then I start getting scsi error messages and dd hangs. I have to > disconnect/re-connect the reader to be able to write to CF again, but > sometimes even this trick doesn't work. > > One day it stopped working for me and since I had a deadline to meet, > went to local shop and bought another one (different model and brand). > It worked fine for few write iterations and then it developed the same > problem. When I decided (out of desperation) to try the old one again, > it worked. So, I ended up using the two and swapping between it when > either of the units stopped working. > > First thing I though that it might be the size of the image (2 or 4GB) > that I was writing with dd and it was heating up the electronics, but > yesterday a friend of mine stumbled upon the same problem and when his > flash reader (different brand and model to mine) stopped working, he > unplugged it from the FreeBSD box, plugged it in into his Linux laptop > and it worked without a problem. In his view it laid to rest my theory > about components heating too much as he did it without giving it a > minute of rest. > > I vaguely recall there were problems with USB support in stable some > time ago, but I thought it was all fixed and searching the list and > the Internet doesn't give me anything. > > Both of us were using 7-stable. I can email model of the card readers > later (not home at the moment). > > Basically, I have two questions: > 1) is it something that well known and not model related > 2) is there a well known reliable model of card reader I can buy. I > don't mind the price if the device is rock solid. > > Any pointers/ideas are greatly appreciated! I have been using 8 (with new USB support) and haven't had issues with for the last year. A possible workaround coud be using pxeboot and install flashcard from unother device avoiding usb. (i use mfsbsd for this). Maybe getting more info would to diagnose (dmesg, and maybe a ktrace of the dd. 2ct, Marten > Regards, > Alex. > -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 08:00:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 050BC106564A for ; Fri, 25 Jun 2010 08:00:50 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id D8C698FC13 for ; Fri, 25 Jun 2010 08:00:49 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o5P80nQw065787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 Jun 2010 01:00:49 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o5P80mta065786; Fri, 25 Jun 2010 01:00:48 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA27579; Fri, 25 Jun 10 00:52:45 PDT Date: Fri, 25 Jun 2010 00:49:05 -0700 From: perryh@pluto.rain.com To: freebsd@jdc.parodius.com Message-Id: <4c245f71.A0/bvg7lQ9M7U7YS%perryh@pluto.rain.com> References: <20100623105441.7cab13b2@nomos> <20100623160524.GA19859@icarus.home.lan> In-Reply-To: <20100623160524.GA19859@icarus.home.lan> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Mouse appears on screen but does not move X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 08:00:50 -0000 Jeremy Chadwick wrote: > The tag= line for ports should always be . (period, indicating > HEAD) ... "always" is a bit too strong here IMO. The tag= line for ports could reasonably be a release label, if the intent is to retrieve the ports tree as of that release; granted this would be an uncommon situation. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 09:00:11 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC5681065676 for ; Fri, 25 Jun 2010 09:00:11 +0000 (UTC) (envelope-from lioux@FreeBSD.org) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F8DB8FC1F for ; Fri, 25 Jun 2010 09:00:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id 7A3005C99 for ; Fri, 25 Jun 2010 02:00:08 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id jjn50Zc2v0yJ for ; Fri, 25 Jun 2010 02:00:08 -0700 (PDT) Received: from 189.72.155.250 (189-72-155-250.bsace702.dsl.brasiltelecom.net.br [189.72.155.250]) by goat.gigo.com (Postfix) with ESMTPSA id 2CA9D5C94 for ; Fri, 25 Jun 2010 02:00:07 -0700 (PDT) Received: (qmail 94162 invoked by uid 1001); 25 Jun 2010 05:54:04 -0300 Message-ID: <20100625085404.94155.qmail@exxodus.fedaykin.here> Date: Fri, 25 Jun 2010 05:54:04 -0300 From: Mario Sergio Fujikawa Ferreira To: Jung-uk Kim References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231510.50863.jkim@FreeBSD.org> <201006231538.27887.jkim@FreeBSD.org> <201006231708.40032.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201006231708.40032.jkim@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: d@delphij.net, freebsd-stable@FreeBSD.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 09:00:14 -0000 On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote: > Date: Wed, 23 Jun 2010 17:08:38 -0400 > From: Jung-uk Kim > To: freebsd-stable@FreeBSD.org > Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira > Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl > ffffffff8004667e > User-Agent: KMail/1.6.2 > > On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote: > > On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote: > > > On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote: > > > > On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: > > > > > On 2010/06/23 11:37, Jung-uk Kim wrote: > > > > > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > > > > > >> Hi, > > > > > >> > > > > > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > > > > > >>> Hi, > > > > > >>> > > > > > >>> I am getting more than 4 thousand of the following > > > > > >>> messages a day: > > > > > >>> > > > > > >>> WARNING pid 24509 (python2.6): ioctl sign-extension ioctl > > > > > >>> ffffffff8004667e > > > > > >> > > > > > >> [...] > > > > > >> > > > > > >> I think we may need to check the code and patch it. > > > > > >> Basically this means that python (or some .so modules) > > > > > >> passed an int or unsigned int as parameter 'cmd', we need > > > > > >> to change it to unsigned long. > > > > > >> > > > > > >> The warning itself should be harmless to my best of > > > > > >> knowledge, one can probably remove the printf in kernel > > > > > >> source code as a workaround. > > > > > >> > > > > > >> By the way it seems to be a POSIX violation and we didn't > > > > > >> seem to really use so wide cmd, but I have not yet > > > > > >> verified everything myself. > > > > > > > > > > > > Long time ago, I had a similar problem with termios > > > > > > TIOCGWINSZ and we patched the port like this: > > > > > > > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python/fil > > > > > >es /A tt > > > > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-type=te > > > > > >xt %2 Fpl ain > > > > > > > > > > > > I believe it was upstream patched at the time but I won't > > > > > > be surprised if something similar was reintroduced. It > > > > > > happens when a Python internal integer type is converted to > > > > > > a native unsigned long. > > > > > > > > > > Well, only *BSD have cmd a long value so it's likely that it > > > > > would be reintroduced. > > > > > > > > Yes, that's what I mean. > > > > > > > > > I have checked the 4.4BSD archive and understood that our > > > > > ioctl's cmd parameter was made long around 1991 or 1992s but > > > > > didn't see what it actually buy us... > > > > > > > > Like it or not, it is too late to revert. :-( > > > > > > From Python 2.6.5: > > > > > > static PyObject * > > > fcntl_ioctl(PyObject *self, PyObject *args) > > > { > > > #define IOCTL_BUFSZ 1024 > > > int fd; > > > /* In PyArg_ParseTuple below, we use the unsigned non-checked > > > 'I' format for the 'code' parameter because Python turns > > > 0x8000000 into either a large positive number (PyLong or PyInt on > > > 64-bit platforms) or a negative number on others (32-bit PyInt) > > > whereas the system expects it to be a 32bit bit field value > > > regardless of it being passed as an int or unsigned long on > > > various platforms. See the termios.TIOCSWINSZ constant across > > > platforms for an example of thise. > > > > > > If any of the 64bit platforms ever decide to use more than > > > 32bits in their unsigned long ioctl codes this will break and > > > need special casing based on the platform being built on. > > > */ > > > unsigned int code; > > > ... > > > > > > It is still a kludge and it won't be fixed. :-( > > > > Please drop the attached patch in ports/lang/python26/files and > > test. Note I am not a Python guy, so please don't shoot me. ;-) > > I found that Python guys added 'k' format since 2.3, which converts a > Python integer to unsigned long. Please ignore the previous patch > and try the attached patch instead. Unfortunately it didn't work. 1) Added patch to lang/python26 2) Recompiled lang/python26 3) cd /var/db/ports && portupgrade -f python* py26* deluge* Restarted deluge afterwards. The message is still there: Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6): ioctl sign-extension ioctl ffffffff8004667e Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 12:13:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F7EA106564A for ; Fri, 25 Jun 2010 12:13:39 +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 B453E8FC16 for ; Fri, 25 Jun 2010 12:13:38 +0000 (UTC) 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 PAA24854; Fri, 25 Jun 2010 15:13:21 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4C249D60.2050103@icyb.net.ua> Date: Fri, 25 Jun 2010 15:13:20 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100517) MIME-Version: 1.0 To: Charles Sprickman References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: amd64 mainboard compatibility list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 12:13:39 -0000 on 25/06/2010 08:26 Charles Sprickman said the following: > While trying to find how not to get burned like we did with some older > oddball Supermicro boards, I came across this page: > > http://www.freebsd.org/platforms/amd64/motherboards.html > > There is a request up top for new submissions (there are no 8.x > entries), is feedback still wanted? If so, I've got a number of "bad" > boards to add. It seems that the list is very outdated and not actively maintained. > I cannot stress enough how great it would be if this were updated. I'm > server shopping at the moment and after running into various SMP and > ACPI issues on some SM boards, I'm quite nervous about committing to any > particular model or brand. Nowadays it is generally expected that any amd64 system should just work. Well, that should be "almost any", or "typical". There is nothing special about amd64 anymore. In certain aspects it's even "better" than i386. So, if something doesn't properly work, then it's "just" a bug that should be appropriately reported. Just in case. Were the problems that you encountered amd64-specific? I.e. did they _not_ happen when you tried i386? -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 12:31:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 229761065674 for ; Fri, 25 Jun 2010 12:31:01 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 091DC8FC18 for ; Fri, 25 Jun 2010 12:31:00 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta11.emeryville.ca.mail.comcast.net with comcast id aBfA1e00F0FhH24ABCX0V0; Fri, 25 Jun 2010 12:31:00 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id aCWy1e0073S48mS8UCWzz4; Fri, 25 Jun 2010 12:31:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 9FA839B425; Fri, 25 Jun 2010 05:30:58 -0700 (PDT) Date: Fri, 25 Jun 2010 05:30:58 -0700 From: Jeremy Chadwick To: Andriy Gapon Message-ID: <20100625123058.GA85800@icarus.home.lan> References: <4C249D60.2050103@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C249D60.2050103@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Charles Sprickman , freebsd-stable@freebsd.org Subject: Re: amd64 mainboard compatibility list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 12:31:01 -0000 On Fri, Jun 25, 2010 at 03:13:20PM +0300, Andriy Gapon wrote: > on 25/06/2010 08:26 Charles Sprickman said the following: > > While trying to find how not to get burned like we did with some older > > oddball Supermicro boards, I came across this page: > > > > http://www.freebsd.org/platforms/amd64/motherboards.html > > > > There is a request up top for new submissions (there are no 8.x > > entries), is feedback still wanted? If so, I've got a number of "bad" > > boards to add. > > It seems that the list is very outdated and not actively maintained. Bummer. > > I cannot stress enough how great it would be if this were updated. I'm > > server shopping at the moment and after running into various SMP and > > ACPI issues on some SM boards, I'm quite nervous about committing to any > > particular model or brand. > > Nowadays it is generally expected that any amd64 system should just work. Well, > that should be "almost any", or "typical". There is nothing special about amd64 > anymore. In certain aspects it's even "better" than i386. So, if something > doesn't properly work, then it's "just" a bug that should be appropriately reported. FWIW, I agree with Andriy. If there's a specific model or series of Supermicro boards which are experiencing SMP or ACPI problems, reporting them officially (either via a PR or here on the appropriate mailing lists) would be highly beneficial. If the issues are FreeBSD-related ("7.x works fine, 8.x doesn't!") then I'm sure we can find the correct resources to track down the problem. Also, if the issues turn out to be ACPI-table-related, reporting the issue to Supermicro (and involving them in the debugging and assistance process) would be equally as beneficial. I do have some contacts at Supermicro who handle BIOS issues. I'll follow this thread closely and reach out to them if need be. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 15:20:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11577106564A for ; Fri, 25 Jun 2010 15:20:31 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id B14708FC0A for ; Fri, 25 Jun 2010 15:20:29 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 692273A6A4 for ; Fri, 25 Jun 2010 19:20:27 +0400 (MSD) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on skuns.gsm900.net Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 4B47F3A69E for ; Fri, 25 Jun 2010 19:20:27 +0400 (MSD) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id 15D023A69A for ; Fri, 25 Jun 2010 19:20:27 +0400 (MSD) Date: Fri, 25 Jun 2010 19:20:27 +0400 From: alexs@ulgsm.ru To: freebsd-stable@freebsd.org Message-ID: <20100625152027.GA78442@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Subject: diskless boot, nfs server behind router X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 15:20:31 -0000 Hi all. I tryed setup server for booting diskless hosts from different networks. In one network booting is ok. I see thet realtek 8139 pxe can`t load pxeboot file fromi tftp server from another network. By changing options in dhcp server, i resolve that pxeboot can load kernel from this server, but than kernel trying mount nfs root file system its failing. Later mounting from /etc/fstab is ok. Maybe im wrong? but diskless booting in several networks possible ony using several servers, one in each network? I think pxe rom on nic and kernel nfs root mounting can`t work on 3-layer. p.s. diskless freebsd 7.1 server freebsd 8.1Pre -- alexs From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 16:15:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13A67106564A for ; Fri, 25 Jun 2010 16:15:25 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 97ED68FC18 for ; Fri, 25 Jun 2010 16:15:24 +0000 (UTC) Received: by fxm13 with SMTP id 13so77977fxm.13 for ; Fri, 25 Jun 2010 09: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:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9JVkgG0zO+39sqEHs4QfWRAcU6mD1nkf+JXKVpm8S+4=; b=uXVYGu9+HlVUdeHBCEmeyM9TBcmrRdCNT6VCLuUngpphHE5gg+h2yi11cnXdNGChPd kQ2Cp922Q3mrP3UReMyfekOsQwPkNNTHfFkNO9CdnuBvGh6xQ8AyMm8bF3HNP+L7BIsl 3tRPcbgM87w6C0sV4ys8na8bzjZvt1RCmylq8= 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=lwoTpFAuJiyAwOiF0NgHpkdWTypTyEfceAosjrgsI3Dx3q4XbILvrhHFlRYxK6qz+r wiBnhgikpbdIoLQmpfHmYj2SvgpMGbl0t5rKq4S9AyXq4Lp1SGk0g1GY3mSVSIR8gSy/ sgwIhlXf7GiY+moVtre5q08kBewhLDh4GggjA= MIME-Version: 1.0 Received: by 10.239.183.84 with SMTP id t20mr67255hbg.54.1277482523311; Fri, 25 Jun 2010 09:15:23 -0700 (PDT) Received: by 10.239.142.20 with HTTP; Fri, 25 Jun 2010 09:15:23 -0700 (PDT) In-Reply-To: <4C249D60.2050103@icyb.net.ua> References: <4C249D60.2050103@icyb.net.ua> Date: Fri, 25 Jun 2010 12:15:23 -0400 Message-ID: From: Mehmet Erol Sanliturk To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Charles Sprickman , freebsd-stable@freebsd.org Subject: Re: amd64 mainboard compatibility list X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:15:25 -0000 On Fri, Jun 25, 2010 at 8:13 AM, Andriy Gapon wrote: > on 25/06/2010 08:26 Charles Sprickman said the following: > > While trying to find how not to get burned like we did with some older > > oddball Supermicro boards, I came across this page: > > > > http://www.freebsd.org/platforms/amd64/motherboards.html > > > > There is a request up top for new submissions (there are no 8.x > > entries), is feedback still wanted? If so, I've got a number of "bad" > > boards to add. > > It seems that the list is very outdated and not actively maintained. > > > I cannot stress enough how great it would be if this were updated. I'm > > server shopping at the moment and after running into various SMP and > > ACPI issues on some SM boards, I'm quite nervous about committing to any > > particular model or brand. > > Nowadays it is generally expected that any amd64 system should just work. > Well, > that should be "almost any", or "typical". There is nothing special about > amd64 > anymore. In certain aspects it's even "better" than i386. So, if > something > doesn't properly work, then it's "just" a bug that should be appropriately > reported. > > Just in case. Were the problems that you encountered amd64-specific? I.e. > did > they _not_ happen when you tried i386? > > -- > Andriy Gapon > _____________ > In the following page , http://www.asus.com/ContentPage.aspx?Content_Type=staticwebpage&Global=1&Content_Id=26 there is a link : http://www.asus.com/websites/global/aboutasus/OS/Linux.pdf In the Linux.pdf , there is a list of ASUS main boards tested and listed for Linux compatibility . Unfortunately , I do not know any FreeBSD related list which contains latest available boards tested for FreeBSD . At least , the above list gives an idea about possible board selections . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 16:33:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B62F21065673; Fri, 25 Jun 2010 16:33:03 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 7CC6A8FC1B; Fri, 25 Jun 2010 16:33:03 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 5F82378C3B; Sat, 26 Jun 2010 01:33:02 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 4D56178C34; Sat, 26 Jun 2010 01:33:02 +0900 (JST) Message-ID: <1931AE1113EC4A8983B8A52A2A1966C2@ad.peach.ne.jp> From: "Daisuke Aoyama" To: References: In-Reply-To: Date: Sat, 26 Jun 2010 01:32:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: iSCSI boot driver version 0.1.1 for iBFT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 16:33:03 -0000 Sorry, isboot-0.1.1 was broken under i386 kernel + loader. The version 0.1.2 is uploaded in my blog. Also I uploaded isboot integrated FreeBSD 7.3 disc1, 8.1-RC1 dics1 and making script. Use at your own risk. You need only iBFT supported NIC and iSCSI target. Please see Intel's site about iBFT supported NIC. http://www.intel.com/support/network/adapter/pro100/sb/CS-028681.htm If you can connect to iSCSI target by NIC BIOS, isboot.ko shows the following log. In this case, em0 is configured automatically with NIC0 parameter in iBFT, and you can install FreeBSD to da1 directly and you can boot from da1. If you want to try to copy existing FreeBSD, then configure NIC and loading isboot.ko via loader.conf or "kldload isboot.ko" from shell. Then, use normal way such as dump/restore. Note: do not set IP to em0 when installation. it might be a problem. --------------------------------------------------------------- iSCSI boot driver version 0.1.2 IS: Initiator name: iqn.2007-09.jp.ne.peach:pluto NIC0: IP address: 192.168.3.48 NIC0: Prefix: 24 NIC0: Gateway: 0.0.0.0 NIC0: MAC address: 00:15:17:97:85:ab TGT0: Target IP address: 192.168.3.36 TGT0: Target Port: 3260 TGT0: Target LUN: 2 TGT0: Target name: iqn.2007-09.jp.ne.peach:isboot1 Boot NIC: em0 Configure IPv4 by NIC0 Attempting to login to iSCSI target and scan all LUNs. ... cut ... da0 at isboot0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C) da1 at isboot0 bus 0 scbus0 target 0 lun 2 da1: Fixed Direct Access SCSI-5 device da1: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) da2 at isboot0 bus 0 scbus0 target 0 lun 3 da2: Fixed Direct Access SCSI-5 device da2: 1024MB (2097152 512 byte sectors: 64H 32S/T 1024C) ... cut ... Boot device: da1 --------------------------------------------------------------- Download links: http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh Try it you self :) Daisuke Aoyama From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 21:59:04 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 634231065673; Fri, 25 Jun 2010 21:59:04 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Fri, 25 Jun 2010 17:58:52 -0400 User-Agent: KMail/1.6.2 References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231708.40032.jkim@FreeBSD.org> <20100625085404.94155.qmail@exxodus.fedaykin.here> In-Reply-To: <20100625085404.94155.qmail@exxodus.fedaykin.here> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201006251758.56393.jkim@FreeBSD.org> Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 21:59:04 -0000 On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira wrote: > On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote: > > Date: Wed, 23 Jun 2010 17:08:38 -0400 > > From: Jung-uk Kim > > To: freebsd-stable@FreeBSD.org > > Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira > > Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING > > ioctl sign-extension ioctl ffffffff8004667e > > User-Agent: KMail/1.6.2 > > > > On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote: > > > On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote: > > > > On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote: > > > > > On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: > > > > > > On 2010/06/23 11:37, Jung-uk Kim wrote: > > > > > > > On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: > > > > > > >> Hi, > > > > > > >> > > > > > > >> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira wrote: > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> I am getting more than 4 thousand of the following > > > > > > >>> messages a day: > > > > > > >>> > > > > > > >>> WARNING pid 24509 (python2.6): ioctl sign-extension > > > > > > >>> ioctl ffffffff8004667e > > > > > > >> > > > > > > >> [...] > > > > > > >> > > > > > > >> I think we may need to check the code and patch it. > > > > > > >> Basically this means that python (or some .so modules) > > > > > > >> passed an int or unsigned int as parameter 'cmd', we > > > > > > >> need to change it to unsigned long. > > > > > > >> > > > > > > >> The warning itself should be harmless to my best of > > > > > > >> knowledge, one can probably remove the printf in > > > > > > >> kernel source code as a workaround. > > > > > > >> > > > > > > >> By the way it seems to be a POSIX violation and we > > > > > > >> didn't seem to really use so wide cmd, but I have not > > > > > > >> yet verified everything myself. > > > > > > > > > > > > > > Long time ago, I had a similar problem with termios > > > > > > > TIOCGWINSZ and we patched the port like this: > > > > > > > > > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python > > > > > > >/fil es /A tt > > > > > > > ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ > > > > > > >e=te xt %2 Fpl ain > > > > > > > > > > > > > > I believe it was upstream patched at the time but I > > > > > > > won't be surprised if something similar was > > > > > > > reintroduced. It happens when a Python internal > > > > > > > integer type is converted to a native unsigned long. > > > > > > > > > > > > Well, only *BSD have cmd a long value so it's likely that > > > > > > it would be reintroduced. > > > > > > > > > > Yes, that's what I mean. > > > > > > > > > > > I have checked the 4.4BSD archive and understood that our > > > > > > ioctl's cmd parameter was made long around 1991 or 1992s > > > > > > but didn't see what it actually buy us... > > > > > > > > > > Like it or not, it is too late to revert. :-( > > > > > > > > From Python 2.6.5: > > > > > > > > static PyObject * > > > > fcntl_ioctl(PyObject *self, PyObject *args) > > > > { > > > > #define IOCTL_BUFSZ 1024 > > > > int fd; > > > > /* In PyArg_ParseTuple below, we use the unsigned > > > > non-checked 'I' format for the 'code' parameter because > > > > Python turns 0x8000000 into either a large positive number > > > > (PyLong or PyInt on 64-bit platforms) or a negative number on > > > > others (32-bit PyInt) whereas the system expects it to be a > > > > 32bit bit field value regardless of it being passed as an int > > > > or unsigned long on various platforms. See the > > > > termios.TIOCSWINSZ constant across platforms for an example > > > > of thise. > > > > > > > > If any of the 64bit platforms ever decide to use more > > > > than 32bits in their unsigned long ioctl codes this will > > > > break and need special casing based on the platform being > > > > built on. */ > > > > unsigned int code; > > > > ... > > > > > > > > It is still a kludge and it won't be fixed. :-( > > > > > > Please drop the attached patch in ports/lang/python26/files and > > > test. Note I am not a Python guy, so please don't shoot me. ;-) > > > > I found that Python guys added 'k' format since 2.3, which > > converts a Python integer to unsigned long. Please ignore the > > previous patch and try the attached patch instead. > > Unfortunately it didn't work. > > 1) Added patch to lang/python26 > 2) Recompiled lang/python26 > 3) cd /var/db/ports && portupgrade -f python* py26* deluge* > > Restarted deluge afterwards. The message is still there: > > Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6): > ioctl sign-extension ioctl ffffffff8004667e It may be a deeper problen, then. :-( First of all, I cannot reproduce the problem because deluged dumps core on my box and I gave it up. Just staring at the code, it seems they rely on a bundled libtorrent for Python binding and the libtorrent relies on Boost, in turn. Then, the actual non-blocking socket implementation is done with Boost ASIO[1]. It is possible that there are more complicated problems between these and the Python binding. In fact, I can see a lot of these: int name() const { return FIONBIO; } ... if (!ec && command.name() == static_cast(FIONBIO)) ... socket_ops::ioctl(impl.socket_, command.name(), ...) ... They are just assuming it is an int type, I guess. Sigh, what a mess... Jung-uk Kim [1] Boost and its Python binding from ports seems to be a newer ASIO version than the bundled ASIO headers. Probably it is a reason for the crash but I didn't bother too much. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 25 22:47:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F56E1065670; Fri, 25 Jun 2010 22:47:29 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id B8B068FC18; Fri, 25 Jun 2010 22:47:28 +0000 (UTC) Received: from vhoffman-macbook.local ([10.0.0.173]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id o5PMlPfL061584 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 25 Jun 2010 23:47:26 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4C2531FD.8050605@unsane.co.uk> Date: Fri, 25 Jun 2010 23:47:25 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Daisuke Aoyama References: <1931AE1113EC4A8983B8A52A2A1966C2@ad.peach.ne.jp> In-Reply-To: <1931AE1113EC4A8983B8A52A2A1966C2@ad.peach.ne.jp> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: iSCSI boot driver version 0.1.1 for iBFT X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 22:47:29 -0000 On 25/06/2010 17:32, Daisuke Aoyama wrote: > Sorry, isboot-0.1.1 was broken under i386 kernel + loader. > The version 0.1.2 is uploaded in my blog. > Also I uploaded isboot integrated FreeBSD 7.3 disc1, 8.1-RC1 dics1 and > making script. Use at your own risk. > > You need only iBFT supported NIC and iSCSI target. Since I dont have a supported nic, would the iscsi support in gpxe (http://etherboot.org/wiki/iscsiboot) be enough? (might give it a try if i get time after the weekend.) Vince > > Please see Intel's site about iBFT supported NIC. > http://www.intel.com/support/network/adapter/pro100/sb/CS-028681.htm > > If you can connect to iSCSI target by NIC BIOS, isboot.ko shows the > following log. > > In this case, em0 is configured automatically with NIC0 parameter in > iBFT, > and you can install FreeBSD to da1 directly and you can boot from da1. > > If you want to try to copy existing FreeBSD, then configure NIC and > loading isboot.ko via loader.conf or "kldload isboot.ko" from shell. > Then, use normal way such as dump/restore. > > Note: do not set IP to em0 when installation. it might be a problem. > --------------------------------------------------------------- > iSCSI boot driver version 0.1.2 > IS: Initiator name: iqn.2007-09.jp.ne.peach:pluto > NIC0: IP address: 192.168.3.48 > NIC0: Prefix: 24 > NIC0: Gateway: 0.0.0.0 > NIC0: MAC address: 00:15:17:97:85:ab > TGT0: Target IP address: 192.168.3.36 > TGT0: Target Port: 3260 > TGT0: Target LUN: 2 > TGT0: Target name: iqn.2007-09.jp.ne.peach:isboot1 > Boot NIC: em0 > Configure IPv4 by NIC0 > Attempting to login to iSCSI target and scan all LUNs. > ... cut ... > da0 at isboot0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C) > da1 at isboot0 bus 0 scbus0 target 0 lun 2 > da1: Fixed Direct Access SCSI-5 device > da1: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) > da2 at isboot0 bus 0 scbus0 target 0 lun 3 > da2: Fixed Direct Access SCSI-5 device > da2: 1024MB (2097152 512 byte sectors: 64H 32S/T 1024C) > ... cut ... > Boot device: da1 > --------------------------------------------------------------- > > Download links: > http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.1.2.iso > > http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.1.2.iso > > http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-amd64-isboot-0.1.2.iso > > http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-i386-isboot-0.1.2.iso > > http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh > > Try it you self :) > Daisuke Aoyama > > > _______________________________________________ > 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-stable@FreeBSD.ORG Fri Jun 25 23:54:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 045FE106564A for ; Fri, 25 Jun 2010 23:54:58 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id AF0DE8FC13 for ; Fri, 25 Jun 2010 23:54:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoYFALzeJEyDaFvJ/2dsb2JhbACSeowwccIXhSEE X-IronPort-AV: E=Sophos;i="4.53,484,1272859200"; d="scan'208";a="81943301" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 25 Jun 2010 19:54:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id E40C0FB8090; Fri, 25 Jun 2010 19:54:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kB6llocf17mV; Fri, 25 Jun 2010 19:54:54 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 21E2DFB809A; Fri, 25 Jun 2010 19:54:54 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o5Q0Bgj08556; Fri, 25 Jun 2010 20:11:42 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 25 Jun 2010 20:11:42 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: alexs@ulgsm.ru In-Reply-To: <20100625152027.GA78442@mail.ulgsm.ru> Message-ID: References: <20100625152027.GA78442@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: diskless boot, nfs server behind router X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2010 23:54:58 -0000 On Fri, 25 Jun 2010, alexs@ulgsm.ru wrote: > Hi all. > > > I tryed setup server for booting diskless hosts from different networks. > > In one network booting is ok. > I see thet realtek 8139 pxe can`t load pxeboot file fromi tftp server from another > network. > > By changing options in dhcp server, i resolve that pxeboot can load kernel > from this server, but than kernel trying mount nfs root file system its > failing. > Later mounting from /etc/fstab is ok. > > Maybe im wrong? but diskless booting in several networks possible ony using > several servers, one in each network? > > I think pxe rom on nic and kernel nfs root mounting can`t work on 3-layer. > >From a quick glance at the code, I think that the dhcp server must return the gateway the client uses to get to the server. (ie. it must be an ip addr on the diskless client's network for the gateway to where the server is) It looks like this will then be used to set boot.netif.gateway to the correct value for the kernel. So you might want to check how your dhcpd is configured w.r.t. gateway address? rick From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 01:02:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38A8F106564A for ; Sat, 26 Jun 2010 01:02:18 +0000 (UTC) (envelope-from bobf@mrp3.com) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 168C08FC17 for ; Sat, 26 Jun 2010 01:02:17 +0000 (UTC) Received: from [66.47.136.67] (helo=BSDSilver.SFT.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OSJUH-0003FW-Cq for freebsd-stable@freebsd.org; Fri, 25 Jun 2010 20:43:13 -0400 Message-ID: <4C254D1F.5010300@mrp3.com> Date: Fri, 25 Jun 2010 17:43:11 -0700 From: bobf User-Agent: Thunderbird 2.0.0.23 (X11/20090905) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 549015f0ad0344773aad58b8ed06a5f90a9da525759e2654afc62f906786278d4e2804cd2e9f44c1f0dc0b2615eb44cc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.47.136.67 Subject: problems building amd64 kernel, cvsup 3 hours ago, no apparent change since X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 01:02:18 -0000 RELENG_8 - cvsup appx 15:00 PDT 1. performed 'make clean' followed by 'make buildworld'. Build complained that the architecture "amd64:i386" did not exist (I think that was the correct error message) on line 139 of Makefile.inc1 . 2. performed 'make buildworld TARGET=amd64' to force the build target. Everything appeared to work until the lib/libc target was reached, at which point an error on line 3 of syscall.S 'invalid register name %r10'. It appears that architecture selection is not working properly, and it prevents libc build from its compiling assembly language files. uname output FreeBSD hack.SFT.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 7 11:02:24 PDT 2010 root@hack.SFT.local:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 01:19:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B7471065674 for ; Sat, 26 Jun 2010 01:19:55 +0000 (UTC) (envelope-from bobf@mrp3.com) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by mx1.freebsd.org (Postfix) with ESMTP id EE13D8FC14 for ; Sat, 26 Jun 2010 01:19:54 +0000 (UTC) Received: from [66.47.136.67] (helo=BSDSilver.SFT.local) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1OSK3m-0006Ec-GR for freebsd-stable@freebsd.org; Fri, 25 Jun 2010 21:19:54 -0400 Message-ID: <4C2555B7.3040400@mrp3.com> Date: Fri, 25 Jun 2010 18:19:51 -0700 From: bobf User-Agent: Thunderbird 2.0.0.23 (X11/20090905) MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 549015f0ad0344773aad58b8ed06a5f90a9da525759e2654afc62f906786278ddf375e2b0d8e598c78c914e01878b5fc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.47.136.67 Subject: problems building amd64 kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 01:19:55 -0000 I traced the problem to an entry I had placed in make.conf to correct deficiencies in some of the multimedia ports a few months ago (not correctly enabling MMX or SSE for amd64 builds). removing these entries eliminated build problems. -------- Original Message -------- Subject: problems building amd64 kernel, cvsup 3 hours ago, no apparent change since Date: Fri, 25 Jun 2010 17:43:11 -0700 From: bobf To: freebsd-stable@freebsd.org RELENG_8 - cvsup appx 15:00 PDT 1. performed 'make clean' followed by 'make buildworld'. Build complained that the architecture "amd64:i386" did not exist (I think that was the correct error message) on line 139 of Makefile.inc1 . 2. performed 'make buildworld TARGET=amd64' to force the build target. Everything appeared to work until the lib/libc target was reached, at which point an error on line 3 of syscall.S 'invalid register name %r10'. It appears that architecture selection is not working properly, and it prevents libc build from its compiling assembly language files. uname output FreeBSD hack.SFT.local 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Apr 7 11:02:24 PDT 2010 root@hack.SFT.local:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 09:12:59 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC381065670 for ; Sat, 26 Jun 2010 09:12:59 +0000 (UTC) (envelope-from lioux@FreeBSD.org) Received: from goat.gigo.com (ipv6.gigo.com [IPv6:2001:470:1:18::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3A46A8FC0C for ; Sat, 26 Jun 2010 09:12:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by goat.gigo.com (Postfix) with ESMTP id 27D1E5C00 for ; Sat, 26 Jun 2010 02:12:59 -0700 (PDT) Received: from goat.gigo.com ([127.0.0.1]) by localhost (vette.gigo.com [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id CBsMzS-xfHHj for ; Sat, 26 Jun 2010 02:12:58 -0700 (PDT) Received: from 189.72.155.250 (189-72-155-250.bsace702.dsl.brasiltelecom.net.br [189.72.155.250]) by goat.gigo.com (Postfix) with ESMTPSA id E0EB45C76 for ; Sat, 26 Jun 2010 02:12:57 -0700 (PDT) Received: (qmail 82644 invoked from network); 26 Jun 2010 06:09:39 -0300 Received: from unknown (HELO exxodus.fedaykin.here) (127.0.0.1) by exxodus.fedaykin.here with SMTP; 26 Jun 2010 06:09:39 -0300 Message-ID: <4C25C3D3.3030109@FreeBSD.org> Date: Sat, 26 Jun 2010 06:09:39 -0300 From: Mario Sergio Fujikawa Ferreira User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; pt-BR; rv:1.9.1.10) Gecko/20100622 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jung-uk Kim References: <20100623025855.82916.qmail@exxodus.fedaykin.here> <201006231708.40032.jkim@FreeBSD.org> <20100625085404.94155.qmail@exxodus.fedaykin.here> <201006251758.56393.jkim@FreeBSD.org> (sfid-20100625_19270_E0B8159B) In-Reply-To: <201006251758.56393.jkim@FreeBSD.org> (sfid-20100625_19270_E0B8159B) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: d@delphij.net, freebsd-stable@FreeBSD.org, python@FreeBSD.org Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 09:12:59 -0000 On 25/06/2010 18:58, Jung-uk Kim wrote: > On Friday 25 June 2010 04:54 am, Mario Sergio Fujikawa Ferreira wrote: >> On Wed, Jun 23, 2010 at 05:08:38PM -0400, Jung-uk Kim wrote: >>> Date: Wed, 23 Jun 2010 17:08:38 -0400 >>> From: Jung-uk Kim >>> To: freebsd-stable@FreeBSD.org >>> Cc: d@delphij.net, Mario Sergio Fujikawa Ferreira >>> Subject: Re: FreeBSD 8.1-PRERELEASE: WARNING >>> ioctl sign-extension ioctl ffffffff8004667e >>> User-Agent: KMail/1.6.2 >>> >>> On Wednesday 23 June 2010 03:38 pm, Jung-uk Kim wrote: >>>> On Wednesday 23 June 2010 03:10 pm, Jung-uk Kim wrote: >>>>> On Wednesday 23 June 2010 03:01 pm, Jung-uk Kim wrote: >>>>>> On Wednesday 23 June 2010 02:41 pm, Xin LI wrote: >>>>>>> On 2010/06/23 11:37, Jung-uk Kim wrote: >>>>>>>> On Wednesday 23 June 2010 02:12 pm, Xin LI wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 2010/06/22 19:58, Mario Sergio Fujikawa Ferreira > wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am getting more than 4 thousand of the following >>>>>>>>>> messages a day: >>>>>>>>>> >>>>>>>>>> WARNING pid 24509 (python2.6): ioctl sign-extension >>>>>>>>>> ioctl ffffffff8004667e >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>> I think we may need to check the code and patch it. >>>>>>>>> Basically this means that python (or some .so modules) >>>>>>>>> passed an int or unsigned int as parameter 'cmd', we >>>>>>>>> need to change it to unsigned long. >>>>>>>>> >>>>>>>>> The warning itself should be harmless to my best of >>>>>>>>> knowledge, one can probably remove the printf in >>>>>>>>> kernel source code as a workaround. >>>>>>>>> >>>>>>>>> By the way it seems to be a POSIX violation and we >>>>>>>>> didn't seem to really use so wide cmd, but I have not >>>>>>>>> yet verified everything myself. >>>>>>>> >>>>>>>> Long time ago, I had a similar problem with termios >>>>>>>> TIOCGWINSZ and we patched the port like this: >>>>>>>> >>>>>>>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/python >>>>>>>> /fil es /A tt >>>>>>>> ic/patch-Modules%3A%3Afcntlmodule.c?rev=1.1;content-typ >>>>>>>> e=te xt %2 Fpl ain >>>>>>>> >>>>>>>> I believe it was upstream patched at the time but I >>>>>>>> won't be surprised if something similar was >>>>>>>> reintroduced. It happens when a Python internal >>>>>>>> integer type is converted to a native unsigned long. >>>>>>> >>>>>>> Well, only *BSD have cmd a long value so it's likely that >>>>>>> it would be reintroduced. >>>>>> >>>>>> Yes, that's what I mean. >>>>>> >>>>>>> I have checked the 4.4BSD archive and understood that our >>>>>>> ioctl's cmd parameter was made long around 1991 or 1992s >>>>>>> but didn't see what it actually buy us... >>>>>> >>>>>> Like it or not, it is too late to revert. :-( >>>>> >>>>> From Python 2.6.5: >>>>> >>>>> static PyObject * >>>>> fcntl_ioctl(PyObject *self, PyObject *args) >>>>> { >>>>> #define IOCTL_BUFSZ 1024 >>>>> int fd; >>>>> /* In PyArg_ParseTuple below, we use the unsigned >>>>> non-checked 'I' format for the 'code' parameter because >>>>> Python turns 0x8000000 into either a large positive number >>>>> (PyLong or PyInt on 64-bit platforms) or a negative number on >>>>> others (32-bit PyInt) whereas the system expects it to be a >>>>> 32bit bit field value regardless of it being passed as an int >>>>> or unsigned long on various platforms. See the >>>>> termios.TIOCSWINSZ constant across platforms for an example >>>>> of thise. >>>>> >>>>> If any of the 64bit platforms ever decide to use more >>>>> than 32bits in their unsigned long ioctl codes this will >>>>> break and need special casing based on the platform being >>>>> built on. */ >>>>> unsigned int code; >>>>> ... >>>>> >>>>> It is still a kludge and it won't be fixed. :-( >>>> >>>> Please drop the attached patch in ports/lang/python26/files and >>>> test. Note I am not a Python guy, so please don't shoot me. ;-) >>> >>> I found that Python guys added 'k' format since 2.3, which >>> converts a Python integer to unsigned long. Please ignore the >>> previous patch and try the attached patch instead. >> >> Unfortunately it didn't work. >> >> 1) Added patch to lang/python26 >> 2) Recompiled lang/python26 >> 3) cd /var/db/ports&& portupgrade -f python* py26* deluge* >> >> Restarted deluge afterwards. The message is still there: >> >> Jun 25 05:49:38 exxodus kernel: WARNING pid 38635 (python2.6): >> ioctl sign-extension ioctl ffffffff8004667e > > It may be a deeper problen, then. :-( > > First of all, I cannot reproduce the problem because deluged dumps > core on my box and I gave it up. Just staring at the code, it seems > they rely on a bundled libtorrent for Python binding and the > libtorrent relies on Boost, in turn. Then, the actual non-blocking > socket implementation is done with Boost ASIO[1]. It is possible > that there are more complicated problems between these and the Python > binding. In fact, I can see a lot of these: > > int name() const > { > return FIONBIO; > } > ... > if (!ec&& command.name() == static_cast(FIONBIO)) > ... > socket_ops::ioctl(impl.socket_, command.name(), ...) > ... > > They are just assuming it is an int type, I guess. > > Sigh, what a mess... Given that your python patch is a step on the right direction, I would propose that it be further tested and then committed if possible. > [1] Boost and its Python binding from ports seems to be a newer ASIO > version than the bundled ASIO headers. Probably it is a reason for > the crash but I didn't bother too much. If you have the time, everything you need to run the latest deluge 1.3.0 RC1 can be found at http://www.freebsd.org/cgi/query-pr.cgi?pr=144337 Check the PR, all the necessary ports can be found there. Let me know what you think. Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 11:34:22 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96B4A106566B for ; Sat, 26 Jun 2010 11:34:22 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 407A28FC17 for ; Sat, 26 Jun 2010 11:34:21 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 68C0E3A8F1 for ; Sat, 26 Jun 2010 15:34:19 +0400 (MSD) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on skuns.gsm900.net Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 4CCB73A8F0 for ; Sat, 26 Jun 2010 15:34:19 +0400 (MSD) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id 19F993A8EF for ; Sat, 26 Jun 2010 15:34:19 +0400 (MSD) Date: Sat, 26 Jun 2010 15:34:19 +0400 From: alexs@ulgsm.ru To: freebsd-stable@freebsd.org Message-ID: <20100626113418.GA80299@mail.ulgsm.ru> References: <20100625152027.GA78442@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: diskless boot, nfs server behind router X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 11:34:22 -0000 * Rick Macklem [2010-06-25 20:11:42 -0400]: > From a quick glance at the code, I think that the dhcp server must return > the gateway the client uses to get to the server. (ie. it must be an ip > addr on the diskless client's network for the gateway to where the server > is) It looks like this will then be used to set boot.netif.gateway to the > correct value for the kernel. > > So you might want to check how your dhcpd is configured w.r.t. gateway > address? dhcp seems ok. [alexs:ul-it13:~]>kenv LINES="24" acpi_load="YES" boot.netif.gateway="10.144.140.1" boot.netif.hwaddr="00:1c:c0:5a:f4:72" boot.netif.ip="10.144.142.78" boot.netif.netmask="255.255.252.0" boot.nfsroot.nfshandle="Xbb55e849c6f9fd520c000000011c0600c20af931000000000000000000000000X" boot.nfsroot.path="/exp/fbsd71" boot.nfsroot.server="10.144.140.160" .... It is from diskless host in same subnet where tftp and nfs server. If i use server from over subnet, pxe cant load pxeboot, and kernel can`t mount boot.nfsroot.path="/exp/fbsd71". About pxe google found http://www.appdeploy.com/faq/detail.asp?id=10 As i understand router must make ip helper. I seen it in cisco routers, not freebsd. -- alexs From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 14:07:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CFAA106566C for ; Sat, 26 Jun 2010 14:07:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id B40958FC0A for ; Sat, 26 Jun 2010 14:07:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAFABenJUyDaFvK/2dsb2JhbACSe4wvcb9mhSQE X-IronPort-AV: E=Sophos;i="4.53,487,1272859200"; d="scan'208";a="81981975" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 26 Jun 2010 10:07:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 54FCC109C2D8; Sat, 26 Jun 2010 10:07:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3MFG9E4o5p5; Sat, 26 Jun 2010 10:07:54 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id C924E109C2D1; Sat, 26 Jun 2010 10:07:54 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o5QEOi516826; Sat, 26 Jun 2010 10:24:44 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sat, 26 Jun 2010 10:24:44 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: alexs@ulgsm.ru In-Reply-To: <20100626113418.GA80299@mail.ulgsm.ru> Message-ID: References: <20100625152027.GA78442@mail.ulgsm.ru> <20100626113418.GA80299@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: diskless boot, nfs server behind router X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 14:07:59 -0000 On Sat, 26 Jun 2010, alexs@ulgsm.ru wrote: [stuff snipped] > > > dhcp seems ok. > [alexs:ul-it13:~]>kenv > LINES="24" > acpi_load="YES" > boot.netif.gateway="10.144.140.1" > boot.netif.hwaddr="00:1c:c0:5a:f4:72" > boot.netif.ip="10.144.142.78" > boot.netif.netmask="255.255.252.0" > boot.nfsroot.nfshandle="Xbb55e849c6f9fd520c000000011c0600c20af931000000000000000000000000X" > boot.nfsroot.path="/exp/fbsd71" > boot.nfsroot.server="10.144.140.160" > .... > > It is from diskless host in same subnet where tftp and nfs server. > Ok, this is when the server is on the same subnet and works ok. Am I correct? > If i use server from over subnet, pxe cant load pxeboot, and kernel can`t > mount boot.nfsroot.path="/exp/fbsd71". > I thought you had said that you had gotten pxeboot to work across to the other subnet and that it was the mount of "/" that then failed? (It is that case where "boot.netif.gateway" needs to be checked to see that it has the gateway for the client's subnet.) > About pxe google found http://www.appdeploy.com/faq/detail.asp?id=10 > As i understand router must make ip helper. > I seen it in cisco routers, not freebsd. > If you haven't been able to get pxeboot to work when the server is on a different subnet, I'm afraid I can't help with that. rick From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 15:57:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D79BB1065670 for ; Sat, 26 Jun 2010 15:57:51 +0000 (UTC) (envelope-from matt@bubblegen.co.uk) Received: from relay.pcl-ipout01.plus.net (relay.pcl-ipout01.plus.net [212.159.7.99]) by mx1.freebsd.org (Postfix) with ESMTP id 70D318FC12 for ; Sat, 26 Jun 2010 15:57:50 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKLAJUxUXebj/2dsb2JhbACDHZwOca9+kFyBKYMJcgQ Received: from outmx01.plus.net ([84.93.230.227]) by relay.pcl-ipout01.plus.net with ESMTP; 26 Jun 2010 16:57:50 +0100 Received: from bubblegen.plus.com ([80.229.236.194] helo=[192.136.1.18]) by outmx01.plus.net with esmtp (Exim) id 1OSXlN-00078e-JM; Sat, 26 Jun 2010 16:57:49 +0100 From: Matthew Lear To: Jeremy Chadwick In-Reply-To: <20100625071644.GA75910@icarus.home.lan> References: <1276876031.7519.39.camel@almscliff.bubblegen.co.uk> <20100618174208.GA47470@icarus.home.lan> <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> <20100624181535.GA58443@icarus.home.lan> <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> <20100625071644.GA75910@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Sat, 26 Jun 2010 16:57:48 +0100 Message-ID: <1277567868.1870.21.camel@almscliff.bubblegen.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 15:57:52 -0000 On Fri, 2010-06-25 at 00:16 -0700, Jeremy Chadwick wrote: > > All in all, replacing a drive is a completely reasonable action when > there's evidence confirming the need for its replacement. I don't like > replacing hardware when there's no indication replacing it will > necessarily fix the problem; I'd rather understand the problem. > > Matthew, if you're able to take the system down for 2-3 hours, I would > recommend downloading Western Digital's Data Lifeguard Diagnostics > software (for DOS; you'll need a CD burner to burn the ISO) and running > that on your drive. If that fails on a Long/Extended test, yep, replace > the disk. Said utility tests a lot more than just SMART. Ok. I've tried this but I think there are some BIOS settings that mean that the WD DOS env can't find the license file (I've read several postings about this). I'd rather not mess around with BIOS settings on the machine I'm trying to restore so I'll remove the drive and plug it into another machine and attempt to run the WD's diagnostics on it. I'll post the results here if anything interesting crops up. > If it passes the test, then we're back at square one, and you can try > replacing the disk if you'd like (then boot from the 2nd disk in the > RAID-1 array). My concern is that replacing it isn't going to fix > anything (meaning you might have a SATA port that's going bad or the > controller itself is broken). > Meanwhile, I powered off the RAID 1 machine, removed the [apparently] faulty drive (ad0), also removed the 160G drive that was a slave on ATA channel 0 (just to simplify things since it wasn't part of the array), replaced ad0 with a brand spanking new one (same make/model), switched the BIOS to boot from the 2nd disk (ie ad2) and booted the machine. Bootmgr started fine, booted the kernel and the machine booted normally. atacontrol status on ar0 gives: ar0: ATA RAID1 status: DEGRADED subdisks: 0 ---- MISSING 1 ---- ONLINE Importantly, atacontrol did detect that the RAID was degraded at boot time: ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode ar0: 305245MB status: DEGRADED ar0: disk0 DOWN no device found for this subdisk ar0: disk1 READY (mirror) using ad2 at ata1-master Just to clarify, the array was created using atacontrol so why it's reporting Intel MatrixRAID I have no idea. Trying to rebuild the array with atacontrol rebuild ar0 gives: atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error So I tried to detach channel ata0 and reattach it. This appeared to go ok. Trying to rebuild the array again gave the same error as above. I found a post on nabble (can't find it now!) where a chap was having the same problem rebuilding his RAID1 array using atacontrol rebuild. Turns out that because it's a software RAID array, atacontrol rebuild won't work. The only recommended way to get the array back on track was to dd the contents of the healthy drive onto the new drive. I tried this just to see what would happen: dd if=/dev/ad2 of=/dev/ad0 bs=1024k Seemed to work just fine as expected. I was hoping that after another reboot, atacontrol would have seen ad0 as the missing array device on chanel 0, done anything required and hey presto, I'd have a health RAID 1 array again. Sadly, not. atacontrol still insists that the array is DEGRADED despite having manually mirrored the contents of ad2 to ad0. Is this a case of RTFM some more or have I missed something? It should surely be possible to restore the array?! -- Matt From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 17:12:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E328E106564A for ; Sat, 26 Jun 2010 17:12:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id C0E9F8FC13 for ; Sat, 26 Jun 2010 17:12:53 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta08.emeryville.ca.mail.comcast.net with comcast id agyU1e0030FhH24A8hCtYR; Sat, 26 Jun 2010 17:12:53 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id ahCs1e0023S48mS8UhCsQL; Sat, 26 Jun 2010 17:12:52 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AF3539B425; Sat, 26 Jun 2010 10:12:51 -0700 (PDT) Date: Sat, 26 Jun 2010 10:12:51 -0700 From: Jeremy Chadwick To: Matthew Lear Message-ID: <20100626171251.GA26022@icarus.home.lan> References: <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> <20100624181535.GA58443@icarus.home.lan> <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> <20100625071644.GA75910@icarus.home.lan> <1277567868.1870.21.camel@almscliff.bubblegen.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1277567868.1870.21.camel@almscliff.bubblegen.co.uk> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 17:12:54 -0000 On Sat, Jun 26, 2010 at 04:57:48PM +0100, Matthew Lear wrote: > On Fri, 2010-06-25 at 00:16 -0700, Jeremy Chadwick wrote: > > > > All in all, replacing a drive is a completely reasonable action when > > there's evidence confirming the need for its replacement. I don't like > > replacing hardware when there's no indication replacing it will > > necessarily fix the problem; I'd rather understand the problem. > > > > Matthew, if you're able to take the system down for 2-3 hours, I would > > recommend downloading Western Digital's Data Lifeguard Diagnostics > > software (for DOS; you'll need a CD burner to burn the ISO) and running > > that on your drive. If that fails on a Long/Extended test, yep, replace > > the disk. Said utility tests a lot more than just SMART. > > Ok. I've tried this but I think there are some BIOS settings that mean > that the WD DOS env can't find the license file (I've read several > postings about this). I'd rather not mess around with BIOS settings on > the machine I'm trying to restore so I'll remove the drive and plug it > into another machine and attempt to run the WD's diagnostics on it. I'll > post the results here if anything interesting crops up. > > > If it passes the test, then we're back at square one, and you can try > > replacing the disk if you'd like (then boot from the 2nd disk in the > > RAID-1 array). My concern is that replacing it isn't going to fix > > anything (meaning you might have a SATA port that's going bad or the > > controller itself is broken). > > > > Meanwhile, I powered off the RAID 1 machine, removed the [apparently] > faulty drive (ad0), also removed the 160G drive that was a slave on ATA > channel 0 (just to simplify things since it wasn't part of the array), > replaced ad0 with a brand spanking new one (same make/model), switched > the BIOS to boot from the 2nd disk (ie ad2) and booted the machine. > Bootmgr started fine, booted the kernel and the machine booted normally. > atacontrol status on ar0 gives: > > ar0: ATA RAID1 status: DEGRADED > subdisks: > 0 ---- MISSING > 1 ---- ONLINE > > Importantly, atacontrol did detect that the RAID was degraded at boot > time: > > ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode > ar0: 305245MB status: DEGRADED > ar0: disk0 DOWN no device found for this subdisk > ar0: disk1 READY (mirror) using ad2 at ata1-master Does "atacontrol list" show the existence of disks ad0 and ad2? If so, then the message probably indicate "ad0 exists but there's missing metadata, so I'm ignoring it". If not, then I have no real explanation other than it sounds like the SATA controller is broken. > Just to clarify, the array was created using atacontrol so why it's > reporting Intel MatrixRAID I have no idea. Are you absolutely 100% positively certain that your system/motherboard does not have "SATA RAID" enabled in the system BIOS? The ar0 "Intel MatrixRAID" line really has me concerned. If MatrixRAID is indeed enabled in the BIOS, then almost all these problems can be explained. > Trying to rebuild the array with atacontrol rebuild ar0 gives: > > atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error > > So I tried to detach channel ata0 and reattach it. This appeared to go > ok. Trying to rebuild the array again gave the same error as above. More on this later. > I found a post on nabble (can't find it now!) where a chap was having > the same problem rebuilding his RAID1 array using atacontrol rebuild. > Turns out that because it's a software RAID array, atacontrol rebuild > won't work. The only recommended way to get the array back on track was > to dd the contents of the healthy drive onto the new drive. I tried this > just to see what would happen: > > dd if=/dev/ad2 of=/dev/ad0 bs=1024k > > Seemed to work just fine as expected. I was hoping that after another > reboot, atacontrol would have seen ad0 as the missing array device on > chanel 0, done anything required and hey presto, I'd have a health RAID > 1 array again. > > Sadly, not. atacontrol still insists that the array is DEGRADED despite > having manually mirrored the contents of ad2 to ad0. This probably has to do with corrupt/missing/incorrect metadata. The dd method (to copy disk X to disk Y) isn't sufficient. The atacontrol man page states the following for your situation: If the system has a pure software array and is not using a "real" ATA RAID controller, then shut the system down, make sure that the disk that was still working is moved to the bootable position (channel 0 or what‐ ever the BIOS allows the system to boot from) and the blank disk is placed in the secondary position, then boot the system into single-user mode and issue the command: atacontrol addspare ar0 ad6 atacontrol rebuild ar0 So I believe what the man page is telling you to do is: 1) Power down the system 2) Physically connect the ad2 (working/has-data) disk to SATA channel 0 3) Physically connect the ad0 (brand-new) disk to SATA channel 1 4) Make mental note that the disk names will now be swapped: ad0 will now be the working/has-data disk, and ad2 will be the brand-new disk 5) Power up the system and make sure you're booting from SATA channel 0 5) Go into single-user 6) Execute: atacontrol addspare ar0 ad2 atacontrol rebuild ar0 I have no idea if this will work or not. If this doesn't work, I'm out of ideas other than restoring from backups or running in degraded mode to back up your data, then afterward, rebuild the system using something like gmirror. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 21:13:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 515E11065687 for ; Sat, 26 Jun 2010 21:13:49 +0000 (UTC) (envelope-from cvs-src@yandex.ru) Received: from forward12.mail.yandex.net (forward12.mail.yandex.net [95.108.130.94]) by mx1.freebsd.org (Postfix) with ESMTP id F21C18FC1E for ; Sat, 26 Jun 2010 21:13:48 +0000 (UTC) Received: from smtp11.mail.yandex.net (smtp11.mail.yandex.net [95.108.130.67]) by forward12.mail.yandex.net (Yandex) with ESMTP id 0C2A422106F7 for ; Sun, 27 Jun 2010 01:13:47 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1277586827; bh=4u3cUNEeVFqzZt2mLf2L6xXPUQ5IjHZngafAAFQPlzw=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=SuI+R44iMMMPgF8r/j/xXKWzdE2Z4g3kFN2e8b4fAmEJO7fFaTwsGwvAOwq5xhanx htTB1fKlINcxQ0rwckymf8QO3yWWD4q0EGdxyy6FCXfteqX0UUURKKNLHD/NIcaDDL bwullkgWEv2m0Y1X7KGmpbwB9uM4isgLKWwaS0MU= Received: from smeshariki2.local (unknown [77.66.149.137]) by smtp11.mail.yandex.net (Yandex) with ESMTPSA id D1FB244D806E for ; Sun, 27 Jun 2010 01:13:46 +0400 (MSD) Message-ID: <4C266D3F.6070400@yandex.ru> Date: Sun, 27 Jun 2010 01:12:31 +0400 From: Ruslan Mahmatkhanov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.1.10) Gecko/20100621 Thunderbird/3.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1277586827 X-Yandex-Spam: 1 X-Yandex-Front: smtp11.mail.yandex.net Subject: bwn panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:13:49 -0000 Hello! I'm using siba_bwn0@pci0:16:0:0: class=0x028000 card=0x1364103c chip=0x431114e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card (BCM4311)' class = network with bwn driver on recent stable. I'm using it with wpa_supplicant for WPA2 encryption. It works well most of the time, but right now (it was first time) i get my laptop rebooted with following in messages: Jun 25 17:31:51 smeshariki2 wpa_supplicant[424]: CTRL-EVENT-SCAN-RESULTS Jun 25 17:36:53 smeshariki2 wpa_supplicant[424]: CTRL-EVENT-SCAN-RESULTS Jun 25 17:38:54 smeshariki2 kernel: bwn0: status of RF switch is changed to ON Jun 25 17:40:05 smeshariki2 kernel: bwn0: HW reset: PHY TX errors Jun 25 17:40:05 smeshariki2 kernel: bwn0: MAC suspend failed Jun 25 17:40:05 smeshariki2 kernel: bwn0: no INITVALS for rev 10 Jun 25 17:40:05 smeshariki2 kernel: Sleeping thread (tid 100024, pid 0) owns a non-sleepable lock Jun 25 17:40:05 smeshariki2 kernel: panic: sleeping thread Jun 25 17:40:05 smeshariki2 kernel: cpuid = 0 Jun 25 17:40:05 smeshariki2 kernel: Uptime: 7h29m29s Jun 25 17:40:05 smeshariki2 kernel: Cannot dump. Device not defined or unavailable. Jun 25 17:40:05 smeshariki2 kernel: Automatic reboot in 15 seconds - press a key on the console to abort Jun 25 17:40:05 smeshariki2 kernel: --> Press a key on the console to reboot, Jun 25 17:40:05 smeshariki2 kernel: --> or switch off the system now. Jun 25 17:40:05 smeshariki2 kernel: Rebooting... I know nothing but it looks like some locking issue. Can please anybody shed some light what's wrong? Thanks. -- Regards, Ruslan From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 21:16:56 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A21FB1065670 for ; Sat, 26 Jun 2010 21:16:56 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5A3368FC0A for ; Sat, 26 Jun 2010 21:16:56 +0000 (UTC) Received: by qyk12 with SMTP id 12so75699qyk.13 for ; Sat, 26 Jun 2010 14:16:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dShA8QXzbMPzrCFNaQjfaAvT/5F/iaqx6GHnGtWzo/s=; b=B0Lmtp8ad3c0jp4NJuLsyvNas4t4gyOPbFYw3DI7dblynTnyMqJpX9XfrvhRFI35tF JWPtRR9XCTvqC1LaFsL5eH2QJQTToGCCWoy+8oFbCG805PWUomaP1XKjjeUkRkVxHDWs xY8KIu2uVh04/Fn8jnB8kf03GsAZey/yMuv+g= 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=q8CS0mf3+iYDrXrpy2g0b8dff9gq5FlRGdZELaqv+xcdS5QmGC4UseWQw91CsjAbvB /3Or9B6bZuVNL+hh0KWrLi3iXSifT1+T5lp4rr0TFMep4lN7hCEhyVzRf03UM7eLrIyj kLrOhDlaSQbSlYQfJiggZ1zlHMYhBJeluZc2k= MIME-Version: 1.0 Received: by 10.224.87.214 with SMTP id x22mr1821617qal.72.1277587015697; Sat, 26 Jun 2010 14:16:55 -0700 (PDT) Received: by 10.229.80.75 with HTTP; Sat, 26 Jun 2010 14:16:55 -0700 (PDT) In-Reply-To: <4C266D3F.6070400@yandex.ru> References: <4C266D3F.6070400@yandex.ru> Date: Sat, 26 Jun 2010 14:16:55 -0700 Message-ID: From: Garrett Cooper To: Ruslan Mahmatkhanov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: bwn panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 21:16:56 -0000 On Sat, Jun 26, 2010 at 2:12 PM, Ruslan Mahmatkhanov wr= ote: > Hello! > > I'm using > > siba_bwn0@pci0:16:0:0: =A0class=3D0x028000 card=3D0x1364103c chip=3D0x431= 114e4 > rev=3D0x01 hdr=3D0x00 > =A0 =A0vendor =A0 =A0 =3D 'Broadcom Corporation' > =A0 =A0device =A0 =A0 =3D 'Broadcom Corporation Dell Wireless 1390 WLAN M= ini-PCI Card > (BCM4311)' > =A0 =A0class =A0 =A0 =A0=3D network > > with bwn driver on recent stable. I'm using it with wpa_supplicant for WP= A2 > encryption. It works well most of the time, but right now (it was first > time) i get my laptop rebooted with following in messages: > > Jun 25 17:31:51 smeshariki2 wpa_supplicant[424]: CTRL-EVENT-SCAN-RESULTS > Jun 25 17:36:53 smeshariki2 wpa_supplicant[424]: CTRL-EVENT-SCAN-RESULTS > Jun 25 17:38:54 smeshariki2 kernel: bwn0: status of RF switch is changed = to > ON > Jun 25 17:40:05 smeshariki2 kernel: bwn0: HW reset: PHY TX errors > Jun 25 17:40:05 smeshariki2 kernel: bwn0: MAC suspend failed > Jun 25 17:40:05 smeshariki2 kernel: bwn0: no INITVALS for rev 10 > Jun 25 17:40:05 smeshariki2 kernel: Sleeping thread (tid 100024, pid 0) o= wns > a non-sleepable lock > Jun 25 17:40:05 smeshariki2 kernel: panic: sleeping thread > Jun 25 17:40:05 smeshariki2 kernel: cpuid =3D 0 > Jun 25 17:40:05 smeshariki2 kernel: Uptime: 7h29m29s > Jun 25 17:40:05 smeshariki2 kernel: Cannot dump. Device not defined or > unavailable. > Jun 25 17:40:05 smeshariki2 kernel: Automatic reboot in 15 seconds - pres= s a > key on the console to abort > Jun 25 17:40:05 smeshariki2 kernel: --> Press a key on the console to > reboot, > Jun 25 17:40:05 smeshariki2 kernel: --> or switch off the system now. > Jun 25 17:40:05 smeshariki2 kernel: Rebooting... > > I know nothing but it looks like some locking issue. > Can please anybody shed some light what's wrong? Thanks. Hi Ruslan, Please take a look at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html if the issue is reproducible. Thanks, -Garrett From owner-freebsd-stable@FreeBSD.ORG Sat Jun 26 23:04:52 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63D59106566B for ; Sat, 26 Jun 2010 23:04:52 +0000 (UTC) (envelope-from matt@bubblegen.co.uk) Received: from relay.ptn-ipout02.plus.net (relay.ptn-ipout02.plus.net [212.159.7.36]) by mx1.freebsd.org (Postfix) with ESMTP id BA7948FC14 for ; Sat, 26 Jun 2010 23:04:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPMkJkxUXeb6/2dsb2JhbACDHZwLca5CkB6BKYE5gVByBA Received: from outmx05.plus.net ([84.93.230.250]) by relay.ptn-ipout02.plus.net with ESMTP; 27 Jun 2010 00:04:50 +0100 Received: from bubblegen.plus.com ([80.229.236.194] helo=[192.136.1.18]) by outmx05.plus.net with esmtp (Exim) id 1OSeQb-0004HL-VK; Sun, 27 Jun 2010 00:04:50 +0100 From: Matthew Lear To: Jeremy Chadwick In-Reply-To: <20100626171251.GA26022@icarus.home.lan> References: <1276889330.2210.44.camel@almscliff.bubblegen.co.uk> <1277155992.1860.3.camel@almscliff.bubblegen.co.uk> <20100622074541.GA71157@icarus.home.lan> <82A96ECD-676C-4A4D-A328-0CFAABD64D50@gid.co.uk> <1277401934.1874.12.camel@almscliff.bubblegen.co.uk> <20100624181535.GA58443@icarus.home.lan> <1277417182.1874.30.camel@almscliff.bubblegen.co.uk> <20100625071644.GA75910@icarus.home.lan> <1277567868.1870.21.camel@almscliff.bubblegen.co.uk> <20100626171251.GA26022@icarus.home.lan> Content-Type: text/plain; charset="UTF-8" Date: Sun, 27 Jun 2010 00:04:48 +0100 Message-ID: <1277593488.1884.107.camel@almscliff.bubblegen.co.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Adam Vande More , freebsd-stable@freebsd.org Subject: Re: 7.2-RELEASE-p4, IO errors & RAID1 failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 23:04:52 -0000 On Sat, 2010-06-26 at 10:12 -0700, Jeremy Chadwick wrote: > On Sat, Jun 26, 2010 at 04:57:48PM +0100, Matthew Lear wrote: > > On Fri, 2010-06-25 at 00:16 -0700, Jeremy Chadwick wrote: > > > > > > All in all, replacing a drive is a completely reasonable action when > > > there's evidence confirming the need for its replacement. I don't like > > > replacing hardware when there's no indication replacing it will > > > necessarily fix the problem; I'd rather understand the problem. > > > > > > Matthew, if you're able to take the system down for 2-3 hours, I would > > > recommend downloading Western Digital's Data Lifeguard Diagnostics > > > software (for DOS; you'll need a CD burner to burn the ISO) and running > > > that on your drive. If that fails on a Long/Extended test, yep, replace > > > the disk. Said utility tests a lot more than just SMART. > > > > Ok. I've tried this but I think there are some BIOS settings that mean > > that the WD DOS env can't find the license file (I've read several > > postings about this). I'd rather not mess around with BIOS settings on > > the machine I'm trying to restore so I'll remove the drive and plug it > > into another machine and attempt to run the WD's diagnostics on it. I'll > > post the results here if anything interesting crops up. > > > > > If it passes the test, then we're back at square one, and you can try > > > replacing the disk if you'd like (then boot from the 2nd disk in the > > > RAID-1 array). My concern is that replacing it isn't going to fix > > > anything (meaning you might have a SATA port that's going bad or the > > > controller itself is broken). > > > > > > > Meanwhile, I powered off the RAID 1 machine, removed the [apparently] > > faulty drive (ad0), also removed the 160G drive that was a slave on ATA > > channel 0 (just to simplify things since it wasn't part of the array), > > replaced ad0 with a brand spanking new one (same make/model), switched > > the BIOS to boot from the 2nd disk (ie ad2) and booted the machine. > > Bootmgr started fine, booted the kernel and the machine booted normally. > > atacontrol status on ar0 gives: > > > > ar0: ATA RAID1 status: DEGRADED > > subdisks: > > 0 ---- MISSING > > 1 ---- ONLINE > > > > Importantly, atacontrol did detect that the RAID was degraded at boot > > time: > > > > ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode > > ar0: 305245MB status: DEGRADED > > ar0: disk0 DOWN no device found for this subdisk > > ar0: disk1 READY (mirror) using ad2 at ata1-master > > Does "atacontrol list" show the existence of disks ad0 and ad2? If so, > then the message probably indicate "ad0 exists but there's missing > metadata, so I'm ignoring it". If not, then I have no real explanation > other than it sounds like the SATA controller is broken. Yes. I agree. > > Just to clarify, the array was created using atacontrol so why it's > > reporting Intel MatrixRAID I have no idea. > Are you absolutely 100% positively certain that your system/motherboard > does not have "SATA RAID" enabled in the system BIOS? The ar0 "Intel > MatrixRAID" line really has me concerned. If MatrixRAID is indeed > enabled in the BIOS, then almost all these problems can be explained. Yep. Agreed! 100% positive. I've just double checked. SATA RAID Enable is definitely set to Disabled in the BIOS. > > Trying to rebuild the array with atacontrol rebuild ar0 gives: > > > > atacontrol: ioctl(IOCATARAIDREBUILD): Input/output error > > > > So I tried to detach channel ata0 and reattach it. This appeared to go > > ok. Trying to rebuild the array again gave the same error as above. > > More on this later. > > > I found a post on nabble (can't find it now!) where a chap was having > > the same problem rebuilding his RAID1 array using atacontrol rebuild. > > Turns out that because it's a software RAID array, atacontrol rebuild > > won't work. The only recommended way to get the array back on track was > > to dd the contents of the healthy drive onto the new drive. I tried this > > just to see what would happen: > > > > dd if=/dev/ad2 of=/dev/ad0 bs=1024k > > > > Seemed to work just fine as expected. I was hoping that after another > > reboot, atacontrol would have seen ad0 as the missing array device on > > chanel 0, done anything required and hey presto, I'd have a health RAID > > 1 array again. > > > > Sadly, not. atacontrol still insists that the array is DEGRADED despite > > having manually mirrored the contents of ad2 to ad0. > > This probably has to do with corrupt/missing/incorrect metadata. The dd > method (to copy disk X to disk Y) isn't sufficient. Yes I suspected as much :-( It felt an extremely flimsy, optimistic and pathetic long shot. > The atacontrol man page states the following for your situation: > > If the system has a pure software array and is not using a "real" ATA > RAID controller, then shut the system down, make sure that the disk that > was still working is moved to the bootable position (channel 0 or what‐ > ever the BIOS allows the system to boot from) and the blank disk is > placed in the secondary position, then boot the system into single-user > mode and issue the command: > > atacontrol addspare ar0 ad6 > atacontrol rebuild ar0 > > So I believe what the man page is telling you to do is: > > 1) Power down the system > 2) Physically connect the ad2 (working/has-data) disk to SATA channel 0 > 3) Physically connect the ad0 (brand-new) disk to SATA channel 1 > 4) Make mental note that the disk names will now be swapped: ad0 will > now be the working/has-data disk, and ad2 will be the brand-new disk > 5) Power up the system and make sure you're booting from SATA channel 0 > 5) Go into single-user > 6) Execute: > atacontrol addspare ar0 ad2 > atacontrol rebuild ar0 > > I have no idea if this will work or not. Worked a treat. I didn't swap the drives around but with ad2 running as the 'good' bootable disk and with a new disk in the ad0 position: # atacontrol addspare ar0 ad0 ad0: inserted into ar0 disk0 as spare # atacontrol rebuild ar0 # atacontrol status ar0 ar0: ATA RAID1 status: REBUILDING 0% completed subdisks: 0 ad0 SPARE 1 ad2 ONLINE ..some time later.. # atacontrol status ar0 ar0: ATA RAID1 status: READY subdisks: 0 ad0 ONLINE 1 ad2 ONLINE Immediately followed by: ad0: WARNING - WRITE_DMA taskqueue timeout - completing request directly ad0: WARNING - WRITE_DMA48 freeing taskqueue zombie request > If this doesn't work, I'm out of ideas other than restoring from backups > or running in degraded mode to back up your data, then afterward, > rebuild the system using something like gmirror. > So it appears to be ok! :-) And upon reboot, everything also seems ok. Phew! The warnings above are somewhat concerning but I wonder if these wouldn't be seen with newer kernels (given the talk of increasing ata timeouts etc)... Incidentally, is there a way to easily migrate from a atacontrol created array to a gmirror created array? I'm running FreeBSD 8.0 on another machine with a gmirror created RAID1 array with no problem whatsoever (I chose gmirror as the choice for this machine over atacontrol after reading various postings about software RAID under recent releases of FreeBSD). I was planning on upgrading the 7.2 machine to 8.0-RC1 anyway so if I could easily move to using gmirror then I would. That said, atacontrol should (I assume) function correctly with 8.x, shouldn't it, or is support of it dwindling somewhat? How easy is it to upgrade an array to use larger disks - atacontrol or gmirror? Feel free to respond with RTFM :-) I suppose one possible solution would be to use something like GpartEd (example Linux land tool) to grow a certain partition on an array (eg the partition mounted on /usr/local). That way both partitions on each of the separate array subdisks would be grown transparently since the operation would be performed on partition ar0s1 (ie, taken care of by atacontrol / gmirror). Thank you for taking the time time to detail and describe things for me to try, Jeremy. I very much appreciate it indeed. Normal services have been resumed! :-) Cheers, -- Matt