Re: Running FreeBSD on the Lenovo Thinkpad T470s (success)
On 7. Jan 2018, at 22:40, Rodney W. Grimes <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: >> >> >> On 7. Jan 2018, at 21:32, Rodney W. Grimes >> <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: >> >>>> >>>> >>>>>> On 7. Jan 2018, at 20:43, clutton <clut...@zoho.com> wrote: >>>>>> >>>>>> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >>>>>> Hi, >>>>> >>>>> Running carbon 5th gen I can't call my setup a success. Wireless iwm >>>>> doesn't support even N and AC is not supported at all. The wifi is much >>>>> slower then on my old machines. I'm going to replace the wifi card in >>>>> mean time, any suggestions which one to buy? >>>>> >>>>> Graphics works perfectly. NVMe SSD with OPAL wouldn't allow machine to >>>>> resume from sleep, sometimes it does after big timeout and writing >>>>> errors to console, sometime it just reboots. >>>>> >>>>> Thinkpad Thunderbolt Dock Station, here is where things get >>>>> interesting. If I boot machine connected to dock station, peripheral >>>>> devices would work, external monitor, keyboard, and mouse. There's no >>>>> other way I know to make it work. Once detached - it wouldn't see >>>>> devices again. Booting and THEN attaching - the same, machine wouldn't >>>>> see devices. >>>>> >>>>> Here is the device being seen (a lot of pcib*): >>>>> pcib5@pci0:6:0:0:class=0x060400 card=0x chip=0x15d38086 >>>>> rev=0x02 hdr=0x01 >>>>> vendor = 'Intel Corporation' >>>>> device = 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge >>>>> 4C 2016]' >>>>> class = bridge >>>>> subclass = PCI-PCI >>>>> >>>>> >>>>> For me the main concern is Thunderbolt thought, docking station is >>>>> amazing thing. Any ideas and thought how to make it work would be >>>>> highly appreciated. >>>> >>>> In my setup, plug/unplug events for display port don't work when docking >>>> (usually I'm not using a dock though). This means: Mouse, Keyboard can be >>>> plugged/unplugged as many time as I want at any point, while displays >>>> connected over display port only work when connected before starting X >>>> (and they don't disappear after disconnecting). Note that stopping X seems >>>> to fix this (so no reboot required), but I don't have the docking station >>>> myself (this is the Ultra Dock Pro or something - the one that connects at >>>> the bottom of the laptop). >>>> >>>> Also, in my setup wifi didn't work without adding iwm0 explicitly to >>>> cloned interfaces (which isn't something I wouldn't expect I have to do, >>>> but in this case I had to). >>> >>> Did you have a >>> wlans_iwm0="wlan0" >>> in /etc/rc.conf? >>> I do not know or see why putting iwm0 in cloned would do much of anything >>> for a wlan device. >>> >>> Also note that is wlans as in plural, not wlan_iwm0. A mistake I >>> often make from finger memory. >>> >> >> I have >> >> wlans_iwm0="wlan0" >> ifconfig_wlan0="WPA DHCP country de" > I use just simply: > ifconfig_wlan0="WPA SYNCDHCP" > > I think without the SYNC you are not waiting for wpa to come up? I works ok, if I really wanted to wait for getting an IP that would make sense, yes. > I do not know of the /etc/rc.d/* stuff is prepared to deal with > your "country de" either. > It is, as country DE shows up in ifconfig after boot and it can actually associate (which it couldn't before adding the country, probably the channel was out of range with default settings). >> >> in rc.conf. Without adding >> >> cloned_interfaces="iwm0" >> >> wlan0 never shows up in ifconfig and wpa_supplicant never starts (that's >> current r326912, setup like described in my blog post). >> >> I just double checked to confirm the behavior. > > Something is broken some place. > Well, if I actually add if_iwm_load="YES" if_iwm3160fw_load="YES" if_iwm7260fw_load="YES" if_iwm7265Dfw_load="YES" if_iwm7265fw_load="YES" if_iwm8000Cfw_load="YES" if_iwm8265fw_load="YES" to /boot/loader.conf (like documented in the man page ^_^), it works without adding iwm0 to cloned_interfaces. Funny how I forgot to do that and how cloned_interfaces just did the right thing by loading the correct modules. Sorry for creating confusion. -m >> Best, >> Michael > > -- > Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Running FreeBSD on the Lenovo Thinkpad T470s (success)
On 7. Jan 2018, at 21:32, Rodney W. Grimes <freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: >> >> >>>> On 7. Jan 2018, at 20:43, clutton <clut...@zoho.com> wrote: >>>> >>>> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >>>> Hi, >>> >>> Running carbon 5th gen I can't call my setup a success. Wireless iwm >>> doesn't support even N and AC is not supported at all. The wifi is much >>> slower then on my old machines. I'm going to replace the wifi card in >>> mean time, any suggestions which one to buy? >>> >>> Graphics works perfectly. NVMe SSD with OPAL wouldn't allow machine to >>> resume from sleep, sometimes it does after big timeout and writing >>> errors to console, sometime it just reboots. >>> >>> Thinkpad Thunderbolt Dock Station, here is where things get >>> interesting. If I boot machine connected to dock station, peripheral >>> devices would work, external monitor, keyboard, and mouse. There's no >>> other way I know to make it work. Once detached - it wouldn't see >>> devices again. Booting and THEN attaching - the same, machine wouldn't >>> see devices. >>> >>> Here is the device being seen (a lot of pcib*): >>> pcib5@pci0:6:0:0:class=0x060400 card=0x chip=0x15d38086 >>> rev=0x02 hdr=0x01 >>> vendor = 'Intel Corporation' >>> device = 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge >>> 4C 2016]' >>> class = bridge >>> subclass = PCI-PCI >>> >>> >>> For me the main concern is Thunderbolt thought, docking station is >>> amazing thing. Any ideas and thought how to make it work would be >>> highly appreciated. >> >> In my setup, plug/unplug events for display port don't work when docking >> (usually I'm not using a dock though). This means: Mouse, Keyboard can be >> plugged/unplugged as many time as I want at any point, while displays >> connected over display port only work when connected before starting X (and >> they don't disappear after disconnecting). Note that stopping X seems to fix >> this (so no reboot required), but I don't have the docking station myself >> (this is the Ultra Dock Pro or something - the one that connects at the >> bottom of the laptop). >> >> Also, in my setup wifi didn't work without adding iwm0 explicitly to cloned >> interfaces (which isn't something I wouldn't expect I have to do, but in >> this case I had to). > > Did you have a >wlans_iwm0="wlan0" > in /etc/rc.conf? > I do not know or see why putting iwm0 in cloned would do much of anything > for a wlan device. > > Also note that is wlans as in plural, not wlan_iwm0. A mistake I > often make from finger memory. > I have wlans_iwm0="wlan0" ifconfig_wlan0="WPA DHCP country de" in rc.conf. Without adding cloned_interfaces="iwm0" wlan0 never shows up in ifconfig and wpa_supplicant never starts (that's current r326912, setup like described in my blog post). I just double checked to confirm the behavior. Best, Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Running FreeBSD on the Lenovo Thinkpad T470s (success)
> On 7. Jan 2018, at 20:43, clutton <clut...@zoho.com> wrote: > >> On Sat, 2017-12-30 at 15:58 +0100, Michael Gmelin wrote: >> Hi, > > Running carbon 5th gen I can't call my setup a success. Wireless iwm > doesn't support even N and AC is not supported at all. The wifi is much > slower then on my old machines. I'm going to replace the wifi card in > mean time, any suggestions which one to buy? > > Graphics works perfectly. NVMe SSD with OPAL wouldn't allow machine to > resume from sleep, sometimes it does after big timeout and writing > errors to console, sometime it just reboots. > > Thinkpad Thunderbolt Dock Station, here is where things get > interesting. If I boot machine connected to dock station, peripheral > devices would work, external monitor, keyboard, and mouse. There's no > other way I know to make it work. Once detached - it wouldn't see > devices again. Booting and THEN attaching - the same, machine wouldn't > see devices. > > Here is the device being seen (a lot of pcib*): > pcib5@pci0:6:0:0:class=0x060400 card=0x chip=0x15d38086 > rev=0x02 hdr=0x01 >vendor = 'Intel Corporation' >device = 'JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge > 4C 2016]' >class = bridge >subclass = PCI-PCI > > > For me the main concern is Thunderbolt thought, docking station is > amazing thing. Any ideas and thought how to make it work would be > highly appreciated. In my setup, plug/unplug events for display port don't work when docking (usually I'm not using a dock though). This means: Mouse, Keyboard can be plugged/unplugged as many time as I want at any point, while displays connected over display port only work when connected before starting X (and they don't disappear after disconnecting). Note that stopping X seems to fix this (so no reboot required), but I don't have the docking station myself (this is the Ultra Dock Pro or something - the one that connects at the bottom of the laptop). Also, in my setup wifi didn't work without adding iwm0 explicitly to cloned interfaces (which isn't something I wouldn't expect I have to do, but in this case I had to). -m ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Running FreeBSD on the Lenovo Thinkpad T470s (success)
> Hi, > > I found some time to play with FreeBSD on a Lenovo Thinkpad T470s and > I'm quite happy with the results, as all important features work, > especially essentials like graphics, touchpad and suspend to RAM. > > The configuration is pretty straightforward, but a few things required > research (like evdev, udev and libinput), that's why I documented my > setup here, hoping that it might help others: > > https://blog.grem.de/pages/t470s.html Would you care to document it here: https://wiki.freebsd.org/Laptops and add https://wiki.freebsd.org/Laptops/Thinkpad_T470s > Best and Happy New Year, > Michael > > p.s. Sorry for cross-posting. > > -- > Michael Gmelin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Running FreeBSD on the Lenovo Thinkpad T470s (success)
Hi, I found some time to play with FreeBSD on a Lenovo Thinkpad T470s and I'm quite happy with the results, as all important features work, especially essentials like graphics, touchpad and suspend to RAM. The configuration is pretty straightforward, but a few things required research (like evdev, udev and libinput), that's why I documented my setup here, hoping that it might help others: https://blog.grem.de/pages/t470s.html Best and Happy New Year, Michael p.s. Sorry for cross-posting. -- Michael Gmelin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
make -j4 buildwolrd success when here are problems (files was not found in depend / all targets)
Hello, Freebsd-current. I'm trying to build world with patch from Rui Paulo, which imports hostapd/wpa_supplicant 2.0 I've used worng patch, which didn't add some files, but make -j4 buildworld succeed! Here are quotes from buildworld log: === usr.sbin/wpa/wpa_supplicant (depend) make: make: don't know how to make driver_common.c. Stop make: stopped in /data/src/usr.sbin/wpa/wpa_supplicant === usr.sbin/wpa/wpa_cli (depend) make: make: don't know how to make edit.c. Stop make: stopped in /data/src/usr.sbin/wpa/wpa_cli === usr.sbin/wpa/wpa_passphrase (depend) --- .depend --- rm -f .depend CC='/usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp -B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin' mkdep -f .depend -a -I/data/src/usr.sbin/wpa/wpa_passphrase -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//hostapd -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/drivers -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/wps -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -DINTERNAL_SHA1 -DINTERNAL_MD5 -I/data/src/usr.sbin/wpa/wpa_passphrase -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//hostapd -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../con trib/wpa//src -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/common -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/drivers -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/l2_packet -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils -I/data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/wps -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX -std=gnu99 /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils/common.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5-internal.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/utils/os_unix.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1-internal.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto /sha1-pbkdf2.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/sha1.c /data/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//wpa_supplicant/wpa_passphrase.c echo wpa_passphrase: /data/obj.nano/gateway.v2/data/src/tmp/usr/lib/libc.a .depend === usr.sbin/wpa/hostapd (depend) make: make: don't know how to make driver_common.c. Stop make: stopped in /data/src/usr.sbin/wpa/hostapd === usr.sbin/wpa/hostapd_cli (depend) make: make: don't know how to make edit.c. Stop make: stopped in /data/src/usr.sbin/wpa/hostapd_cli And, later === usr.sbin/wpa/wpa_supplicant (all) make: make: don't know how to make driver_common.c. Stop make: stopped in /data/src/usr.sbin/wpa/wpa_supplicant === usr.sbin/wpa/wpa_cli (all) make: make: don't know how to make edit.c. Stop make: stopped in /data/src/usr.sbin/wpa/wpa_cli But -- World build completed on Sun Jun 30 21:13:10 MSK 2013 -- Later, installworld failed due to absence of wpa_ssupplicant program! I'm using r252420 as base. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
On Tue, Apr 03, 2012 at 06:18:43PM -0700, Julian Elischer wrote: for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. I'm working on it. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpnW1D0zD64a.pgp Description: PGP signature
trim/discard success story
Today I had reason to try the UFS trim support on the FreeBSD version of the Fusion-IO driver, and I'm pleased to say that it appears to work just fine.. on a 1.3TB flash card.. the numbers of 'sectors' that the drive considers to hold valid data is reduced after the contents of the drive is erased..: After newfs -E: hw.fusion.fio.fio0.data.stats: [...] 861327 [...] After writing a few GB to the filesystem but BEFORErm -r * pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 3628354 [...] Afterrm -r * pu05# sysctl hw.fusion.fio.fio0.data.stats hw.fusion.fio.fio0.data.stats: [...] 919690 [...] so from 861,327 packets valid to 3,628,354 packets valid, back to 919,690 packets valid. (since bitmaps etc are allocated as needed the growth is expected but will not grow forever). (yeah I know it never actually reached 1% full but it was a test, ok?) for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
On Tue, 3 Apr 2012, Julian Elischer wrote: for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. The major unknown issue with trim is how well the drives schedules/defers the trim operation so that it does not interfer with other I/Os. Also, it would be really bad if the drive applied trim after the block had been re-allocated for a write. It would also be really bad if the drive loses unrelated data if there is a power fail during trim. If writes get blocked by a pending trim, then trim would not help very much. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
My experience at Alacritech was that Trim was so expensive timewise that it could not be used in that application space. Instead, SECURITY ERASE on the relatively infrequent reboots cleaned things up pretty well. This should be with a grain of salt because I expect trim timings are not only vendor dependent but firmware release dependent. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
On 4/3/12 6:50 PM, Bob Friesenhahn wrote: On Tue, 3 Apr 2012, Julian Elischer wrote: for flash drives this is great news.. Now if ZFS would get trim support, that too would be great. The major unknown issue with trim is how well the drives schedules/defers the trim operation so that it does not interfer with other I/Os. Also, it would be really bad if the drive applied trim after the block had been re-allocated for a write. It would also be really bad if the drive loses unrelated data if there is a power fail during trim. If writes get blocked by a pending trim, then trim would not help very much. well since I work for the drive manufacturer I can say that in this case it really is worth it. :-) But I'm glad that it is getting out there that trim aint as easy as it seems. The hard part about trim is making it so that if you get a power failure, the trimmed data says trimmed. In some cases, it is not important. For example when a filesystem is used, trimmed data will never be accessed again without first writing new data to that address. but for any application that assumes that trimmed data will return zero's it is a critical feature. Bob ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trim/discard success story
On 4/3/12 8:51 PM, Matthew Jacob wrote: My experience at Alacritech was that Trim was so expensive timewise that it could not be used in that application space. Instead, SECURITY ERASE on the relatively infrequent reboots cleaned things up pretty well. This should be with a grain of salt because I expect trim timings are not only vendor dependent but firmware release dependent. very true. In this case, on this drive, on this version.. it is fast. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
Everything is detected correctly, everything comes up correctly. See a new option (reload) in the RC script for hast. success story snipped same here - have patched the master databse achines, all came up fine, everything running erfectly, have flip-flopped between the two machines with no ill effects whatsoever, and all looking very good. cheers, -pete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Sun, Apr 10, 2011 at 12:36 PM, Mikolaj Golub troc...@freebsd.org wrote: On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC Once the deadlock patches above are MFC'd to -STABLE, I can do an FC upgrade cycle and test them. Committed to STABLE. Updated src tree to r220537. Recompiled world, kernel, etc. Installed world, kernel, etc. ZFSv28 patch was not affected. Everything is detected correctly, everything comes up correctly. See a new option (reload) in the RC script for hast. Can create/change role for 24 hast devices simultaneously. Can switch between master/slave modes. Have 5 rsyncs running in parallel without any issues, transferring 80-120 Mbps over the network (just under 100 Mbps seems to be the average right now). Switching roles while the rsyncs are running succeeds without deadlocking (obviously, rsync complains a whole bunch while the switch happens as the pool disappears out from underneath it, but it picks up again when the pool is back in place). Hitting the reset switch on the box while the rsyncs are running doesn't affect the hast devices or the pool, beyond losing the last 5 seconds of writes. It's only been a couple of hours of testing and hammering, but so far things are much more stable/performant than before. Anything else I should test? -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Mon, 11 Apr 2011 11:26:15 -0700 Freddie Cash wrote: FC On Sun, Apr 10, 2011 at 12:36 PM, Mikolaj Golub troc...@freebsd.org wrote: On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC Once the deadlock patches above are MFC'd to -STABLE, I can do an FC upgrade cycle and test them. Committed to STABLE. FC Updated src tree to r220537. Recompiled world, kernel, etc. FC Installed world, kernel, etc. ZFSv28 patch was not affected. FC Everything is detected correctly, everything comes up correctly. See FC a new option (reload) in the RC script for hast. FC Can create/change role for 24 hast devices simultaneously. FC Can switch between master/slave modes. FC Have 5 rsyncs running in parallel without any issues, transferring FC 80-120 Mbps over the network (just under 100 Mbps seems to be the FC average right now). FC Switching roles while the rsyncs are running succeeds without FC deadlocking (obviously, rsync complains a whole bunch while the switch FC happens as the pool disappears out from underneath it, but it picks up FC again when the pool is back in place). FC Hitting the reset switch on the box while the rsyncs are running FC doesn't affect the hast devices or the pool, beyond losing the last 5 FC seconds of writes. FC It's only been a couple of hours of testing and hammering, but so far FC things are much more stable/performant than before. Cool! Thanks for reporting! FC Anything else I should test? Nothing particular, but any tests and reports are appreciated. E.g. ones of the recent features Pawel has added are checksum and compression. You could try different options and compare :-) -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC Once the deadlock patches above are MFC'd to -STABLE, I can do an FC upgrade cycle and test them. Committed to STABLE. -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? FC Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Yes, r220264 and 220266. As it is stated in the commit log MFC is planned after 1 week. -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Tue, Apr 5, 2011 at 5:05 AM, Mikolaj Golub troc...@freebsd.org wrote: On Mon, 4 Apr 2011 11:08:16 -0700 Freddie Cash wrote: FC On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? FC Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Yes, r220264 and 220266. As it is stated in the commit log MFC is planned after 1 week. Okay. I'll keep an eye out next week for the MFC of those patches to hit -STABLE, and do an upgrade/test cycle after that point. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Sat, Apr 2, 2011 at 1:44 AM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: [Not sure which list is most appropriate since it's using HAST + ZFS on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on replies.] I'm having a hell of a time making this work on real hardware, and am not ruling out hardware issues as yet, but wanted to get some reassurance that someone out there is using this combination (FreeBSD + HAST + ZFS) successfully, without kernel panics, without core dumps, without deadlocks, without issues, etc. I need to know I'm not chasing a dead rabbit. I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? Just to confirm, this is commit r220264, 220265, 220266 to -CURRENT? Looking through the commit logs, I don't see any of these MFC'd to -STABLE yet, so I can't test them directly. The storage box that was having the issues is running 8-STABLE r219754 at the moment (with ZFSv28 and Mikolag's ggate patches). I see there have been a lot of hast/ggate-related MFCs in the past week, but they don't include the deadlock patches. Once the deadlock patches above are MFC'd to -STABLE, I can do an upgrade cycle and test them. I do have the previous 9-CURRENT install saved, just nothing to run it on atm. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: [Not sure which list is most appropriate since it's using HAST + ZFS on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on replies.] I'm having a hell of a time making this work on real hardware, and am not ruling out hardware issues as yet, but wanted to get some reassurance that someone out there is using this combination (FreeBSD + HAST + ZFS) successfully, without kernel panics, without core dumps, without deadlocks, without issues, etc. I need to know I'm not chasing a dead rabbit. I just committed a fix for a problem that might look like a deadlock. With trociny@ patch and my last fix (to GEOM GATE and hastd) do you still have any issues? -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpfaqPYEbyOO.pgp Description: PGP signature
Re: Any success stories for HAST + ZFS?
Yes, you may hit it only on hast devices creation. The workaround is to avoid using 'hastctl role primary all', start providers one by one instead. Interesting to note that I just hit a lockup in hast (the discs froze up - could not run hastctl or zpool import, and could not kill them). I have two hast devices instead of one, but I am starting them individually instead of using 'all'. The copde includes all the latest patches which have gone into STABLE over the last few days, none of which look particularly controversial! I havent tried your atch yet, nor been able to reporduce the lockup, but thought you might be interested to know that I also had problems with multiple providers. cheers, -pete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Fri, 01 Apr 2011 11:40:11 +0100 Pete French wrote: Yes, you may hit it only on hast devices creation. The workaround is to avoid using 'hastctl role primary all', start providers one by one instead. PF Interesting to note that I just hit a lockup in hast (the discs froze PF up - could not run hastctl or zpool import, and could not kill PF them). I have two hast devices instead of one, but I am starting them PF individually instead of using 'all'. The copde includes all the latest PF patches which have gone into STABLE over the last few days, none of which PF look particularly controversial! PF I havent tried your atch yet, nor been able to reporduce the lockup, but PF thought you might be interested to know that I also had problems with PF multiple providers. This looks like a different problem. If you have this again please provide the output of 'procstat -kka'. -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
The other 5% of the time, the hastd crashes occurred either when importing the ZFS pool, or when running multiple parallel rsyncs to the pool. hastd was always shown as the last running process in the backtrace onscreen. This is what I am seeing - did you manage to reproduce this with the patch, or does it fix the issue for you ? Am doing more test now, with only a single hast device to see if it is stable. Am Ok to run without mirroring across hast devices for now, but wouldnt like to do so long term! -pete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
This looks like a different problem. If you have this again please provide the output of 'procstat -kka'. Will do... -pete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Fri, Apr 1, 2011 at 4:22 AM, Pete French petefre...@ingresso.co.uk wrote: The other 5% of the time, the hastd crashes occurred either when importing the ZFS pool, or when running multiple parallel rsyncs to the pool. hastd was always shown as the last running process in the backtrace onscreen. This is what I am seeing - did you manage to reproduce this with the patch, or does it fix the issue for you ? Am doing more test now, with only a single hast device to see if it is stable. Am Ok to run without mirroring across hast devices for now, but wouldnt like to do so long term! I have not been able to crash or hang the box since applying Mikolaj's patch. I've tried the following: - destroy pool - create pool - destroy hast providers - create hast providers - switch from master to slave via hastctl using role secondary all - switch from slave to master via hastctl using role primary all - switch roles via hast-carp-switch which does one provider per second - import/export pool I've been running 6 parallel rsyncs for the past 48 hours, getting a consistent 200 Mbps of transfers, with just under 2 TB of deduped data in the pool, without any lockups. So far, so good. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Mon, 28 Mar 2011 10:47:22 +0100 Pete French wrote: It is not a hastd crash, but a kernel crash triggered by hastd process. I am not sure I got the same crash as you but apparently the race is possible in g_gate on device creation. I got the following crash starting many hast providers simultaneously: PF This is very interestng to me - my successful ZFS+HAST only had PF a single drive, but in my new setup I am intending to use two PF HAST processes and then mirror across thhem under ZFS, so I am PF likely to hit this bug. Are the processes stable once launched ? Yes, you may hit it only on hast devices creation. The workaround is to avoid using 'hastctl role primary all', start providers one by one instead. -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
It is not a hastd crash, but a kernel crash triggered by hastd process. I am not sure I got the same crash as you but apparently the race is possible in g_gate on device creation. I got the following crash starting many hast providers simultaneously: This is very interestng to me - my successful ZFS+HAST only had a single drive, but in my new setup I am intending to use two HAST processes and then mirror across thhem under ZFS, so I am likely to hit this bug. Are the processes stable once launched ? I dont have a system on whcih to try your patch at the moment, but will do so when I get the opportunity! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Sun, Mar 27, 2011 at 5:16 AM, Mikolaj Golub troc...@freebsd.org wrote:
On Sat, 26 Mar 2011 10:52:08 -0700 Freddie Cash wrote:
FC hastd backtrace is here:
FC http://www.sd73.bc.ca/downloads/crash/hast-backtrace.png
It is not a hastd crash, but a kernel crash triggered by hastd process.
Ah, interesting.
I am not sure I got the same crash as you but apparently the race is possible
in g_gate on device creation.
95% of the time that it would crash, would be when creating the
/dev/hast/* devices (switching to primary role). Most of the crashes
happened when doing hastctl role primary all, but would occasionally
happen when doing it manually for each resource. Creating the
resources by hand, one every 2 seconds or so, would usually create
them all without crashing.
The other 5% of the time, the hastd crashes occurred either when
importing the ZFS pool, or when running multiple parallel rsyncs to
the pool. hastd was always shown as the last running process in the
backtrace onscreen.
I got the following crash starting many hast providers simultaneously:
fault virtual address = 0x0
#8 0xc0c11adc in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#9 0xc086ac6b in g_gate_ioctl (dev=0xc6a24300, cmd=3374345472,
addr=0xc9fec000 \002, flags=3, td=0xc7ff0b80)
at /usr/src/sys/geom/gate/g_gate.c:410
#10 0xc0853c5b in devfs_ioctl_f (fp=0xc9b9e310, com=3374345472,
data=0xc9fec000, cred=0xc8c9c200, td=0xc7ff0b80)
at /usr/src/sys/fs/devfs/devfs_vnops.c:678
#11 0xc09210cd in kern_ioctl (td=0xc7ff0b80, fd=3, com=3374345472,
data=0xc9fec000 \002) at file.h:262
#12 0xc0921254 in ioctl (td=0xc7ff0b80, uap=0xf5edbcec)
at /usr/src/sys/kern/sys_generic.c:679
#13 0xc0916616 in syscallenter (td=0xc7ff0b80, sa=0xf5edbce4)
at /usr/src/sys/kern/subr_trap.c:315
#14 0xc0c2b9ff in syscall (frame=0xf5edbd28)
at /usr/src/sys/i386/i386/trap.c:1086
#15 0xc0c11b71 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:266
Or just creating many ggate devices simultaneously:
for i in `jot 100`; do
./ggiocreate $i
done
ggiocreate.c is attached.
In my case the kernel crashes in g_gate_create() when checking for name
collisions in strcmp():
/* Check for name collision. */
for (unit = 0; unit g_gate_maxunits; unit++) {
if (g_gate_units[unit] == NULL)
continue;
if (strcmp(name, g_gate_units[unit]-sc_provider-name) != 0)
continue;
mtx_unlock(g_gate_units_lock);
mtx_destroy(sc-sc_queue_mtx);
free(sc, M_GATE);
return (EEXIST);
}
I think the issue is the following. When preparing sc we take
g_gate_units_lock, check for name collision, fill sc fields except
sc-sc_provider, and registers sc in g_gate_units[unit]. sc_provider is filled
later, when g_gate_units_lock is released. So the scenario is possible:
1) Thread A registers sc in g_gate_units[unit] with
g_gate_units[unit]-sc_provider still null and releases g_gate_units_lock.
2) Thread B traverses g_gate_units[] when checking for name collision and
craches accessing g_gate_units[unit]-sc_provider-name.
The attached patch fixes the issue in my case.
Patch applied cleanly to 8-STABLE with ZFSv28 patch also applied.
Just to be safe, did a full buildwold/kernel cycle, running GENERIC
kernel.
So far, I have not been able to produce a crash in hastd, through
several reboots, switching from primary to secondary and back, and
just switching from primary to init and back.
So far, so good.
Now to see if I can reproduce any of the ZFS crashes I had earlier.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Sat, 26 Mar 2011 10:52:08 -0700 Freddie Cash wrote:
FC hastd backtrace is here:
FC http://www.sd73.bc.ca/downloads/crash/hast-backtrace.png
It is not a hastd crash, but a kernel crash triggered by hastd process.
I am not sure I got the same crash as you but apparently the race is possible
in g_gate on device creation.
I got the following crash starting many hast providers simultaneously:
fault virtual address = 0x0
#8 0xc0c11adc in calltrap () at /usr/src/sys/i386/i386/exception.s:168
#9 0xc086ac6b in g_gate_ioctl (dev=0xc6a24300, cmd=3374345472,
addr=0xc9fec000 \002, flags=3, td=0xc7ff0b80)
at /usr/src/sys/geom/gate/g_gate.c:410
#10 0xc0853c5b in devfs_ioctl_f (fp=0xc9b9e310, com=3374345472,
data=0xc9fec000, cred=0xc8c9c200, td=0xc7ff0b80)
at /usr/src/sys/fs/devfs/devfs_vnops.c:678
#11 0xc09210cd in kern_ioctl (td=0xc7ff0b80, fd=3, com=3374345472,
data=0xc9fec000 \002) at file.h:262
#12 0xc0921254 in ioctl (td=0xc7ff0b80, uap=0xf5edbcec)
at /usr/src/sys/kern/sys_generic.c:679
#13 0xc0916616 in syscallenter (td=0xc7ff0b80, sa=0xf5edbce4)
at /usr/src/sys/kern/subr_trap.c:315
#14 0xc0c2b9ff in syscall (frame=0xf5edbd28)
at /usr/src/sys/i386/i386/trap.c:1086
#15 0xc0c11b71 in Xint0x80_syscall ()
at /usr/src/sys/i386/i386/exception.s:266
Or just creating many ggate devices simultaneously:
for i in `jot 100`; do
./ggiocreate $i
done
ggiocreate.c is attached.
In my case the kernel crashes in g_gate_create() when checking for name
collisions in strcmp():
/* Check for name collision. */
for (unit = 0; unit g_gate_maxunits; unit++) {
if (g_gate_units[unit] == NULL)
continue;
if (strcmp(name, g_gate_units[unit]-sc_provider-name) != 0)
continue;
mtx_unlock(g_gate_units_lock);
mtx_destroy(sc-sc_queue_mtx);
free(sc, M_GATE);
return (EEXIST);
}
I think the issue is the following. When preparing sc we take
g_gate_units_lock, check for name collision, fill sc fields except
sc-sc_provider, and registers sc in g_gate_units[unit]. sc_provider is filled
later, when g_gate_units_lock is released. So the scenario is possible:
1) Thread A registers sc in g_gate_units[unit] with
g_gate_units[unit]-sc_provider still null and releases g_gate_units_lock.
2) Thread B traverses g_gate_units[] when checking for name collision and
craches accessing g_gate_units[unit]-sc_provider-name.
The attached patch fixes the issue in my case.
--
Mikolaj Golub
ggiocreate.c
Description: Binary data
Index: sys/geom/gate/g_gate.c
===
--- sys/geom/gate/g_gate.c (revision 220050)
+++ sys/geom/gate/g_gate.c (working copy)
@@ -407,13 +407,14 @@ g_gate_create(struct g_gate_ctl_create *ggio)
for (unit = 0; unit g_gate_maxunits; unit++) {
if (g_gate_units[unit] == NULL)
continue;
- if (strcmp(name, g_gate_units[unit]-sc_provider-name) != 0)
+ if (strcmp(name, g_gate_units[unit]-sc_name) != 0)
continue;
mtx_unlock(g_gate_units_lock);
mtx_destroy(sc-sc_queue_mtx);
free(sc, M_GATE);
return (EEXIST);
}
+ sc-sc_name = name;
g_gate_units[sc-sc_unit] = sc;
g_gate_nunits++;
mtx_unlock(g_gate_units_lock);
@@ -432,6 +433,9 @@ g_gate_create(struct g_gate_ctl_create *ggio)
sc-sc_provider = pp;
g_error_provider(pp, 0);
g_topology_unlock();
+ mtx_lock(g_gate_units_lock);
+ sc-sc_name = sc-sc_provider-name;
+ mtx_unlock(g_gate_units_lock);
if (sc-sc_timeout 0) {
callout_reset(sc-sc_callout, sc-sc_timeout * hz,
Index: sys/geom/gate/g_gate.h
===
--- sys/geom/gate/g_gate.h (revision 220050)
+++ sys/geom/gate/g_gate.h (working copy)
@@ -76,6 +76,7 @@
* 'P:' means 'Protected by'.
*/
struct g_gate_softc {
+ char *sc_name; /* P: (read-only) */
int sc_unit; /* P: (read-only) */
int sc_ref; /* P: g_gate_list_mtx */
struct g_provider *sc_provider; /* P: (read-only) */
@@ -96,7 +97,6 @@ struct g_gate_softc {
LIST_ENTRY(g_gate_softc) sc_next; /* P: g_gate_list_mtx */
char sc_info[G_GATE_INFOSIZE]; /* P: (read-only) */
};
-#define sc_name sc_provider-geom-name
#define G_GATE_DEBUG(lvl, ...) do { \
if (g_gate_debug = (lvl)) { \
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Sun, 27 Mar 2011 15:16:15 +0300 Mikolaj Golub wrote to Freddie Cash: MG The attached patch fixes the issue in my case. The patch is committed to current. -- Mikolaj Golub ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
Hi, 2011/3/24 Freddie Cash fjwc...@gmail.com: The hardware is fairly standard fare: - SuperMicro H8DGi-F motherboard - AMD Opteron 6100-series CPU (8-cores @ 2.0 GHz) - 8 GB DDR3 SDRAM - 64 GB Kingston V-Series SSD for the OS install (using ahci(4) and the motherboard SATA controller) - 3x SuperMicro AOC-USAS2-8Li SATA controllers with IT firmware - 6x 1.5 TB Seagate 7200.11 drives (1x raidz2 vdev) - 12x 1.0 TB Seagate 7200.12 drives (2x raidz2 vdev) - 6x 0.5 TB WD RE3 drives (1x raidz2 vdev) just for info, sun recommend 1 Gb of RAM per Tera of data. i see here ~ 16 To of available data, so i would recommend 16 Gb for arc_size and 24 or 32 Gb for the host. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Fri, Mar 25, 2011 at 12:55 AM, Pawel Jakub Dawidek p...@freebsd.org wrote:
On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote:
I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28
patches, and 9-CURRENT (after the ZFSv28 commit). Things work well
until I start hastd. Then either the system locks up, or hastd causes
a kernel panic, or hastd dumps core.
The minimum amount of information (as always) would be backtrace from
the kernel and also hastd backtrace when it coredumps. There is really
decent logging in hast, so I'm also sure it does log something
interesting on primary or secondary. Another useful thing would be to
turn on debugging in hast (single -d option for hastd).
The best you can do is to give me the simplest and quickest procedure to
reproduce the issue, eg. configure two hast resources, put ZFS mirror on
top, start rsync /usr/src to the file system on top of hast and switch
roles. The simpler the better.
FreeBSD 8-STABLE r219754 with the ZFSv28 patches applied.
hast.conf:
resource disk-a1 {
local /dev/label/disk-a1
on omegadrive {
remote tcp4://10.20.0.102
}
on alphadrive {
remote tcp4://10.20.0.101
}
}
resource disk-a2 {
local /dev/label/disk-a2
on omegadrive {
remote tcp4://10.20.0.102
}
on alphadrive {
remote tcp4://10.20.0.101
}
}
Following will crash hastd:
service hastd onestart
hastctl create disk-a1
hastctl create disk-a2
hastctl role primary all
hastd backtrace is here:
http://www.sd73.bc.ca/downloads/crash/hast-backtrace.png
I'll try running it with -d to see if there's anything interesting there.
Sure, running it with -d and -F, output to a log file, everything
works well using 2 disks.
Hrm, running it with all 24 disks, I can't make it crash now.
However, I did change the kernel hz from 100 to 1000. I'll see if I
can switch it back to 100 and try the tests again using -dF.
The backtrace listed above is with kern.hz=100.
--
Freddie Cash
fjwc...@gmail.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Any success stories for HAST + ZFS?
On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote: I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 patches, and 9-CURRENT (after the ZFSv28 commit). Things work well until I start hastd. Then either the system locks up, or hastd causes a kernel panic, or hastd dumps core. The minimum amount of information (as always) would be backtrace from the kernel and also hastd backtrace when it coredumps. There is really decent logging in hast, so I'm also sure it does log something interesting on primary or secondary. Another useful thing would be to turn on debugging in hast (single -d option for hastd). The best you can do is to give me the simplest and quickest procedure to reproduce the issue, eg. configure two hast resources, put ZFS mirror on top, start rsync /usr/src to the file system on top of hast and switch roles. The simpler the better. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpYcvgL105vI.pgp Description: PGP signature
Re: Any success stories for HAST + ZFS?
So, please, someone, somewhere, share a success story, where you're using FreeBSD, ZFS, and HAST. Let me know that it does work. I'm starting to lose faith in my abilities here. :( I ran our main database for the old company using ZFS on top of HAST without any problems at all. Had a single HAST disc with a zpool on top of it, and mysql on top of that. All worked perfectly for us. Am not running that currently as the company went under and we lost the hardware. But am working for a new business and am about to deploy the same configuration for the main database as its tried and tested as far as I am concerned. Will be slightly different, as I will have a pair of HAST drives and do mirroring over the top with ZFS. But I shall report back how well, or not, it works. -pete. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Any success stories for HAST + ZFS?
[Not sure which list is most appropriate since it's using HAST + ZFS on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on replies.] I'm having a hell of a time making this work on real hardware, and am not ruling out hardware issues as yet, but wanted to get some reassurance that someone out there is using this combination (FreeBSD + HAST + ZFS) successfully, without kernel panics, without core dumps, without deadlocks, without issues, etc. I need to know I'm not chasing a dead rabbit. In tests using VirtualBox and FreeBSD 8-STABLE from when HAST was first MFC'd, everything worked wonderfully. HAST-based pool would come up, data would sync to the slave node, fail-over worked nicely, bringing the other box back online as the slave worked, data synced back, etc. It was a thing of beauty. Now, on real hardware, I cannot get the system to stay online for more than an hour. :( hastd causes kernel panics with bufwrite: buffer not busy errors. ZFS pools get corrupted. System deadlocks (no log messages, no onscreen errors, not even NumLock key works) at random points. The hardware is fairly standard fare: - SuperMicro H8DGi-F motherboard - AMD Opteron 6100-series CPU (8-cores @ 2.0 GHz) - 8 GB DDR3 SDRAM - 64 GB Kingston V-Series SSD for the OS install (using ahci(4) and the motherboard SATA controller) - 3x SuperMicro AOC-USAS2-8Li SATA controllers with IT firmware - 6x 1.5 TB Seagate 7200.11 drives (1x raidz2 vdev) - 12x 1.0 TB Seagate 7200.12 drives (2x raidz2 vdev) - 6x 0.5 TB WD RE3 drives (1x raidz2 vdev) The motherboard BIOS is up-to-date. I do not see any way to update the firmware on the SATA controllers. Using the onboard IPMI-based sensors, CPU, motherboard, RAM temps and volatages are in the nominal range. I've tried with FreeBSD 8.2-RELEASE, 8-STABLE, 8-STABLE w/ZFSv28 patches, and 9-CURRENT (after the ZFSv28 commit). Things work well until I start hastd. Then either the system locks up, or hastd causes a kernel panic, or hastd dumps core. Each harddrive is glabel'd as disk-a1 through disk-d6. hast.conf has 24 resources listed, one for each glabel'd device. The pool is created using the /dev/hast/* devices with disk-a1 through disk-a6 being one raidz2 vdev, and so on through disk-b*, disk-c*, and disk-d*, for a total of 4 raidz2 vdevs of 6 drives each. A fairly standard setup, I would think. Even using a GENERIC kernel, I can't keep things stable and running. So, please, someone, somewhere, share a success story, where you're using FreeBSD, ZFS, and HAST. Let me know that it does work. I'm starting to lose faith in my abilities here. :( Or point out where I'm doing things wrong so I can correct the issues. Thanks. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Success compiling R v 1.8.0
The R statistics port (ports/math/R-letter) is at version 1.7.0. Being the impatient type I tried compiling the recently released 1.8.0 using the same Makefile (with 1.7 changed to 1.8) and a new MD5 value, and had no new problems compiling. R v.1.7 and v 1.8 trigger a bug in GCC (internal compiler error) and the workaround is to wait for the bug to trigger, then compile that particular piece of code using -O2 rather than -O, and then execute make again. Mike Squires ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Success compiling R v 1.8.0
On Mon, 27 Oct 2003, Michael L. Squires wrote: The R statistics port (ports/math/R-letter) is at version 1.7.0. Being the impatient type I tried compiling the recently released 1.8.0 using the same Makefile (with 1.7 changed to 1.8) and a new MD5 value, and had no new problems compiling. R v.1.7 and v 1.8 trigger a bug in GCC (internal compiler error) and the workaround is to wait for the bug to trigger, then compile that particular piece of code using -O2 rather than -O, and then execute make again. The gcc folks tend to be interested in this sort of thing. You might want to follow the instructions given and report the bug. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Success compiling R v 1.8.0
On Mon, Oct 27, 2003 at 07:42:06PM -0800, Doug White wrote: On Mon, 27 Oct 2003, Michael L. Squires wrote: The R statistics port (ports/math/R-letter) is at version 1.7.0. Being the impatient type I tried compiling the recently released 1.8.0 using the same Makefile (with 1.7 changed to 1.8) and a new MD5 value, and had no new problems compiling. R v.1.7 and v 1.8 trigger a bug in GCC (internal compiler error) and the workaround is to wait for the bug to trigger, then compile that particular piece of code using -O2 rather than -O, and then execute make again. The gcc folks tend to be interested in this sort of thing. You might want to follow the instructions given and report the bug. Try gcc 3.3.2 (e.g. install the port) first. Kris pgp0.pgp Description: PGP signature
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
I found easy way to ugen problem: in /etc/devfs.rules I added [local_ruleset=10] add path 'ugen*' mode 664 then in /etc/rc.conf devfs_system_ruleset=local_ruleset And this is it. Now user can acces camera (PowerShots50) with gtkam. The resolution was given by (http://lists.freebsd.org/pipermail/freebsd-current/2003-September/009706.html) Jeff Walters*. *Based on man devfs it is impossible to resolve this issue. * * ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
Poul-Henning, many thanks for you kind guidance to the wonderful world of devfs (which I never had to tweak in the past) ;-) On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote: I would probably just use a wildcard: permugen* 0666 The wildcard feature is really fine ! Thanks for pointing me into that direction. This makes the rules only apply to devices arriving in the future, you also need: devfs rule applyset to make them apply to currently available devices. Good hint ! Thanks ! Well and now things work like expected. I put these devfs commands now into /etc/rc.local. But since /etc/rc.local officially has gone, I think this is not the best place ... After a longer examination of /etc/devfs, /etc/rc.subr /etc/defaults/devfs.rules and /etc/defaults/rc.conf I got the clue, that I can put the statements into /etc/devfs.rules. Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. Andreas /// -- Andreas Klemm - Powered by FreeBSD 5.1-CURRENT Need a magic printfilter today ? - http://www.apsfilter.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
In message [EMAIL PROTECTED], Andreas Klemm writ es: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) I personally end up less(1)'ing /etc/rc.d/* every time I want to do something... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: success (Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted)
On Mon, Oct 20, 2003 at 02:40:00PM +0200, Poul-Henning Kamp wrote: Hint: here again we seem to be missing a manpage: devfs.rules(5). In /etc/rc.subr you see for example a reference to this manpage, but it doesn't exist. I'm sure we'd be more than happy to see somebody (hint hint!) send manual page text to us :-) That's not the right attitude for something that is 100% your baby. You've added a completely new subsystem to FreeBSD, one that people have no choice but to deal with when they move from 4.x to 5.x since you made devfs mandatory. It is YOUR responsibility to document it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OT: Success Story
I thought I'd relate this success story to all of you -current people. We are the webhost for talklikeapirate.com -- the official site for International Talk Like a Pirate Day that happened this past friday. This is about as big an event that the small regional ISP I work for has ever seen. I have been working on designs for our new web servers all summer, using FreeBSD 5.1R as our OS. When it became apparent to us that the Linux based server the website was on was not going to handle the load gracefully, we switched our operations to our untested FreeBSD cluster. The new cluster shined, and sustained the traffic, which reached 2000 simultaneous connections, without a hiccup. We have a lot of linux zealots in our organization, and FreeBSD was a hard sell for me initially. This event has validated my choice to others in the organization. The point of all of this is that I wanted to thank all of the folks that work so hard on FreeBSD. The product is excellent, and the interactions I've had with everyone involved with the project has been stellar. The nature of the job is that it's pretty thankless, and I think you guys could use an attaboy every once in a while. I could not be successful without all of your hard work and contributions. Thanks again! -- Jeremy C. McDermond [EMAIL PROTECTED] Lead Engineer Peak Internet, LLC (541) 738-4921 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success (fwd)
eh? i silently assumed that it already was commited! i used bluetooth
on my T30 on -current which is maybe three weeks old and it works!
and to make this very clear, it did NOT work on a -current from around
the time when i sent that email below. the patch fixed it back then,
nothing else did.
so, now i am confused...
On Mon, Aug 25, 2003 at 01:24:20PM -0700, Lee Damon wrote:
Does anyone have an estimate of when this patch will be checked in?
Please?
thanks,
nomad
--- Forwarded Messages
Date: Mon, 16 Jun 2003 23:37:38 +0200
From: Tobias Roth [EMAIL PROTECTED]
To: Lee Damon [EMAIL PROTECTED]
Subject: Re: IBM T30 bluetooth - success
Message-ID: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jun 16, 2003 at 02:22:02PM -0700, Lee Damon wrote:
What did you do?
in short, whining to some people about usb being broken until
someone (Bernd Walter) came up with a patch :-)
Other than that, I just followed Pavs tutorials at
http://www.oook.cz/bsd
good luck, t.
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=usb_working.diff
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.54
diff -u -r1.54 usb_subr.c
--- usb_subr.c14 Jan 2003 23:07:43 - 1.54
+++ usb_subr.c14 Jun 2003 16:01:38 -
@@ -964,6 +964,7 @@
usbd_device_handle dev;
struct usbd_device *hub;
usb_device_descriptor_t *dd;
+ usb_port_status_t ps;
usbd_status err;
int addr;
int i;
@@ -1020,12 +1021,14 @@
up-device = dev;
dd = dev-ddesc;
/* Try a few times in case the device is slow (i.e. outside specs.) */
- for (i = 0; i 3; i++) {
+ for (i = 0; i 15; i++) {
/* Get the first 8 bytes of the device descriptor. */
err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd);
if (!err)
break;
usbd_delay_ms(dev, 200);
+ if ((i 3) == 3)
+ usbd_reset_port(up-parent, port, ps);
}
if (err) {
DPRINTFN(-1, (usbd_new_device: addr=%d, getting first desc
--PNTmBPCT7hxwcZjr--
--- Message 2
Date: Tue, 17 Jun 2003 07:07:25 +0200
From: Bernd Walter [EMAIL PROTECTED]
To: Lee Damon [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: IBM T30 bluetooth - success
Message-ID: [EMAIL PROTECTED]
On Mon, Jun 16, 2003 at 04:31:25PM -0700, Lee Damon wrote:
I can second that success. Any chance of getting this patch checked in?
I just wait on a review.
- --
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
--- End of Forwarded Messages
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success (fwd)
On Tue, Aug 26, 2003 at 08:46:12AM +0200, Tobias Roth wrote: eh? i silently assumed that it already was commited! i used bluetooth on my T30 on -current which is maybe three weeks old and it works! and to make this very clear, it did NOT work on a -current from around the time when i sent that email below. the patch fixed it back then, nothing else did. so, now i am confused... It's a timing related hardwarebug on power up. Other environment temperatures, etc may change things. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success (fwd)
Does anyone have an estimate of when this patch will be checked in?
Please?
thanks,
nomad
--- Forwarded Messages
Date: Mon, 16 Jun 2003 23:37:38 +0200
From: Tobias Roth [EMAIL PROTECTED]
To: Lee Damon [EMAIL PROTECTED]
Subject: Re: IBM T30 bluetooth - success
Message-ID: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Mon, Jun 16, 2003 at 02:22:02PM -0700, Lee Damon wrote:
What did you do?
in short, whining to some people about usb being broken until
someone (Bernd Walter) came up with a patch :-)
Other than that, I just followed Pavs tutorials at
http://www.oook.cz/bsd
good luck, t.
--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=usb_working.diff
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.54
diff -u -r1.54 usb_subr.c
--- usb_subr.c 14 Jan 2003 23:07:43 - 1.54
+++ usb_subr.c 14 Jun 2003 16:01:38 -
@@ -964,6 +964,7 @@
usbd_device_handle dev;
struct usbd_device *hub;
usb_device_descriptor_t *dd;
+ usb_port_status_t ps;
usbd_status err;
int addr;
int i;
@@ -1020,12 +1021,14 @@
up-device = dev;
dd = dev-ddesc;
/* Try a few times in case the device is slow (i.e. outside specs.) */
- for (i = 0; i 3; i++) {
+ for (i = 0; i 15; i++) {
/* Get the first 8 bytes of the device descriptor. */
err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd);
if (!err)
break;
usbd_delay_ms(dev, 200);
+ if ((i 3) == 3)
+ usbd_reset_port(up-parent, port, ps);
}
if (err) {
DPRINTFN(-1, (usbd_new_device: addr=%d, getting first desc
--PNTmBPCT7hxwcZjr--
--- Message 2
Date: Tue, 17 Jun 2003 07:07:25 +0200
From: Bernd Walter [EMAIL PROTECTED]
To: Lee Damon [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: IBM T30 bluetooth - success
Message-ID: [EMAIL PROTECTED]
On Mon, Jun 16, 2003 at 04:31:25PM -0700, Lee Damon wrote:
I can second that success. Any chance of getting this patch checked in?
I just wait on a review.
- --
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
--- End of Forwarded Messages
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success (fwd)
On Mon, Aug 25, 2003 at 01:24:20PM -0700, Lee Damon wrote: Does anyone have an estimate of when this patch will be checked in? I will commit this patch during this week. Several persons were asked for review without even a reply. Thanks for reminding me. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Checking buildworld success from ssh
Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? Thanks. Greg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Checking buildworld success from ssh
On Mon, Jul 28, 2003 at 09:28:07AM -0400, Gregory Pavelcak wrote: Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? The last thing made is creation of the freebsd.cf file. See if it was created in /usr/obj/usr/src/etc/sendmail. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
Re: Checking buildworld success from ssh
Hi, you could restart the buildworld with the -DNOCLEAN option, this would terminate much faster than usual o r show up where it fails.. Hope this helps. Regards Henry Am Montag, 28.07.03, um 15:28 Uhr (Europe/Berlin) schrieb Gregory Pavelcak: Hi all, I started a buildworld on current sources this morning, but, foolishly, didn't redirect the output to a file. Now I have some free time at work and would like to ssh in and do the kernel and mergemaster. Of course, I don't want to do these things if buildworld failed. Is there any way I can tell in the absence of saved output? ... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success
Tobias, I just wanted to let you know that I got the integrated bluetooth device in my IBM T30 to work (yes, I am sending this mail from my T30 via bluetooth via my Ericsson T68i and GPRS cool :) i'm glad you made it working :) Thanks to Pav and Max for all the fabulous work and help! Thanks to Bernd for the usb patch who made this possible! and thank you for your time and help with testing :) max p.s. if you have any problems, questions or suggestions please let us know __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success
I can second that success. Any chance of getting this patch checked in?
thanks,
nomad
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x), rev 1.00
uhub2
port 1 addr 2: full speed, power 200 mA, config 1, IBM Integrated
Bluetooth(0x0310), TDK(0x04bf), rev 1.15
ubt0
port 2 powered
Index: usb_subr.c
===
RCS file: /home/ncvs/src/sys/dev/usb/usb_subr.c,v
retrieving revision 1.54
diff -u -r1.54 usb_subr.c
--- usb_subr.c14 Jan 2003 23:07:43 - 1.54
+++ usb_subr.c14 Jun 2003 16:01:38 -
@@ -964,6 +964,7 @@
usbd_device_handle dev;
struct usbd_device *hub;
usb_device_descriptor_t *dd;
+ usb_port_status_t ps;
usbd_status err;
int addr;
int i;
@@ -1020,12 +1021,14 @@
up-device = dev;
dd = dev-ddesc;
/* Try a few times in case the device is slow (i.e. outside specs.) */
- for (i = 0; i 3; i++) {
+ for (i = 0; i 15; i++) {
/* Get the first 8 bytes of the device descriptor. */
err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd);
if (!err)
break;
usbd_delay_ms(dev, 200);
+ if ((i 3) == 3)
+ usbd_reset_port(up-parent, port, ps);
}
if (err) {
DPRINTFN(-1, (usbd_new_device: addr=%d, getting first desc
nomad
--- - Lee nomad Damon - \
play: [EMAIL PROTECTED]or castle!nomad \
work: [EMAIL PROTECTED] \
/\
Seneschal, Castle PAUS./ \
Celebrate Diversity /\
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IBM T30 bluetooth - success
On Mon, Jun 16, 2003 at 04:31:25PM -0700, Lee Damon wrote: I can second that success. Any chance of getting this patch checked in? I just wait on a review. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
success report of gcc3.2.1
Hi The new binutils and gcc3.2.1 release hit the tree recently, nice to see everything is moving forward. I would like to tell the importers that XFree86-4, KDE3 and GNOME2 built without a hitch for me. Here's my list without GNOME2, latter was built only for testing purposes and deleted promptly after success. Mesa-3.4.2_2A graphics library similar to SGI's OpenGL ORBit-0.5.17High-performance CORBA ORB with support for the C language XFree86-4.2.0_1,1 X11/XFree86 core distribution (complete, using mini/meta-po XFree86-FontServer-4.2.0_1 XFree86-4 Font Server XFree86-Server-4.2.1_5 XFree86-4 X server and related programs XFree86-clients-4.2.1_2 XFree86-4 Client environments XFree86-documents-4.2.0 XFree86-4 Document Files XFree86-font100dpi-4.2.0 XFree86-4 bitmap 100 dpi fonts XFree86-font75dpi-4.2.0 XFree86-4 bitmap 75 dpi fonts XFree86-fontCyrillic-4.2.0_4 XFree86-4 Cyrillic Fonts XFree86-fontDefaultBitmaps-4.2.0 XFree86-4 default bitmap fonts XFree86-fontEncodings-4.2.0 XFree86-4 font encoding files XFree86-fontScalable-4.2.0 XFree86-4 Scalable font files XFree86-libraries-4.2.1_4 XFree86-4 include/(shared) library kit Xaw3d-1.5 A 3-D Athena Widget set that looks like Motif Xft-2.0_1 A client-sided font API for X applications aalib-1.4.r5_1 An ascii art library arts-1.0.4,1Audio system for the KDE integrated X11 desktop atk-1.0.3 A GNOME accessibility toolkit (ATK) autoconf-2.53_1 Automatically configure source code on many Un*x platforms autoconf213-2.13.000227_5 Automatically configure source code on many Un*x platforms automake-1.5,1 GNU Standards-compliant Makefile generator automake14-1.4.5_9 GNU Standards-compliant Makefile generator (legacy version bash-2.05b.004 The GNU Bourne Again Shell boehm-gc-6.1Garbage collection and memory leak detection for C and C++ bundle-workstation-1.0 Vallo meta-port cdrtools-1.11.a39 Cdrecord, mkisofs and several other programs to record CD-R cups-base-1.1.15.1_4 The Common UNIX Printing System: headers, libs, daemons cups-pstoraster-7.05.5_1 GNU Postscript interpreter for CUPS printing to non-PS prin expat-1.95.5XML 1.0 parser written in C fetchmail-6.1.2 Batch mail retrieval utility for IMAP/POP2/POP3/APOP/KPOP/E fontconfig-2.0_2An XML-based font configuration API for X Windows freetype2-2.1.2_1 A free and portable TrueType font rendering engine gettext-0.11.5_1GNU gettext package ghostscript-gnu-7.05_3 GNU Postscript interpreter gimp-1.3.10,1 A GNU Image Manipulation Program (unstable development vers gimp-print-4.2.3GIMP Print Printer Driver glib-1.2.10_8 Some useful routines of C programming (previous stable vers glib-2.0.7 Some useful routines of C programming (current stable versi gmake-3.80 GNU version of 'make' utility gnupg-1.2.1 The GNU Privacy Guard gtk-1.2.10_9Gimp Toolkit for X11 GUI (previous stable version) gtk-2.0.9 Gimp Toolkit for X11 GUI (current stable version) gv-3.5.8_1 A PostScript and PDF previewer help2man-1.29 Automatically generating simple manual pages from program o imake-4.2.0_1 Imake and other utilities from XFree86 ipcalc-0.35_1 IP Calculator ja-libslang-1.4.5.j2 A library permits a programmer to develop software ja-mutt-1.5.1.j1Text-based mail client (Japanised development version) jpeg-6b_1 IJG's jpeg compression utilities kdebase-3.0.5 Base modules for the KDE integrated X11 desktop kdegames-3.0.4 Games for the KDE integrated X11 desktop kdegraphics-3.0.4 Graphics utilities for the KDE3 integrated X11 desktop kdelibs-3.0.5_1 Libraries for KDE kdemultimedia-3.0.4 Multimedia utilities for the KDE integrated X11 desktop kdenetwork-3.0.5Network modules for KDE3 kdeutils-3.0.4_1Utilities for the KDE integrated X11 desktop lame-3.93.1 ISO code based fast MP3 encoder kit lcms-1.09 Light Color Management System -- a color management library libart_lgpl2-2.3.10 Library for high-performance 2D graphics libaudiofile-0.2.3 A sound library for SGI audio file libdvdcss-1.2.2 Portable abstraction library for DVD decryption libdvdread-0.9.3This is needed by ogle, which is a DVD player that supports libiconv-1.8_2 A character set conversion library libijs-0.34 C library that supports plugin printer driver for Ghostscri libmikmod-3.1.10MikMod Sound Library libmng-1.0.4Multiple-image Network Graphics (MNG) reference library libogg-1.0_1,3 Ogg bitstream library libtool-1.3.4_4 Generic shared library support script libvorbis-1.0_1,3 Audio compression codec library libxml-1.8.17_1 Xml parser library for GNOME libxml2-2.4.28_1Xml parser library for GNOME libxslt-1.0.23 The XSLT C library for GNOME liveMedia-2002.11.18 LIVE.COM Streaming Media m4-1.4_1GNU m4 mkisofs-1.15.a39Create iso9660/Rock Ridge/Joliet filesystems mozilla
Re: FYI - 4.3-stable to 5.0 upgrade success
On Sat, Nov 30, 2002 at 05:48:21PM -0500, Daniel Eischen wrote: I recently upgraded a Dell Lattitude C600 from some version of -stable after 4.3 to 5.0-current. I first upgraded it to 4.7-stable, then to 5.0-current. I followed the instructions at the end of src/UPDATING pretty much to the letter. I haven't recompiled any applications for 5.0, so they're all running OK under -current (KDE and some other stuff). You could also jump directly from 4.3 to 5.0 -- I'm in charge of supporting this upgrade path, down to 4.0. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg48079/pgp0.pgp Description: PGP signature
FYI - 4.3-stable to 5.0 upgrade success
I recently upgraded a Dell Lattitude C600 from some version of -stable after 4.3 to 5.0-current. I first upgraded it to 4.7-stable, then to 5.0-current. I followed the instructions at the end of src/UPDATING pretty much to the letter. I haven't recompiled any applications for 5.0, so they're all running OK under -current (KDE and some other stuff). -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
A success story, of sorts
Last week I decided to blow away my newer laptop's ancient 4.3 installation (well, actually, Lose XP decided to do it for me, but that's another story). I had just gotten my complimentary developer's CD set from FreeBSDmall.com (thanks, guys!) and decided to reinstall everything from scratch. So after I finished fighting with Windows eXtreme Punishment, I stick the 4.7 install CD and reboot. Windows loads again. I spend the next hour playing all sorts of games with the BIOS, and so far as I can tell it just absolutely refuses to load the 4.7 CD. (Windows installed from CD just fine.) I borrow a Debian 3.0 CD from a cow-orker, and it gets a little bit further, but crashes before loading the kernel. Finally, I give up in despair and make boot floppies. Works perfectly. I do as minimal an installation as I possibly can, and immediately cvsup to -current. Buildworld runs perfectly; installworld drops dead pretty quickly, as I hadn't yet rebooted with the new kernel. Having done that, everything goes smoothly. Every reboot, ACPI prints some odd messages on my console: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.11.0 \\_SB_.LNKB irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.11.1 \\_SB_.LNKC irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.9.0 \\_SB_.LNKE irq 3: [ 3 4] low,level,sharable 0.7.0 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.13.0 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.12.0 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.5.3 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.15.0 \\_SB_.LNKA irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.16.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKA irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.11.0 \\_SB_.LNKB irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.11.1 \\_SB_.LNKC irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.9.0 \\_SB_.LNKE irq 3: [ 3 4] low,level,sharable 0.7.0 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.13.0 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.12.0 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.5.3 \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.15.0 \\_SB_.LNKA irq 11: [ 5 6 7 10 11 12] low,level,sharable 0.16.0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xd000-0xdfff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 initial configuration \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 1.0.0 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKD irq 11: [ 5 6 7 10 11 12] low,level,sharable 1.0.0 pci1: ACPI PCI bus on pcib1 This looks to me like debugging information that probably should not be printed by default. The ASL and raw DSDT are available on request. What else is there to mention NEWCARD worked beautifully with my Enterasys RoamAbout card and with my old standby 3C589D (which I use when I need a static address). I am noticing some surprising network hesitation on the 3Com when I send large files to the laptop. Now that I have working CardBus I should try upgrading to a 32-bit network card. After deleting the cvsup that I had originally installed and installing an older (non-gui) version, I was able to build X from scratch with no trouble. Mozilla 1.2 also built without error. KDE was another story, but I didn't care to spend a lot of time debugging huge C++ programs so I stopped bothering with it. I also built ImageMagick, which I need when downloading images from my digital camera, and had no trouble other than the useless dependency that it has on some library or other that I couldn't care less about and never builds for me anyway. I had to back the openssh-portable port off to the previous version so that the Kerberos patches would apply. (Perhaps this needs to be separated out into a separate port.) All the commits I made this past weekend were build-tested on the laptop (accessing it remotely from home), so from that perspective at least the system seems pretty solid. Disklabel is unhappy with GEOM, as others have already noted. I don't anticipate needing to redo the label any time soon, so I'm not immediately concerned about this. I have no clue how to interpret the output from `sysctl hw.acpi.thermal'. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A success story, of sorts
Garrett Wollman wrote: I have no clue how to interpret the output from `sysctl hw.acpi.thermal'. peter@mobile[2:44pm]~-100 sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 30 hw.acpi.thermal.tz0.temperature: 3281 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3581 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3731 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 The temperatures are in kelvin * 10. ie: subtract 2731 to get degrees celcius, then divide by 10. In my case above: 3281 - 2731 = 550, or 55.0C. There are two types of cooling. active or passive. In my case its passive - ie: fully automatic. _PSV is the nominal temperature that the fan starts to kick in at, 85C in this case. _CRT is the critical (you're about to catch fire) alert temperature - 100C in my case. I think _HOT is the point that you should be worried, while _CRT = power down now or else!. The various _AC0, _AC1 etc are for the active cooling system. ie: the OS has to monitor the temperature, and set the fan speed as it crosses the _AC* levels. There is another method that it calls to do this, and this is driven by the kthread acpi_fan or acpi_thermal, I dont remember exactly. .tz0. is thermal zone 0. There may be more than one zone, especially in larger servers. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A success story, of sorts
On Mon, 28 Oct 2002 14:51:31 -0800, Peter Wemm [EMAIL PROTECTED] said: The temperatures are in kelvin * 10. ie: subtract 2731 to get degrees celcius, then divide by 10. In my case above: 3281 - 2731 = 550, or 55.0C. Cool. I just wasted an hour hacking up xload to make it display temperature (in dekadegrees Celsius) instead of load average. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Success story - was Re: HEADS UP: OpenSSH 3.1 imported
Hello, On Mon, Mar 18, 2002 at 11:27:48AM -0800, David Wolfskill wrote: I generally try to avoid chattering too much on the lists, but given the eventfulness of the normally-rather-routine -CURRENT build this morning, I thought it would be appropriate to announce a measure of success. Heh. I did my routine build yesterday and so far I can report success too. Needless to say, I do not yet have the new OpenSSH, but I did the Perl upgrade and the rest. (including the splitfs support in the boot2. Now I get interesting output at boot telling me how it looks for components.) And, watch this, I have no problems so far with the new zlib, even the dreaded man ispell works fine for me. In addition, it feels that I am getting increased I/O performance on my ATA disk with a softupdates-less filesystem. Something like: Erasing the /usr/obj/* directory strucutre took about 20 mins before, yesterday it was done in 2 mins? In the next moment I heard the sound of my jaw slamming onto my desk...:-) Keep up the good work! -- Regards: Szilveszter ADAM Szombathely Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: Success! critical_enter()/critical_exit() revamp (was Re: m
On 24-Feb-02 Matthew Dillon wrote: Apart from all the assembly coding, there were two serious issues. fork_exit() assumes that interrupts are hard-disabled on entry. I readjusted the code such that the trampoline assembly initialized the td_critnest count so it could STI prior to calling fork_exit(). Err, this is a feature. It isn't safe for us to take an interrupt until we have safeuly cleaned up and released sched_lock. The second issue is that cpu_switch() does not save/restore the PSL_I (interrupt disablement mask). I added a PSL word to the PCB structure to take care of the problem. Without this if you have a thread switch away while holding interrupts hard-disabled, the next thread will inherit the hard disablement. I saw the sti's you added in various places but I figured the best solution was to simply save/restore the state. The original code didn't have this problem because interrupts were always hard-disabled while holding the sched_lock and, of course, cpu_switch() is always called while holding sched_lock. (Similarly, icu_lock needed hard-disablements wrapped around it for the same reason, because a level interrupt still needs to be able to get icu_lock in order to defer itself). That's cause the state of PSL_I is saved in td_savecrit. Note that the only caller of cpu_switch() is mi_switch(). You need to look at the two functions together. Much of the stuff that used to be in asm is now in C to make the code more portable so that supporting other arch's is easier. While the state for pending interrupts should be per-CPU, you should still be using some per-thread state since we can call switch with interrupts disabled (this happens when we preempt with interrupts disabled.) Speaking of preemption. :) critical_enter/exit are specifically divided into two portions: and MD portion and an MI portion. The preemption patches grow the MI functions a bit to handle deferred preemptions. It would be best if instead of getting rid of the MI functions you would work within the existing framework and architecture and change the implementation of cpu_critical_enter/exit. Note that you have a fully opaque type critical_t to allow you to store whatever per-thread state you wish. Also, you are free to use whatever per-CPU state as well. In anycase, I have successfully built the world in a -current SMP + apic_vector system. Tomorrow I will cleanup on the UP icu_vector code to match the apic_vector code and post the results. I also have a sysctl that allows developers to toggle the mode for testing purposes (old way or new way). Finally, I took your suggestion in regards to not trying to combine the masks together. I have a 'some sort of interrupt is pending' variable then I have fpending (for fast interrupts), ipending (for normal interrupt threads), and spending (which I use for the stat and hardclock forwarding). They're all per-cpu entities, of course. unpend() prioritizes them. In anycase, I'll post it all tomorrow after I've got icu_vector cleaned up. One of the best things about this patch set is that it is really flexible. We should be able to really make interrupts fly. In fact, it should even be possible for one cpu to steal another cpu's pending interrupt(s) fairly trivially, without having to resort to IPIs. Eww, how does that work unless the other CPU uses an atomic op to clear the bit, which means that now the local CPU needs to use atomic ops to ensure consistent data. -Matt -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RE: Success! critical_enter()/critical_exit() revamp (was Re: m
: : :On 24-Feb-02 Matthew Dillon wrote: : Apart from all the assembly coding, there were two serious issues. : fork_exit() assumes that interrupts are hard-disabled on entry. I : readjusted the code such that the trampoline assembly initialized : the td_critnest count so it could STI prior to calling fork_exit(). : :Err, this is a feature. It isn't safe for us to take an interrupt until we :have safeuly cleaned up and released sched_lock. This and your other comments only apply to systems that have a hard interrupt disablement side effect to critical_enter(). My critical_*() patch set (partially based on BDE's work) removes this requirement and exposes two flaws in the existing MI code (discussed on the lists already). One is a flaw in fork_exit() due to it making improper assumptions as to the nature of the trampoline code to close a td_critnest/sched_lock initialization race, and the other is a flaw in ast() which uses cpu_critical_*() routines as a hack to tightly couple it with MD doreti(). In fact, the assembly that calls ast() should be responsible for placing the machine in the proper critical state. These are not 'bugs' per say, because the flaws remain consistent within their domain. But they are flaws. I am rather disturbed that you keep explaining the flaws and MD/MI cross pollution away as being a 'feature'. It most certainly is not a feature. I am also disturbed that these special interactions assumptions were not documented *anywhere* in the critical_*() or cpu_critical_*() code. And, finally, I am extremely disturbed about the logic you use to justify both the two-level critical_*() API and to justify the hacks in fork_exit() and ast(). In anycase, it's going to become moot very soon now as I clean it up. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Success! critical_enter()/critical_exit() revamp (was Re: malloc_bucket() idea (was Re: How to fix malloc.))
I'm going to wait until tomorrow before posting it. I have a bunch of cleanup to do. Bruce, your sys.dif was *invaluable*! It would have taken me a lot longer to figure out the interrupt disablement requirement around the icu_lock, and the statclock and hardclock forwarding issues (which I got working by the way!). It turns out that putting the pending masks in the per-cpu area was the right solution! It made statclock and hardclock forwarding easy (I can see why you didn't even try in your patch set, doing it with a global mask would be nearly impossible). In fact, it made everything unbelievably easy. Apart from all the assembly coding, there were two serious issues. fork_exit() assumes that interrupts are hard-disabled on entry. I readjusted the code such that the trampoline assembly initialized the td_critnest count so it could STI prior to calling fork_exit(). The second issue is that cpu_switch() does not save/restore the PSL_I (interrupt disablement mask). I added a PSL word to the PCB structure to take care of the problem. Without this if you have a thread switch away while holding interrupts hard-disabled, the next thread will inherit the hard disablement. I saw the sti's you added in various places but I figured the best solution was to simply save/restore the state. The original code didn't have this problem because interrupts were always hard-disabled while holding the sched_lock and, of course, cpu_switch() is always called while holding sched_lock. (Similarly, icu_lock needed hard-disablements wrapped around it for the same reason, because a level interrupt still needs to be able to get icu_lock in order to defer itself). In anycase, I have successfully built the world in a -current SMP + apic_vector system. Tomorrow I will cleanup on the UP icu_vector code to match the apic_vector code and post the results. I also have a sysctl that allows developers to toggle the mode for testing purposes (old way or new way). Finally, I took your suggestion in regards to not trying to combine the masks together. I have a 'some sort of interrupt is pending' variable then I have fpending (for fast interrupts), ipending (for normal interrupt threads), and spending (which I use for the stat and hardclock forwarding). They're all per-cpu entities, of course. unpend() prioritizes them. In anycase, I'll post it all tomorrow after I've got icu_vector cleaned up. One of the best things about this patch set is that it is really flexible. We should be able to really make interrupts fly. In fact, it should even be possible for one cpu to steal another cpu's pending interrupt(s) fairly trivially, without having to resort to IPIs. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Success! critical_enter()/critical_exit() revamp (was Re:malloc_bucket() idea (was Re: How to fix malloc.))
On Sun, 24 Feb 2002, Matthew Dillon wrote: Bruce, your sys.dif was *invaluable*! It would have taken me a lot longer to figure out the interrupt disablement requirement around the icu_lock, and the statclock and hardclock forwarding issues (which I got working by the way!). Thanks. It turns out that putting the pending masks in the per-cpu area was the right solution! It made statclock and hardclock forwarding easy (I can see why you didn't even try in your patch set, doing it with a global mask would be nearly impossible). In fact, it made everything unbelievably easy. ... [This paragraph reordered] up. One of the best things about this patch set is that it is really flexible. We should be able to really make interrupts fly. In fact, it should even be possible for one cpu to steal another cpu's pending interrupt(s) fairly trivially, without having to resort to IPIs. Good idea. Stealing would be even easier if the mask were global :-). The second issue is that cpu_switch() does not save/restore the PSL_I (interrupt disablement mask). I added a PSL word to the PCB structure to take care of the problem. Without this if you have a thread switch away while holding interrupts hard-disabled, the next thread will inherit the hard disablement. I saw the sti's you added in various places but I figured the best solution was to simply save/restore the state. The original code didn't have cpu_switch() certainly needs to do this if it can be called with the interrupt enable flag[s] in different states. I need the sti's (actually enable_intr()'s because I don't want fast interrupts to be disabled during context switches. This works because enabling interrupts is sure to be safe, since we might be switching to a thread that will enable them. Some sort of lock is needed to prevent interrupts interfering with the switch. I think soft-masking them in critical_enter() is sufficient in your version too. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Success! critical_enter()/critical_exit() revamp (was Re:malloc_bucket() idea (was Re: How to fix malloc.))
: up. One of the best things about this patch set is that it is really
: flexible. We should be able to really make interrupts fly. In fact,
: it should even be possible for one cpu to steal another cpu's pending
: interrupt(s) fairly trivially, without having to resort to IPIs.
:
:Good idea. Stealing would be even easier if the mask were global :-).
Well, for the moment I am attempting to avoid having to use lock;'d
bus cycles to keep things efficient. When we get to the stealing part
we might wind up using lock;, but I'll deal with that when the time
comes.
: The second issue is that cpu_switch() does not save/restore the
: PSL_I (interrupt disablement mask). I added a PSL word to the PCB
: structure to take care of the problem. Without this if you have
: a thread switch away while holding interrupts hard-disabled, the
: next thread will inherit the hard disablement. I saw the sti's
: you added in various places but I figured the best solution was
: to simply save/restore the state. The original code didn't have
:
:cpu_switch() certainly needs to do this if it can be called with the
:interrupt enable flag[s] in different states. I need the sti's (actually
:enable_intr()'s because I don't want fast interrupts to be disabled
:during context switches. This works because enabling interrupts is sure
:to be safe, since we might be switching to a thread that will enable
:them. Some sort of lock is needed to prevent interrupts interfering
:with the switch. I think soft-masking them in critical_enter() is
:sufficient in your version too.
:
:Bruce
I don't think we want to make sched_lock any more complex then it
already is, so at least for the foreseeable future we are not
going to be able to actually execute an interrupt handler until
the sched_lock is released in (typically) msleep(). I am rather
annoyed that two levels of procedure have to be called with the
sched_lock held (mi_switch() and cpu_switch()), leaving interrupts
disabled for a fairly long period of time, but I don't see any way
around it right now.
Eventually (presumably) we will have per-cpu run queues. That combined
with interrupt stealing may resolve the problem for us. I am still
not convinced that making the various *pending* flags globals will
be more efficient, because it introduces significant cache mastership
issues. It might be easier to do this:
interrupt_vector
{
if (td-td_critnest) {
... try to forward the interrupt to another cpu that is not
in a critical section ...
... else set bit in local ipending mask.
} else {
... take or schedule interrupt ...
}
}
Or possibly:
interrupt_vector
{
if (td-td_critnest) {
if (!mtx_owned(sched_lock) mtx_trylock(sched_lock)) {
... we can still schedule the interrupt even
though we are in a critical section, we
just can't switch to it yet ...
} else {
... try to forward the interrupt to a cpu that is not
in a critical section ...
... else set bit in local ipending mask.
}
} else {
... take or schedule interrupt ...
}
}
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Success! critical_enter()/critical_exit() revamp (was Re:malloc_bucket() idea (was Re: How to fix malloc.))
On Sun, 24 Feb 2002, Matthew Dillon wrote: :cpu_switch() certainly needs to do this if it can be called with the :interrupt enable flag[s] in different states. I need the sti's (actually :enable_intr()'s because I don't want fast interrupts to be disabled :during context switches. This works because enabling interrupts is sure :to be safe, since we might be switching to a thread that will enable :them. Some sort of lock is needed to prevent interrupts interfering :with the switch. I think soft-masking them in critical_enter() is :sufficient in your version too. I don't think we want to make sched_lock any more complex then it already is, so at least for the foreseeable future we are not going to be able to actually execute an interrupt handler until the sched_lock is released in (typically) msleep(). I am rather Well, my kernel has been executing fast interrupt handlers while sched_lock is held for almost a year. It's actually less complicated with respect to sched_lock but more complicated with respect to fast interrupt handlers. annoyed that two levels of procedure have to be called with the sched_lock held (mi_switch() and cpu_switch()), leaving interrupts disabled for a fairly long period of time, but I don't see any way around it right now. The worst offenders for interrupt latency seemed to be calcru() and/or the sched_locking related to fork and/or exit. Latency was many thousand instructions (reasonable only on 100+ MIPS machines). sched_locking for calcru() is moostly bogus and should be easy to avoid, but not so for context switching. Eventually (presumably) we will have per-cpu run queues. That combined with interrupt stealing may resolve the problem for us. I am still not convinced that making the various *pending* flags globals will be more efficient, because it introduces significant cache mastership issues. It might be easier to do this: OK. I don't care about this yet. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
:Bruce's patch amounts to a retry if the current timecounter was updated
:while we were calculating time. It is a bit more defensive than it
:needs to be and generally pessimizes the timecounters elegant lockless
:design a fair bit, but it is still much better than slamming a mutex
:around the entire clock code.
:
:If this patch cures the PIIX problem, something I'm not at all convinced
:about, it should go in, if not only the comment should go in.
:
:Poul-Henning
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
Ok, I've tested Bruce's patch and it appeaars to mostly solve the problem.
I no longer get 'microuptime ... backwards' errors on a -current SMP
box.
However, I think to be complete we need to make it even less elegant.
The TC module is only flip-flopping between two time counters, which
means that it can flip-flop twice and the test will not work. We need
a generation count on the timecounter as well:
do {
tc = timecounter;
gen = tc-tc_generation;
*bt = tc-tc_offset;
bintime_addx(bt, tc-tc_scale * tco_delta(tc));
} while (tc != timecounter || tc-tc_generation != gen);
There is also an issue on non-i386 machines. The timecounter swapping
code requires a memory synchronization point after updating the
contents of the new timecounter but before setting the 'timecounter' global
to the new timecounter. If this is not done, non-i386 machines running
SMP may see the new timecounter structure but access pre-updated values
from it.
(i386 boxes do not have this problem because writes are ordered so the
inherent synchronication point at the end of the timer interrupt is
enough).
Is there a memory synchronization point macro available?
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went backwards (775.159625 - 775.159612)
I also think this retry loop has to be done everywhere where the
timecounter structure is accessed directly.
-Matt
:Ok, I've tested Bruce's patch and it appeaars to mostly solve the problem.
:I no longer get 'microuptime ... backwards' errors on a -current SMP
:box.
:...
Index: kern/kern_tc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
retrieving revision 1.113
diff -u -r1.113 kern_tc.c
--- kern/kern_tc.c 7 Feb 2002 21:21:55 - 1.113
+++ kern/kern_tc.c 17 Feb 2002 20:41:47 -
@@ -107,9 +107,11 @@
{
struct timecounter *tc;
- tc = timecounter;
- *bt = tc-tc_offset;
- bintime_addx(bt, tc-tc_scale * tco_delta(tc));
+ do {
+ tc = timecounter;
+ *bt = tc-tc_offset;
+ bintime_addx(bt, tc-tc_scale * tco_delta(tc));
+ } while (tc != timecounter);
}
void
@@ -126,8 +128,10 @@
struct timecounter *tc;
ngetmicrotime++;
- tc = timecounter;
- *tvp = tc-tc_microtime;
+ do {
+ tc = timecounter;
+ *tvp = tc-tc_microtime;
+ } while (tc != timecounter);
}
void
@@ -136,8 +140,10 @@
struct timecounter *tc;
ngetnanotime++;
- tc = timecounter;
- *tsp = tc-tc_nanotime;
+ do {
+ tc = timecounter;
+ *tsp = tc-tc_nanotime;
+ } while (tc != timecounter);
}
void
@@ -166,8 +172,10 @@
struct timecounter *tc;
ngetmicrouptime++;
- tc = timecounter;
- bintime2timeval(tc-tc_offset, tvp);
+ do {
+ tc = timecounter;
+ bintime2timeval(tc-tc_offset, tvp);
+ } while (tc != timecounter);
}
void
@@ -176,8 +184,10 @@
struct timecounter *tc;
ngetnanouptime++;
- tc = timecounter;
- bintime2timespec(tc-tc_offset, tsp);
+ do {
+ tc = timecounter;
+ bintime2timespec(tc-tc_offset, tsp);
+ } while (tc != timecounter);
}
void
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message [EMAIL PROTECTED], Matthew Dillon wri
tes:
However, I think to be complete we need to make it even less elegant.
The TC module is only flip-flopping between two time counters, which
means that it can flip-flop twice and the test will not work. We need
a generation count on the timecounter as well:
do {
tc = timecounter;
gen = tc-tc_generation;
*bt = tc-tc_offset;
bintime_addx(bt, tc-tc_scale * tco_delta(tc));
} while (tc != timecounter || tc-tc_generation != gen);
No, more like:
do {
tc = timecounter;
gen = tc-gen;
...
} while (gen != tc-gen);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...' using ACPI timer. Shouldn't that be impossible? )
In message [EMAIL PROTECTED], Matthew Dillon wri tes: Whoop! I take it back. I'm still getting the errors: microuptime() went backwards (458.168990 - 458.168882) microuptime() went backwards (578.609995 - 577.929801) microuptime() went backwards (748.912755 - 748.237402) microuptime() went backwards (775.159625 - 775.159612) I also think this retry loop has to be done everywhere where the timecounter structure is accessed directly. No, only where the timecounter hardware is read and the math done. As far as I know, this is the only place. As I said, I am far from convinced this is the solution to the problem we are looking at with the PIIX timecounter. Msmith has some magic code in sys/dev/acpi/acpi_timer.c which tries to identify if the PIIX counter is broken or OK and I notice that the mask seems to always be set to 24 bits even if the hardware is 32 bits. I am not sure I read his code right, but he seems to default to the unsafe method, can you try this copypasted patch ? Index: acpi_timer.c === RCS file: /home/ncvs/src/sys/dev/acpica/acpi_timer.c,v retrieving revision 1.11 diff -u -r1.11 acpi_timer.c --- acpi_timer.c8 Jan 2002 06:45:56 - 1.11 +++ acpi_timer.c17 Feb 2002 20:48:23 - @@ -138,7 +138,7 @@ if (getenv(debug.acpi.timer_test) != NULL) acpi_timer_test(); -acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount; +acpi_timer_timecounter.tc_get_timecount = acpi_timer_get_timecount_safe; acpi_timer_timecounter.tc_frequency = acpi_timer_frequency; tc_init(acpi_timer_timecounter); -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Success! Sorta! (was Re: 'microuptime() went backwards ...'using ACPI timer. Shouldn't that be impossible? )
On Sun, 17 Feb 2002, Matthew Dillon wrote:
Whoop! I take it back. I'm still getting the errors:
microuptime() went backwards (458.168990 - 458.168882)
microuptime() went backwards (578.609995 - 577.929801)
microuptime() went backwards (748.912755 - 748.237402)
microuptime() went backwards (775.159625 - 775.159612)
I also think this retry loop has to be done everywhere where the
timecounter structure is accessed directly.
Yes, since the reads of all the relevant timecounter variables are
non-atomic.
Index: kern/kern_tc.c
===
RCS file: /home/ncvs/src/sys/kern/kern_tc.c,v
retrieving revision 1.113
diff -u -r1.113 kern_tc.c
--- kern/kern_tc.c7 Feb 2002 21:21:55 - 1.113
+++ kern/kern_tc.c17 Feb 2002 20:41:47 -
@@ -126,8 +128,10 @@
struct timecounter *tc;
ngetmicrotime++;
- tc = timecounter;
- *tvp = tc-tc_microtime;
+ do {
+ tc = timecounter;
+ *tvp = tc-tc_microtime;
+ } while (tc != timecounter);
}
void
E.g., tc_mictrotime here is a timeval. It doesn't matter getting a stale
value (although getting a stale value increases the possible incoherency
of the get*() functions from 1/HZ to NTIMECOUNTER/HZ), but getting a
stale value that changed underneath the read would be bad.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Make World Success - Good Going
I just completed a 'make world' from sources at midnight PST. I made a static vi before starting. I had problems trying to make libc. I got lots of complaints about 'tqh_last' not being members of a structure. But, world completed OK. Must have been something on my system or something I did. Good work everyone. I have a nagging worry with SMP, but, UP seems OK, now. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Partial success with current on Laptop.
Hi, with -current as of yesterday I get partial success. My configuration: - Tecra8000 - 256MB Ram - ad0: IBM DARA 25000 @ UDMA33 - ad1: IBM DARA 26480 @ UDMA33 - kernel and modules in sync, fresh buildworld, buildkernel... - Nonstandart-options: o enabled apm, acpi, usb, pcm, pcic. o all slices are mounted with noatime and sofdep. o sysctl -w vfs.vmiodirenable=1 o sysctl -w vfs.write_behind=0 o kern.vm.kmem.size=20971520 in loader.conf What seems to work: - buildkernel; (buildworld not testet) - linuxerator (testet staroffice, Oracle 8.1.5, SAP R/3 4.5B) - X - Wine - pcmcia (ep0, aic0 - insert/delete testet) - apm (suspend/resume not testet) What doesn't - Heavy (concurrent?) disk I/O locks up the system solid. Testet with "du -sk /usr/ports" or "tar cf - . | `cd /scratch; tar xvf -`" in multiuser mode... "tar cf /dev/null /usr/ports ; tar cf - /usr/ports | tar tvf -" in singleuser mode (disks mounted -oro ) o getting (after hanging with "du -sk /usr/ports" into ddb - ps shows some processes in ffsvgt and du hanging in some FFS operation. o in singleuser mode - ddb - ps I see the 3 tar's in stat: 3, wmesg: piperd, inode, FFS node. - "panic" in ddb hangs in "syncing disks x x ...". Bye/2 -- Michael Reifenberger - IT, UNIX, R/3-Basis Work: [EMAIL PROTECTED]Proj: [EMAIL PROTECTED] Pers: [EMAIL PROTECTED] Webspace: http://www.reifenberger.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Partial success with current on Laptop.
Reifenberger Michael [EMAIL PROTECTED] écrivait (wrote) : My configuration: - Tecra8000 I run the same, with only 64Mo. - 256MB Ram - ad0: IBM DARA 25000 @ UDMA33 - ad1: IBM DARA 26480 @ UDMA33 I have only one disk, in DMA, with softupdates. I have tried some of the stress tests you mention, and ... no crashes. - apm (suspend/resume not testet) Works for me. My only problem is that Fan is NEVER turned off (it seems that idle loop in kernel as become CPU intensive and energy hardware can not stop cooling). At this time, this is a minor annoyance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
AW: Partial success with current on Laptop.
Hi, sorry, it's easilly reproducable. I built a -current kernel supped today now without apm, acpi, usb. - "boot -s" for singleuser - "mount -oro /usr" - "cd /usr/ports" - "tar cf /dev/null . " - "tar cf - . | tar tvf -" ...wait... ...freeze... ...why?... Could someone enlight me how to get some more usefull information after getting into ddb? ddb(4) and the handbook is not really specific about. Esp. how do I inspect specific processes which I see in "ps". "trace" is of no help when manually breaking into ddb. Is there something like "bt" or "up", like in gdb? Bye/2 -- Michael Reifenberger - IT, UNIX, R/3-Basis Work: [EMAIL PROTECTED]Proj: [EMAIL PROTECTED] Pers: [EMAIL PROTECTED] Webspace: http://www.reifenberger.com -Urspr üngliche Nachricht- Von: Alain Thivillon [SMTP:[EMAIL PROTECTED]] Gesendet am: Freitag, 15. September 2000 14:11 An: Reifenberger Michael Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Betreff: Re: Partial success with current on Laptop. Reifenberger Michael [EMAIL PROTECTED] écrivait (wrote) : My configuration: - Tecra8000 I run the same, with only 64Mo. - 256MB Ram - ad0: IBM DARA 25000 @ UDMA33 - ad1: IBM DARA 26480 @ UDMA33 I have only one disk, in DMA, with softupdates. I have tried some of the stress tests you mention, and ... no crashes. - apm (suspend/resume not testet) Works for me. My only problem is that Fan is NEVER turned off (it seems that idle loop in kernel as become CPU intensive and energy hardware can not stop cooling). At this time, this is a minor annoyance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Partial success with current on Laptop.
- apm (suspend/resume not testet) Works for me. My only problem is that Fan is NEVER turned off (it seems that idle loop in kernel as become CPU intensive and energy hardware can not stop cooling). At this time, this is a minor annoyance. Do you have acpi enabled in your kernel? If so, it could be. Thermal and processor power management portion of acpi is not implemented yet. All of the power resource components such as fan are just turned on at booting for now :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Partial success with current on Laptop.
Mitsuru IWASAKI [EMAIL PROTECTED] écrivait (wrote) : Do you have acpi enabled in your kernel? no. I have tried ACPI some days ago, but system boot becomes incredibly slow (for example, syslogd complained about something like 'child process timeout' after enabling ACPI). All system activity such as fork and so was affected. and processor power management portion of acpi is not implemented yet. All of the power resource components such as fan are just turned on at booting for now :-) Other problem with -CURRENT and laptops is that system time is not reinitialised after suspend and resume :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Partial success with current on Laptop.
Do you have acpi enabled in your kernel? no. I have tried ACPI some days ago, but system boot becomes incredibly slow (for example, syslogd complained about something like 'child process timeout' after enabling ACPI). All system activity such as fork and so was affected. It seems the same with my TOSHIBA POTEGE 3110CT because of lack of processor power management implementation I think. My short term solution is acpiconf -d to make CPU running in normal speed. and processor power management portion of acpi is not implemented yet. All of the power resource components such as fan are just turned on at booting for now :-) Other problem with -CURRENT and laptops is that system time is not reinitialised after suspend and resume :) Ah, you probably need to have a `device pmtimer' in your kernel config and `hint.pmtimer.0.at="isa"' in your devce.hints. If you don't like to reinitialize system time (e.g. prefer running ntpdate), you don't need to have pmtimer. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Partial success with current on Laptop.
Alain Thivillon [EMAIL PROTECTED] écrivait (wrote) : Other problem with -CURRENT and laptops is that system time is not reinitialised after suspend and resume :) Oups, this one is fixed by adding new 'pmtimer' device in my kernel. Maybe an entry in UPDATING will help. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Success with ESP over IPV4 ?
Did someone manage to get a ESP tunnel over IPV4 working ? I try to use the following setkey commands, which constantly fail with the following message : "Must get list of supported protocols first." My problem is how to get this list of supported protocols ? this config file is inspired from samples in /usr/src/usr.sbin/setkey ... i'm just experimenting, have a very limited knowledge about IPV6, and the samples shipped with CURRENT's sources do not work out of the box :-( all this stuff is done in order to test IPV6/pipsecd interoperability. Thanks in advance ! --- snip -- snip --- flush; add AAA.AAA.AAA.AAA BBB.BBB.BBB.BBB esp 1001 -m any -f zero-pad -E blowfish-cbc "AAA key" ; add BBB.BBB.BBB.BBB AAA.AAA.AAA.AAA esp 1001 -m any -f zero-pad -E blowfish_cbc "BBB key"; spdflush; spdadd AAA.AAA.AAA.AAA/32[any] BBB.BBB.BBB.BBB/32[any] any -P in ipsec esp/transport//use; spdadd BBB.BBB.BBB.BBB/32[any] AAA.AAA.AAA.AAA/32[any] any -P out ipsec esp/transport//use; -- UNIX *IS* user friendly. It's just selective about who its friends are. --unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrade 3.4 - 5.0 -current Success
On Tue 2000-04-04 (21:14), Thomas D. Dean wrote: I installed the 3.4 normal user, bin and docs on the new disk. I copied /etc, /usr/src and /usr/ports from the old -current disk. I did a make world to upgrade to -current. 'make world' had two problems. The buildworld phase completed successfully. There were two problems in the install phase. 1. install-info. The 3.4 version of install-info does not support the newest version of the flags, it wants -section, not -dsection. I copied the version in /usr/obj/usr/src/i386/usr/bin to /usr/bin and this problem was solved. Can 'make install' use /usr/obj/usr/src/i386/usr/bin/install-info? This is a known problem, and unfortunately my solution to it broke cross-compilation. Someone more intelligent may just fix it soon. 2. sh is installed and then is used in later in the installation process. The number of syscalls changed, so the new version of sh core dumps. I copied a 5.0-current kernel from another disk, rebooted, and install completed without error. Can make copy or link the existing version of sh to tools and use that during the install? I think you're supposed to reboot with a new kernel (built with 'make buildkernel make installkernel') and then installworld. This is the new 'one true way'. It's not supposed to work over more than one major version, so I doubt 3.4 - 5.0 will work for much longer. Good work on the make/install process. Cool. Marcel and others deserve a massive round of applause. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Upgrade 3.4 - 5.0 -current Success
I just upgraded a 3.4 system from the Jan. 2000 CD to 5.0 -current. I used the 3.4 CD as an installation vehicle to get -current on a new disk, cleaning the tree in the process. I removed about 100MB that had accumulated over three years tracking -current. I had an existing -current system, and was installing a larger disk. I installed the 3.4 normal user, bin and docs on the new disk. I copied /etc, /usr/src and /usr/ports from the old -current disk. I did a make world to upgrade to -current. 'make world' had two problems. The buildworld phase completed successfully. There were two problems in the install phase. 1. install-info. The 3.4 version of install-info does not support the newest version of the flags, it wants -section, not -dsection. I copied the version in /usr/obj/usr/src/i386/usr/bin to /usr/bin and this problem was solved. Can 'make install' use /usr/obj/usr/src/i386/usr/bin/install-info? 2. sh is installed and then is used in later in the installation process. The number of syscalls changed, so the new version of sh core dumps. I copied a 5.0-current kernel from another disk, rebooted, and install completed without error. Can make copy or link the existing version of sh to tools and use that during the install? Good work on the make/install process. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
BP6 (Was Re: Success with ATA drivers and UDMA66)
"Dave J. Boers" wrote: On Tue, Dec 21, 1999 at 11:22:12PM +0100, Thierry Herbelot wrote: Let's start a thread on the BP6 ? (the release of the board was carefully synchronized with stable SMP releases of FreeBSD : kudos to the FreeBSD release engineering team ;-)) I second that! Running -current since October and never had a serious SMP problem. I was not really serious, but the nearly simultaneous release of a "stable" SMP FreeBSD and a very inexpensive Dual MoBo was a very pleasant surprise. [SNIP] I think the PS is pressed to its limits because if I add just one more drive (5400 RPM IDE disk) it's over the edge. Those Celeron's must be eating lot's of power (they are 400 Mhz ones running at 75 Mhz bus speed). Is it possible to directly boot from the HPT-366 controller ? (I know the BIOS is ok, but is there any problem with the new ata driver ?) I'm doing it currently. Very fine [SNIP] I would like to know how HOT other people's processors get. In the stationary situation I have a system core (= processor average) temperature of 46 and a case temperature of 50 degrees Celcius/Centigrade. What do you use for temp. watching ? (I fetched a little hack which is called wmtempmon). My temps are somewhat lower : around 35/36 °C, as I've installed "Alpha" coolers, bought from www.3dfx.com. One colleague at work uses the same sink/fan combo, but with peltier and a monstrous PSU to get to 572MHz. I've also loaded the latest BIOS from Abit. TfH Don't ask why case temperature is higher than core temperature! I don't get it either. The hard drives are not even above 30 degrees. Maybe it's the graphics board (viper 550 agp): it's doing 1600x1200@85Hz. I once clocked the system at 500 Mhz (83 Mhz bus), which runs fine but then things get way too hot. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: BP6 (Was Re: Success with ATA drivers and UDMA66)
I know your talking SMP but thought you'd like to know some temps for UP systems as well... I have a Celeron 300a that I overclock to 464 MHz (100 MHz FSB + extra turbo frequency boost) running at 2.1 v and it runs at about 30 degrees celcius when idle and at 52 degrees when running setiathome (was 50 degrees in winter). A friend of mine running an ISP on FreeBSD has alarms set at 53 degrees (and they haven't gone off unless there has been a problem to date). A friend of above friend (in Sydney) has all his machines running quite reliably at 96 degrees (yes celcius). His alarms dont go off until 104! I dont think he has any airconditioning in his machine room. I cant speak for what the other peoples hardware is but it appears that the Intel CPUs can take quite a beating I wouldn't be worried until you hit at least 65 degrees. On Wed, 22 Dec 1999, Thierry Herbelot wrote: "Dave J. Boers" wrote: On Tue, Dec 21, 1999 at 11:22:12PM +0100, Thierry Herbelot wrote: Let's start a thread on the BP6 ? (the release of the board was carefully synchronized with stable SMP releases of FreeBSD : kudos to the FreeBSD release engineering team ;-)) I second that! Running -current since October and never had a serious SMP problem. I was not really serious, but the nearly simultaneous release of a "stable" SMP FreeBSD and a very inexpensive Dual MoBo was a very pleasant surprise. [SNIP] I think the PS is pressed to its limits because if I add just one more drive (5400 RPM IDE disk) it's over the edge. Those Celeron's must be eating lot's of power (they are 400 Mhz ones running at 75 Mhz bus speed). Is it possible to directly boot from the HPT-366 controller ? (I know the BIOS is ok, but is there any problem with the new ata driver ?) I'm doing it currently. Very fine [SNIP] I would like to know how HOT other people's processors get. In the stationary situation I have a system core (= processor average) temperature of 46 and a case temperature of 50 degrees Celcius/Centigrade. What do you use for temp. watching ? (I fetched a little hack which is called wmtempmon). My temps are somewhat lower : around 35/36 °C, as I've installed "Alpha" coolers, bought from www.3dfx.com. One colleague at work uses the same sink/fan combo, but with peltier and a monstrous PSU to get to 572MHz. I've also loaded the latest BIOS from Abit. TfH Don't ask why case temperature is higher than core temperature! I don't get it either. The hard drives are not even above 30 degrees. Maybe it's the graphics board (viper 550 agp): it's doing 1600x1200@85Hz. I once clocked the system at 500 Mhz (83 Mhz bus), which runs fine but then things get way too hot. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- /===\ | Work: [EMAIL PROTECTED] | Home: [EMAIL PROTECTED] | \===/ "If it is true that our Universe has a zero net value for all conserved quantities, then it may simply be a fluctuation of the vacuum of some larger space in which our Universe is imbedded. In answer to the question of why it happened, I offer the modest proposal that our Universe is simply one of those things which happen from time to time." E. P. Tryon from "Nature" Vol.246 Dec.14, 1973 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
[snip] What is the rating of your Power supply ? Not quite high enough :-( It's a 300 Watt power supply. Hehe - I'm running dual 540's (2.2V) on a BP6 (I'm guessing around 30 Watts per CPU), extra case fan, big CPU fans, CD, TNT and an IDE drive (I've had three hooked up once) - on a 235W power supply :) (Although it is probably a better-than-average PS, it's the one that comes with the AOpen HX45 case). One of these days I'm going to hook up a multimeter and see what it draws... Tom Embt [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
On Tue, Dec 21, 1999 at 11:22:12PM +0100, Thierry Herbelot wrote: Let's start a thread on the BP6 ? (the release of the board was carefully synchronized with stable SMP releases of FreeBSD : kudos to the FreeBSD release engineering team ;-)) I second that! Running -current since October and never had a serious SMP problem. I've also got one of these babies (dual 460 @ 2.1V) and I'm wondering if I should buy a new PSU (300W, instead of the present 250W) - the reliability is not yet up to par with my ancient (??) P-II (I've got a crash after a row of "make buildworld"s). Hmm, I only had one nasty kernel panic once during installworld, but I don't think that was hardware related. I must have done at least 50 buildworld's or so since beginning of October; no crashes. My main system is running dual 450 Mhz. Like I said earlier in the thread, it's running on a 300 Watt PS with a couple of extra fans to cool the hard drives, two 7200 RPM disks, 2 network i/f's, scsi, CD reader and writer, tape unit and zipdrive. I think the PS is pressed to its limits because if I add just one more drive (5400 RPM IDE disk) it's over the edge. Those Celeron's must be eating lot's of power (they are 400 Mhz ones running at 75 Mhz bus speed). Is it possible to directly boot from the HPT-366 controller ? (I know the BIOS is ok, but is there any problem with the new ata driver ?) I'm doing it currently. The HPT-366 controller is a completely separate device. On my bootup, the system doesn't detect any "normal" ide devices (you can't autotype them in the bios either), then the screen goes blank and the HPT comes up with its disk detection. Next is the Adaptec detection and the boot proceeds. In the BIOS you can choose EXT=[ATA,SCSI] and I have the boot sequence set to EXT,C,A. EXT=ATA. The ATA driver nicely autodetects (from dmesg): ata-pci1: HighPoint HPT366 ATA controller irq 18 at device 19.0 on pci0 ata-pci1: Busmastering DMA supported ata2 at 0xb000 irq 11 on ata-pci1 ata-pci2: HighPoint HPT366 ATA controller irq 18 at device 19.1 on pci0 ata-pci2: Busmastering DMA supported ad0: WDC AC418000D/J78OA30K ATA-4 disk at ata2 as master ad0: 17206MB (35239680 sectors), 34960 cyls, 16 heads, 63 S/T, 512 B/S ad0: 16 secs/int, 32 depth queue, UDMA66 I would like to know how HOT other people's processors get. In the stationary situation I have a system core (= processor average) temperature of 46 and a case temperature of 50 degrees Celcius/Centigrade. Don't ask why case temperature is higher than core temperature! I don't get it either. The hard drives are not even above 30 degrees. Maybe it's the graphics board (viper 550 agp): it's doing 1600x1200@85Hz. I once clocked the system at 500 Mhz (83 Mhz bus), which runs fine but then things get way too hot. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
On Sat, Dec 18, 1999 at 07:27:16AM +0100, Thierry Herbelot wrote: Do you boot from the UDMA66 drive ? Yes. Bios boot sequence is EXT,C,A; where EXT is set to UDMA66, not SCSI. The SCSI disk is a 4.3 Gb WD Enterprise on an Adaptec 2940AU board. What is your BIOS revision ? Award Bios v. 4.51PG Revision line (bottom of screen) sais: 06/08/1999-i440BX-W83977-2A69KA1SC-LP Highpoint Bios: HPT 366 v. 1.07 How many SDRAM DIMMs do you use ? Currently there is one 128 Mb DIMM in the first slot. In a few weeks I will add a 256 Mb DIMM in the second slot, if I can get my hands on one (memory prices are going down again). What is the rating of your Power supply ? Not quite high enough :-( It's a 300 Watt power supply. Do you use an AGP graphics board ? Yes. It's a diamond Viper 550 with 8 Mb RAM. (I also have a BP6 and I'm mildly satisfied by its stability up to now, I'm looking for ways to upgrade it and hints to increase the reliability) I haven't got any complaints about the BP6, actually. It runs quite nicely here. Exactly what are your complaints about it (i.e. why do you say "mildly" instead of "wildly")? Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Success with ATA drivers and UDMA66
Hi all, I just wanted to let you know that I enabled UDMA66 (by plugging in an 80 conductor cable) on my WDC AC418000D today. The mainboard is an ABit BP6 with builtin Highpoint HPT366 ATA controller. The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). If someone wants me to do some specific testing, let me know. Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Success with ATA drivers and UDMA66
On 18-Dec-99 Dave J. Boers wrote: The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). /proc too? (although technically, /proc isn't a filesystem. ;-) -- Will Andrews [EMAIL PROTECTED] GCS/E/S @d- s+:++:- a---+++ C++ UB P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP t++ 5 X++ R+ tv+ b++ DI+++ D+ G+ e- h! r--+++ y? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Success with ATA drivers and UDMA66
"Dave J. Boers" wrote: Hi all, I just wanted to let you know that I enabled UDMA66 (by plugging in an 80 conductor cable) on my WDC AC418000D today. The mainboard is an ABit BP6 with builtin Highpoint HPT366 ATA controller. The system works very nicely. I did some heavy testing in single user mode by moving several 300 Mb files around between the IDE disk and my other SCSI disk (which got me a sustained transfer rate of over 10 Mb/sec). Then I made world. Everything works great (softupdates enabled on all filesystems except "/"). If someone wants me to do some specific testing, let me know. Do you boot from the UDMA66 drive ? What is your BIOS revision ? How many SDARM DIMMs do you use ? What is the rating of your Power supply ? Do you use an AGP graphics board ? (I also have a BP6 and I'm mildly satisfied by its stability up to now, I'm looking for ways to upgrade it and hints to increase the reliability) TfH Regards, Dave Boers. -- God, root, what's the difference? [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Jail - any success?
Poul-Henning Kamp wrote (1999/05/03): You need to put ip aliases on your loopback interface, forinstance: ifconfig lo0 10.0.0.1 netmask 255.255.255.255 alias ... ifconfig lo0 10.0.0.5 netmask 255.255.255.255 alias Then you give each jail one of these ipnumbers and start whatever daemons you want in the jail (inetd, sshd, apache...) Of course your routing needs to work such that these ip numbers end up on your machine, you can also do this by adding multiple IP# to the ethernet of the machine. Thanks. Now I know where was the problem - if I create ip alias ifconfig lo0 A.B.C.D netmask 255.255.255.255 alias I must write jail command as jail /path domain.name D.C.B.A /command so on my PC ip-address isn't converted to a network format. Here are my suggestions: *) Aplly this patch to jail.c: (Or bug is in system call? What format should be there?) --- jail.c.orig Tue May 4 14:00:36 1999 +++ jail.c Tue May 4 14:00:47 1999 @@ -21,7 +21,7 @@ i = inet_aton(argv[3], in); if (!i) errx(1, Couldn't make sense if ip number\n); - j.ip_number = in.s_addr; + j.ip_number = htonl(in.s_addr); i = jail(j); if (i) err(1, Imprisonment failed); *) There should be $Id in all Makefile, jail.8, and jail.c I think. *) In jail(8) there is synopsis jail path hostname ip-number. It should be jail path hostname ip command ... as is usage of jail command. (I you want I can fill PRs :-) Is it possible to call ping in prison session? # ping some.host ping: socket: Operation not permitted --=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= Rudolf Cejka (cej...@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Jail - any success?
In message 1999050417.a25...@kazi.dcse.fee.vutbr.cz, Rudolf Cejka writes: Is it possible to call ping in prison session? # ping some.host ping: socket: Operation not permitted I have not bothered with it yet, I would have to peek into the ICMP packets to make sure they were OK. Much time, little payback. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Jail - any success?
I'm trying to test the new jail feature. It looks it works. But I can't find, how to setup the network communication. Is there anybody who successfully took a run of jail virtual serverrs with networking? Thanks for any suggestions. --=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= Rudolf Cejka (cej...@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) Brno University of Technology, Faculty of El. Engineering and Comp. Science Bozetechova 2, 612 66 Brno, Czech Republic To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Jail - any success?
In message 199905031339.paa20...@kazi.dcse.fee.vutbr.cz, Rudolf Cejka writes: I'm trying to test the new jail feature. It looks it works. But I can't find, how to setup the network communication. Is there anybody who successfully took a run of jail virtual serverrs with networking? You need to put ip aliases on your loopback interface, forinstance: ifconfig lo0 10.0.0.1 netmask 255.255.255.255 alias ifconfig lo0 10.0.0.2 netmask 255.255.255.255 alias ifconfig lo0 10.0.0.3 netmask 255.255.255.255 alias ifconfig lo0 10.0.0.4 netmask 255.255.255.255 alias ifconfig lo0 10.0.0.5 netmask 255.255.255.255 alias Then you give each jail one of these ipnumbers and start whatever daemons you want in the jail (inetd, sshd, apache...) Of course your routing needs to work such that these ip numbers end up on your machine, you can also do this by adding multiple IP# to the ethernet of the machine. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org Real hackers run -current on their laptop. FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new-bus Success
I am running 4.0-current SMP, cvsup today and built an hour ago. Everything seems OK. Great work. tomdean To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new-bus, a moderate success report.
To also follow the 'new-bus' success report story... I configured and built for a AMI mother board- two PCI busses... the only thing that was a gotcha was that de0 and de1 (both on separate PCI busses) got swapped in the changeover. -matt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
new-bus, a success report.
Since everybody's slagging new-bus right now, I thought I'd just jump in and say that as of 10 minutes ago, having made the world and a new kernel, everything's working great. NOTE: Look at GENERIC! Things have changed and you will likely need to update your old config file before everything is peachy again. I had to update my PS/2 rodent and keyboard entries, as well as the parallel port bus stuff, and it's now working wonderfully on my dual PII/450 with a fairly non-trivial set of peripherals plugged into it, including on-board PnP sound and a Hauppage bt848 card for video. My dmesg output, JFYI: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sun Apr 18 08:30:14 PDT 1999 j...@zippy.cdrom.com:/usr/src/sys/compile/ZIPPY Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Xeon/Celeron (686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping=2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134217728 (131072K bytes) avail memory = 127864832 (124868K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc02a5000. Pentium Pro MTRR support enabled, default memory type is uncacheable npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Host to PCI bridge (vendor=8086 device=71a0) at device 0.0 on pci0 pcib1: PCI to PCI bridge (vendor=8086 device=71a1) at device 1.0 on pci0 pci1: PCI bus on pcib1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 devclass_alloc_unit: npx0 already exists, using next available unit number isa0: ISA bus on isab0 ide_pci0: Intel PIIX4 Bus-master IDE controller at device 7.1 on pci0 chip1: Intel 82371AB Power management controller at device 7.3 on pci0 pcib2: PCI to PCI bridge (vendor=1011 device=0024) at device 16.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel EtherExpress Pro 10/100B Ethernet at device 17.0 on pci0 fxp0: interrupting at irq 19 fxp0: Ethernet address 00:e0:81:10:20:9e ahc0: Adaptec aic7895 Ultra SCSI adapter at device 18.0 on pci0 ahc0: interrupting at irq 16 ahc0: aic7895 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: Adaptec aic7895 Ultra SCSI adapter at device 18.1 on pci0 ahc1: interrupting at irq 16 ahc1: aic7895 Wide Channel B, SCSI Id=7, 16/255 SCBs bktr0: BrookTree 848a at device 20.0 on pci0 bti2c0: bt848 Hard/Soft I2C controller iicbb0: I2C generic bit-banging driver on bti2c0 iicbus0: Philips I2C bus on iicbb0 master-only smbus0: System Management Bus on bti2c0 smb0: SMBus general purpose I/O on smbus0 bktr0: interrupting at irq 17 Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner. fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive at fdc0 drive 0 wdc0 at port 0x1f0-0x1f7 irq 14 on isa0 wdc0: unit 0 (wd0): WDC AC36400L wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S wdc0: interrupting at irq 14 wdc1 at port 0x170-0x177 irq 15 on isa0 wdc1: unit 0 (atapi): CREATIVEDVD-ROM DVD5240E/1.01, removable, accel, dma, iordis wcd0: drive speed 5500KB/sec, 512KB cache wcd0: supported read types: CD-R, CD-RW, CD-DA, packet track wcd0: Audio: play, 255 volume levels wcd0: Mechanism: ejectable tray wcd0: Medium: no/blank disc inside, unlocked wdc1: interrupting at irq 15 atkbdc0: keyboard controller (i8042) at port 0x60 on isa0 atkbd0: AT Keyboard on atkbdc0 atkbd0: interrupting at irq 1 psm0: PS/2 Mouse on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 psm0: interrupting at irq 12 vga0: Generic ISA VGA on isa0 sc0: System console on isa0 sc0: VGA color 16 virtual consoles, flags=0x0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: interrupting at irq 4 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at irq 3 ppc0 at port 0x378 irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppi0: generic parallel i/o on ppbus 0 ppc0: interrupting at irq 7 pcm0 at port 0x220 irq 5 drq 1 flags 0x13 on isa0 pcm0: interrupting at irq 5 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39102LW 0005 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
Re: new-bus, a success report.
Jordan K. Hubbard wrote: Since everybody's slagging new-bus right now, I thought I'd just jump in and say that as of 10 minutes ago, having made the world and a new kernel, everything's working great. NOTE: Look at GENERIC! Things have changed and you will likely need to update your old config file before everything is peachy again. I had to update my PS/2 rodent and keyboard entries, as well as the parallel port bus stuff, and it's now working wonderfully on my dual PII/450 with a fairly non-trivial set of peripherals plugged into it, including on-board PnP sound and a Hauppage bt848 card for video. My PPro/SMP (Remember that board, Jordan?) is also running it with nary a glitch. Here's my DMESG: Copyright (c) 1992-1999 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #0: Sat Apr 17 13:17:31 SAST 1999 r...@greenpeace.grondar.za:/usr/src/sys/compile/GA586DX Timecounter i8254 frequency 1193182 Hz CPU: Pentium Pro (686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping=9 Features=0xfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV real memory = 67108864 (65536K bytes) avail memory = 62566400 (61100K bytes) Programming 24 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfec08000 cpu1 (AP): apic id: 12, version: 0x00040011, at 0xfec08000 io0 (APIC): apic id: 13, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc0284000. Pentium Pro MTRR support enabled, default memory type is uncacheable Probing for PnP devices: CSN 1 Vendor ID: CSC0b36 [0x360b630e] Serial 0x Comp ID: @@@ [0x] mss_attach CS42361 at 0x530 irq 5 dma 1:0 flags 0x10 pcm1 (CS423x/Yamaha/AD1816 CS4236 sn 0x) at 0x530-0x537 irq 5 drq 1 flags 0x10 on isa npx0: math processor on motherboard npx0: INT 16 interface pcib0: PCI host bus adapter on motherboard pci0: PCI bus on pcib0 chip0: Intel 82440FX (Natoma) PCI and memory controller at device 0.0 on pci0 fxp0: Intel EtherExpress Pro 10/100B Ethernet at device 6.0 on pci0 fxp0: interrupting at irq 18 fxp0: Ethernet address 00:a0:c9:49:c1:95 isab0: Intel 82371SB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 ahc0: Adaptec aic7880 Ultra SCSI adapter at device 9.0 on pci0 ahc0: interrupting at irq 17 ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs fdc0: interrupting at irq 6 fdc0: NEC 72065B or clone at port 0x3f0-0x3f7 irq 6 drq 2 on isa0 atkbdc0: keyboard controller (i8042) at port 0x60 on isa0 atkbd0: AT Keyboard on atkbdc0 atkbd0: interrupting at irq 1 psm0: PS/2 Mouse on atkbdc0 psm0: model MouseMan+, device ID 0 psm0: interrupting at irq 12 vga0: Generic ISA VGA on isa0 sc0: System console on isa0 sc0: VGA color 16 virtual consoles, flags=0x0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio0: interrupting at irq 4 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio1: interrupting at irq 3 ppc0 at port 0x378 irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port ppc0: interrupting at irq 7 APIC_IO: routing 8254 via 8259 on pin 0 Waiting 4 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ahc0 bus 0 target 0 lun 0 da0: IBM OEM DCHS04U 5353 Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 4340MB (543 512 byte sectors: 255H 63S/T 553C) ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus, a success report.
On Sun, 18 Apr 1999, Jordan K. Hubbard wrote: Since everybody's slagging new-bus right now, I thought I'd just jump in and say that as of 10 minutes ago, having made the world and a new kernel, everything's working great. NOTE: Look at GENERIC! Things have changed and you will likely need to update your old config file before everything is peachy again. I had to update my PS/2 rodent and keyboard entries, as well as the parallel port bus stuff, and it's now working wonderfully on my dual PII/450 with a fairly non-trivial set of peripherals plugged into it, including on-board PnP sound and a Hauppage bt848 card for video. Heck, Jordan, you weren't first. I can't understand why Alex is all upset, most especially about the sound breakage (which I don't see, my sound works fine). The sound stuff is one of the things that's likely to be helped by the fact of our bus technology on the road to becoming closer to NetBSD/OpenBSD bus technology, so we can share code. It's not done, but that's the path, and Alex would be one of those helped by it. I don't see any breakage at all, myself, but even if there is (and I know, there must be some) then it sure seems worth it. This new-bus stuff is absolutely great, and I hope Doug, Peter, and everyone else involved doesn't hear the criticism only. You guys are doing fine work. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: new-bus, a success report.
On Sun, Apr 18, 1999 at 05:20:44PM -0400, Chuck Robey wrote: This new-bus stuff is absolutely great, and I hope Doug, Peter, and everyone else involved doesn't hear the criticism only. You guys are doing fine work. Hear Hear! A painless switch here too (nothing unusual about the box). -- Adrian Wontroba To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
