Re: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huang wrote: > Hi, > > I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX 6250" bundled. > The device seems recognized as iwn0 correctly but it just doesn't work. > The command "ifconfig wlan0 up scan" return immediately and nothing showed. > > Is the device not supported, or do I miss something? > Any suggestion is welcome, thanks. > > Here is some information: > > $ uname -a > FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST > 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 > > dmesg -a: > http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt > > rc.conf: > http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf > > kldstat -v > http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt When loading acpi_ibm, I got more error information: $ kldload acpi_ibm acpi_ibm0: on acpi0 $ ifconfig wlan0 up iwn0: iwn5000_send_calibration: could not send calibration result, error 22 iwn0: iwn_init_locked: could not initialize hardware, error 22 Any suggestion? Thanks. Tz-Huan ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 15:52, Andreas Tobler wrote: > - Original Message > From: Tz-Huan Huang > To: freebsd-current@freebsd.org > Subject: Re: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work > Date: 07/09/11 09:40 > >> On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huang> wrote: >> > Hi, >> > >> > I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX > 6250" bundled. >> > The device seems recognized as iwn0 correctly but it just doesn't > work. >> > The command "ifconfig wlan0 up scan" return immediately and > nothing showed. >> > >> > Is the device not supported, or do I miss something? >> > Any suggestion is welcome, thanks. >> > >> > Here is some information: >> > >> > $ uname -a >> > FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST >> > 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 >> > >> > dmesg -a: >> > http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt >> > >> > rc.conf: >> > http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf >> > >> > kldstat -v >> > http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt >> >> When loading acpi_ibm, I got more error information: >> >> $ kldload acpi_ibm >> acpi_ibm0: on acpi0 >> $ ifconfig wlan0 up >> iwn0: iwn5000_send_calibration: could not send calibration result, error > 22 >> iwn0: iwn_init_locked: could not initialize hardware, error 22 >> >> >> Any suggestion? Thanks. > > Maybe, is the wlan switch on? (on the left side?) I recently had such an > experience with a t60 where the switch was off. Took a while until I > realized that I can switch on the wlan I have dual boot on this machine (FreeBSD and Win7) and the wlan works on Win7. I don't touch the switch so that I'm pretty sure that the switch is on. :-) Also, I have checked the dev.acpi_ibm.0.wlan and the value is 1. Thanks, Tz-Huan ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
- Original Message From: Tz-Huan Huang To: freebsd-current@freebsd.org Subject: Re: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work Date: 07/09/11 09:40 > On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huangwrote: > > Hi, > > > > I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX 6250" bundled. > > The device seems recognized as iwn0 correctly but it just doesn't work. > > The command "ifconfig wlan0 up scan" return immediately and nothing showed. > > > > Is the device not supported, or do I miss something? > > Any suggestion is welcome, thanks. > > > > Here is some information: > > > > $ uname -a > > FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST > > 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 > > > > dmesg -a: > > http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt > > > > rc.conf: > > http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf > > > > kldstat -v > > http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt > > When loading acpi_ibm, I got more error information: > > $ kldload acpi_ibm > acpi_ibm0: on acpi0 > $ ifconfig wlan0 up > iwn0: iwn5000_send_calibration: could not send calibration result, error 22 > iwn0: iwn_init_locked: could not initialize hardware, error 22 > > > Any suggestion? Thanks. Maybe, is the wlan switch on? (on the left side?) I recently had such an experience with a t60 where the switch was off. Took a while until I realized that I can switch on the wlan Gruss, Andreas ___ 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"
[ANNOUNCE] 802.11n TX aggregation support for Atheros 11n NICs
Hi all, I apologise up front for the cross-posting. Please redirect all future queries about this to freebsd-wirel...@freebsd.org. I guess the cat is out of the bag (and it hasn't killed anyone yet.) For the last 6 or so months, the if_ath driver and net80211 802.11n support has been updated to (hopefully) be usable, both in station and hostap modes. Users could use ath(4) in -HEAD as an 11n station or hostap by just disabling ampdutx. I've been doing that successfully for a few months now at home, with respectable (> 200mbit UDP, ~ 100mbit TCP) throughput in the receive direction (as AMPDU RX now works well.) Through the gracious sponsorship of Hobnob, Inc., (and the completion of my bachelors degree in something completely unrelated to all of this!) I've dived in head-first into the 802.11n TX aggregation support. As I type this, I have an EEEPC 701 w/ an AR9280 currently spitting out a 130mbit/sec TCP stream to a Ubiquiti Routerstation Pro MIPS board w/ an AR9160 (5ghz HT/40/shortgi mode.) They're both running FreeBSD. A user asked about the state of this code on the -wireless list a couple days ago and has reported that his AR5416 based NIC is happily performing much the same way. So, since it's passed my "works for someone who isn't me!" test, I've decided to make a wider announcement. There's still a -lot- to do. Specifically (this isn't an exhaustive list): * There are locking issues with ath/net80211 which need to be resolved before this is merged back into -HEAD. * There's currently no support for HT RTS/CTS frame protection. I can add it easily enough, but I first have to add the AR5416 workarounds (8k limitation on RTS protected frames) before I can do that. * The AMPDU code is currently not sending BAR frames. This requires a little more fore-thought and net80211 reorganisation before they can be queued and sent. * Don't try to do a UDP iperf test before you establish AMPDU, or you'll fill the hardware TX queue with UDP frames and then end up with no frames available to send the ADDBA management frames. Oops! :) * The rate control module (sample) supports 11n and some basic TX aggregation stuff, but it isn't optimal. It's only "good enough" for me to not have to care about rate control causing large issues. Something needs to be done before it's merged into -HEAD - either a replacement needs to be written, or minstrel_ht needs to be ported. * There's no hardware power saving support in place at the moment. This means it'll draw a lot of power in station mode. * There's no MIMO PS support. Same caveat as the above. * adhoc, ahdemo, TDMA and IBSS modes likely won't work just yet. I'm not likely to begin looking at those until all the net80211 and ath driver changes are in place and tested. * I haven't yet added "filtered frames" support, so there's going to be a lot of packet loss in hostap mode when a station decides to go into power-saving or off-channel mode (eg to do a scan). * There are still (very) occasional TX-side hangs which I'm seeing. I'm trying to get to the bottom of this. * I've not tested this -at all- on multi-CPU/multi-core setups, primarily because I don't run freebsd+wifi on anything like that just yet. * net80211 AMPDU TX is based on QoS/WME Access Category (AC) numbers, rather than the full set of available TIDs. This is likely going to need to change (and the ieee80211 superg support tested/updated) before this can be merged into -HEAD as I've been told it's quite valid to expect multiple aggregation sessions in the same AC. What does work (what have I tested): * HT/20 and HT/40 support; * 2 and 5ghz support; * station and and hostap modes; * AR5416/AR5418, AR9160, AR9280 chipsets. I haven't tested AR9285 or AR9287 yet; * HT/20 and HT/40 interoperability support - ie, a HT/40 AP can have HT/20 and HT/40 nodes associated. 11a/11bg nodes can also associate but the current lack of HT frame protection is likely to cause significant interference; * ADDBA negotiation (with the above caveat that buffer management needs to be tidied up in my codebase, or you could end up with no TX buffers..) * ath_rate_sample knows enough about 11n and aggregation to make decent enough rate choices, but it isn't optimal by any means. * Software retransmission of aggregate frames, including doing new rate lookups so frames aren't simply retried at a bad rate. What I'm currently working on: * verifying that AR5212 series NICs haven't been broken by this. If someone has AR5210/AR5211 series PCMCIA hardware that they'd be able to send to me I'll also give them a test and verify I haven't broken them; * fixing TX side hangs; * HT protection support, w/ the AR5416 workarounds as needed; * Filtered-frame support; * More debugging and better behaviour during channel scan / off channel behaviour and during an interface reset. All of that said, it's working for me and it's working for someone else, so if you're interested in trying it out, I'm happy to take bug reports and feedback. But since I'
Re: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
Hi! Hm, maybe the iwn driver doesn't have the 6250 support? Is it supposed to use 6000/6200 specific calibration (and other routines), or is it using the 5000 routines correctly? Has the card successfully loaded the firmware in? Adrian ___ 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: BETA2 panic
On Tue, Sep 6, 2011 at 22:42, Joel Dahl wrote: > On 05-09-2011 9:02, Bernhard Schmidt wrote: >> On Mon, Sep 5, 2011 at 08:24, Joel Dahl wrote: >> > On 05-09-2011 5:09, Adrian Chadd wrote: >> >> On 5 September 2011 01:04, Joel Dahl wrote: >> >> > Hi, >> >> > >> >> > I upgraded my laptop from BETA1 to rev. 225367 today, and now my laptop >> >> > panics just a few minutes after booting. This is 100% reproducible, it >> >> > panics every time. >> >> > >> >> > I've got a pic with the backtrace here: >> >> > http://www.vnode.se/sc/panic_20110904.jpg >> >> >> >> Hi, >> >> >> >> There weren't many commits between BETA1 and -HEAD in the wireless >> >> area; would you please do a binary search of the kernel revisions (no >> >> need to do full buildworlds) to find which commit broke it? >> > >> > Yes, I'll do that tonight. >> >> While doing so, can you enable at least some debugging? >> wlandebug +state >> or even better >> wlandebug 0x >> >> It smells like that something is poking the SW bmiss handler while not >> in RUN state and therefore you're hitting a KASSERT(). Question is if >> the bmiss timer isn't stopped/drained somewhere or if there is too >> excessive call. > > Exactly what in the wlandebug output are you looking for? I've posted a pic > at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like right > before the panic. This is with "wlandebug 0x". Thanks, so, looks like it is scanning while the panic happens. At that point it should actually never ever care about beacon misses.. this is strange, really. Can you try to comment out the call to ieee80211_beacon_miss() on line 2936 in if_iwn.c? If the panic no longer happens the issue is somewhere in the conditions before that call. > I've also installed kernels all the way back to revision 222980, but they all > panic, which I think is somewhat odd. I think this is an issue related to iwn(4), which had its last commit prior to that. -- Bernhard ___ 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"
[ANNOUNCE] 802.11n TX aggregation support for Atheros 11n NICs
Hi all, I apologise up front for the cross-posting. Please redirect all future queries about this to freebsd-wirel...@freebsd.org. I guess the cat is out of the bag (and it hasn't killed anyone yet.) For the last 6 or so months, the if_ath driver and net80211 802.11n support has been updated to (hopefully) be usable, both in station and hostap modes. Users could use ath(4) in -HEAD as an 11n station or hostap by just disabling ampdutx. I've been doing that successfully for a few months now at home, with respectable (> 200mbit UDP, ~ 100mbit TCP) throughput in the receive direction (as AMPDU RX now works well.) Through the gracious sponsorship of Hobnob, Inc., (and the completion of my bachelors degree in something completely unrelated to all of this!) I've dived in head-first into the 802.11n TX aggregation support. As I type this, I have an EEEPC 701 w/ an AR9280 currently spitting out a 130mbit/sec TCP stream to a Ubiquiti Routerstation Pro MIPS board w/ an AR9160 (5ghz HT/40/shortgi mode.) They're both running FreeBSD. A user asked about the state of this code on the -wireless list a couple days ago and has reported that his AR5416 based NIC is happily performing much the same way. So, since it's passed my "works for someone who isn't me!" test, I've decided to make a wider announcement. There's still a -lot- to do. Specifically (this isn't an exhaustive list): * There are locking issues with ath/net80211 which need to be resolved before this is merged back into -HEAD. * There's currently no support for HT RTS/CTS frame protection. I can add it easily enough, but I first have to add the AR5416 workarounds (8k limitation on RTS protected frames) before I can do that. * The AMPDU code is currently not sending BAR frames. This requires a little more fore-thought and net80211 reorganisation before they can be queued and sent. * Don't try to do a UDP iperf test before you establish AMPDU, or you'll fill the hardware TX queue with UDP frames and then end up with no frames available to send the ADDBA management frames. Oops! :) * The rate control module (sample) supports 11n and some basic TX aggregation stuff, but it isn't optimal. It's only "good enough" for me to not have to care about rate control causing large issues. Something needs to be done before it's merged into -HEAD - either a replacement needs to be written, or minstrel_ht needs to be ported. * There's no hardware power saving support in place at the moment. This means it'll draw a lot of power in station mode. * There's no MIMO PS support. Same caveat as the above. * adhoc, ahdemo, TDMA and IBSS modes likely won't work just yet. I'm not likely to begin looking at those until all the net80211 and ath driver changes are in place and tested. * I haven't yet added "filtered frames" support, so there's going to be a lot of packet loss in hostap mode when a station decides to go into power-saving or off-channel mode (eg to do a scan). * There are still (very) occasional TX-side hangs which I'm seeing. I'm trying to get to the bottom of this. * I've not tested this -at all- on multi-CPU/multi-core setups, primarily because I don't run freebsd+wifi on anything like that just yet. * net80211 AMPDU TX is based on QoS/WME Access Category (AC) numbers, rather than the full set of available TIDs. This is likely going to need to change (and the ieee80211 superg support tested/updated) before this can be merged into -HEAD as I've been told it's quite valid to expect multiple aggregation sessions in the same AC. What does work (what have I tested): * HT/20 and HT/40 support; * 2 and 5ghz support; * station and and hostap modes; * AR5416/AR5418, AR9160, AR9280 chipsets. I haven't tested AR9285 or AR9287 yet; * HT/20 and HT/40 interoperability support - ie, a HT/40 AP can have HT/20 and HT/40 nodes associated. 11a/11bg nodes can also associate but the current lack of HT frame protection is likely to cause significant interference; * ADDBA negotiation (with the above caveat that buffer management needs to be tidied up in my codebase, or you could end up with no TX buffers..) * ath_rate_sample knows enough about 11n and aggregation to make decent enough rate choices, but it isn't optimal by any means. * Software retransmission of aggregate frames, including doing new rate lookups so frames aren't simply retried at a bad rate. What I'm currently working on: * verifying that AR5212 series NICs haven't been broken by this. If someone has AR5210/AR5211 series PCMCIA hardware that they'd be able to send to me I'll also give them a test and verify I haven't broken them; * fixing TX side hangs; * HT protection support, w/ the AR5416 workarounds as needed; * Filtered-frame support; * More debugging and better behaviour during channel scan / off channel behaviour and during an interface reset. All of that said, it's working for me and it's working for someone else, so if you're interested in trying it out, I'm happy to take bug reports and feedback. But since I'
Shared libraries version bump?
When FreeBSD 9.0_BETA1 was announced, the announcement included a notice that shared library version would be updated some time prior to BETA2, which would necessitate rebuilding all ports. Has this happened yet? I don't want to rebuild all ports at the wrong time. I notice BETA2 has been released but see no announcement. Readme, hardware notes and release notes say nothing specific to the BETA2 release/snapshot. If the shared libraries version bump has not yet occurred, I would want to update in place, if the installer can do that; otherwise I would install BETA2 to a different partition, keeping the old /home and swap. That way, I would still have BETA1 to fall back on for the built ports, before I would finish rebuilding the ports on BETA2. This is on a new computer, with Western Digital Caviar Green 3 TB hard drive, using GPT, so for now I have plenty of space. I already downloaded and dd'ed the amd64 memstick image for amd64, and have looked at the data thereon. Tom ___ 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: RELENG_8 / mpt / zpool Errors
On 7 September 2011 13:54, Tim Gustafson wrote: > > What are the drives exactly? You may have issues like TLER or > > frequent head parking. Are these SATA, SCSI or SAS and are port > > multipliers in use? > > root@bsd-03: dmesg | grep da6 > da6 at mpt0 bus 0 scbus1 target 1 lun 0 > da6: Fixed Direct Access SCSI-5 device > da6: 300.000MB/s transfers > da6: Command Queueing enabled > da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > > The drives are housed in two of the following enclosures: > > ses0 at mpt0 bus 0 scbus1 target 32 lun 0 > ses0: Fixed Enclosure Services SCSI-5 device > ses0: 300.000MB/s transfers > ses0: Command Queueing enabled > ses0: SCSI-3 SES Device > > Each enclosure is directly connected by a dedicated cable to the 2-port > controller: > > mps0: port 0xfc00-0xfcff mem > 0xef5f-0xef5f,0xef58-0xef5b irq 44 at device 0.0 on pci1 > mps0: Firmware: 07.15.04.00 > mps0: IOCCapabilities: > 185c > mps0: [ITHREAD] > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Tim Gustafson > t...@soe.ucsc.edu > Baskin School of Engineering > 831-459-5354 > UC Santa Cruz Baskin Engineering > 317B > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > You'll be interested in the thread "PCIe SATA HBA for ZFS on -STABLE" on the FreeBSD-STABLE list between 31 May 2011 and 12 June 2011. Jeremy Chadwick's post on the 1st of June is particularly enlightening. Advice is: Use -STABLE and not -RELEASE Upgrade firmware Avoid port multipliers I'm having no troubles but with 8 identical SATA disks instead of SAS. As I'm using cheap 4K green drives I had to use wdidle3.exe to fix the 8 second head parking and I also had to use gnop to force my ZFS pool to use 4K transfers. mps0: port 0xee00-0xeeff mem 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 mps0: Firmware: 07.00.00.00 da0 at mps0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 09:39, Tz-Huan Huang wrote: > On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huang wrote: >> Hi, >> >> I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX 6250" >> bundled. >> The device seems recognized as iwn0 correctly but it just doesn't work. >> The command "ifconfig wlan0 up scan" return immediately and nothing showed. >> >> Is the device not supported, or do I miss something? >> Any suggestion is welcome, thanks. >> >> Here is some information: >> >> $ uname -a >> FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST >> 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 >> >> dmesg -a: >> http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt >> >> rc.conf: >> http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf >> >> kldstat -v >> http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt > > When loading acpi_ibm, I got more error information: > > $ kldload acpi_ibm > acpi_ibm0: on acpi0 > $ ifconfig wlan0 up > iwn0: iwn5000_send_calibration: could not send calibration result, error 22 > iwn0: iwn_init_locked: could not initialize hardware, error 22 Can you do sysctl dev.iwn.0.debug=0x before doing ifconfig wlan0 up? I'm curious on which result it can't send to the firmware. -- Bernhard ___ 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: Shared libraries version bump?
On Wed, Sep 07, 2011 at 09:14:12AM +, "Thomas Mueller When FreeBSD 9.0_BETA1 was announced, the announcement included a notice that > shared library version would be updated some time prior to BETA2, which would > necessitate rebuilding all ports. > > Has this happened yet? I don't want to rebuild all ports at the wrong time. > I notice BETA2 has been released but see no announcement. > > Readme, hardware notes and release notes say nothing specific to the BETA2 > release/snapshot. > > If the shared libraries version bump has not yet occurred, I would want to > update in place, if the installer can do that; otherwise I would install > BETA2 to a different partition, keeping the old /home and swap. That way, I > would still have BETA1 to fall back on for the built ports, before I would > finish rebuilding the ports on BETA2. > > This is on a new computer, with Western Digital Caviar Green 3 TB hard drive, > using GPT, so for now I have plenty of space. > > I already downloaded and dd'ed the amd64 memstick image for amd64, and have > looked at the data thereon. The bump was done for BETA2, see r225227, done on 2011-08-28. The bump has much less scope since we did the ABI analysis and only bumped the libraries which interfaces changed in incompatible way and which were not yet bumped. See the referenced commit for the libraries list. To be absolutely safe, you indeed need to rebuild all ports. Practically, the damage done by bump is very limited and most people can get away without rebuild if you already tracked HEAD. I would mostly worry about libpcap. pgprGLcOI9Cxa.pgp Description: PGP signature
Re: RELENG_8 / mpt / zpool Errors
On 7 September 2011 19:07, Matt Thyer wrote: > On 7 September 2011 13:54, Tim Gustafson wrote: > >> > What are the drives exactly? You may have issues like TLER or >> > frequent head parking. Are these SATA, SCSI or SAS and are port >> > multipliers in use? >> >> root@bsd-03: dmesg | grep da6 >> da6 at mpt0 bus 0 scbus1 target 1 lun 0 >> da6: Fixed Direct Access SCSI-5 device >> da6: 300.000MB/s transfers >> da6: Command Queueing enabled >> da6: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) >> >> The drives are housed in two of the following enclosures: >> >> ses0 at mpt0 bus 0 scbus1 target 32 lun 0 >> ses0: Fixed Enclosure Services SCSI-5 device >> ses0: 300.000MB/s transfers >> ses0: Command Queueing enabled >> ses0: SCSI-3 SES Device >> >> Each enclosure is directly connected by a dedicated cable to the 2-port >> controller: >> >> mps0: port 0xfc00-0xfcff mem >> 0xef5f-0xef5f,0xef58-0xef5b irq 44 at device 0.0 on pci1 >> mps0: Firmware: 07.15.04.00 >> mps0: IOCCapabilities: >> 185c >> mps0: [ITHREAD] >> >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> Tim Gustafson >> t...@soe.ucsc.edu >> Baskin School of Engineering >> 831-459-5354 >> UC Santa Cruz Baskin Engineering >> 317B >> >> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >> > > You'll be interested in the thread "PCIe SATA HBA for ZFS on -STABLE" on > the FreeBSD-STABLE list between 31 May 2011 and 12 June 2011. > > Jeremy Chadwick's post on the 1st of June is particularly enlightening. > > Advice is: > > Use -STABLE and not -RELEASE > Upgrade firmware > Avoid port multipliers > > I'm having no troubles but with 8 identical SATA disks instead of SAS. > > As I'm using cheap 4K green drives I had to use wdidle3.exe to fix the 8 > second head parking and I also had to use gnop to force my ZFS pool to use > 4K transfers. > > mps0: port 0xee00-0xeeff mem > 0xfbdfc000-0xfbdf,0xfbd8-0xfbdb irq 16 at device 0.0 on pci1 > mps0: Firmware: 07.00.00.00 > da0 at mps0 bus 0 scbus0 target 0 lun 0 > da0: Fixed Direct Access SCSI-5 device > da0: 300.000MB/s transfers > da0: Command Queueing enabled > da0: 1907729MB (3907029168 512 byte sectors: 255H 63S/T 243201C) > > A bit more info... The mps driver has problems with the LSI SAS2008 when using port multipliers (which are in the enclosures). If you go to the previous SAS 3G version of that chip I think you'll be OK. Either that or run Solaris Express or fix the driver. ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
Tz-Huan Huang wrote: > Hi, > > I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX 6250" bundled. > The device seems recognized as iwn0 correctly but it just doesn't work. > The command "ifconfig wlan0 up scan" return immediately and nothing showed. > > Is the device not supported, or do I miss something? > Any suggestion is welcome, thanks. > > Here is some information: > > $ uname -a > FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST > 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 > > dmesg -a: > http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt > > rc.conf: > http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf > > kldstat -v > http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt Please try attached patch. It seems like OpenBSD added support for 6205, but I'm not sure if it works for 6250. > Tz-Huan Kevin Index: sys/dev/iwn/if_iwnreg.h === --- sys/dev/iwn/if_iwnreg.h (revision 225433) +++ sys/dev/iwn/if_iwnreg.h (working copy) @@ -739,6 +739,8 @@ struct iwn5000_calib_elem { uint32_t enable; uint32_t start; +#define IWN5000_CALIB_DC (1 << 1) + uint32_t send; uint32_t apply; uint32_t reserved; Index: sys/dev/iwn/if_iwn.c === --- sys/dev/iwn/if_iwn.c (revision 225433) +++ sys/dev/iwn/if_iwn.c (working copy) @@ -245,6 +245,7 @@ static int iwn_set_pslevel(struct iwn_softc *, int, int, int); static int iwn_send_btcoex(struct iwn_softc *); static int iwn_send_advanced_btcoex(struct iwn_softc *); +static int iwn5000_runtime_calib(struct iwn_softc *); static int iwn_config(struct iwn_softc *); static uint8_t *ieee80211_add_ssid(uint8_t *, const uint8_t *, u_int); static int iwn_scan(struct iwn_softc *); @@ -2594,6 +2595,14 @@ return; } + /* + * XXX Differential gain calibration makes the 6005 firmware + * crap out, so skip it for now. This effectively disables + * sensitivity tuning as well. + */ + if (sc->hw_type == IWN_HW_REV_TYPE_6005) + return; + if (calib->state == IWN_CALIB_STATE_ASSOC) iwn_collect_noise(sc, &stats->rx.general); else if (calib->state == IWN_CALIB_STATE_RUN) @@ -4995,6 +5004,19 @@ } static int +iwn5000_runtime_calib(struct iwn_softc *sc) +{ + struct iwn5000_calib_config cmd; + + memset(&cmd, 0, sizeof cmd); + cmd.ucode.once.enable = 0x; + cmd.ucode.once.start = IWN5000_CALIB_DC; + DPRINTF(sc, IWN_DEBUG_CALIBRATE, + "%s: configuring runtime calibration\n", __func__); + return iwn_cmd(sc, IWN5000_CMD_CALIB_CONFIG, &cmd, sizeof(cmd), 0); +} + +static int iwn_config(struct iwn_softc *sc) { struct iwn_ops *ops = &sc->ops; @@ -5014,6 +5036,18 @@ } } + if (sc->hw_type == IWN_HW_REV_TYPE_6050 || + sc->hw_type == IWN_HW_REV_TYPE_6005) { + /* Configure runtime DC calibration. */ + error = iwn5000_runtime_calib(sc); + if (error != 0) { + device_printf(sc->sc_dev, + "%s: could not configure runtime calibration\n", + __func__); + return error; + } + } + /* Configure valid TX chains for >=5000 Series. */ if (sc->hw_type != IWN_HW_REV_TYPE_4965) { txmask = htole32(sc->txchainmask); ___ 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: BETA2 panic
On 07-09-2011 10:59, Bernhard Schmidt wrote: > On Tue, Sep 6, 2011 at 22:42, Joel Dahl wrote: > > On 05-09-2011 9:02, Bernhard Schmidt wrote: > >> On Mon, Sep 5, 2011 at 08:24, Joel Dahl wrote: > >> > On 05-09-2011 5:09, Adrian Chadd wrote: > >> >> On 5 September 2011 01:04, Joel Dahl wrote: > >> >> > Hi, > >> >> > > >> >> > I upgraded my laptop from BETA1 to rev. 225367 today, and now my > >> >> > laptop panics just a few minutes after booting. This is 100% > >> >> > reproducible, it panics every time. > >> >> > > >> >> > I've got a pic with the backtrace here: > >> >> > http://www.vnode.se/sc/panic_20110904.jpg > >> >> > >> >> Hi, > >> >> > >> >> There weren't many commits between BETA1 and -HEAD in the wireless > >> >> area; would you please do a binary search of the kernel revisions (no > >> >> need to do full buildworlds) to find which commit broke it? > >> > > >> > Yes, I'll do that tonight. > >> > >> While doing so, can you enable at least some debugging? > >> wlandebug +state > >> or even better > >> wlandebug 0x > >> > >> It smells like that something is poking the SW bmiss handler while not > >> in RUN state and therefore you're hitting a KASSERT(). Question is if > >> the bmiss timer isn't stopped/drained somewhere or if there is too > >> excessive call. > > > > Exactly what in the wlandebug output are you looking for? I've posted a pic > > at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like > > right > > before the panic. This is with "wlandebug 0x". > > Thanks, so, looks like it is scanning while the panic happens. At that > point it should actually never ever care about beacon misses.. this is > strange, really. > > Can you try to comment out the call to ieee80211_beacon_miss() on line > 2936 in if_iwn.c? If the panic no longer happens the issue is > somewhere in the conditions before that call. Hm, this is with bwn(4), not iwn(4). :) -- Joel ___ 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: http://www.freebsd.org/marketing/os-comparison.html
This is interesting, and could be mentioned in updated page http://www.phoronix.com/scan.php?page=article&item=linux_games_bsd&num=1 -- Aldis Berjoza http://www.bsdroot.lv/ signature.asc Description: PGP signature
Re: BETA2 panic
On Wed, Sep 7, 2011 at 12:53, Joel Dahl wrote: > On 07-09-2011 10:59, Bernhard Schmidt wrote: >> On Tue, Sep 6, 2011 at 22:42, Joel Dahl wrote: >> > On 05-09-2011 9:02, Bernhard Schmidt wrote: >> >> On Mon, Sep 5, 2011 at 08:24, Joel Dahl wrote: >> >> > On 05-09-2011 5:09, Adrian Chadd wrote: >> >> >> On 5 September 2011 01:04, Joel Dahl wrote: >> >> >> > Hi, >> >> >> > >> >> >> > I upgraded my laptop from BETA1 to rev. 225367 today, and now my >> >> >> > laptop panics just a few minutes after booting. This is 100% >> >> >> > reproducible, it panics every time. >> >> >> > >> >> >> > I've got a pic with the backtrace here: >> >> >> > http://www.vnode.se/sc/panic_20110904.jpg >> >> >> >> >> >> Hi, >> >> >> >> >> >> There weren't many commits between BETA1 and -HEAD in the wireless >> >> >> area; would you please do a binary search of the kernel revisions (no >> >> >> need to do full buildworlds) to find which commit broke it? >> >> > >> >> > Yes, I'll do that tonight. >> >> >> >> While doing so, can you enable at least some debugging? >> >> wlandebug +state >> >> or even better >> >> wlandebug 0x >> >> >> >> It smells like that something is poking the SW bmiss handler while not >> >> in RUN state and therefore you're hitting a KASSERT(). Question is if >> >> the bmiss timer isn't stopped/drained somewhere or if there is too >> >> excessive call. >> > >> > Exactly what in the wlandebug output are you looking for? I've posted a >> > pic >> > at http://www.vnode.se/sc/panic_20110906.jpg showing what it looks like >> > right >> > before the panic. This is with "wlandebug 0x". >> >> Thanks, so, looks like it is scanning while the panic happens. At that >> point it should actually never ever care about beacon misses.. this is >> strange, really. >> >> Can you try to comment out the call to ieee80211_beacon_miss() on line >> 2936 in if_iwn.c? If the panic no longer happens the issue is >> somewhere in the conditions before that call. > > Hm, this is with bwn(4), not iwn(4). :) Uhm.. right, I'm sorry, missed that Still.. two options, remove IEEE80211_FEXT_SWBMISS or try with ifconfig wlan0 -bgscan -- Bernhard ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 12:10, Kevin Lo wrote: > Tz-Huan Huang wrote: >> Hi, >> >> I have a lenovo X201s with a "Intel Centrino Advanced-N + WiMAX 6250" >> bundled. >> The device seems recognized as iwn0 correctly but it just doesn't work. >> The command "ifconfig wlan0 up scan" return immediately and nothing showed. >> >> Is the device not supported, or do I miss something? >> Any suggestion is welcome, thanks. >> >> Here is some information: >> >> $ uname -a >> FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST >> 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 >> >> dmesg -a: >> http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt >> >> rc.conf: >> http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf >> >> kldstat -v >> http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt > > > Please try attached patch. It seems like OpenBSD added support > for 6205, but I'm not sure if it works for 6250. Worth a try, but I don't think it will make a difference. I had that code once (it should even be visible on the svn history) but removed it because it isn't required, the 6005 series devices work very well without it (I'm using a 6230 (6000g2b) daily) without issues. What is import though is which calibration results are sent to the runtime firmware, I suspect there might be an issue in iwn5000_rx_calib_results() around IWN5000_PHY_CALIB_DC. I remember that someone reported the 6250 devices working once, it might be worth going over the last revisions (there where some calibration related changes) and figure out which one broke it. -- Bernhard ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 17:20, Bernhard Schmidt wrote: > On Wed, Sep 7, 2011 at 09:39, Tz-Huan Huang wrote: >> On Wed, Sep 7, 2011 at 14:10, Tz-Huan Huang wrote: >>> >>> $ uname -a >>> FreeBSD bud 9.0-BETA2 FreeBSD 9.0-BETA2 #2: Tue Sep 6 16:50:09 CST >>> 2011 root@bud:/usr/obj/usr/src/sys/BUD amd64 >>> >>> dmesg -a: >>> http://www.csie.ntu.edu.tw/~b90093/tmp/dmesg.txt >>> >>> rc.conf: >>> http://www.csie.ntu.edu.tw/~b90093/tmp/rc.conf >>> >>> kldstat -v >>> http://www.csie.ntu.edu.tw/~b90093/tmp/kldstat.txt >> >> When loading acpi_ibm, I got more error information: >> >> $ kldload acpi_ibm >> acpi_ibm0: on acpi0 >> $ ifconfig wlan0 up >> iwn0: iwn5000_send_calibration: could not send calibration result, error 22 >> iwn0: iwn_init_locked: could not initialize hardware, error 22 > > Can you do > sysctl dev.iwn.0.debug=0x > before doing > ifconfig wlan0 up? > > I'm curious on which result it can't send to the firmware. Sure, here are the error messages: http://www.csie.ntu.edu.tw/~b90093/tmp/iwn-debug.txt Thanks, Tz-Huan ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 20:34, Bernhard Schmidt wrote: > On Wed, Sep 7, 2011 at 12:10, Kevin Lo wrote: >> >> Please try attached patch. It seems like OpenBSD added support >> for 6205, but I'm not sure if it works for 6250. Okay, I am re-building the kernel now, will report here if any news. > Worth a try, but I don't think it will make a difference. I had that > code once (it should even be visible on the svn history) but removed > it because it isn't required, the 6005 series devices work very well > without it (I'm using a 6230 (6000g2b) daily) without issues. What is > import though is which calibration results are sent to the runtime > firmware, I suspect there might be an issue in > iwn5000_rx_calib_results() around IWN5000_PHY_CALIB_DC. > > I remember that someone reported the 6250 devices working once, it > might be worth going over the last revisions (there where some > calibration related changes) and figure out which one broke it. Yes, this device works fine according to this post: http://forums.freebsd.org/showthread.php?t=19839 I have scanned the source but it seems that the iwn sources changed a lot... Thanks, Tz-Huan ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 16:53, Adrian Chadd wrote: > Hi! > > Hm, maybe the iwn driver doesn't have the 6250 support? Is it supposed > to use 6000/6200 specific calibration (and other routines), or is it > using the 5000 routines correctly? > Has the card successfully loaded the firmware in? I'm not sure is the 6250 supported or not because the iwn(4) says nothing about it, but it seems be supported according to these pages: http://en.wikipedia.org/wiki/Comparison_of_open_source_wireless_drivers http://forums.freebsd.org/showthread.php?t=19839 Thanks, Tz-Huan ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 21:11, Tz-Huan Huang wrote: > On Wed, Sep 7, 2011 at 20:34, Bernhard Schmidt wrote: >> On Wed, Sep 7, 2011 at 12:10, Kevin Lo wrote: >>> >>> Please try attached patch. It seems like OpenBSD added support >>> for 6205, but I'm not sure if it works for 6250. > > Okay, I am re-building the kernel now, > will report here if any news. Well, it is no luck here. The error messages are almost the same: http://www.csie.ntu.edu.tw/~b90093/tmp/iwn-patched-debug.txt Here is the diff: --- iwn-debug.txt 2011-09-07 20:56:08.724651659 +0800 +++ iwn-patched-debug.txt 2011-09-07 21:23:28.674953262 +0800 @@ -24,7 +24,6 @@ interrupt reg1=8000 reg2=0 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 -interrupt reg1=0 reg2=0 iwn5000_query_calibration: sending calibration query iwn_cmd: IWN5000_CMD_CALIB_CONFIG (0x65) flags 0 qid 4 idx 2 interrupt reg1=8000 reg2=0 @@ -62,7 +61,6 @@ interrupt reg1=8000 reg2=0 iwn_notif_intr: qid 0 idx 1 flags 0 type 98(UNKNOWN INTR NOTIF/CMD) len 8 iwn_notif_intr: qid 4 idx 1 flags 0 type 176(IWN_CMD_PHY_CALIB) len 4 -interrupt reg1=0 reg2=0 send calibration result idx=0 len=3964 iwn0: iwn5000_send_calibration: could not send calibration result, error 22 iwn0: iwn_init_locked: could not initialize hardware, error 22 Thanks, Tz-Huan ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 15:11, Tz-Huan Huang wrote: > On Wed, Sep 7, 2011 at 20:34, Bernhard Schmidt wrote: >> On Wed, Sep 7, 2011 at 12:10, Kevin Lo wrote: >>> >>> Please try attached patch. It seems like OpenBSD added support >>> for 6205, but I'm not sure if it works for 6250. > > Okay, I am re-building the kernel now, > will report here if any news. > >> Worth a try, but I don't think it will make a difference. I had that >> code once (it should even be visible on the svn history) but removed >> it because it isn't required, the 6005 series devices work very well >> without it (I'm using a 6230 (6000g2b) daily) without issues. What is >> import though is which calibration results are sent to the runtime >> firmware, I suspect there might be an issue in >> iwn5000_rx_calib_results() around IWN5000_PHY_CALIB_DC. >> >> I remember that someone reported the 6250 devices working once, it >> might be worth going over the last revisions (there where some >> calibration related changes) and figure out which one broke it. > > Yes, this device works fine according to this post: > http://forums.freebsd.org/showthread.php?t=19839 > > I have scanned the source but it seems that the iwn sources changed a lot... Yeah, thanks, I start to remember.. Seems like I broke 6250 support by adding support for 6005. Point is, the DC calibration result generated by the init firmware is too large (saving calibration result code=8 len=3964, compare with other results..) to pass over to the runtime firmware, this is where it chokes. The solution is to not bother about it at all and let the runtime firmware do the calibration again, so no need to send anything. Basically, Kevin's patch is correct, it should also just remove handling of PHY_CALIB_DC in iwn5000_rx_calib_results(), ideally for all >= 6000 devices. Can you try this in addition to Kevin's patch? Index: if_iwn.c === --- if_iwn.c(revision 225188) +++ if_iwn.c(working copy) @@ -2502,9 +2502,7 @@ iwn5000_rx_calib_results(struct iwn_softc *sc, str switch (calib->code) { case IWN5000_PHY_CALIB_DC: - if ((sc->sc_flags & IWN_FLAG_INTERNAL_PA) == 0 && - (sc->hw_type == IWN_HW_REV_TYPE_5150 || -sc->hw_type >= IWN_HW_REV_TYPE_6000)) + if (sc->hw_type == IWN_HW_REV_TYPE_5150) idx = 0; break; case IWN5000_PHY_CALIB_LO: Thanks -- Bernhard ___ 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: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
On Wed, Sep 7, 2011 at 21:30, Bernhard Schmidt wrote: > On Wed, Sep 7, 2011 at 15:11, Tz-Huan Huang wrote: >> On Wed, Sep 7, 2011 at 20:34, Bernhard Schmidt wrote: >>> On Wed, Sep 7, 2011 at 12:10, Kevin Lo wrote: Please try attached patch. It seems like OpenBSD added support for 6205, but I'm not sure if it works for 6250. >> >> Okay, I am re-building the kernel now, >> will report here if any news. >> >>> Worth a try, but I don't think it will make a difference. I had that >>> code once (it should even be visible on the svn history) but removed >>> it because it isn't required, the 6005 series devices work very well >>> without it (I'm using a 6230 (6000g2b) daily) without issues. What is >>> import though is which calibration results are sent to the runtime >>> firmware, I suspect there might be an issue in >>> iwn5000_rx_calib_results() around IWN5000_PHY_CALIB_DC. >>> >>> I remember that someone reported the 6250 devices working once, it >>> might be worth going over the last revisions (there where some >>> calibration related changes) and figure out which one broke it. >> >> Yes, this device works fine according to this post: >> http://forums.freebsd.org/showthread.php?t=19839 >> >> I have scanned the source but it seems that the iwn sources changed a lot... > > Yeah, thanks, I start to remember.. > > Seems like I broke 6250 support by adding support for 6005. Point is, > the DC calibration result generated by the init firmware is too large > (saving calibration result code=8 len=3964, compare with other > results..) to pass over to the runtime firmware, this is where it > chokes. The solution is to not bother about it at all and let the > runtime firmware do the calibration again, so no need to send > anything. Basically, Kevin's patch is correct, it should also just > remove handling of PHY_CALIB_DC in iwn5000_rx_calib_results(), ideally > for all >= 6000 devices. > > Can you try this in addition to Kevin's patch? It works! Thank you all so much! :-) Tz-Huan > Index: if_iwn.c > === > --- if_iwn.c (revision 225188) > +++ if_iwn.c (working copy) > @@ -2502,9 +2502,7 @@ iwn5000_rx_calib_results(struct iwn_softc *sc, str > > switch (calib->code) { > case IWN5000_PHY_CALIB_DC: > - if ((sc->sc_flags & IWN_FLAG_INTERNAL_PA) == 0 && > - (sc->hw_type == IWN_HW_REV_TYPE_5150 || > - sc->hw_type >= IWN_HW_REV_TYPE_6000)) > + if (sc->hw_type == IWN_HW_REV_TYPE_5150) > idx = 0; > break; > case IWN5000_PHY_CALIB_LO: > > Thanks > > -- > Bernhard > ___ 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 9.0-BETA2 Available...
The second BETA build of the 9.0-RELEASE release cycle is now available. Since this is the first release of a brand new branch I cross-post the announcements on both -current and -stable. But just so you know most of the developers active in head pay more attention to the -current mailing list. If you notice problems you can report them through the normal Gnats PR system or on the -current mailing list. The 9.0-RELEASE cycle will be tracked here: http://wiki.freebsd.org/Releng/9.0TODO though the schedule listed there is now way off. BETA1 and some other factors caused a lot of activity. We'll re-work the schedule some time soon. NOTE: The location of the FTP install tree and ISOs have changed slightly. What we used for BETA2 reflects a directory structure that would let us fully utilize building and distributing a wider variety of architectures, based on this: farrell 1 % cd /usr/src farrell 2 % make targets Supported TARGET/TARGET_ARCH pairs for world and kernel targets amd64/amd64 arm/arm arm/armeb i386/i386 ia64/ia64 mips/mipsel mips/mipseb mips/mips64el mips/mips64eb mips/mipsn32eb pc98/i386 powerpc/powerpc powerpc/powerpc64 sparc64/sparc64 farrell 3 % However we currently, and likely will never, do builds of everything. The new layout does add a some extra complexity. So we're actively discussing whether or not to change the layout from previous releases, and if we do change it whether or not to change it this much... What's there now can be viewed as an almost "worst case" scenario (one of the possibilities being discussed includes having both $TARGET and $TARGET_ARCH in the filenames). It's entirely possible we'll back off and revert to the old layout despite that layout potentially limiting what we can do with the new build infrastructure. ISO images for the following architectures are available, with pathnames given relative to the top-level of the FTP site: amd64: .../releases/amd64/amd64/ISO-IMAGES/9.0/ i386: .../releases/i386/i386/ISO-IMAGES/9.0/ powerpc: .../releases/powerpc/powerpc/ISO-IMAGES/9.0/ powerpc64: .../releases/powerpc/powerpc64/ISO-IMAGES/9.0/ sparc64: .../releases/sparc64/sparc64/ISO-IMAGES/9.0/ Due to a bug that crept in just before BETA2 the ia64 architecture builds failed. That bug has since been fixed. MD5/SHA256 checksums are tacked on below. In addition to lots of bugfixes and a few new things that crept in since BETA1 we have done what we hope will be the final bump of versions for the non-symbol-versioned system libraries. This time we did not bump the version of every non-symbol-versioned library, we just did the ones that had an API and/or ABI change. As before one of the many new features of 9.0 we would like tested is the new installer, so fresh installs on test systems are encouraged. The shift in the directory layout described above is in part due to the new installer. FTP-based installs of BETA1 would have failed, as-is the new installer expects this for where to find the FTP install trees: .../releases/`uname -m`/`uname -p`/`uname -r` We're discussing whether or not the ISO images need to tag along with the FTP install bits to these sub-directories as part of the re-structuring, etc. If you would like to use csup/cvsup mechanisms to access the source tree the branch tag to use is "." (head). If you would like to access the source tree via SVN it is "svn://svn.freebsd.org/base/head/". At this time FreeBSD-Update is not available, in part to help encourage testing the installer. Checksums: MD5 (FreeBSD-9.0-BETA2-amd64-bootonly.iso) = 888a6eacd82a716846ce1f5151bce1a6 MD5 (FreeBSD-9.0-BETA2-amd64-dvd1.iso) = 38178ecee5924950fbcace6ed9881210 MD5 (FreeBSD-9.0-BETA2-amd64-memstick.img) = 741a1fb240fde587d4208540e1c13779 MD5 (FreeBSD-9.0-BETA2-i386-bootonly.iso) = b74f87a5a5d3da0e9241e3485d3eb2cf MD5 (FreeBSD-9.0-BETA2-i386-dvd1.iso) = d81b89d182bdbe11155dfd1e9e165fee MD5 (FreeBSD-9.0-BETA2-i386-memstick.img) = acfc9797273704008c08c416f7aa8d8b MD5 (FreeBSD-9.0-BETA2-powerpc-bootonly.iso) = f2f0274b655c4a79d6b88472162905f9 MD5 (FreeBSD-9.0-BETA2-powerpc-memstick) = 200ca101d6bb761e15d70aa743a632f6 MD5 (FreeBSD-9.0-BETA2-powerpc-release.iso) = 23df0f1e07b375be50f139e7dc95dcf5 MD5 (FreeBSD-9.0-BETA2-powerpc64-bootonly.iso) = ed0ac1edfcfe71596f7409339cfabc9f MD5 (FreeBSD-9.0-BETA2-powerpc64-memstick) = eb552d31fe999396c0bd027b0586d2ce MD5 (FreeBSD-9.0-BETA2-powerpc64-release.iso) = c4469fe01301ac835c40701d52422b55 MD5 (FreeBSD-9.0-BETA2-sparc64-CHECKSUM.MD5) = d41d8cd98f00b204e9800998ecf8427e MD5 (FreeBSD-9.0-BETA2-sparc64-bootonly.iso) = e72add6b8f2ad4d9564eddbf7ae533f0 MD5 (FreeBSD-9.0-BETA2-sparc64-dvd1.iso) = 2227e2095d57c4353400bbc4409cacff SHA256 (FreeBSD-9.0-BETA2-amd64-bootonly.iso) = 01319df05dbccaac2a8c56c4284798a4c8c3399a0c0fc8ba04407cd8eea89f76 SHA256 (FreeBSD-9.0-BETA2-amd64-dvd1.iso) = e4fa69243aeefcfbce98ac8c30a8120a33ff122e7eb8c5fd73c23d49e3b2f
Re: RELENG_8 / mpt / zpool Errors
> Advice is: > > Use -STABLE and not -RELEASE > Upgrade firmware > Avoid port multipliers > > As I'm using cheap 4K green drives I had to use wdidle3.exe to fix > the 8 second head parking and I also had to use gnop to force my > ZFS pool to use 4K transfers. We're already using -STABLE; we update to RELENG_8 periodically. LSI's web site is a little bizarre when it comes to their downloads section. I searched their drivers section for my specific model number and got a bunch of firmware upgrades for other cards with different port configurations. We can't avoid port multipliers. Nobody makes a 32-port SAS/SATA controller. And anyhow, the hardware is already purchased so I need to figure out how to make it work. :) WDC's web site says that the wdidle3.exe utility you suggested is not for this drive; the site says it's only for WD1000FYPS-01ZKB0, WD7500AYPS-01ZKB0, and WD7501AYPS-01ZKB0. I'm not sure what you mean about using gnop to force 4K transfers. > The mps driver has problems with the LSI SAS2008 when using port > multipliers (which are in the enclosures). If you go to the previous > SAS 3G version of that chip I think you'll be OK. When you say "go to the previous SAS 3G version of that chip", do you mean "buy an older version of that controller card"? Or are you talking about downgrading, rather than upgrading, the firmware? There are newer LSI cards out there as well. Would upgrading the card help any? The LSI SAS 9205-8e seems to be a workable solution, and not too expensive. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Tim Gustafsont...@soe.ucsc.edu Baskin School of Engineering 831-459-5354 UC Santa Cruz Baskin Engineering 317B -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ___ 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: FreeBSD 9.0 BETA2 gpart resize -s uses whole disk on first resize
On 07.09.2011 04:21, Mikael Fridh wrote: > Hi gurus, > > FreeBSD freebsd9.mg8.tmtowtdi.se 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Wed > Aug 31 18:07:44 UTC 2011 > r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > When resizing a partition, on first attempt it uses up the whole disk. > Only on second attempt it resizes to the correct target size. > > Resizing from any smaller size to a larger size initially uses up the > whole disk, like if -s was not used at all even if it's as little as > one logical disk block. > > I'm wondering if anyone else can reproduce. I can't reproduce. # dd if=/dev/zero of=./disk count=1 seek=3907029167 1+0 records in 1+0 records out 512 bytes transferred in 0.000116 secs (4409617 bytes/sec) # mdconfig -f disk md0 # gpart create -s gpt md0 md0 created # gpart add -t freebsd-boot -b 64 -s 128 md0 md0p1 added # gpart add -t freebsd-swap -s 8388608 md0 md0p2 added # gpart show md0 =>34 3907029101 md0 GPT (1.8T) 34 30 - free - (15k) 64 1281 freebsd-boot (64k) 192 83886082 freebsd-swap (4.0G) 8388800 3898640335 - free - (1.8T) # gpart resize -i 2 -s 33554432 md0 md0p2 resized # gpart show md0 =>34 3907029101 md0 GPT (1.8T) 34 30 - free - (15k) 64 1281 freebsd-boot (64k) 192335544322 freebsd-swap (16G) 33554624 3873474511 - free - (1.8T) === So, can you enable G_F_CTLDUMP flag and try it again, and show what you will get? Just use: # sysctl kern.geom.debugflags=0x80 # gpart resize -i 2 -s 33554432 md0 On the console (and in the log files) will be printed some info. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9.0 BETA2 gpart resize -s uses whole disk on first resize
On 07.09.2011 04:21, Mikael Fridh wrote: > Resizing from any smaller size to a larger size initially uses up the > whole disk, like if -s was not used at all even if it's as little as > one logical disk block. > > I'm wondering if anyone else can reproduce. Also, can you show the output of this command: # diskinfo -v ada0 -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?
Hello, freebsd-current. I'm building NanoBSD image based on latest HEAD sources. I've added WITHOUT_GCC to install configuration, as I don't need gcc/g++ (it is documented in man src.conf as disabling exactly gcc and g++), but it affect /usr/bin/cpp too. And I need cpp for some config processing. Is it bug in documentation (man src.conf) or build system? I know about WITHOUT_TOOLCHAIN, and it seems reasonable, that WITHOUT_TOOLCHAIN disables cpp too, but not WITHOUT_GCC :(. -- // Black Lion AKA Lev Serebryakov ___ 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: ZFS: i/o error - all block copies unavailable after upgrading to r225312
on 02/09/2011 16:35 Andriy Gapon said the following: > Then: > - obtain this patch http://people.freebsd.org/~avg/zfstest.head.diff > - cd sys/boot/zfs > - apply the patch to zfstest.c > - cc -I. -I../../cddl/boot/zfs zfstest.c -o zfstest > - run the resulting binary as root and provide your pool device(s) as > parameter(s); e.g.: > ./zfstest /dev/ada0p4 Thanks to a lot of excellent testing, debugging and analysis from Sebastian (which went behind the scenes) we now have this patch: http://people.freebsd.org/~avg/zfs-boot-gang.diff The patch introduces the following changes: - checksum is now verified for gang header blocks - checksum is now verified for reconstituted data of whole gang blocks (previously it is verified only for individual gang member leaf blocks) - reconstituted data of a whole gang block is now decompressed if the gang block is compressed The last change is _the_ change. If you use compression for a filesystem where your kernel resides and you get a problem with booting, then please test this patch and report back. Many thanks to Sebastian! Additional heap of thanks to Doug Rabson who came up with the idea and implementation of zfstest.c! This tool is of the immense help when debugging an issue like this one. -- Andriy Gapon ___ 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: WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?
On 2011-09-07 18:10, Lev Serebryakov wrote: I'm building NanoBSD image based on latest HEAD sources. I've added WITHOUT_GCC to install configuration, as I don't need gcc/g++ (it is documented in man src.conf as disabling exactly gcc and g++), but it affect /usr/bin/cpp too. And I need cpp for some config processing. Is it bug in documentation (man src.conf) or build system? I know about WITHOUT_TOOLCHAIN, and it seems reasonable, that WITHOUT_TOOLCHAIN disables cpp too, but not WITHOUT_GCC :(. It's a bug in the documentation. WITHOUT_GCC actually disables at least the following executables: /usr/bin/c++ /usr/bin/c++filt /usr/bin/CC /usr/bin/cc /usr/bin/cpp /usr/bin/g++ /usr/bin/gcc /usr/bin/gcov /usr/libexec/cc1 /usr/libexec/cc1plus ___ 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: WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?
Hello, Dimitry. You wrote 7 сентября 2011 г., 21:17:20: >>I'm building NanoBSD image based on latest HEAD sources. I've added >> WITHOUT_GCC to install configuration, as I don't need gcc/g++ (it is >> documented in man src.conf as disabling exactly gcc and g++), but it >> affect /usr/bin/cpp too. And I need cpp for some config processing. >> Is it bug in documentation (man src.conf) or build system? I know >> about WITHOUT_TOOLCHAIN, and it seems reasonable, that >> WITHOUT_TOOLCHAIN disables cpp too, but not WITHOUT_GCC :(. > It's a bug in the documentation. WITHOUT_GCC actually disables at IMHO, it is bug in build process ;-) -- see below > least the following executables: > /usr/bin/c++ > /usr/bin/c++filt > /usr/bin/CC > /usr/bin/cc > /usr/bin/cpp > /usr/bin/g++ > /usr/bin/gcc > /usr/bin/gcov > /usr/libexec/cc1 > /usr/libexec/cc1plus I think, that /usr/bin/cpp is valuable by itself, as it is handy generic preprocessor tool, useful for preparing complex ipfw scripts, for example. All others are bundled together, for sure. I think, it is good idea to exclude cpp from this list (but not from WITHOUT_TOOLCHAIN, of course). -- // Black Lion AKA Lev Serebryakov ___ 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: WITHOUT_GCC flag disables installation of /usr/bin/cpp too -- is it Ok?
On 2011-09-07 19:20, Lev Serebryakov wrote: ... I think, that /usr/bin/cpp is valuable by itself, as it is handy generic preprocessor tool, useful for preparing complex ipfw scripts, for example. All others are bundled together, for sure. I think, it is good idea to exclude cpp from this list (but not from WITHOUT_TOOLCHAIN, of course). The problem is that it ain't easy. :) Currently, MK_GCC==no simply disables building everything under /usr/src/gnu/usr.bin/cc, which has all the gcc subcomponents. And you cannot just build cpp by itself, specific gcc support tools need to be built first. ___ 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: panic: sched_priority: invalid priority 3990 on r225375
On Sunday, September 04, 2011 7:21:23 pm Ryan Stone wrote: > I've gotten the following panic twice while running recent builds of > head under VirtualBox(FreeBSD 8.2 host). > > panic: sched_priority: invalid priority 3990: nice 0, ticks 1227873280 > ftick 175669871 ltick 175679894 tick pri 3818 > > The crashes happened while I was running a stress test of the network > stack. I have a client machine and a server machine. The client is > running head with a patch that I'm trying to prove out; the server > should be running with basically stock head as of r225375(I think that > there's a couple of minor changes in the tree I used to build the > server with, but I've gotten the crash on the client and the server, > and neither have any uncommitted patches in common). The server is > running several netcat instances in listen mode; the client has a > script sitting in a loop starting netcat instances that connect to > instances running on the server and send data from client -> server. > The client also has a script that changes the routing tables > periodically. > > Both the client and the server have crashed once so far. I haven't > been running any tests on actual hardware so I can't say whether this > is a FreeBSD problem or a VirtualBox problem. I'm going to start > running the same tests against VMs running some version of FreeBSD 8 > to see if I can reproduce the problem there. In the meantime, I've > made a core.txt accessible in case anybody wants to take a look. You > can find it at: > > http://people.freebsd.org/~rstone/sched_priority/core.txt.0.bz2 > > Please let me know if you need any more information. This is due to ts->ts_ticks being way too large. I think it needs a cap to handle this case, but I'm not sure exactly which bits need to be capped, and what the maximum value they should be capped at is. -- John Baldwin ___ 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: ath0 no longer attaches, cardbus problems?
On Tue, 6 Sep 2011, John Baldwin wrote: On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: Looks like I had a typo in my original e-mail, try "debug.acpi.disabled=hostres" rather than "debug.acpi.disable=hostres". Ok, I'll try that. Setting debug.acpi.disabled=hostres in /boot/loader.conf did not help. I tried this with a recent kernel from HEAD. More info. I've found that kernels: March 31 - work, ath attaches and works April 1 - June 6: panic on cardbus attach June 7 - HEAD: work, but ath doesn't attach I found the commit that fixed the panic: Index: sys/dev/pci/pci.c === RCS file: /opt/FreeBSD/cvs/src/sys/dev/pci/pci.c,v retrieving revision 1.420 retrieving revision 1.421 diff -u -r1.420 -r1.421 --- sys/dev/pci/pci.c 3 May 2011 17:37:24 - 1.420 +++ sys/dev/pci/pci.c 6 Jun 2011 13:21:11 - 1.421 @@ -2576,6 +2576,17 @@ uint16_t cmd; struct resource *res; + /* +* The BAR may already exist if the device is a CardBus card +* whose CIS is stored in this BAR. +*/ + pm = pci_find_bar(dev, reg); + if (pm != NULL) { + maprange = pci_maprange(pm->pm_value); + barlen = maprange == 64 ? 2 : 1; + return (barlen); + } + pci_read_bar(dev, reg, &map, &testval); if (PCI_BAR_MEM(map)) { type = SYS_RES_MEMORY; I applied this patch to the April 1st kernel (which previously paniced) and was able to boot the kernel. ath still does not attach. So the commit that broke my cardbus ath occurred on April 1. -- DE ___ 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: FreeBSD 9.0 BETA2 gpart resize -s uses whole disk on first resize
2011/9/7 Andrey V. Elsukov : > On 07.09.2011 04:21, Mikael Fridh wrote: >> Hi gurus, >> >> FreeBSD freebsd9.mg8.tmtowtdi.se 9.0-BETA2 FreeBSD 9.0-BETA2 #0: Wed >> Aug 31 18:07:44 UTC 2011 >> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >> >> When resizing a partition, on first attempt it uses up the whole disk. >> Only on second attempt it resizes to the correct target size. >> >> Resizing from any smaller size to a larger size initially uses up the >> whole disk, like if -s was not used at all even if it's as little as >> one logical disk block. >> >> I'm wondering if anyone else can reproduce. > > I can't reproduce. > > So, can you enable G_F_CTLDUMP flag and try it again, and show what you > will get? > Just use: > # sysctl kern.geom.debugflags=0x80 > # gpart resize -i 2 -s 33554432 md0 > > On the console (and in the log files) will be printed some info. I saw your patch and will try to patch and try it. For completion here is the information you requested. freebsd9# gpart add -t freebsd-swap -s 200 -l testswap ada0 ada0p5 added freebsd9# gpart show ada0 =>34 3907029101 ada0 GPT (1.8T) 34 30- free - (15k) 64 128 1 freebsd-boot (64k) 19233554240 2 freebsd-swap (16G) 33554432 209715200 3 freebsd-zfs (100G) 243269632 3663757312 4 freebsd-zfs (1.7T) 3907026944 200 5 freebsd-swap (100k) 39070271441991- free - (995k) freebsd9# sysctl kern.geom.debugflags=0x80 kern.geom.debugflags: 0 -> 128 freebsd9# gpart resize -i 5 -s 800 ada0 ada0p5 resized freebsd9# gpart show ada0 =>34 3907029101 ada0 GPT (1.8T) 34 30- free - (15k) 64 128 1 freebsd-boot (64k) 19233554240 2 freebsd-swap (16G) 33554432 209715200 3 freebsd-zfs (100G) 243269632 3663757312 4 freebsd-zfs (1.7T) 39070269442184 5 freebsd-swap (1.1M) 3907029128 7- free - (3.5k) freebsd9# diskinfo -v ada0 ada0 512 # sectorsize 2000398934016 # mediasize in bytes (1.8T) 3907029168 # mediasize in sectors 4096# stripesize 0 # stripeoffset 3876021 # Cylinders according to firmware. 16 # Heads according to firmware. 63 # Sectors according to firmware. WD-WCAVY1880124 # Disk ident. dmesg output from gpart add and 2 sequential gpart resizes (gpart resize -i 5 -s 800 ada0): * add: Dump of gctl request at 0xfe0002b94a80: param:"class" [R5] = "PART" param:"verb" [R4] = "add" param:"version" [R4] = 00 00 00 00 param:"type" [R13] = "freebsd-swap" param:"size" [R4] = "200" param:"label" [R9] = "testswap" param:"start" [R11] = "3907026944" param:"flags" [R2] = "C" param:"arg0" [R5] = "ada0" param:"output" [RW4096] = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * resize 1: Dump of gctl request at 0xfe0002b94c80: param:"class" [R5] = "PART" param:"verb" [R7] = "resize" param:"version" [R4] = 00 00 00 00 param:"index" [R8] = 05 00 00 00 00 00 00 00 param:"size" [R5] = "2184" param:"flags" [R2] = "C" param:"arg0" [R5] = "ada0" param:"output" [RW4096] = 00 00 00 00 00 00 00 00 00 0
Re: FreeBSD 9.0-BETA2 Available...
On 07/09/2011 15:51, Ken Smith wrote: As before one of the many new features of 9.0 we would like tested is the new installer, so fresh installs on test systems are encouraged. The shift in the directory layout described above is in part due to the new installer. FTP-based installs of BETA1 would have failed, as-is the new installer expects this for where to find the FTP install trees: There's still a typo in the installer: "Resovler Configuration". Also, it seems the OK button doesn't work if the installer fails to fetch a file - to exit from the "Fetch Error" screen I had to press Ctrl-C. -- Bruce Cran ___ 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: FreeBSD 9.0-BETA2 Available...
On Wed, Sep 7, 2011 at 1:35 PM, Bruce Cran wrote: > On 07/09/2011 15:51, Ken Smith wrote: >> >> As before one of the many new features of 9.0 we would like tested >> is the new installer, so fresh installs on test systems are encouraged. >> The shift in the directory layout described above is in part due to >> the new installer. FTP-based installs of BETA1 would have failed, >> as-is the new installer expects this for where to find the FTP >> install trees: > > There's still a typo in the installer: "Resovler Configuration". Already fixed, but it didn't make it into the BETA2 media. > Also, it seems the OK button doesn't work if the installer fails to fetch a > file - to exit from the "Fetch Error" screen I had to press Ctrl-C. Hmm... don't know about that one. Thanks! -Garrett ___ 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"
-CURRENT (BETA2) nfs client surprise
Hello, Freebsd-current. I've built NanoBSD image for my router based on latest HEAD sources. Image contains minimal set of kernel modules and custom kernel with NFSCLIENT option. Router mounts "/usr/home" via NFS with this "/etc/fstab" line: 192.168.134.2:/usr/home /usr/home nfs rw,late,soft,intr,bg,wsize=65536,rsize=65536,tcp 0 0 And I've been very surprised when boot failed because it cannot find "nfscl" module. Yes, I know, that now here are TWO versions of in-kernel NFS clients. But, IMHO, it is POLA violation not to boot with valid configuration from previous version. -- // Black Lion AKA Lev Serebryakov ___ 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: -CURRENT (BETA2) nfs client surprise
2011/9/7 Lev Serebryakov : > Hello, Freebsd-current. > > I've built NanoBSD image for my router based on latest HEAD sources. > Image contains minimal set of kernel modules and custom kernel with > NFSCLIENT option. It needs to be changed to NFSCL: $ svngrep -r NFSCL /sys/i386/conf/GENERIC options NFSCL # New Network Filesystem Client options NFS_ROOT# NFS usable as /, requires NFSCL > Router mounts "/usr/home" via NFS with this "/etc/fstab" line: > > 192.168.134.2:/usr/home /usr/home nfs > rw,late,soft,intr,bg,wsize=65536,rsize=65536,tcp 0 0 > > And I've been very surprised when boot failed because it cannot find > "nfscl" module. > > Yes, I know, that now here are TWO versions of in-kernel NFS > clients. But, IMHO, it is POLA violation not to boot with valid > configuration from previous version. I think the nomenclature change was done s.t. clients using old NFS implementations didn't require any changes in their KERNCONF files. Thanks, -Garrett ___ 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: -CURRENT (BETA2) nfs client surprise
Hello, Garrett. You wrote 8 сентября 2011 г., 0:55:11: > It needs to be changed to NFSCL: > $ svngrep -r NFSCL /sys/i386/conf/GENERIC > options NFSCL # New Network Filesystem Client > options NFS_ROOT# NFS usable as /, requires NFSCL Yep, I found it in seconds, but after that kernel + nanobsd image rebuild takes considerable amount of time. > I think the nomenclature change was done s.t. clients using old NFS > implementations didn't require any changes in their KERNCONF files. It is not true. I'm using old KERNCONF (with only NFSCLIENT) and old fstab (Without any NSF vversion options) -- and got error on boot due to unmountable file system! Of course, if this system had had full set of modules, this situation would have masked by transparent loading of nfscl.ko. -- // Black Lion AKA Lev Serebryakov ___ 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: -CURRENT (BETA2) nfs client surprise
Lev Serebryakov wrote: > Hello, Freebsd-current. > > I've built NanoBSD image for my router based on latest HEAD sources. > Image contains minimal set of kernel modules and custom kernel with > NFSCLIENT option. > Router mounts "/usr/home" via NFS with this "/etc/fstab" line: > > 192.168.134.2:/usr/home /usr/home nfs > rw,late,soft,intr,bg,wsize=65536,rsize=65536,tcp 0 0 > > And I've been very surprised when boot failed because it cannot find > "nfscl" module. > See UPDATING (in head) date 20110427. > Yes, I know, that now here are TWO versions of in-kernel NFS > clients. But, IMHO, it is POLA violation not to boot with valid > configuration from previous version. > I'll admit I don't even know what the acronym POLA stands for, but it was my understanding that this change was ok for a major new release. Anyhow, the new client (kernel "options NFSCL") is now the one called "nfs". If you want to use the old client (options NFSCLIENT), the file system type is called "oldnfs". > -- > // Black Lion AKA Lev Serebryakov > > ___ > 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: -CURRENT (BETA2) nfs client surprise
On Wednesday, September 07, 2011 5:02:47 pm Lev Serebryakov wrote: > Hello, Garrett. > You wrote 8 сентября 2011 г., 0:55:11: > > > It needs to be changed to NFSCL: > > > $ svngrep -r NFSCL /sys/i386/conf/GENERIC > > options NFSCL # New Network Filesystem Client > > options NFS_ROOT# NFS usable as /, requires NFSCL > Yep, I found it in seconds, but after that kernel + nanobsd image > rebuild takes considerable amount of time. > > > I think the nomenclature change was done s.t. clients using old NFS > > implementations didn't require any changes in their KERNCONF files. > It is not true. I'm using old KERNCONF (with only NFSCLIENT) and old > fstab (Without any NSF vversion options) -- and got error on boot due > to unmountable file system! Of course, if this system had had full set > of modules, this situation would have masked by transparent loading of > nfscl.ko. You can't rely on using kernel configs unchanged across major releases. -- John Baldwin ___ 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: ath0 no longer attaches, cardbus problems?
On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: > On Tue, 6 Sep 2011, John Baldwin wrote: > > > On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: > >> On Tue, 6 Sep 2011, John Baldwin wrote: > >>> > >>> Looks like I had a typo in my original e-mail, try > >>> "debug.acpi.disabled=hostres" > >>> rather than "debug.acpi.disable=hostres". > >> > >> Ok, I'll try that. > > Setting debug.acpi.disabled=hostres in /boot/loader.conf > did not help. I tried this with a recent kernel from HEAD. Did it remove the 'pcib0: decoding ' lines from a verbose dmesg? > More info. I've found that kernels: > >March 31 - work, ath attaches and works > >April 1 - June 6: panic on cardbus attach > >June 7 - HEAD: work, but ath doesn't attach > > > I found the commit that fixed the panic: > >Index: sys/dev/pci/pci.c >=== >RCS file: /opt/FreeBSD/cvs/src/sys/dev/pci/pci.c,v >retrieving revision 1.420 >retrieving revision 1.421 >diff -u -r1.420 -r1.421 >--- sys/dev/pci/pci.c 3 May 2011 17:37:24 - 1.420 >+++ sys/dev/pci/pci.c 6 Jun 2011 13:21:11 - 1.421 >@@ -2576,6 +2576,17 @@ >uint16_t cmd; >struct resource *res; > >+ /* >+* The BAR may already exist if the device is a CardBus card >+* whose CIS is stored in this BAR. >+*/ >+ pm = pci_find_bar(dev, reg); >+ if (pm != NULL) { >+ maprange = pci_maprange(pm->pm_value); >+ barlen = maprange == 64 ? 2 : 1; >+ return (barlen); >+ } >+ >pci_read_bar(dev, reg, &map, &testval); >if (PCI_BAR_MEM(map)) { >type = SYS_RES_MEMORY; > > > I applied this patch to the April 1st kernel (which previously > paniced) and was able to boot the kernel. ath still does not > attach. > > So the commit that broke my cardbus ath occurred on April 1. Hmm. There are no PCI or Cardbus commits on April 1. There are some ath(4) changes though including two HAL changes: Author: adrian Date: Sat Apr 2 00:24:13 2011 New Revision: 220258 URL: http://svn.freebsd.org/changeset/base/220258 Log: Add some more debugging Modified: head/sys/dev/ath/ath_hal/ar5416/ar2133.c Modified: head/sys/dev/ath/ath_hal/ar5416/ar2133.c == --- head/sys/dev/ath/ath_hal/ar5416/ar2133.cSat Apr 2 00:08:32 2011 (r220257) +++ head/sys/dev/ath/ath_hal/ar5416/ar2133.cSat Apr 2 00:24:13 2011 (r220258) @@ -251,11 +251,19 @@ ar2133SetRfRegs(struct ath_hal *ah, cons /* Only the 5 or 2 GHz OB/DB need to be set for a mode */ if (IEEE80211_IS_CHAN_2GHZ(chan)) { + HALDEBUG(ah, HAL_DEBUG_EEPROM, "%s: 2ghz: OB_2:%d, DB_2:%d\n", + __func__, + ath_hal_eepromGet(ah, AR_EEP_OB_2, AH_NULL), + ath_hal_eepromGet(ah, AR_EEP_DB_2, AH_NULL)); ar5416ModifyRfBuffer(priv->Bank6Data, ath_hal_eepromGet(ah, AR_EEP_OB_2, AH_NULL), 3, 197, 0); ar5416ModifyRfBuffer(priv->Bank6Data, ath_hal_eepromGet(ah, AR_EEP_DB_2, AH_NULL), 3, 194, 0); } else { + HALDEBUG(ah, HAL_DEBUG_EEPROM, "%s: 5ghz: OB_5:%d, DB_5:%d\n", + __func__, + ath_hal_eepromGet(ah, AR_EEP_OB_5, AH_NULL), + ath_hal_eepromGet(ah, AR_EEP_DB_5, AH_NULL)); ar5416ModifyRfBuffer(priv->Bank6Data, ath_hal_eepromGet(ah, AR_EEP_OB_5, AH_NULL), 3, 203, 0); ar5416ModifyRfBuffer(priv->Bank6Data, Date: Sat Apr 2 00:27:22 2011 New Revision: 220259 URL: http://svn.freebsd.org/changeset/base/220259 Log: From ath9k - clear the RX descriptor status before recycling it. Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c Modified: head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c == --- head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c Sat Apr 2 00:24:13 2011(r220258) +++ head/sys/dev/ath/ath_hal/ar5416/ar5416_recv.c Sat Apr 2 00:27:22 2011(r220259) @@ -67,6 +67,7 @@ ar5416SetupRxDesc(struct ath_hal *ah, st uint32_t size, u_int flags) { struct ar5416_desc *ads = AR5416DESC(ds); + HAL_CAPABILITIES *pCap = &AH_PRIVATE(ah)->ah_caps; HALASSERT((size &~ AR_BufLen) == 0); @@ -77,6 +78,10 @@ ar5416SetupRxDesc(struct ath_hal *ah, st /* this should be enough */ ads->ds_rxstatus8 &= ~AR_RxDone; + /* clear the rest of the status fields */ + if (! pCap->halAutoSleepSupport) + OS_MEMZERO(&(ads->u), sizeof(ads->u)); + return AH_TRUE; } > > -- > DE > -- John Baldwin
Re: ath0 no longer attaches, cardbus problems?
On Wed, 7 Sep 2011, John Baldwin wrote: On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: On Tuesday, September 06, 2011 3:34:58 pm Daniel Eischen wrote: On Tue, 6 Sep 2011, John Baldwin wrote: Looks like I had a typo in my original e-mail, try "debug.acpi.disabled=hostres" rather than "debug.acpi.disable=hostres". Ok, I'll try that. Setting debug.acpi.disabled=hostres in /boot/loader.conf did not help. I tried this with a recent kernel from HEAD. Did it remove the 'pcib0: decoding ' lines from a verbose dmesg? I don't see that line in a verbose dmesg. The hostres verbose dmesg is here: http://people.freebsd.org/~deischen/ath_dmesg_hostres.txt More info. I've found that kernels: March 31 - work, ath attaches and works April 1 - June 6: panic on cardbus attach June 7 - HEAD: work, but ath doesn't attach I found the commit that fixed the panic: [ snip ] I applied this patch to the April 1st kernel (which previously paniced) and was able to boot the kernel. ath still does not attach. So the commit that broke my cardbus ath occurred on April 1. Hmm. There are no PCI or Cardbus commits on April 1. There are some ath(4) changes though including two HAL changes: I'm using a local CVS repo, so the a -D date means (I guess) the beginning of the day. So the commit that actually broke the kernel for me occurred on Mar 31. According to: cvs diff -u -D"31 Mar 2011" -D"1 Apr 2011" there were a lot of sys/dev/pci changes. -- DE ___ 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"
-CURRENT (BETA1) zfs pool recognized as corrupted
hi I've tried to import my zfs pool on: FreeBSD-9.0-BETA1-amd64-memstick.img My system currently runs 9.0-BETA1 and pool works correctly. zpool import returns: pool: zroot id: 3239789026273107181 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://www.sun.com/msg/ZFS-8000-5E config: zroot FAULTED corrupted data 9327291201483595311 UNAVAIL corrupted data gpart show lists all my partitions => 34 250069613 ada0 GPT (119G) 34128 1 freebsd-boot (64k) 162 1886 5 bios-boot (943k) 2048 16777216 2 !0fc63daf-8483-4772-8e79-3d69d8477de4 (8.0G) 16779264 33554432 3 freebsd-ufs (16G) 50333696 199735951 4 freebsd-zfs (95G) My pool 'zroot' consists of partition 4. I'm able to import this pool on 8.2-RELEASE, booted from CD: pool: zroot id: 3239789026273107181 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: zroot ONLINE gptid/9795c3f7-b191-11e0-94fb-e89a8f131096 ONLINE Pool properties: NAME PROPERTY VALUE SOURCE zroot size 95G - zroot used 70.5G - zroot available 24.5G - zroot capacity 74% - zroot altroot- default zroot health ONLINE - zroot guid 3239789026273107181 default zroot version15 default zroot bootfs zroot local zroot delegation on default zroot autoreplaceoff default zroot cachefile - default zroot failmode panic local zroot listsnapshots off default I'm running zpool at version 15. ___ 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 9.0 and 4-socket Intel XEON E7-4870 system -->> 80 logical CPUs
Watching the ncpu number, I realized that FreeBSD is limited to 64 processors. Some vendors offer now 4-socket Intel Xeon E7-4870 systems. This "Westmere" based CPU has 10 physical and 20 logical cores, summa summarum 80 cores. Is FreeBSD 9.0 capable of handling such a server? Regards, Oliver ___ 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: FreeBSD 9.0 and 4-socket Intel XEON E7-4870 system -->> 80 logical CPUs
On Wed, Sep 7, 2011 at 3:27 PM, Hartmann, O. wrote: > > Watching the ncpu number, I realized that FreeBSD is limited to 64 > processors. > Some vendors offer now 4-socket Intel Xeon E7-4870 systems. This > "Westmere" > based CPU has 10 physical and 20 logical cores, summa summarum 80 > cores. > Is FreeBSD 9.0 capable of handling such a server? Yes, with some potential catches. -Garrett 1. http://svnweb.freebsd.org/base?view=revision&revision=222813 2. http://groups.google.com/group/mailing.freebsd.hackers/browse_thread/thread/2f4da860c972d5aa ___ 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: PAM/setloginclass link error in jail
Just for the archives, this turned out to be a problem with updating the ezjail basejail directory. I had run ezjail-admin update -i, but for some reason it did not install the new libc.so.7 while it did install pretty much everything else. Moving the old basejail out of the way and installing a new basejail from scratch solved the problem. Its not clear why ezjail's cpio command failed to update the libc.so.7 file in the first place. Sorry for the noise. - Ben On Sep 5, 2011, at 7:17 PM, Ben Kelly wrote: > Hello all, > > I upgraded my server today to a recent HEAD from its old sources from about > October 2010. After the upgrade I ran into an unusual problem. I've worked > around the issue for now, but I was wondering if anyone could help me solve > it correctly. > > The problem is that all PAM related operations fail inside jails. Initially > I was getting this error in /var/log/messages: > > passwd: in openpam_load_module(): no pam_unix.so found > > That file was clearly there, however, so I dug into PAM and enabled some > debug in pam_dynamic.c. This got me the following message: > > openpam_dynamic(): /usr/lib/pam_unix.so: /lib/libutil.so.9: Undefined symbol > "setloginclass" > > This is a syscall added to the system in March, 2011. The link process works > fine normally, but fails in any jail. I went as far as turning on rtld debug > to verify it was giving up on libutil about half way through when it could > not resolve the symbol. I verified that libc.so.7 was the same both inside > and outside the jail. The setloginclass symbol was defined as a WEAK > reference. > > Looking through past e-mail I noticed trasz@ said he was going to explicitly > put in code to support setloginclass from root in a jail. I think I see this > code in the prison privilege checking as well. Its just not clear to me why > its not linking. > > To work around the issue I hacked setloginclass out of libutil for now. This > is clearly not ideal as I'm not sure when and where that will blow up on me. > It did let me log back into my e-mail, however. > > For reference: > > FreeBSD ianto.in.wanderview.com 9.0-BETA2 FreeBSD 9.0-BETA2 #1 r278M: Mon Sep > 5 18:54:58 UTC 2011 > r...@ianto.in.wanderview.com:/usr/obj/usr/src/sys/SERVER i386 > > The system is using zfs, nullfs, and ezjail to manage the jails. I did > upgrade my zfs pools to the latest version at this same time, but so far I > can't tie that to this problem. > > Does anyone know why a jail would prevent rtld from linking in a particular > syscall? Any help or advice is greatly appreciated. > > Thank you. > > Ben ___ 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"
8-stable -> 9-current upgrade
I've been looking for any information on any special steps required to update from 8-stable to 9-current. /usr/src/UPDATING is a bit out of date as it has instructions for going from 5-stable to "current", although the instruction may well be the same. I am particularly concerned with things like header files (/usr/include) that might bite me if not deleted. Thanks! -- R. Kevin Oberman, Network Engineer - Retired E-mail: kob6...@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: 8-stable -> 9-current upgrade
On Wed, Sep 07, 2011 at 05:12:45PM -0700, Kevin Oberman wrote: > ... > I am particularly concerned with things like header files > (/usr/include) that might bite me if not deleted. This isn't specific to that upgrade, but when I do a "make installworld", I augment the instructions from UPDATING, prefixing the "make installworld" itself with: rm -fr /usr/include.old && mv /usr/include{,.old} && \ rm -fr /usr/share/man Thus, I have reasonable confidence that the newly-installed world has no significant "pollution" from the old world, at least in /usr/include and /usr/share/man. (Libraries are a different matter -- and addressed differently.) Note, too, that a "standard" source upgrade has no provision for updating /etc/localtime, in case that may be an issue. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpnJVeAKhFA1.pgp Description: PGP signature
Re: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work
Sweet. Bernhard, can you get this committed to -HEAD before 9.0-RC1 ? Adrian ___ 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: ZFS: i/o error - all block copies unavailable after upgrading to r225312
On 2011-Sep-07 19:35:09 +0300, Andriy Gapon wrote: >Thanks to a lot of excellent testing, debugging and analysis from Sebastian >(which went behind the scenes) we now have this patch: >http://people.freebsd.org/~avg/zfs-boot-gang.diff ... >If you use compression for a filesystem where your kernel resides and >you get a problem with booting, then please test this patch and >report back. Since the problem isn't consistent (it can appear on some files but not others), I modified zfstest to take a pathname, rather than have the pathname hard-coded. Using this, I found an example file that works with the patch but not with the old ZFS code: pjdesk% ./zfstest.old /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 |less ZFS: i/o error - all block copies unavailable can't lookup pjdesk% ./zfstest.old /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 |less ZFS: i/o error - all block copies unavailable can't lookup pjdesk% ./zfstest.old /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 |less ZFS: i/o error - all block copies unavailable can't lookup pjdesk% ./zfstest /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 |less ^?ELF^B^A^A ^@^@^@^@^@^@^@^@^A^@>^@^A^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@p ... pjdesk% ./zfstest /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 | cmp - /boot/kernel.old/iwn6000fw.ko.symbols pjdesk% ./zfstest /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 | cmp - /boot/kernel.old/iwn6000fw.ko.symbols pjdesk% ./zfstest.old /boot/kernel.old/iwn6000fw.ko.symbols /dev/ad0p3 | cmp - /boot/kernel.old/iwn6000fw.ko.symbols stdin /boot/kernel.old/iwn6000fw.ko.symbols differ: char 1, line 1 pjdesk% This was tested on an 8-STABLE system at r225392. I've built new bootblocks but not tested them yet - I will do that tomorrow. -- Peter Jeremy pgpVRdecjLxqB.pgp Description: PGP signature
Re: FreeBSD 9.0 and 4-socket Intel XEON E7-4870 system -->> 80 logical CPUs
On 8 September 2011 02:27, Hartmann, O. wrote: > > Watching the ncpu number, I realized that FreeBSD is limited to 64 > processors. > Some vendors offer now 4-socket Intel Xeon E7-4870 systems. This > "Westmere" > based CPU has 10 physical and 20 logical cores, summa summarum 80 > cores. > Is FreeBSD 9.0 capable of handling such a server? See kernel option MAXCPU and its description in NOTES. -- wbr, pluknet ___ 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: FreeBSD 9.0 and 4-socket Intel XEON E7-4870 system -->> 80 logical CPUs
On 09/08/11 08:15, Sergey Kandaurov wrote: On 8 September 2011 02:27, Hartmann, O. wrote: Watching the ncpu number, I realized that FreeBSD is limited to 64 processors. Some vendors offer now 4-socket Intel Xeon E7-4870 systems. This "Westmere" based CPU has 10 physical and 20 logical cores, summa summarum 80 cores. Is FreeBSD 9.0 capable of handling such a server? See kernel option MAXCPU and its description in NOTES. Thanks a lot. My view of the limit was a bit outdated ... Regards, oh ___ 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"