Re: 7.2-RELEASE-p4, IO errors RAID1 failure
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=51READY,DSC,ERROR
error=10NID_NOT_FOUND 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 last LBA. 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.
[r...@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 EnableValue Vendor
write cacheyes 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/0xFE128/0x80
[r...@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:
Re: bwn(4) on 8.1-RC1: connection problems
On Sun, Jun 20, 2010 at 2:23 PM, Quentin Stievenart acier...@awesom.eu wrote: 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST 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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST 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 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_b...@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: Broadcom BCM4318 802.11b/g Wireless 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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[stable 7]config -g -ppp + kgmon causes deadlock
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.2-RELEASE-p4, IO errors RAID1 failure
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. -- Bob Bishop r...@gid.co.uk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bwn(4) on 8.1-RC1: connection problems
On Tue, Jun 22, 2010 at 11:18:04AM +, Paul B Mahol wrote: Where is weptxkey. Read manual again. Oh sorry, I missed that. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
panic during boot on 8.0-RELEASE
Oops, sent this to the wrong list. --Nick -- Forwarded message -- From: Nicholas Mills nlmi...@g.clemson.edu Date: Tue, Jun 22, 2010 at 7:41 PM Subject: panic during boot on 8.0-RELEASE To: freebsd-curr...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
The mouse appears on screen but doesn't move.
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 r...@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 @ 0xd000/268435456, 0xfe9f/65536, 0xfe80/1048576, I/O @ 0xd000/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:
Re: The mouse appears on screen but doesn't move.
On Tue, Jun 22, 2010 at 7:14 PM, Nathan Maier maier.nat...@gmail.comwrote: 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: snip (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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 8.1-PRERELEASE: WARNING ioctl sign-extension ioctl ffffffff8004667e
Hi, I am getting more than 4 thousand of the following messages a day: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl 8004667e 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 li...@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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: The mouse appears on screen but doesn't move.
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 r...@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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
