Bridge stopped bridging after upgrade from 11-STABLE to 12-STABLE
I’m probably just missing something, but I don’t see anything obviously wrong
and Google is not being helpful.
I have em0 and wlan0 bridged on my internal network, but wireless devices
cannot access wired devices and vice versa - except for the bridging host
itself. That used to work before I upgraded to 12-STABLE.
How should I recover connectivity between both media?
In rc.conf I have:
---
# Wireless
wlans_ath0="wlan0"
create_args_wlan0="wlanmode hostap"
# Bridged interfaces (see example at man 4 bridge)
cloned_interfaces="bridge0"
ifconfig_bridge0="addm em0 addm wlan0 stp em0 stp wlan0 up"
ifconfig_bridge0_alias0="inet 10.0.0.1/24"
ifconfig_bridge0_ipv6_alias0="inet6 fe80::6efd:b9ff:fe68:db36%bridge0"
ifconfig_wlan0="ssid solfertje country NL mode 11g channel 9:ht/40 up"
ifconfig_wlan0_ipv6="inet6 accept_rtadv"
hostapd_enable="YES"
ifconfig_em0="tso up"
ifconfig_em0_ipv6="inet6 accept_rtadv”
---
Resulting in these interfaces:
---
wlan0: flags=8943 metric 0 mtu
1500
ether 6c:fd:b9:68:db:36
inet6 fe80::6efd:b9ff:fe68:db36%wlan0 prefixlen 64 scopeid 0x4
groups: wlan
ssid solfertje channel 9 (2452 MHz 11g) bssid 6c:fd:b9:68:db:36
regdomain 32924 country CN indoor ecm authmode WPA2/802.11i
privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit
txpower 20 scanvalid 60 protmode CTS wme burst dtimperiod 1 -dfs
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: running
nd6 options=23
em0: flags=8943 metric 0 mtu
1500
options=812099
ether 68:05:ca:17:fe:f7
inet6 fe80::6a05:caff:fe17:fef7%em0 prefixlen 64 scopeid 0x1
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=23
bridge0: flags=8843 metric 0 mtu 1500
ether 02:95:bb:bd:98:00
inet 10.0.0.1 netmask 0xff00 broadcast 10.0.0.255
id 68:05:ca:17:fe:f7 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 68:05:ca:17:fe:f7 priority 32768 ifcost 0 port 0
member: wlan0 flags=167
ifmaxaddr 0 port 4 priority 128 path cost 3 proto rstp
role designated state forwarding
member: em0 flags=1e7
ifmaxaddr 0 port 1 priority 128 path cost 2 proto rstp
role designated state forwarding
groups: bridge
nd6 options=9
—
Regards,
Alban Hertroys
P.S. The package for postgresql10-server links to icu libraries version 61,
while version 64 gets installed. I should be running PG 11, I know, working on
that ;)
--
There is always an exception to always.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
make buildworld breaks on missing yacc.h
For me, make buildworld breaks on missing yacc.h. A very similar issue was reported Mar 2, 2016, which was then fixed by r296324 (see: https://lists.freebsd.org/pipermail/freebsd-current/2016-March/059946.html). # uname -a FreeBSD home 11.1-STABLE FreeBSD 11.1-STABLE #1 r329516: Sun Feb 18 15:10:03 CET 2018 me@home:/usr/obj/usr/src/sys/BUFFALO amd64 # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/11 Relative URL: ^/stable/11 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 345532 Node Kind: directory Schedule: normal Last Changed Author: hselasky Last Changed Rev: 345532 Last Changed Date: 2019-03-26 14:35:23 +0100 (Tue, 26 Mar 2019) Command was a plain # make buildworld (…) ===> usr.bin/mkesdb_static (obj,build-tools) Building /usr/obj/usr/src/usr.bin/mkesdb_static/lex.o /usr/src/usr.bin/mkesdb/lex.l:46:10: fatal error: 'yacc.h' file not found #include "yacc.h" ^~~~ 1 error generated. *** Error code 1 Stop. make[3]: stopped in /usr/src/usr.bin/mkesdb_static .ERROR_TARGET='lex.o' .ERROR_META_FILE='/usr/obj/usr/src/usr.bin/mkesdb_static/lex.o.meta' .MAKE.LEVEL='3' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='cc -O2 -pipe -I/usr/src/usr.bin/mkesdb_static -I/usr/src/usr.bin/mke sdb_static/../mkesdb -I/usr/src/usr.bin/mkesdb_static/../../lib/libc/iconv -g -std=gnu99 -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -c lex .c -o lex.o; ;' .CURDIR='/usr/src/usr.bin/mkesdb_static' .MAKE='make' .OBJDIR='/usr/obj/usr/src/usr.bin/mkesdb_static' .TARGETS='build-tools' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/usr/obj' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20170720' PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /us r/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk / etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /usr/s rc/usr.bin/mkesdb_static/Makefile /usr/src/usr.bin/mkesdb/Makefile.inc /usr/src/ tools/build/mk/bsd.prog.mk /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.i nit.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share /mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/usr.bin/mkesdb_static/. ./Makefile.inc /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /u sr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/m k/src.libnames.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.nls.mk /us r/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd .incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/sh are/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.o bj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk /usr/src/tool s/build/mk/Makefile.boot' .PATH='. /usr/src/usr.bin/mkesdb_static /usr/src/lib/libc/iconv /usr/src/usr.bin /mkesdb' *** Error code 1 Stop. make[2]: stopped in /usr/src .ERROR_TARGET='build-tools_usr.bin/mkesdb_static' .ERROR_META_FILE='' .MAKE.LEVEL='2' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='.PHONY' .CURDIR='/usr/src' .MAKE='make' .OBJDIR='/usr/obj/usr/src' .TARGETS='build-tools' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: kern.sched.quantum: Creepy, sadistic scheduler
t;correct" value for the quantum depends on your type of workload. PostgreSQL's auto-vacuum is a typical background process that will probably (I didn't verify) request to be run at a lower priority, giving other, more important, jobs more chance to get picked from the ready queue (provided that the OS implements priority for the ready queue). That is probably why your endless loop gets much more CPU time than the VACUUM process. It may be that FreeBSD's default value for the quantum is not suitable for your workload. Finding the one best suited to you is not particularly easy though - perhaps FreeBSD allows access to average job times (below quantum) that can be used to calculate a reasonable average from. That said, SCHED_ULE (the default scheduler for quite a while now) was designed with multi-CPU configurations in mind and there are claims that SCHED_4BSD works better for single-CPU configurations. You may give that a try, if you're not already on SCHED_4BSD. A much better option in your case would be to put the database on a multi-core machine. > [1] > A pure-I/O job without compute load, like "dd", does not show > this behaviour. Also, when other tasks are running, the unjust > behaviour is not so stongly pronounced. That is probably because dd has the decency to give the reins back to the scheduler at regular intervals. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ryzen issues on FreeBSD ? (summary of 4 issues)
On 24 January 2018 at 15:42, Mike Tancsa wrote: > b) CPUs manufactured prior to week 25 (some say week 33?) have a > hardware defect that manifests itself as segfaults in heavy compiles. I > was able to confirm this on 1 of the CPUs I had using a Linux setup. It > seems to confirm this, you need to physically look at the CPU for the > manufacturing date :( Not sure how to trigger it on FreeBSD reliably, > but there is a github project I used to verify on Linux > (https://github.com/suaefar/ryzen-test) According to post #39 in the referenced Linux thread (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085): "It was officially fixed for all ryzen manufactured after week 30." I currently have a Ryzen 1600X from week 17/30, which suggests it will have the bug. Unfortunately, I don't have it built into a system yet as I'm waiting for DDR4 prices to become reasonable again before ordering any, so I can't test it. I'm not sure how solid this info is, should I RMA it without even having tested that it has a problem? Alban Hertroys -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: hostapd loses connectivity on ath0
> On 26 Oct 2015, at 22:10, Adrian Chadd wrote: > > hiya, > > you should try -head. > > But there's some long standing issues hiding around in the AR9227 code > somewhere where they occasionally go deaf and I never figured out > why... :( Frankly, I'm not too eager attempting to run -head on my home gateway/firewall/wifi AP/file server, especially not if there is little chance that this issue is fixed there. I don't have a whole lot of spare time to mess with it and outside of that I need a working server. In the mean time, I noticed these messages in my daily security run output after several restarts of hostapd over the last couple of weeks: +ath0: ath_tx_default_comp: bf 0xfe0001359fc8: seqno 2659: bf_next not NULL! +ath0: ath_tx_default_comp: bf 0xfe00013407c8: seqno 2660: bf_next not NULL! +ath0: ath_tx_default_comp: bf 0xfe000135c2d8: seqno 2661: bf_next not NULL! +wlan0: ieee80211_new_state_locked: pending RUN -> SCAN transition lost (I'm guessing a lockup of the card is imminent again) Is that any help in getting closer to the cause? Is there any info I might be able to provide when it locks up again? If this isn't a hardware bug, I would like to see this fixed if possible in the current constraints. Or should I just swap my ath card for a different model (or brand)? If so, which are safe? Regards, > On 26 October 2015 at 13:27, Alban Hertroys wrote: >> At random times my devices suddenly fail to connect to Wifi on my ath0 >> device. Issueing /etc/rc.d/hostapd restart usually resolves the issue, but >> at some point that also hung. >> >> Shutting down to single user mode in the hung state only partially >> succeeded, in the sense that ifconfig, hostapd and a few other >> network-related processes kept "running" - I assume the hangup of hostapd >> was caused by a hung process somewhere in that tree. >> >> The system is: >> >> uname -a >> FreeBSD solfertje 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #19 r286718: Thu >> Aug 13 10:00:32 CEST 2015 dalroi@solfertje:/usr/obj/usr/src/sys/ANTELOPE >> amd64 >> >> It's quite possible that I've misconfigured something, so here's the >> relevant lines of my configs… >> >> rc.conf: >> >> # Outside interface >> ifconfig_fxp0="DHCP" >> ifconfig_fxp0_ipv6="inet6 accept_rtadv" >> >> # Wireless >> wlans_ath0="wlan0" >> >> create_args_wlan0="wlanmode hostap" >> >> ifconfig_wlan0="mode ng channel 9:ht/40" >> ifconfig_wlan0_ipv6="inet6 accept_rtadv" >> >> # Bridged interfaces (see example at man 4 bridge) >> cloned_interfaces="bridge0" >> ifconfig_bridge0="addm em0 stp em0 addm wlan0 stp wlan0 up" >> ifconfig_bridge0_alias0="inet 10.236.150.1/24" >> ifconfig_bridge0_ipv6_alias0="inet6 fe80::6efd:b9ff:fe68:db36%bridge0" >> >> # Internal wired ethernet (should that be above the bridge declaration?) >> ifconfig_em0="up" >> ifconfig_em0_ipv6="inet6 accept_rtadv" >> >> hostapd_enable="YES" >> >> #= >> >> hostapd.conf: >> >> interface=wlan0 >> driver=bsd >> debug=1 >> ctrl_interface=/var/run/hostapd >> ctrl_interface_group=wheel >> ssid=foo >> country_code=NL >> ieee80211d=1 >> hw_mode=g >> wpa=2 >> wpa_passphrase=nonononono >> wpa_key_mgmt=WPA-PSK >> wpa_pairwise=CCMP >> >> >> The ath0 device is: >> pciconf -lv ath0 >> ath0@pci0:5:6:0:class=0x028000 card=0x0300168c chip=0x002d168c >> rev=0x01 hdr=0x00 >>vendor = 'Atheros Communications Inc.' >>device = 'AR9227 Wireless Network Adapter' >>class = network >> >> In case it's relevant: All connected devices get their IPv4 addresses >> through DHCP from this machine, the machine itself gets it's IPv4 external >> address from my upstream provider, the internal addresses are hardwired per >> interface. DHCP is configured to use hostnames (instead of IP's) that get >> looked up in Bind9 on the same machine. >> >> >> Google did find some people on the internet with apparently the same >> problem, but nobody seems to have found (or posted) a resolution. >> >> Am I doing something wrong? If not, is this a known issue? What's the next >> step? >> >> Alban Hertroys >> -- >> If you can't see the forest for the trees, >> cut the trees and you'll find there is no forest. >> >> ___ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
hostapd loses connectivity on ath0
At random times my devices suddenly fail to connect to Wifi on my ath0 device. Issueing /etc/rc.d/hostapd restart usually resolves the issue, but at some point that also hung. Shutting down to single user mode in the hung state only partially succeeded, in the sense that ifconfig, hostapd and a few other network-related processes kept "running" - I assume the hangup of hostapd was caused by a hung process somewhere in that tree. The system is: uname -a FreeBSD solfertje 10.2-PRERELEASE FreeBSD 10.2-PRERELEASE #19 r286718: Thu Aug 13 10:00:32 CEST 2015 dalroi@solfertje:/usr/obj/usr/src/sys/ANTELOPE amd64 It's quite possible that I've misconfigured something, so here's the relevant lines of my configs… rc.conf: # Outside interface ifconfig_fxp0="DHCP" ifconfig_fxp0_ipv6="inet6 accept_rtadv" # Wireless wlans_ath0="wlan0" create_args_wlan0="wlanmode hostap" ifconfig_wlan0="mode ng channel 9:ht/40" ifconfig_wlan0_ipv6="inet6 accept_rtadv" # Bridged interfaces (see example at man 4 bridge) cloned_interfaces="bridge0" ifconfig_bridge0="addm em0 stp em0 addm wlan0 stp wlan0 up" ifconfig_bridge0_alias0="inet 10.236.150.1/24" ifconfig_bridge0_ipv6_alias0="inet6 fe80::6efd:b9ff:fe68:db36%bridge0" # Internal wired ethernet (should that be above the bridge declaration?) ifconfig_em0="up" ifconfig_em0_ipv6="inet6 accept_rtadv" hostapd_enable="YES" #= hostapd.conf: interface=wlan0 driver=bsd debug=1 ctrl_interface=/var/run/hostapd ctrl_interface_group=wheel ssid=foo country_code=NL ieee80211d=1 hw_mode=g wpa=2 wpa_passphrase=nonononono wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP The ath0 device is: pciconf -lv ath0 ath0@pci0:5:6:0:class=0x028000 card=0x0300168c chip=0x002d168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9227 Wireless Network Adapter' class = network In case it's relevant: All connected devices get their IPv4 addresses through DHCP from this machine, the machine itself gets it's IPv4 external address from my upstream provider, the internal addresses are hardwired per interface. DHCP is configured to use hostnames (instead of IP's) that get looked up in Bind9 on the same machine. Google did find some people on the internet with apparently the same problem, but nobody seems to have found (or posted) a resolution. Am I doing something wrong? If not, is this a known issue? What's the next step? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ix(intel) vs mlxen(mellanox) 10Gb performance
On 17 August 2015 at 13:54, Slawa Olhovchenkov wrote: > On Mon, Aug 17, 2015 at 01:49:27PM +0200, Alban Hertroys wrote: > >> On 17 August 2015 at 13:39, Slawa Olhovchenkov wrote: >> >> > In any case, for 10Gb expect about 1200MGB/s. >> >> Your usage of units is confusing. Above you claim you expect 1200 > > I am use as topic starter and expect MeGaBytes per second That's a highly unusual way of writing MB/s. There are standards for unit prefixes: k means kilo, M means Mega, G means Giga, etc. See: https://en.wikipedia.org/wiki/International_System_of_Units#Prefixes >> million gigabytes per second, or 1.2 * 10^18 Bytes/s. I don't think >> any known network interface can do that, including highly experimental >> ones. >> >> I suspect you intended to claim that you expect 1.2GB/s (Gigabytes per >> second) over that 10Gb/s (Gigabits per second) network. >> That's still on the high side of what's possible. On TCP/IP there is >> some TCP overhead, so 1.0 GB/s is probably more realistic. > > TCP give 5-7% overhead (include retrasmits). > 10^9/8*0.97 = 1.2125 In information science, Bytes are counted in multiples of 2, not 10. A kb is 1024 bits or 2^10 b. So 10 Gb is 10 * 2^30 bits. It's also not unusual to be more specific about that 2-base and use kib, Mib and Gib instead. Apparently you didn't know that... Also, if you take 5% off, you are left with (0.95 * 10 * 2^30) / 8 = 1.1875 B/s, not 0.97 * ... Your calculations were a bit optimistic. Now I have to admit I'm used to use a factor of 10 to convert from b/s to B/s (that's 20%!), but that's probably no longer correct, what with jumbo frames and all. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ix(intel) vs mlxen(mellanox) 10Gb performance
On 17 August 2015 at 13:39, Slawa Olhovchenkov wrote: > In any case, for 10Gb expect about 1200MGB/s. Your usage of units is confusing. Above you claim you expect 1200 million gigabytes per second, or 1.2 * 10^18 Bytes/s. I don't think any known network interface can do that, including highly experimental ones. I suspect you intended to claim that you expect 1.2GB/s (Gigabytes per second) over that 10Gb/s (Gigabits per second) network. That's still on the high side of what's possible. On TCP/IP there is some TCP overhead, so 1.0 GB/s is probably more realistic. WRT the actual problem you're trying to solve, I'm no help there. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 4TB Western Digital My Book 1230 USB hard drive not working on 10.2
On 3 August 2015 at 15:01, Paul Mather wrote: > On Aug 2, 2015, at 9:34 PM, Adam McDougall wrote: > >> On 08/02/2015 21:22, Paul Mather wrote: >>> I have a 4TB external USB drive (Western Digital My Book 1230) that I am >>> trying to use under FreeBSD/amd64 10.2 (10.2-PRERELEASE #0 r286052: Wed Jul >>> 29 20:59:39 EDT 2015). This system has a MSI 760GMA-P34 (FX) motherboard. >>> >>> The drive probes unreliably when plugged in to a USB 3 port. It reliably >>> probes when plugged into a USB 2 port. However, it works in neither cases. >>> Attempting to dd from the drive results in a "dd: /dev/da0: Invalid >>> argument". FYI: I had been experiencing the same with a 2 TB WD MyBook on OS X (Mavericks). The drive was being used for Time Machine backups, but it would at irregular intervals it would just 'disconnect' itself. My guess is that there's a firmware problem in the USB3 chip in those drives. After trying to get the issue fixed for almost half a year I returned it and replaced it by a Seagate, which has been working flawlessly ever since. I'm just saying, perhaps the problem isn't with FreeBSD but with the drive. Cheers. ___ 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: how to remove usb-storage devices without CAM errors
On 8 August 2013 05:56, Michael Schuh wrote: > ugen3.2: at usbus3 > umass0: on usbus3 > umass0: SCSI over Bulk-Only; quirks = 0x0100 > umass0:8:0:-1: Attached to scbus8 > da0 at umass-sim0 bus 0 scbus8 target 0 lun 0 > da0: Removable Direct Access SCSI-6 device > da0: 40.000MB/s transfers > da0: 7385MB (15124992 512 byte sectors: 255H 63S/T 941C) > da0: quirks=0x2 > > ugen7.2: at usbus7 > umass1: on usbus7 > umass1: SCSI over Bulk-Only; quirks = 0x0100 > umass1:9:1:-1: Attached to scbus9 > da1 at umass-sim1 bus 1 scbus9 target 0 lun 0 > da1: Removable Direct Access SCSI-6 device > da1: 40.000MB/s transfers > da1: 7385MB (15124992 512 byte sectors: 255H 63S/T 941C) > da1: quirks=0x2 > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 02 44 80 00 00 80 00 > ugen3.2: at usbus3 (disconnected) > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > umass0: (da0:at uhub3, port 3, addr 2 (disconnected) > umass-sim0:0:0:0): Retrying command > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 02 44 80 00 00 80 00 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (da0:umass-sim0:0:0:0): Retrying command > I'm mostly guessing, but what I suspect that happens is that after you successfully remove da0, the former da1 becomes da0 and any operations on da1 (or da2 that now became da1) get aborted. That you just happen to have exactly identical USB sticks in this case does not help diagnosing whether that's the case though. I'm really hoping this isn't actually what happens here, but it would explain what you're seeing. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ 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: hme0 interface going up/down (dhclient ?)
On 9 July 2013 16:05, dcx dcy wrote: > Hi all, > > I am having an issue where my hme0 interface is always turning up > and down with dhclient requesting a lease. > > > > I am thinking this could be the same issue described by Jeremy Chadwick on > June 9th: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-June/073711.html > > Sounds like it. I recall someone warned that this issue would pop up with more (especially older) ethernet drivers. I was one of the people that ran into this on the em driver (Intel EtherExpress 100Mbit), which got a fairly prompt fix after I raised the issue. Since this is apparently caused by an interaction between the dhclient interface up/down detection mechanism and various wired ethernet interface drivers, it seems to me that it would help to be able to turn off dhclient's detection feature (or can we do that already?). The feature seems to be mostly useful for mobile devices (laptops and such) who tend to leave and enter different wireless network areas and need a new lease at that point. With wired interfaces, especially those that don't change physical location, the feature seems mostly pointless. Being able to turn it on or off at will seems useful and it would give other people running into this an easy way out. Regards, -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ 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: ZFS Panic after freebsd-update
On Jul 1, 2013, at 19:04, Jeremy Chadwick wrote: > But even stable/X doesn't provide enough coverage at times (the recent > fxp(4)/dhclient issue is proof of that). It's just too bad so many > people have this broken mindset of what "stability" means on FreeBSD. As one of the few persons who have run into that issue I feel like I should speak up here and add that this issue was fixed within a very reasonable time span after raising the matter here on freebsd-stable@. You've personally been a great help in getting that fixed, so thank you for that. Apparently there was one earlier report of the issue very late in the pre-release process, which does imply that fxp hardware is fairly rarely in use among FreeBSD users these days (which was the excuse for how the issue passed testing for 8.4/9.1 RELEASE). I don't think the release engineering team can really be blamed for not catching bugs that go unreported that far into the release cycle; they have to make a decision when to release at some point and the later it gets into the cycle the harder it is to turn that decision around. I can completely understand that. That this happened was inconvenient, but it happens in stable. ISTR that "stable" doesn't mean stable in the sense that it won't crash, but rather that the API's won't change until the next release. I wish other OS companies were as reliable; both MS and Apple let a lot more slip by and they take a lot longer to release fixes as well. Of course nobody likes when their system behaves erratically due to some error outside their control, but until that point FreeBSD has been rock-solid for me for years. And even with this issue, the system was usable. To get back to the ZFS issue... ZFS has always seen a fairly large fraction of raised issues on this list. Often those were user mistakes, ranging from putting not enough memory into the system to not assigning enough to the ZIL (once that became usable). ZFS on FreeBSD has come a long way since then. I don't think it's in quite as usable a state on, for example, Linux. Yes, people are taking a risk when using ZFS for everything. The same goes for any FS. No matter which file system you use, if it breaks you're between a rock and a hard place. Depending on how badly broken it is, you may end up not being able to access your data and with some data that's not an option. That's what we have backups and test environments for, don't we? File system code can break. It shouldn't, and I think it's safe to say that in FreeBSD's history it has been very rare indeed, but it does happen. The problem is probably more that it's so rare that people don't take measures for the few times it does happen; like how many of us have an atomic shelter available to them? Or a rubber boat? How many nuclear incidents have there been versus how many serious file-system breakages in FreeBSD? How many of us first test an update to STABLE on an identical test system before upgrading our production servers? Jeremy, I know for a fact that you're a lot more on this list than I am and probably longer than I have been (I'm pretty sure you were around already back in the days when I started using FreeBSD 2.2.8), but in this case, as much respect as I have for you, I think you're overreacting a bit. And finally, we're having this whole discussion about how problematic FreeBSD's been (or not) recently WHILE THE OP HASN"T EVEN GOTTEN BACK TO ANSWER DETAILS ABOUT HIS ISSUE YET. Perhaps it's a bit early for that? It's entirely possible that we're looking at some hardware issue here or a user error that triggered a corner case that wasn't handled or something like that. P.S: Personally, I don't use ZFS because I'm a bit of a database nut and feel like log-based file-systems aren't a good match for database write loads, but that's mostly just me being pedantic. Cheers, Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: zpool labelclear destroys GPT data
On 14 June 2013 10:21, Daniel O'Connor wrote: > > On 14/06/2013, at 17:48, Alban Hertroys wrote: > > IMHO it would be helpful to verify what's there first and warn the user > about it if such an operation will overwrite a different type of label than > what is about to get written there. > > Perhaps it should even refuse to write (by issuing an error stating that > there is already a label there - and preferably also what type) until the > label that's already there gets explicitly cleared by the user or until the > command gets forced. > > Does that make sense? > > The problem with this is that then each label tool needs to know about > every other label format you want to detect for.. > Isn't it possible to add such information to labels, so that the tools at least know "who" to ask what they're dealing with? > > If a label format has a checksum then you could ignore a request to nuke > the label if there is no valid checksum (with a flag to force). No idea how > many have checksums though.. > If there is no guaranteed method of identifying "data" on the disk as a label, then you can't warn the user in all cases. That's not particularly helpful for those cases where you can't warn the user. That's possibly a worse situation than what started this thread. -- If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ 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: zpool labelclear destroys GPT data
On 14 June 2013 10:02, Daniel O'Connor wrote: > > On 14/06/2013, at 17:05, Johan Hendriks wrote: > >> Of course, zpool(8) will do exactly what you tell it to do. It does > >> not know about any partitioning schemes and assumes that the user > >> knows that using labelclear on a the whole disk will potentially > >> destroy all data on it including any partitioning information. > >> > > Well as i found out, zpool(8) does not know what it clears. ! :D > > > > I think an adjustment to the man page is in order here. > > The man page clearly state it removes ZFS labels, not GPT, gmirror and > glabel labels. > > It should mention it will remove labels from the disk/device, and that > it clears ALL labels. > > > > If a user reads the man page it now looks save to use labelclear. > > I thougt that zpool would know if there was zpool label information on > the disk, and if i a case there is no ZFS label information it will tell me > that! > > In my case i did not loose anything, so no big deal but there will > proberbly be someone who gets bitten by this. > > > > A plus is that i found a new way to clear my disks fast ! ;) > > > It only clears ZFS labels, just because GPT & gmirror information sits in > a similar place doesn't make that incorrect. > > You are saying the equivalent of.. > Why does "dd if=/dev/zero of=/dev/da0" erase my whole disk, not just the > first partition? > > ie you are giving the tool bad options and then complaining when it > doesn't do what you meant :) > > Perhaps it should be modified to check if there is valid ZFS data there > before proceeding (although that could be annoying unless there is a way to > force it), and/or the man page could be amended to say it doesn't do any > checks before erasing things. > The same goes for several geom labels. For example, if you write a geom_mirror label to a GPT-partitioned disk (as opposed to writing it to a partition within that disk), you overwrite the backup GPT table. I got recently warned not to do that (it didn't apply in my case, but still). IMHO it would be helpful to verify what's there first and warn the user about it if such an operation will overwrite a different type of label than what is about to get written there. Perhaps it should even refuse to write (by issuing an error stating that there is already a label there - and preferably also what type) until the label that's already there gets explicitly cleared by the user or until the command gets forced. Does that make sense? If you can't see the forest for the trees, Cut the trees and you'll see there is no forest. ___ 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: fxp0 interface going up/down/up/down (dhclient related?)
On Jun 9, 2013, at 13:45, YongHyeon PYUN wrote: > On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: >> I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, >> with dhclient requesting a lease each time in between. I think it's caused >> by dhclient: >> >> solfertje # dhclient -d fxp0 >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> send_packet: Network is down >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> ^C >> >> In above test I turned off devd (/etc/rc.d/devd stop) and background >> dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. >> There's practically no time spent between up/down cycles, this just keeps >> going on and on. >> fxp0 is the only interface that runs on DHCP. The others have static IP's. >> > > Try attached patch and let me know whether it also works for you. > I'm now running with this patch and the symptoms seem to have gone away. Thanks! Is there anything I should be aware of with this patch or anything you'd like to know about how it runs? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: fxp0 interface going up/down/up/down (dhclient related?)
On Jun 9, 2013, at 12:44, Jeremy Chadwick wrote: > On Sun, Jun 09, 2013 at 12:21:37PM +0200, Alban Hertroys wrote: >> I'm having an issue where my fxp0 interface keeps looping between DOWN/UP, >> with dhclient requesting a lease each time in between. I think it's caused >> by dhclient: >> >> solfertje # dhclient -d fxp0 >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> send_packet: Network is down >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> fxp0 link state down -> up >> DHCPREQUEST on fxp0 to 255.255.255.255 port 67 >> DHCPACK from 109.72.40.1 >> bound to 141.105.10.89 -- renewal in 7200 seconds. >> fxp0 link state up -> down >> ^C >> >> In above test I turned off devd (/etc/rc.d/devd stop) and background >> dhclient (/etc/rc.d/dhclient stop fxp0), and I still go the above result. >> There's practically no time spent between up/down cycles, this just keeps >> going on and on. >> fxp0 is the only interface that runs on DHCP. The others have static IP's. >> >> Initially I thought the issue might be caused by devd, because I have both >> ethernet and 822.11 type NICs (2x ethernet, 1x wifi) in that system. >> >> This is 9-STABLE from yesterday. >> >> Before, I had 9-RELEASE running on this system with the same config, and >> that worked well. > > And so what I predicted begins... > > The issue is described in the 8.4-RELEASE Errata Notes; the driver is > using the same driver version as in stable/9, hence you're experiencing > the same problem. See Open Issues: > > http://www.freebsd.org/releases/8.4R/errata.html > > No fix for this has been committed. It is still under discussions by > multiple kernel folks as to where the fix should be applied (dhclient or > the fxp(4) driver), because the changes made to dhclient (that tickle > this bug) may actually affect more drivers than just fxp(4). > > You can start by reading the (extremely long but very informative) > thread here. I do urge you to read all the posts, not skim them: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073440.html > http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/thread.html#73440 Goodness, and here I was hoping it was just a silly mistake I made… IIUC, the issue is a combination of: - dhclient now being aware of link state changes and - the fxp driver reinitializes for certain mode changes, such as assigning an IP address Which causes dhclient to think that the link state changed, fetch a "new" IP address and assigns it to the fxp adapter again, causing the same link state change over and over again. Is that about correct? > The only known workarounds at this time are: > > a) Cease use of DHCP; set a static IP in rc.conf, > > b) Try some of the patches mentioned within the above thread, > specifically this one: > http://lists.freebsd.org/pipermail/freebsd-stable/2013-May/073581.html Or c) Use DHCP with a static media setting: ifconfig_fxp0="DHCP media 100baseTX mediaopt full-duplex" That worked for two out of three people apparently. I'm not done reading this thread yet though and I noticed a patch by YongHyeon that I'll test first. > The patch is for head (CURRENT) so it may not patch cleanly. If not, > you can try to work the patch in yourself/by hand, or you can ask > Yong-Hyeon or others for help. > >> I'm not sure it's related, but on the wireless interface I get alot of: >> Jun 9 12:08:11 solfertje kernel: ath0: stuck beacon; resetting (bmiss count >> 4) > > Absolutely 100% unrelated. That issue has been around for years, and > the root cause varies tremendously. I discussed it back in February > 2011: > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-February/061700.html > > If you want to know how I solved that problem, I can tell you, but I'm > certain yo
fxp0 interface going up/down/up/down (dhclient related?)
Network Connection' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) speed 2.5(2.5) cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 6805ca17fef7 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error xhci1@pci0:4:0:0: class=0x0c0330 card=0x50071458 chip=0x70231b6f rev=0x01 hdr=0x00 class = serial bus subclass = USB cap 01[50] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[70] = MSI supports 4 messages, 64 bit, vector masks cap 10[a0] = PCI-Express 2 endpoint max data 128(1024) FLR link x1(x1) speed 5.0(5.0) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0003[190] = Serial 1 0101010101010101 PCI-e errors = Correctable Error Detected Unsupported Request Detected Corrected = Advisory Non-Fatal Error ath0@pci0:5:6:0:class=0x028000 card=0x0300168c chip=0x002d168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR9287 Wireless Network Adapter' class = network cap 01[44] = powerspec 2 supports D0 D3 current D0 fxp0@pci0:5:7:0:class=0x02 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9/0/1 Ethernet Pro 100' class = network subclass = ethernet cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 none2@pci0:5:14:0: class=0x0c0010 card=0x10001458 chip=0x30441106 rev=0xc0 hdr=0x00 vendor = 'VIA Technologies, Inc.' device = 'VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller' class = serial bus subclass = FireWire cap 01[50] = powerspec 2 supports D0 D2 D3 current D0 Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Serial terminal issues
On Jun 5, 2013, at 2:59, Jeremy Chadwick wrote: > On Tue, Jun 04, 2013 at 11:32:48PM +0200, Alban Hertroys wrote: >> I can't seem to get my serial terminal to work with my new system. >> >> I had a serial terminal connected to my old system that worked great >> and copied /boot.config, /boot/loader.conf and /etc/ttys settings over >> from it. >> >> The new system has a Gigabyte GA970A-UD3 board with just a serial >> header on the board. I bought a serial connector backplate in an >> electronics store and connected it to the board. Could the pinout be >> different or something? > > It is very possible. You should have asked Gigabyte what exact product > (specifically part number) to purchase that provided a > header-to-backplane DB9 port, or if they could send you one (many will > for free). Always use what the mainboard vendor tells you. Always. I contacted Gigabyte, but haven't heard from them yet. For the Dutch readers: their website is at gigabyte.co.nl. You absolutely don't want to go to gigabyte.nl - not safe for work, not at all (guess where I was…). > It's also very possible the cable you're using to connect from the > Gigabyte board to something (you didn't disclose what) is wired wrong. I doubt that. It has worked fine before in the same setup with the previous PC and only stopped working once I connected it to the new PC. The new PC is the only variable, I expect that's where the problem is. The other end of the serial cable is connected to a Bull serial terminal (TWSH004/A). The cable has been that same serial cable for the last 10 years or so. >>> cat /boot.config >> -D -S19200 > > Please try using "-S19200 -Dh" (please read carefully). The order of > the arguments may matter as well (there has been some speculation on the > lists about this, and I do not care to do the analysis; just passing > information on blindly). That's interesting, I didn't expect that. I'll test that when I get around to playing with the serial port again. That said, these settings worked in the old PC. I copied boot.config straight over from my backups. >>> cat /boot/loader.conf >> boot_multicons="YES" >> boot_serial="YES" >> comconsole_speed="19200" >> console="comconsole,vidconsole" > > You do not need any of this given what /boot.config contains. Please > remove it all. Good to know, I never liked having this information in duplicate. >>> From /var/log/messages: >> Jun 4 21:28:50 solfertje kernel: uart0: <16550 or compatible> port >> 0x3f8-0x3ff irq >> 4 flags 0x10 on acpi0 >> Jun 4 21:28:50 solfertje kernel: uart0: console (19200,n,8,1) >> Jun 4 21:28:50 solfertje kernel: orm0: at iomem >> 0xd5000-0xd67ff,0xd7000-0xd7fff on isa0 >> Jun 4 21:28:50 solfertje kernel: sc0: at flags 0x100 on >> isa0 >> Jun 4 21:28:50 solfertje kernel: sc0: VGA <16 virtual consoles, flags=0x300> >> Jun 4 21:28:50 solfertje kernel: vga0: at port >> 0x3c0-0x3df iomem 0xa-0xb on isa0 >> Jun 4 21:28:50 solfertje kernel: atkbdc0: at >> port 0x60,0x64 on isa0 >> Jun 4 21:28:50 solfertje kernel: atkbd0: irq 1 on atkbdc0 >> Jun 4 21:28:50 solfertje kernel: kbd0 at atkbd0 >> Jun 4 21:28:50 solfertje kernel: atkbd0: [GIANT-LOCKED] > > Okay, so what's the problem? You're not seeing any I/O on the serial > port? I get a blank screen with just a cursor. It's not blinking because blinking cursors get on my nerves. Whether that means no I/O at all or the wrong kind of I/O I can't tell. I haven't set up a terminal like this in 10 years as the previous setup always just worked once set up. It's quite possible that I forgot some important detail. > How do you have your serial device connected to something on the > other end? Meaning: solfertje has a serial port, and it's connected to > what exactly? The Bull terminal mentioned above. > Are you sure the device its connected to is working? Well, it was still working great a few days ago before I replaced the PC it was connected to, so I assume it still does. (snipped useful information that doesn't apply to my case as my cable has proven to be correct) > >> I didn't see any options in the BIOS to set the console speed (just >> address and IRQ, those are in the above). ISTR that my old mobo did >> allow to set that information, but then again, that board (Tyan Tiger) >> gave me access to the BIOS through the serial console. > > This has absolutely no relevancy. I thought as much, but it is one obvious difference between the old and new situation... > Serial p
Serial terminal issues
I can't seem to get my serial terminal to work with my new system. I had a serial terminal connected to my old system that worked great and copied /boot.config, /boot/loader.conf and /etc/ttys settings over from it. The new system has a Gigabyte GA970A-UD3 board with just a serial header on the board. I bought a serial connector backplate in an electronics store and connected it to the board. Could the pinout be different or something? > cat /boot.config -D -S19200 > cat /boot/loader.conf boot_multicons="YES" boot_serial="YES" comconsole_speed="19200" console="comconsole,vidconsole" > cat /etc/ttys ttyv0 "/usr/libexec/getty Pc" xterm on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" xterm on secure ttyv2 "/usr/libexec/getty Pc" xterm on secure ttyv3 "/usr/libexec/getty Pc" xterm on secure ttyv4 "/usr/libexec/getty Pc" xterm on secure ttyv5 "/usr/libexec/getty Pc" xterm on secure ttyv6 "/usr/libexec/getty Pc" xterm on secure ttyv7 "/usr/libexec/getty Pc" xterm on secure ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyu0 "/usr/libexec/getty std.19200" vt320 on secure ttyu1 "/usr/libexec/getty std.9600" dialup off secure ttyu2 "/usr/libexec/getty std.9600" dialup off secure ttyu3 "/usr/libexec/getty std.9600" dialup off secure # Dumb console dcons "/usr/libexec/getty std.9600" vt100 off secure >From /var/log/messages: Jun 4 21:28:50 solfertje kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jun 4 21:28:50 solfertje kernel: uart0: console (19200,n,8,1) Jun 4 21:28:50 solfertje kernel: orm0: at iomem 0xd5000-0xd67ff,0xd7000-0xd7fff on isa0 Jun 4 21:28:50 solfertje kernel: sc0: at flags 0x100 on isa0 Jun 4 21:28:50 solfertje kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jun 4 21:28:50 solfertje kernel: vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Jun 4 21:28:50 solfertje kernel: atkbdc0: at port 0x60,0x64 on isa0 Jun 4 21:28:50 solfertje kernel: atkbd0: irq 1 on atkbdc0 Jun 4 21:28:50 solfertje kernel: kbd0 at atkbd0 Jun 4 21:28:50 solfertje kernel: atkbd0: [GIANT-LOCKED] I didn't see any options in the BIOS to set the console speed (just address and IRQ, those are in the above). ISTR that my old mobo did allow to set that information, but then again, that board (Tyan Tiger) gave me access to the BIOS through the serial console. What am I missing? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Corrupt GPT header on disk from twa array - fixable?
On Jun 3, 2013, at 1:09, Warren Block wrote: > On Mon, 3 Jun 2013, Alban Hertroys wrote: >>> >>> Really, the easiest way would be to temporarily install the old RAID >>> controller and copy the data off the array. >> >> Well, that would mean I'd have to assemble the old server again, as the >> controller is not compatible with the hardware in the new one. And that >> would probably be unnecessary as well, since I already did copy the data off >> those disks. >> >> I was just curious whether it would be possible to read that data off the >> disks while I still have them (with their original contents) in the new >> server in the eventuality that I _did_ forget to copy something over or that >> something wasn't copied over correctly. >> >> I copied the data over a 100MBit ethernet link, which was the fastest option >> I had with the old server; it had USB1 and no native SATA. Hence the RAID >> controller, but that was on a now deprecated PCI-X channel (those 64-bit >> parallel things) and all 4 ports were in use. Not to mention that the CPU >> was so old that it had a rather narrow margin for operating temperatures and >> overheated several times during the copying process, because rsync+sshd put >> a relatively high load on the CPU (An old Athlon XP 2000+). > > PCI-X cards will operate in PCI slots. Or at least some will; I've done that > with an Intel network card. The motherboard can't have components that block > the unused part of the edge connector, or the offending card edge could be > removed with extreme prejudice. Not this 3Ware card. I remember buying that particular motherboard because the card wouldn't fit in the PCI slots on the board I had. There's a division in those PCI-X slots opposite of where there's one in normal PCI slots and no groove in the card to match the division in the PCI slot. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Corrupt GPT header on disk from twa array - fixable?
On Jun 2, 2013, at 20:39, Warren Block wrote: > On Sun, 2 Jun 2013, Alban Hertroys wrote: >> On Jun 2, 2013, at 16:46, Warren Block wrote: >> I've never worked with gnop before; is this a safe approach?: >> >> # kldload geom_nop >> # gnop create -v -o 41943006 -S 512 ada4 >> # mount /dev/ada4.nop /mnt >> >> I get the impression that gnop might be non-destructive, but that's not >> entirely clear from the man page. > > Well, yes, but mount it read-only. gnop is (yet another) GEOM transform. It > should be non-destructive as long as you don't write to it. Yup, writing to them obviously could be destructive. I was aware of that, but I hadn't thought of mounting them read-only. Thanks. >> I tried the above on ada5 (the other half of the mirror that I applied gpart >> recover to earlier), but it spews: >> >> gnop: Invalid offset for provider ada5. >> >> What number does it expect for that offset? > > The trick would be figuring out what number was used by the RAID controller. Ah right, I need the start of the next volume. I think my calculation put me at the start of the RAID controllers volume header block for the first volume - a few sectors too early probably. I suppose it shouldn't take too long finding the start of the second volume with some trial and error now that I know to look past sector 41943005 + 1 + volume header size. I'll have a look whether perhaps the controllers' documentation mentions anything of a size... > >> And what exactly is gpart show showing? I was under the assumption that both >> would be sectors (which judging from the numbers would be 512 bytes in size). > > Yes, it's sectors--the last column is human-readable. But the GEOM logical > device might be constructed from the GPT parameters. It may not see the > additional blocks on the physical device until the GPT tables are repaired. > Which might corrupt the actual data. > > Really, the easiest way would be to temporarily install the old RAID > controller and copy the data off the array. Well, that would mean I'd have to assemble the old server again, as the controller is not compatible with the hardware in the new one. And that would probably be unnecessary as well, since I already did copy the data off those disks. I was just curious whether it would be possible to read that data off the disks while I still have them (with their original contents) in the new server in the eventuality that I _did_ forget to copy something over or that something wasn't copied over correctly. I copied the data over a 100MBit ethernet link, which was the fastest option I had with the old server; it had USB1 and no native SATA. Hence the RAID controller, but that was on a now deprecated PCI-X channel (those 64-bit parallel things) and all 4 ports were in use. Not to mention that the CPU was so old that it had a rather narrow margin for operating temperatures and overheated several times during the copying process, because rsync+sshd put a relatively high load on the CPU (An old Athlon XP 2000+). If I manage to get those volumes mounted with gnop, that would give me the opportunity to checksum the contents of the original disks with the copied content on the new disks. I'm sure that rsync is quite reliable, but I had a few hangs of the old server during the process and although rsync is capable of continueing where it left off, it'd be nice to be able to verify that worked as advertised. I'll experiment some more with gnop, but if that doesn't get me anywhere I'll probably just wipe those old disks with a new GPT partition table so that I can use them for storage again. There shouldn't be anything on it that I don't have already. > gmirror is good. GPT is also good. The combination is a problem. gmirror > metadata overwrites the backup GPT, so those disks will show "corrupt" also. > For now, the recommended workaround is to just use MBR, which doesn't have > any metadata at the end of the disk. Or you mirror the partitions on the disk as Jeremy pointed out, in which case the backup GPT goes to the end of the disk, while the gmirror meta-data goes to the end of each partition within that space. I get that now. Thanks for all the help, guys! If I figure out how to access those extra volumes, I'll report back. Who knows who'll run into the same problem some day (possibly less prepared for the situation). Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Corrupt GPT header on disk from twa array - fixable?
On Jun 2, 2013, at 17:48, Jeremy Chadwick wrote: > On Sun, Jun 02, 2013 at 05:12:48PM +0200, Alban Hertroys wrote: >> >> On Jun 2, 2013, at 16:46, Warren Block wrote: >> >>> On Sun, 2 Jun 2013, Alban Hertroys wrote: >>> >>>> On Jun 2, 2013, at 16:12, Kimmo Paasiala wrote: >>>>> >>>>> Looking at the gpart(8) output it seems that only 20GBs of the disk is >>>>> recognized by the disk driver but the GPT table still shows the full >>>>> capacity 910GB. I'd say that the GPT table is in fact correct and if >>>>> you can somehow get the disks to be recognized with full capacity they >>>>> should be usable as they are. What does dmesg(8) say about the disks? >>>> >>>> From dmesg: >>>> >>>> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >>>> ada2: usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) >>>> ATA-8 SATA 2.x device >>>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>>> USB_ERR_IOERROR >>>> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada2: Command Queueing enabled >>>> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >>>> ada2: Previously was known as ad8 >>>> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >>>> ada3: ATA-8 SATA 2.x device >>>> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >>>> ada3: Command Queueing enabled >>>> ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >>>> ada3: Previously was known as ad10 >>>> ada4 at ahcich4 bus 0 scbus4 target 0 lun 0 >>>> ada4: ATA-8 SATA 2.x device >>>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, >>>> ignored) >>>> ada4: 300.000MB/s transfers (SATA 2.x, usbd_setup_device_desc: getting >>>> device descriptor at addr 2 failed, USB_ERR_IOERROR >>>> UDMA6, PIO 8192bytes) >>>> ada4: Command Queueing enabled >>>> ada4: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >>>> ada4: Previously was known as ad12 >>>> ada5 at ahcich5 bus 0 scbus5 target 0 lun 0 >>>> ada5: ATA-8 SATA 3.x device >>>> ada5: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >>>> ada5: Command Queueing enabled >>>> ada5: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >>>> ada5: Previously was known as ad14 >>>> SMP: AP CPU #1 Launched! >>>> Timecounter "TSC-low" frequency 13371081 Hz quality 800 >>>> GEOM: ada2: the secondary GPT header is not in the last LBA. >>>> GEOM: ada3: the secondary GPT header is not in the last LBA. >>>> GEOM_MIRROR: Device mirror/boot launched (2/2). >>>> GEOM_MIRROR: Device mirror/swap launched (2/2). >>>> GEOM_MIRROR: Device mirror/root launched (2/2). >>>> GEOM: ada4: the secondary GPT header is not in the last LBA. >>>> GEOM: ada5: the secondary GPT header is not in the last LBA. >>> > I think you're missing what Warren is telling you, because you have > multiple things going on/complexities to deal with simultaneously. > > You haven't provided any details about your gmirror setup either. All > we know at this point: > >>>> GEOM_MIRROR: Device mirror/boot launched (2/2). >>>> GEOM_MIRROR: Device mirror/swap launched (2/2). >>>> GEOM_MIRROR: Device mirror/root launched (2/2). > > My gut feeling is ada2 and ada3 make up the mirror, and the mirror is at > the disk level (ada2 and ada3). I'm basing this on past evidence > presented in the thread, and having to make assumptions. No "gmirror > status" output = we have to make assumptions. The gmirror is actually on ada0+ada1, and not at all on the disks that I copied the dmesg information of. Those disks weren't in the hardware RAID array of the old server, and the gmirror isn't on the disks that were in that RAID controller. I took care to keep those separate until I can erase them and add them as "normal" disks. > Now, what Warren is telling you: gmirror + GPT do not play well > together. This is a design flaw** on the part of gmirror. If you want > to use gmirror with disks using GPT, your only solutions are to mirror > the partitions (adaXpX) and not the disk (adaX), which has its own set > of caveats, or to use the MBR scheme (and if these are 4K sectors disks, > or you plan on using those, you're even more screwed). I didn't kno
Re: Corrupt GPT header on disk from twa array - fixable?
On Jun 2, 2013, at 16:46, Warren Block wrote: > On Sun, 2 Jun 2013, Alban Hertroys wrote: > >> On Jun 2, 2013, at 16:12, Kimmo Paasiala wrote: >>> >>> Looking at the gpart(8) output it seems that only 20GBs of the disk is >>> recognized by the disk driver but the GPT table still shows the full >>> capacity 910GB. I'd say that the GPT table is in fact correct and if >>> you can somehow get the disks to be recognized with full capacity they >>> should be usable as they are. What does dmesg(8) say about the disks? >> >> From dmesg: >> >> ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 >> ada2: usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) >> ATA-8 SATA 2.x device >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >> USB_ERR_IOERROR >> ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada2: Command Queueing enabled >> ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada2: Previously was known as ad8 >> ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 >> ada3: ATA-8 SATA 2.x device >> ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> ada3: Command Queueing enabled >> ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) >> ada3: Previously was known as ad10 >> ada4 at ahcich4 bus 0 scbus4 target 0 lun 0 >> ada4: ATA-8 SATA 2.x device >> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) >> ada4: 300.000MB/s transfers (SATA 2.x, usbd_setup_device_desc: getting >> device descriptor at addr 2 failed, USB_ERR_IOERROR >> UDMA6, PIO 8192bytes) >> ada4: Command Queueing enabled >> ada4: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >> ada4: Previously was known as ad12 >> ada5 at ahcich5 bus 0 scbus5 target 0 lun 0 >> ada5: ATA-8 SATA 3.x device >> ada5: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) >> ada5: Command Queueing enabled >> ada5: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) >> ada5: Previously was known as ad14 >> SMP: AP CPU #1 Launched! >> Timecounter "TSC-low" frequency 13371081 Hz quality 800 >> GEOM: ada2: the secondary GPT header is not in the last LBA. >> GEOM: ada3: the secondary GPT header is not in the last LBA. >> GEOM_MIRROR: Device mirror/boot launched (2/2). >> GEOM_MIRROR: Device mirror/swap launched (2/2). >> GEOM_MIRROR: Device mirror/root launched (2/2). >> GEOM: ada4: the secondary GPT header is not in the last LBA. >> GEOM: ada5: the secondary GPT header is not in the last LBA. > > There is a lot of stuff going on there. > > You switched from a hardware RAID card to something else in the new machine. > Maybe a different card, or maybe just the motherboard. The old controller > may have put metadata on the drives and hidden it. On a new controller, that > metadata is not hidden. This would explain the "secondary GPT header is not > in the last LBA" message. > > If the old controller "split" the combined drives into virtual volumes, there > may be another GPT somewhere in the remainder of the drive. If you could > find that, gnop(8) could be used with an offset to mount it. This could be > another explanation for the GPT being "corrupt": the GPT at the start of the > drive is for the first volume, the backup GPT at the end of the drive is for > the second volume. It did indeed! I just sent a message about that, as I realised that wasn't clear from my original description. I think gnop(8) is the answer to my question. I've never worked with gnop before; is this a safe approach?: # kldload geom_nop # gnop create -v -o 41943006 -S 512 ada4 # mount /dev/ada4.nop /mnt I get the impression that gnop might be non-destructive, but that's not entirely clear from the man page. I tried the above on ada5 (the other half of the mirror that I applied gpart recover to earlier), but it spews: gnop: Invalid offset for provider ada5. What number does it expect for that offset? And what exactly is gpart show showing? I was under the assumption that both would be sectors (which judging from the numbers would be 512 bytes in size). > Finally, GPT and gmirror are combined. That's a problematic combination > because both want metadata in the last block of the drive. The new section in > the Handbook about RAID1 (gmirror) describes that in the "Metadata Issues" > section: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/GEOM-mirror.html I'm pretty sure the disks on the controller had nothing to do with gmirror eve
Re: Corrupt GPT header on disk from twa array - fixable?
I realise I only implied a fairly critical difference between the old and new situations: On Jun 2, 2013, at 15:53, Alban Hertroys wrote: > Hello list, > > I just replaced my home server and moved the disks from the old one over to > the new one. In the old server, 4 of the disks were connected to a twa (3Ware > 9550) controller, which of course has it's own way of marking units/volumes > on those disks. > > The thing is, I have these disks in the new server and I found that (to my > surprise) I can actually mount them! But, I'm missing a large part and I am > wondering if there's some method to access those last partitions too. The new server doesn't have the raid controller. The disks are directly connected to the onboard SATA ports. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Corrupt GPT header on disk from twa array - fixable?
On Jun 2, 2013, at 16:02, Steven Hartland wrote: > Does "gpart recover ada4" help at all? > > Be warned this could edit the partition on the disk and make it worse, but > I've had success in the past with it. I applied gpart recover to the other half of what was originally a mirror and it marked the missing parts as empty - which they weren't, so I'm glad I have two! (wouldn't have tried otherwise) I expected something like that would happen. The partition table only looks corrupt when you look at it when it's not connected to the raid controller. > - Original Message - From: "Alban Hertroys" > To: > Sent: Sunday, June 02, 2013 2:53 PM > Subject: Corrupt GPT header on disk from twa array - fixable? > > >> Hello list, >> >> I just replaced my home server and moved the disks from the old one over to >> the new one. In the old server, 4 of the disks were connected to a twa >> (3Ware 9550) controller, which of course has it's own way of marking >> units/volumes on those disks. >> >> Before you start yelling at me, yes, of course I made backups ;) [*] >> >> The thing is, I have these disks in the new server and I found that I (to my >> surprise) I can actually mount them! But, I'm missing a large part and I am >> wondering if there's some method to access those last partitions too. >> >> Here's what gpart show says about the problematic disk: >> >> # gpart show /dev/ada4 >> => 34 41942972 ada4 GPT (931G) [CORRUPT] >> 34 128 1 freebsd-boot (64k) >> 162 1048448 2 freebsd-ufs (512M) >> 1048610 6291456 3 freebsd-swap (3.0G) >> 7340066 1048576 4 freebsd-ufs (512M) >> 8388642 2097152 5 freebsd-ufs (1.0G) >> 10485794 31457211 6 freebsd-ufs (15G) >> 41943005 1- free - (512B) >> >> As you can see, most (about 910GB) of the disk is missing! This disk was one >> half of a mirror on the twa controller, which had those disks split in two >> again (I don't recall how, perhaps 2 different BSD slices?) >> I already looked if that part may perhaps have ended up as a different >> device. On the old server, fstab was this: >> >> # cat /tmp/solfertje/etc/fstab >> # DeviceMountpoint FStype Options DumpPass# >> >> # These are the partitions listed above in gpart >> /dev/da0p2 / ufs rw 1 1 >> /dev/da0p3 noneswapsw 0 0 >> /dev/da0p4 /varufs rw 2 2 >> /dev/da0p5 /tmpufs rw 2 2 >> /dev/da0p6 /usrufs rw 2 2 >> >> # These are missing >> /dev/da1p1 /home ufs rw 2 2 >> /dev/da1p2 /media ufs rw 2 2 >> >> # These are on a different disk (ada2) >> /dev/da2p1 /media2 ufs rw 2 2 >> >> >> I don't _really_ need to get to those partitions, but it would be a >> comfortable thought if it were possible somehow. >> >> >> [*] The reason I was trying to access those disks anyway is that I thought I >> forgot to backup my database tables, but it turns out I had just misplaced >> that backup and it has been restored now. >> >> Alban Hertroys >> -- >> If you can't see the forest for the trees, >> cut the trees and you'll find there is no forest. >> >> ___ >> 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" > > > > This e.mail is private and confidential between Multiplay (UK) Ltd. and the > person or entity to whom it is addressed. In the event of misdirection, the > recipient is prohibited from using, copying, printing or otherwise > disseminating it or any information contained in it. > In the event of misdirection, illegible or incomplete transmission please > telephone +44 845 868 1337 > or return the E.mail to postmas...@multiplay.co.uk. > Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Corrupt GPT header on disk from twa array - fixable?
On Jun 2, 2013, at 16:19, "Steven Hartland" wrote: > - Original Message - From: "Kimmo Paasiala" > >> Looking at the gpart(8) output it seems that only 20GBs of the disk is >> recognized by the disk driver but the GPT table still shows the full >> capacity 910GB. I'd say that the GPT table is in fact correct and if >> you can somehow get the disks to be recognized with full capacity they >> should be usable as they are. What does dmesg(8) say about the disks? > > What does "camcontrol identify ada4" show? You guys are asking good questions! I'm learning new stuff already :P # camcontrol identify ada4 pass4: ATA-8 SATA 2.x device pass4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) protocol ATA/ATAPI-8 SATA 2.x device model Hitachi HDS721010CLA332 firmware revision JP4OA39C serial number JP2930HQ0XPH3H WWN 5000cca35dcd0b0d cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 268435455 sectors LBA48 supported 1953525168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 7200 Feature Support Enabled Value Vendor read ahead yes yes write cacheyes yes flush cacheyes yes overlapno Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes no 0/0x00 automatic acoustic management yes no 254/0xFE128/0x80 media status notification no no power-up in Standbyyes no write-read-verify no no unload no no free-fall no no data set management (TRIM) no For good measure: # uname -a FreeBSD solfertje 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 (I'm building STABLE world as we speak) Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Corrupt GPT header on disk from twa array - fixable?
On Jun 2, 2013, at 16:12, Kimmo Paasiala wrote: > > Looking at the gpart(8) output it seems that only 20GBs of the disk is > recognized by the disk driver but the GPT table still shows the full > capacity 910GB. I'd say that the GPT table is in fact correct and if > you can somehow get the disks to be recognized with full capacity they > should be usable as they are. What does dmesg(8) say about the disks? >From dmesg: ada2 at ahcich2 bus 0 scbus2 target 0 lun 0 ada2: usb_alloc_device: set address 2 failed (USB_ERR_IOERROR, ignored) ATA-8 SATA 2.x device usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada2: Command Queueing enabled ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Previously was known as ad8 ada3 at ahcich3 bus 0 scbus3 target 0 lun 0 ada3: ATA-8 SATA 2.x device ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada3: Previously was known as ad10 ada4 at ahcich4 bus 0 scbus4 target 0 lun 0 ada4: ATA-8 SATA 2.x device usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) ada4: 300.000MB/s transfers (SATA 2.x, usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR UDMA6, PIO 8192bytes) ada4: Command Queueing enabled ada4: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada4: Previously was known as ad12 ada5 at ahcich5 bus 0 scbus5 target 0 lun 0 ada5: ATA-8 SATA 3.x device ada5: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada5: Command Queueing enabled ada5: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada5: Previously was known as ad14 SMP: AP CPU #1 Launched! Timecounter "TSC-low" frequency 13371081 Hz quality 800 GEOM: ada2: the secondary GPT header is not in the last LBA. GEOM: ada3: the secondary GPT header is not in the last LBA. GEOM_MIRROR: Device mirror/boot launched (2/2). GEOM_MIRROR: Device mirror/swap launched (2/2). GEOM_MIRROR: Device mirror/root launched (2/2). GEOM: ada4: the secondary GPT header is not in the last LBA. GEOM: ada5: the secondary GPT header is not in the last LBA. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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"
Corrupt GPT header on disk from twa array - fixable?
Hello list, I just replaced my home server and moved the disks from the old one over to the new one. In the old server, 4 of the disks were connected to a twa (3Ware 9550) controller, which of course has it's own way of marking units/volumes on those disks. Before you start yelling at me, yes, of course I made backups ;) [*] The thing is, I have these disks in the new server and I found that I (to my surprise) I can actually mount them! But, I'm missing a large part and I am wondering if there's some method to access those last partitions too. Here's what gpart show says about the problematic disk: # gpart show /dev/ada4 => 34 41942972 ada4 GPT (931G) [CORRUPT] 34 128 1 freebsd-boot (64k) 162 1048448 2 freebsd-ufs (512M) 1048610 6291456 3 freebsd-swap (3.0G) 7340066 1048576 4 freebsd-ufs (512M) 8388642 2097152 5 freebsd-ufs (1.0G) 10485794 31457211 6 freebsd-ufs (15G) 41943005 1- free - (512B) As you can see, most (about 910GB) of the disk is missing! This disk was one half of a mirror on the twa controller, which had those disks split in two again (I don't recall how, perhaps 2 different BSD slices?) I already looked if that part may perhaps have ended up as a different device. On the old server, fstab was this: # cat /tmp/solfertje/etc/fstab # DeviceMountpoint FStype Options DumpPass# # These are the partitions listed above in gpart /dev/da0p2 / ufs rw 1 1 /dev/da0p3 noneswapsw 0 0 /dev/da0p4 /varufs rw 2 2 /dev/da0p5 /tmpufs rw 2 2 /dev/da0p6 /usrufs rw 2 2 # These are missing /dev/da1p1 /home ufs rw 2 2 /dev/da1p2 /media ufs rw 2 2 # These are on a different disk (ada2) /dev/da2p1 /media2 ufs rw 2 2 I don't _really_ need to get to those partitions, but it would be a comfortable thought if it were possible somehow. [*] The reason I was trying to access those disks anyway is that I thought I forgot to backup my database tables, but it turns out I had just misplaced that backup and it has been restored now. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll find there is no forest. ___ 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: Machine check errors
On 24 Jan 2011, at 6:02, per...@pluto.rain.com wrote: > Alban Hertroys wrote: > >> Ever since installing 7.4-PRERELEASE I'm seeing MCA machine check >> errors on my home-server ... >> >> MCA: Bank 0, Status 0xb6220135 >> MCA: Global Cap 0x0104, Status 0x0004 >> MCA: Vendor "AuthenticAMD". ID 0x662, APIC ID 1 >> MCA: CPU 0 UNCOR PCC DCACHE L1 DRD error > ^ >> MCA: Address 0x162933f0 > > That's an error in the on-chip data cache. It is, I saw that too. > The first thing I would check is cooling. Maybe one of the fans > has quit working, or the air filter (if the box has one) has gotten > clogged up with dust, so that the CPU is running hotter than it > should. It's amazing how your perception of acceptable temperature ranges rises with the actual average temperature. Turns out the last time I unclogged the dust filter on the case was longer ago than I thought it was. Good call! Temperature went down from 55C to 46C over the last 10 minutes already... I think I'm starting to appreciate the MCA feature already :) Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling. !DSPAM:363,4d3d2c0011731311418875! ___ 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"
Machine check errors
Ever since installing 7.4-PRERELEASE I'm seeing MCA machine check errors on my home-server. They usually occur during my Sunday-night level1 dump via ssh to a disk connected to a different machine, although that's probably not relevant. Today I finally managed to catch it on the terminal, here's a hand-transcribed copy: MCA: Bank 0, Status 0xb6220135 MCA: Global Cap 0x0104, Status 0x0004 MCA: Vendor "AuthenticAMD". ID 0x662, APIC ID 1 MCA: CPU 0 UNCOR PCC DCACHE L1 DRD error MCA: Address 0x162933f0 Fatal trap 20: Machine check trap while in user mode cpuid = 0; apic id = 01 instruction pointer = 0x33:0x8086bd0 stack pointer = 0x3b:0xbfbfd390 frame pointer = 0x3b:0xbfbfd3e8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 3, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, IOPL = 0 current process = 18119 (postgres) trap number = 20 panic: machine check trap cpuid = 0 GEOM_MIRROR: Device home: provider mirror/home destroyed. Dmesg is also attached. !DSPAM:363,4d3c03e411733364220958! dmesg_20110123 Description: Binary data >From searching the archives I found claims that L1 cache errors would cause >far more troubles than I'm seeing. The user in that case however was using an >Intel-based Thinkpad laptop, while I'm seeing them on an AthlonXP-based server >(Tyan Tiger board, 3Ware RAID-controller, the works). Now there is something unusual about my server that could be related to these MCA errors: It's a dual-CPU motherboard that normally would host two AthlonMP's, but is instead hosting a single AthlonXP. So one of the CPU sockets has no CPU in it. So, what's my situation? Do I need to go looking for a replacement CPU or is something wrong with the machine-check itself? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:363,4d3c03e411733364220958! ___ 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: sed is broken under freebsd?
On 13 Jan 2011, at 6:10, Chris H wrote: > FWIW On a hunch, I just performed an experimentwith sed(1) > against gsed on 50,000 html documents. My mission; to replace all > instances of: > > > > with: > > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> > http://www.w3.org/1999/xhtml"; xml:lang="en" dir="ltr"> I do hope you didn't orphan a -tag there? Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,4d2f565011879296619823! ___ 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: fault tolerant web servers on freebsd
On 7 Apr 2010, at 8:05, Aristedes Maniatis wrote: > Until we get to 'database' everything is HA and quite easy to build and > manage. Having a clustered database solution is expensive and beyond most > smallish budgets. mysql and postgresql don't have anything available that is > quite ready yet (IMO), so you'll need to be talking to the bigger (expensive) > players about their clustered offerings. There are quite a few replication projects for postgres, aren't you writing them off a bit too easily? I know that for example the guys from Skype wrote and maintain one of them, I imagine they'd be quite concerned about HA. And there are a number more (see: http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling). I suggest that you poll their mailing list with your problem/requirements if you didn't already. They're usually rather helpful and will certainly confirm if there's no solution to your situation (yet). Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,4bbc600010411126416115! ___ 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: PCIe audio cards: what is tob be preferred with FreeBSD 8.0/9-CURRENT?
On 24 Jan 2010, at 17:36, O. Hartmann wrote: > At this moment, I look for the Soundblaster X-Fi range of PCIe cards, but I'm > not sure whether they are supported by FreeBSd 8/9. Any suggestions? I'm actually looking for a replacement for my X-Fi (I have the PCI X-Fi Gamer). The sound quality isn't great and it's only supported in Windows. I believe there's an effort going on to get a functioning driver on Linux at the moment. Besides that, the card I have got some proprietary connectors for digital audio that you need to buy some kind of dongle for that dangles outside your case. You can fit a 3.5mm optical jack in the proprietary connector, but the signal isn't SP/DIF - my receiver has no idea what to do with it. The more expensive versions probably don't have that problem, they have plenty of connections for all kinds of signals after all. Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4b5d7a9e10605695025844! ___ 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"
NULL-pointer reference in ulpt
I didn't get any replies to my previous report, so I'm trying again. I frequently get a kernel-panic after printing something to my USB printer (A Samsung ML-1210). It looks like usb_setup_xfer() is called with a NULL-pointer for xfer from ulpt_tick(). System is a 7.2-STABLE, last updated on Sep 15. I just did a make update, but there were no changes to ulpt.c. The core-summary is available from http://solfertje.student.utwente.nl/~dalroi/core.txt Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4ae5a9e512191499454227! ___ 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"
Kernel panic in ulpt
Hello, I just got a kernel panic on a FreeBSD 7.2 STABLE after a print job finished on ulpt. The kgdb output (ran in script) is attached. I'll keep the vmcore around in case anyone needs more info. Shout if you need more info. !DSPAM:363,4aaa786713781058220185! kgdb.out Description: Binary data Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:363,4aaa786713781058220185! ___ 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: gconcat file system damage
On 11 Sep 2009, at 5:45, Andrew Snow wrote: Peter C. Lai wrote: What is the status of growfs(8) then? As far as I can tell, it doesn't work reliably with UFS2 partitions, and it doesn't work at all with large partitions. People who do try to use it, can end up with corrupted filesystems... and the code is currently unmaintained. Aha, I forgot about that step, but I did indeed use growfs to expand it. Is there any way to repair the corruption without erasing my data, or do I need to buy an external disk to backup to first (which I need for backups anyway)? If so, what's the pattern of the corruption? Is it likely to only start after a certain size? Lastly, having a tool in the base system that causes these kinds of issues doesn't seem like a very good idea. growfs does issue a warning that made me read the bugs section in the man page. That section points to an ffsinfo command that I ran on the filesystem in question, but it appears to be alright: = START CYLINDER SUMMARY = # 0...@28202000: 0. csum in fscs ndir int32_t 0x0001 nbfree int32_t 0x2474 nifree int32_t 0x5bfd nffree int32_t 0x000d = END CYLINDER SUMMARY = The filesystem is 740G, which seems to fit in the 'critical data structure'; 1480 < 0x2474... Or is this a different (and undocumented) issue? Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4aaa10f412071914714074! ___ 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"
gconcat file system damage
Hello, I recently added two disks to the mirror on my 3ware 9550 controller with the intend to expand my mirror. It doesn't support that with differently sized disks though, so I ended up creating a new mirror and gconcat-ed them together. Now I'm seeing lots of UNKNOWN FILETYPE and PARTIAL somethings if fsck verifies the disk, all in subsequent inodes so it looks like fsck gets some offset wrong somewhere. It started with a number of SOFTUPDATE INCONSISTENCY's, which of course went away after disabling softupdates on that FS (it's hardly ever written to anyway). I originally created the concatted disk in two steps. First I created the concat on my new mirrored disks and copied the files from my existing mirror in there. Second I appended the existing mirror to my concatted disk. It seemed to work fine, but now I'm seeing so much errors that I can only mount the concat r/o! Is there anything I can do to fix the issue? World is a stable from just after the 7.2 release, I'm building a fresh one now. Here are a few details: > uname -a FreeBSD solfertje.student.utwente.nl 7.2-STABLE FreeBSD 7.2-STABLE #1: Thu Sep 10 01:34:44 CEST 2009 dal...@solfertje.student.utwente.nl:/ usr/obj/usr/src/sys/ERGOPROXY i386 > gconcat list Geom name: media State: UP Status: Total=2, Online=2 Type: AUTOMATIC ID: 1530457230 Providers: 1. Name: concat/media Mediasize: 819977973760 (764G) Sectorsize: 512 Mode: r1w0e1 Consumers: 1. Name: da0p1 Mediasize: 319988660736 (298G) Sectorsize: 512 Mode: r1w0e2 Start: 499989313536 End: 819977973760 2. Name: da1p1 Mediasize: 499989314048 (466G) Sectorsize: 512 Mode: r1w0e2 Start: 0 End: 499989313536 tw_cli output: //solfertje> /c0 show Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy -- u0RAID-1OK - - - 298.013 ON OFF u1RAID-1OK - - - 465.651 ON OFF Port Status Unit SizeBlocksSerial --- p0 OK u1 465.76 GB 976773168 9VM18XZY p1 OK u0 298.09 GB 625142448 5QF383J7 p2 OK u1 465.76 GB 976773168 9VM141ST p3 OK u0 298.09 GB 625142448 9QF3Z5LM //solfertje> /c0 show unitstatus Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy -- u0RAID-1OK - - - 298.013 ON OFF u1RAID-1OK - - - 465.651 ON OFF Alban Hertroys -- Screwing up is the best way to attach something to the ceiling. !DSPAM:74,4aa8f20512071992670156! ___ 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: Upgrading from 6.4 to 7.2
On 31 Jul 2009, at 16:36, Louis Mamakos wrote: Also beware that gmirror in RELENG_7 will upgrade the metadata in your mirror when you boot. This could be an issue if you need to revert to a RELENG_6 kernel with the older gmirror. I've done a source upgrade (months ago, though) from 6.x to 7.x successfully, though. I'm pretty sure that was before 6.4 so your metadata has already been upgraded, but it can't hurt to check UPDATING for it. If memory serves me correctly from my own (rather problematic) upgrade 25 days ago that changed in Nov 2006. I remember that date because the metadata upgrade caught me unaware and caused me quite a headache when my 7.2 custom kernel panicked and my old 6.3 kernel couldn't read the mirror anymore. Just in case, you can mount one of the devices in the mirror instead and boot your old root off it, but don't make the same mistake I made fsck-ing it (don't forget to disable background fsck as well to make sure). Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:363,4a7438a910138351221251! ___ 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: Upcoming Releases Schedule...
On Sep 18, 2008, at 9:23 PM, Jo Rhett wrote: On Sep 18, 2008, at 12:01 PM, Robert Watson wrote: Let's consider three more productive avenues by which you can offer assistance with the problem of how to increase branch support lifetimes: (1) Become a contributor to the community by developing and maintaining patches against unsupported branches, especially against older releases such as 4.x and 5.x where the branches are open for commits but have fallen out of support status. I can't promise the results will We have no 4.x or 5.x systems nor do we have any interest in maintaining those. So perhaps a good idea, but not something I can help with. I *did* offer to work on maintenance for 6.2, but was told it would be rejected by the developers. Would I extend effort to do exactly what I am talking about -- extending the support lifetime for very recent releases? Absolutely. If its in a form useful for the community as a whole. Are you seriously insisting that a minor release should be supported for more than a year? I think that's pretty exceptional already for any piece of software, and yet you want to extend that? I don't know what your line of work demands, but maybe you're not as constrained as you think you are? The support lifetime of FreeBSD 6 (the major release) is estimated to be up to somewhere in 2010, according to the release information, which seems to satisfy your needs. To me this is a rhetorical question only, I have no way to apply any answers I get to these questions. I'm not involved in the FreeBSD project or in your line of work, I'm just a humble user and supporter. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:74,48d2afa510139919116692! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how much beer do I need to get this patch applied?
On Jun 20, 2007, at 21:43, Jo Rhett wrote: On Jun 20, 2007, at 10:40 AM, Kurt Buff wrote: Indeed, which is why this patch might not be such a good idea. In this case, absence of evidence is indeed evidence of absence, which is contrary to the general case. You appear to be completely confused about what this change does. All it does is TO ALLOW (not require) the OP to disable the spurious and empty output from successful cron jobs. If I get a message every day saying "No output", how do I know when a failure has occurred? This patch changes nothing about that behavior. Getting no message is equally useless in the situation where no output was generated *AND* the result code is positive. The more likely is that the OP starts deleting the messages unread each day and thus never sees an actual failure report. You obviously both make a good point. You don't want to get flooded by messages saying that everything is all right, but you do want to know when not every machine is able to send such a message. Would it help if "everything is all right"-mails would be easily discerned from messages saying "there is a problem"? IMHO that way you could move the "everything is all right" messages into a separate mailbox which would serve as a coarse check (there'd be about the same amount of new messages in it every day), while the "there's a problem" mails would still stick out like a soar thumb. I don't know how hard this would be, it'd probably be more work than the suggested patch. My 2 cents. -- Alban Hertroys "This person has performed an illegal operation, and will be shot down." !DSPAM:74,4679997c10034581612333! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Mar 14, 2007, at 1:55, Steven Hartland wrote: Alban Hertroys wrote: Sorry, couldn't resist... Being a troll? I don't troll, I'm not like that. I have a problem with how mysql often gets falsely marketed as the fastest database. The subject just pushed the right buttons, sorry about that. Apparently I was vaguely aware of that, or I wouldn't have written that. This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. You seem to have been paying no attention at all to any of the mysql performance benchmarks and optimisation efforts that have being going on recently. I keep track of this ML, this was the first time I've seen the topic come up. If this started somewhere else, then sorry, didn't know about it. I have to admit I was confused about the purpose of the benchmark. I am so used to seeing (usually bad) comparison benchmarks between mysql and postgres that I mistook this for one. That's probably due to me being a postgresql mailing list regular. Not to say that PostgreSQL is the ultimate benchmark instead of mysql, just a better one. Of course they both have their uses, but IMO mysql is loosing terrain fast. Any benchmark which looks to closely emulate "real life work" is valid, just be because "you" dont use or like a particular product doesnt make it any less suitable for testing / benchmarking. I'm sure if you took a survey of how many people are using mysql vs PostgreSQL it would show that the former is much more popular DB. No this doesnt make it better but it does make it a more suitable candidate for performance work as the benefits will benefit more people and more systems. Well, that depends on what you're trying to benchmark of course. It keeps amazing me that people choose a product based on how many people use it, instead of how well it works. That goes for mysql vs postgresql as much as for linux vs freebsd. In that way benchmarks like these are useful; it shows that freebsd outperforms linux if you use mysql. It shows that what most people chose is not necessarily the best choice. What I would have liked to see was a graph showing that postgresql on FreeBSD performs both better than MySQL on either platform and better than postgresql on linux (all of which are quite theoretical at this point). Combined into a well written and well argumented article (that is easy to stumble upon preferably), that may just help a little to get people off that ridiculous idea. It also has a "known" bottleneck to its performance on FreeBSD see earlier comments in other threads by Kris on this which clearly limits any benefit gained from using it as a benchmark. This is unfortunate, and now you mention it I do have a vague recollection of a problem discussion. I'll have to read up on that once I have the time to, and I hope to be able to cross-reference that to the pg-general ML. In real life situations, I usually find that a database problem can often be rewritten into a more optimal design once you move from mysql to postgresql. I use both, although I vastly prefer postgresql. Where you hit a brick wall with mysql, you can usually move on in postgresql by putting data into materialised views, using smarter subqueries, stored procedures, triggers, contrib packages like ltree, etc. So, even though there is apparently a bottleneck with it on FreeBSD (not too severe, I hope), the end result may still be better than when using mysql. I realise this is starting to get off topic, I suggest replies should focus on the first half of my reply. -- Alban Hertroys "If you can't see the forest through the trees, cut the trees and you'll see there is no forest" !DSPAM:74,45f847759413227012565! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Mar 14, 2007, at 1:55, Kris Kennaway wrote: This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. This might be standard dogma, but it also appears not to be true: http://people.freebsd.org/~kris/scaling/mysql.html Interesting. Results I have seen using a 16 CPU SGI Altex(?) showed an almost linear rise for postgres while mysql topped off after about 4 threads. Sorry, don't have the URL at hand (I probably still have it in my work mail). Now this may well have been a version before 5.0.33. I'm not sure what OS was used either, I suppose it was either Irix or Linux. Now I am curious whether the same performance drop on Linux would occur with a postgres benchmark. It probably will, but if not it seems like there's a problem in the way that mysql and linux interact. -- Alban Hertroys "If you can't see the forest through the trees, cut the trees and you'll see there is no forest" !DSPAM:74,45f7b2c29417620521737! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD mysql Benchmark on 4BSD/ULE scheduler and i386/amd64
On Mar 13, 2007, at 22:45, Kris Kennaway wrote: I used sql-bench /usr/ports/databases/mysql50-server/work/mysql-5.0.33/sql-bench/ (at this time) the default Makefile of port have "--without-bench" options so u need to make manually Hmm. This seems to be a single-user test, so while it's presumably testing some relevant basic ingredients of database performance it's probably not a realistic measure of server performance. i.e. if you really only have a maximum of one client accessing your database then your 4-core system is being more than 75% wasted :) Sorry, couldn't resist... This being mysql, the number of processors isn't going to matter much, no matter how many connections you have. Mysql doesn't scale very well to multiple cpu's. I've had my doubts about this "benchmark" from the beginning of this thread, I don't see the point of benchmarks using mysql - especially if it's not even clear whether myIsam or Innodb was used. If this benchmark means anything, I'm sure there are benchmarks that better suit the purpose (with the exception of benchmarking mysql performance for a single connection). What are we actually trying to benchmark here? In my experience mysql as a database accepts invalid data, doesn't comply to the SQL standards much and isn't very fast at real-life database queries - among other things. It doesn't compare[1] to a tuned PostgreSQL database, which I think is a considerably more interesting benchmark. And of course that would include multiple simultaneous connections. Not to say that PostgreSQL is the ultimate benchmark instead of mysql, just a better one. Of course they both have their uses, but IMO mysql is loosing terrain fast. [1] I really mean it doesn't compare. PostgreSQL provides more (and IMHO better) features, and can be faster under the right circumstances (usually complex queries or concurrent writes). It also scales almost linearly to the number of cpu's, provided there are enough simultaneous connections. -- Alban Hertroys Priest to alien: "We want to know, is there a higher being?". Alien: "Well, actually that's why we're here, we're sheer out of virgins". !DSPAM:74,45f741509413780612645! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.1 to 6.2
On Mar 13, 2007, at 4:58, Matthew Herzog wrote: Hello. The 6.1 install is intact on disk0 and still works fine. I copied my ipfilter and ipnat config files to the new system after building an ipf/ipnat enabled kernel on the 6.2 install but the machine is not acting as a gateway. In fact, I can't even ssh into it from inside or outside Does issuing ipf -F a -f /etc/ipf.rules help? It solved a similar looking problem for me on my amd64 home gateway. I could still log into the server from my LAN, but not all of my rules were active somehow. Reloading the rule-set from a shell (after each reboot) helped. If it does, I guess there's an rc-order problem somewhere? As a temporary workaround (haven't tried yet) you could add that line to rc.local. Note: My server runs a 6-STABLE from shortly after 6.2-RELEASE. -- Alban Hertroys "If you throw your hands up in the air, how're you gonna catch them?" !DSPAM:74,45f65bb99411478922070! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB stalled errors
On Jan 31, 2007, at 22:48, Alban Hertroys wrote: Good day (or night, if more appropriate), I'm seeing these for a while now, it's time to see if it can be fixed :P I have a setup where a KVM/USB switch (Gefen 2x1 DVI switcher) is connected to my athlon64 machine, which is connected to yet another hub in my TFT display to which my keyboard and mouse are connected. I would have expected some response to this. I'm kind of disappointed. Well, I have a new data point. I found a PR about the Apple Cinema Display USB device hanging the usb stack or some such. Thinking it might solve my problem I disconnected the ACD USB device and plugged my keyboard and mouse directly in the KVM switch and booted the machine. Same problem, but on uhub3 this time. It gave a device write error instead of a TIMEOUT, but I've seen that before when the ACD was still connected too. So the problem _does not seem to be related_ to the ACD problem(s). Apparently the KVM switch contains a Cypress Tetra hub (acc. to the vendor/device codes in dmesg). Could someone please shed some light on this? Schematically the USB devices are connected like this: Athlon64 --- KVM switch --- Display --- Keyboard Mac ---/\-- Mouse This time it looked like: Athlon64 --- KVM switch --- Keyboard Mac ---/\-- Mouse While booting I see messages like these: uhub3: vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/0.09, addr 2 uhub3: multiple transaction translators uhub3: 4 ports with 4 removable, self powered uhub4: vendor 0x05ac product 0x9131, class 9/0, rev 2.00/1.01, addr 3 uhub4: multiple transaction translators uhub4: 3 ports with 2 removable, self powered uhub4: device problem (STALLED), disabling port 1 uhub4: device problem (STALLED), disabling port 2 uhub4: device problem (TIMEOUT), disabling port 3 uhub3 is the KVM switch, while uhub4 is the display. The messages are usually STALLED, but I've seen TIMEOUT (as above) and SHORT_XFER as well. I have tried eliminating the hub in the display from the equation, the results are the same (the errors are on uhub3 in that case - although I'm not 100% sure now I write this). I've tried different hub cables (all but one came new with the switch), to no avail. The KVM switch replaced a Sweex USB hub that had very similar problems. Something that I think is odd is that the vendor/product ID's of the hub in the KVM switch are listed among those in the sources, yet looking them up apparently fails. I compiled a kernel with DEBUG_USB enabled and attached the resulting dmesg. I tried retrying usbd_new_device after the first failure, but that just resulted in another STALLED message (as suggested by an XXX remark in uhub.c). Anything else I can do to help solve this? Regards, -- Alban Hertroys "If you throw your hands up in the air, how're you gonna catch them?" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable- [EMAIL PROTECTED]" -- Alban Hertroys "It's not a bug! It's a six-legged feature!" !DSPAM:74,45e3e56f9411858390337! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB stalled errors
On Jan 31, 2007, at 22:59, Alban Hertroys wrote: Strange, I did attach that file. It is in my sent box even... I wonder where it got lost. Maybe the size? Alright... here then: http://solfertje.student.utwente.nl/~dalroi/ dmesg.debug.out I wonder who's stripping my mail. -- Alban Hertroys "If you can't see the forest through the trees, cut the trees and you'll see there is no forest" !DSPAM:74,45c112f49346141411866! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB stalled errors
On Jan 31, 2007, at 22:48, Alban Hertroys wrote: I compiled a kernel with DEBUG_USB enabled and attached the resulting dmesg. I tried retrying usbd_new_device after the first failure, but that just resulted in another STALLED message (as suggested by an XXX remark in uhub.c). Strange, I did attach that file. It is in my sent box even... I wonder where it got lost. Maybe the size? !DSPAM:74,45c110f89345022090619! -- Alban Hertroys "If you lose your memory, you can't remember where you left it." !DSPAM:74,45c110f89345022090619! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB stalled errors
Good day (or night, if more appropriate), I'm seeing these for a while now, it's time to see if it can be fixed :P I have a setup where a KVM/USB switch (Gefen 2x1 DVI switcher) is connected to my athlon64 machine, which is connected to yet another hub in my TFT display to which my keyboard and mouse are connected. Schematically the USB devices are connected like this: Athlon64 --- KVM switch --- Display --- Keyboard Mac ---/\-- Mouse While booting I see messages like these: uhub3: vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/0.09, addr 2 uhub3: multiple transaction translators uhub3: 4 ports with 4 removable, self powered uhub4: vendor 0x05ac product 0x9131, class 9/0, rev 2.00/1.01, addr 3 uhub4: multiple transaction translators uhub4: 3 ports with 2 removable, self powered uhub4: device problem (STALLED), disabling port 1 uhub4: device problem (STALLED), disabling port 2 uhub4: device problem (TIMEOUT), disabling port 3 uhub3 is the KVM switch, while uhub4 is the display. The messages are usually STALLED, but I've seen TIMEOUT (as above) and SHORT_XFER as well. I have tried eliminating the hub in the display from the equation, the results are the same (the errors are on uhub3 in that case - although I'm not 100% sure now I write this). I've tried different hub cables (all but one came new with the switch), to no avail. The KVM switch replaced a Sweex USB hub that had very similar problems. Something that I think is odd is that the vendor/product ID's of the hub in the KVM switch are listed among those in the sources, yet looking them up apparently fails. I compiled a kernel with DEBUG_USB enabled and attached the resulting dmesg. I tried retrying usbd_new_device after the first failure, but that just resulted in another STALLED message (as suggested by an XXX remark in uhub.c). Anything else I can do to help solve this? Regards, -- Alban Hertroys "If you throw your hands up in the air, how're you gonna catch them?"  !DSPAM:74,45c10e909341268575503! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
buildkernel failure
Building a kernel of a freshly updated RELENG_6 source tree reveals the following: ===> firmware (all) cc -O2 -fno-strict-aliasing -pipe -march=athlon64 -Werror -D_KERNEL - DKLD_MODULE -nostdinc -I- -DHAVE_KERNEL_OPTION_HEADERS -include / build/obj/build/src/sys/BOLTTHROWER/opt_global.h -I. -I@ -I@/contrib/ altq -I@/../include -finline-limit=8000 -fno-common -fno-omit-frame- pointer -I/build/obj/build/src/sys/BOLTTHROWER -mcmodel=kernel -mno- red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft- float -fno-asynchronous-unwind-tables -ffreestanding -Wall - Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions - std=c99 -c /build/src/sys/modules/firmware/../../kern/subr_firmware.c /build/src/sys/modules/firmware/../../kern/subr_firmware.c: In function `firmware_get': /build/src/sys/modules/firmware/../../kern/subr_firmware.c:192: warning: implicit declaration of function `linker_release_module' /build/src/sys/modules/firmware/../../kern/subr_firmware.c:192: warning: nested extern declaration of `linker_release_module' *** Error code 1 Stop in /build/src/sys/modules/firmware. *** Error code 1 Stop in /build/src/sys/modules. *** Error code 1 Stop in /build/obj/build/src/sys/BOLTTHROWER. Exit 1 System is amd64 with a custom kernel. I don't know what might be dependent on subr_firmware, but the error doesn't seem to point to a missing kernel option or device. In the CVS logs I can see that this function was added recently; maybe something was forgotten in the MFC? -- Alban Hertroys "Memory expensive?!? My computer has free memory!" !DSPAM:74,45bf91649342038170548! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gmirror or ata problem
On Jan 30, 2007, at 9:54, Oliver Fromme wrote: Hi, This is strange. gmirror just detached one of its disks for no apparent reason. I've built a mirror consisting of the components ad0 and ad1 (both SATA drives). It has been running fine. This is RELENG_6 from 2006-12-20. Yesterday evening ad1 was detached. There is no other error message logged on console or in the logs (i.e. no I/O error such as a bad sector or anything). There was no particularly high load at that time. In fact, the machine had been under much higher load before, without anything bad happening. I had unexplainable intermittent detaches until I replaced one of my memory modules. Never happened since. Admittedly I also had problems completing buildworld - that's why I checked my memory modules in the first place. -- Alban Hertroys "This person has performed an illegal operation, and will be shot down." !DSPAM:74,45bf76649345499641489! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Running large DB's on FreeBSD
On Oct 24, 2006, at 1:09, Bill Moran wrote: Well, you should be using FreeBSD+PostgreSQL, but that's just my religion. Is it religion when it just makes more sense? But I digress. There are numerous reasons to prefer PostgreSQL over MySQL, a few of which are: - It scales well to multiple CPUs (almost linear, provided your connections are under sufficient load). I've seen benchmarks like this from a 16 CPU Altix (SGI). - It can do complex queries, and it does them well (I've seen it outperform MySQL regularly - especially where MySQL couldn't perform the query directly). - Data integrity is very important to the PostgreSQL community, so it doesn't ignore errors or truncate your data or things like that (MySQL does). - It has a great community; the people on the mailing lists are very knowledgeable and helpful. You'll usually have a solution for a problem within a day. - AFAIK, the key developers run FreeBSD. One thing; there are a lot of PostgreSQL vs. MySQL comparisons, but they usually fail to tune both databases properly or test with workloads that have been optimized for MySQL. For further questions you really should ask around at the postgresql mailing lists. Regards, -- Alban Hertroys "It's not a bug! It's a six-legged feature!" !DSPAM:363,453dbe3b7241041496339! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Total crash in gdb!.. something is broken!.. Was: Re: FreeBSD with a Gigabyte GA-K8NSC?
On Sep 25, 2006, at 8:36, Johan Ström wrote:
What exactly does
kernel dumps on /dev/mirror/gm0s1b
mean? Not that it saves any kernel dumps at least.. But otoh I have
no clue why it
It means exactly that. IIRC kernel dumps are created in swap space
and on the next boot are moved to ${dumpdir}. I'm pretty certain this
is explained nicely in the handbook[1].
AFAIK kernels can only be dumped on real devices, not on virtual
devices like /dev/mirror/*. In that case your setup is not going to
get you any dumps.
Besides that, it is probably not a very good idea to mirror your
swap. I am certain it is bad for performance, if it'd gain you
reliability is beyond my knowledge. This has been discussed before,
you probably want to check the archives.
[1] Which I didn't check as I'm about to be in a hurry...
--
Alban Hertroys
Priest to alien: "We want to know, is there a higher
being?".
Alien: "Well, actually that's why we're here,
we're sheer out of virgins".
!DSPAM:74,45178b3f7241469027555!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arrrrgh! Guys, who's breaking -STABLE's gmirror code?!
On Sep 15, 2006, at 24:34, hackmiester (Hunter Fuller) wrote: Hahahahaha... That's ironic... That wasn't meant to be ironic. Years of experience and observations of development lead to this conclusion. RIght. All i can say, though, is that someone that doesn't know any better would probably not think "Oh! That means that upgrades are possible between releases, and not that my system will actually run, or anything!" It just seems it'd be quite a cause of confusion. So, actually Microsoft may be correctly claiming that WindowsXP is more stable than Linux. That it spontaneously reboots as soon as I bore it isn't related at all... -- Alban Hertroys "This person has performed an illegal operation, and will be shot down." !DSPAM:74,450a59b47241130310126! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.x CVSUP today crashes with zero load ...
On Jun 26, 2006, at 11:54 PM, M.Hirsch wrote: Ok, sorry. Misunderstanding here. My point was, along what has been posted here in this thread: "An ECC error should raise a kernel panic immediately, not only a message in the log files." Preferably not until the running transactions are processed and the transaction server failed over to another one... Otherwise it's like making a car do a full stop on a busy highway because one of the tires is worn out. -- Alban Hertroys "I think, therefore I drink" Lazarus !DSPAM:74,44a0eb4b333521351116725! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: upgrading
On 21 Sep, Matthew Seaman hit a keyboard in the following places: > # shutdown -r now Hmm, I usually prefer to do just: #shutdown now so that I end up in single user mode immedately. I usually check 'ps' to see whether no daemons are running (fleeing?) that should have died. This method has the effect that you're still running the same kernel, but I'm now unsure whether that's a good or a bad thing. If you reboot (with '-r'), you are booting a system where the kernel is upgraded, but the rest of the system isn't. That could cause startup scripts to fail and the like. OTOH, if you don't, are you using the installed install tools or the upgraded ones (which may require the new kernel) when running installworld? I'm getting a bit confused here... > (Various output will scroll past. When prompted for what shell to > run, just hit return) > > # fsck -p > # swapon -a > # mount -a Careful there, you don't want to mount NFS mounts and the like. I usually do (depends on your partitioning): mount -u / mount /tmp mount /var mount /usr I usually leave out /home and other mount points that aren't needed by installworld, so that they can't get corrupted if something gets screwed up (likely by me). Looking at the mount man page, you could also create an alternate "minimal" fstab file, and do mount -a -F . I think I'll have a (f)stab at that... ;) -- Alban Hertroys http://solfertje.student.utwente.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - No, it's not a bug! It's a six-legged feature! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: malloc does not return null when out of memory
On 24 Jul, Pete French punched keys in this particular order: > Its not bogus - the trouble is that you cant tell at the time malloc returns > whether the pointer will be useable or not. You only find that out when > you try and use it, and whether theres any space or not depends oon what > else may have munched up (or released) memory between you making the call > to malloc() and actually writing to the location returned. This looks similar to the problem with mktemp(). Maybe it is possible to solve this in a similar way? For example, by allocating memory and filling it in the same call? That probably would mean that all the software should switch to a new way of allocating memory, but it's a start... -- Alban Hertroys http://solfertje.student.utwente.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This person has performed an illegal operation and will be shot down. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ata33 vs others?
On 31 Jan, Eric Timme punched keys in this particular order: > After wrestling with an 80gb hd and an Abit BX6-R2 for an afternoon and being > pleasantly surprised that Abit's last bios release would allow my board to > detect and use an 80gb hd I came to the sad realization that the computer > only supported ata33. That shouldn't matter much if it is the only drive on the IDE channel. Modern harddrives still perform under 40MB/s last time I checked (the IBM 60GXP series could do 37.5MB/s), and that is at maximum. The ATA100 standard was necessery because two disks on a channel could in some cases press the required data throughput of the controller over 66MB/s (2x37.5=75), though I'm sure it maxes out quite a bit under 100MB/s. I don't know how much overhead data on an IDE channel has (like 'packet headers' or some equivalent) and we now have an ATA133 standard that would be kind of absurd with the above reasoning. Maybe someone can shine a light on this? -- Alban Hertroys http://solfertje.student.utwente.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This person has performed an illegal operation and will be shot down. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.0 Install World problems on all systems
On 21 Mar, Joe Gleason wrote: > cp /usr/obj/usr/src/i386/usr/bin/install-info /usr/bin > > If this is done after make buildworld and before installworld, it should > be groovy. > > The old version of install-info does not work correctly when doing > the installworld. This reminds me of the trouble I got after doing that. I had missed the notion that i neded to compile a new kernel first, so after doing this my /bin/sh's exec-ed by make started raining core-dumps on me. No need to say my install was pretty much screwed after that. The only thing still working was the shell I statred the make installworld from... Eventually I managed to get things working from the emergency holographic shell in the install boot floppies (Unfortunately I did install /bin first, which happily overwrote most of my /etc files). To prevent this in the future: Maybe it is an idea to test if the newly compiled versions of installation programs like sh, cp, mv, etc. actually do work in the current environment? That gives a good warning that something is going wrong, and it doesn't screw up your working OS. Now I suppose this doesn't *ensure* a correct install, but it does decrease the risks. Another suggestion: In sysinstall, make /bin and /etc two different install sets instead of the one that's in it now, so that installing just /bin to recover the programs you need doesn't erase your setup. -- Alban Hertroys http://wit401310.student.utwente.nl - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This person has performed an illegal operation and will be shot down. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
