date:20110907

Re: "Intel Centrino Advanced-N + WiMAX 6250" doesn't work

2011-09-07 Thread Tz-Huan Huang

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

2011-09-07 Thread Tz-Huan Huang

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

2011-09-07 Thread Andreas Tobler

- 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

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

2011-09-07 Thread Adrian Chadd

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

2011-09-07 Thread Adrian Chadd

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

2011-09-07 Thread Bernhard Schmidt

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

2011-09-07 Thread Adrian Chadd

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?

2011-09-07 Thread 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.

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

2011-09-07 Thread Matt Thyer

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

2011-09-07 Thread Bernhard Schmidt

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?

2011-09-07 Thread Kostik Belousov

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

2011-09-07 Thread Matt Thyer

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

2011-09-07 Thread Kevin Lo

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

2011-09-07 Thread Joel Dahl

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

2011-09-07 Thread Aldis Berjoza

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

2011-09-07 Thread Bernhard Schmidt

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

2011-09-07 Thread Bernhard Schmidt

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

2011-09-07 Thread Tz-Huan Huang

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

2011-09-07 Thread Tz-Huan Huang

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

2011-09-07 Thread Tz-Huan Huang

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

2011-09-07 Thread Tz-Huan Huang

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

2011-09-07 Thread Bernhard Schmidt

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

2011-09-07 Thread Tz-Huan Huang

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...

2011-09-07 Thread Ken Smith


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

2011-09-07 Thread Tim Gustafson

> 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

2011-09-07 Thread 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.

# 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

2011-09-07 Thread Andrey V. Elsukov

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?

2011-09-07 Thread Lev Serebryakov

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

2011-09-07 Thread Andriy Gapon

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?

2011-09-07 Thread Dimitry Andric


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?

2011-09-07 Thread Lev Serebryakov

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?

2011-09-07 Thread Dimitry Andric


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

2011-09-07 Thread John Baldwin

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?

2011-09-07 Thread Daniel Eischen


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-09-07 Thread Mikael Fridh

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...

2011-09-07 Thread Bruce Cran


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...

2011-09-07 Thread Garrett Cooper

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

2011-09-07 Thread 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.
  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-09-07 Thread Garrett Cooper

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

2011-09-07 Thread Lev Serebryakov

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

2011-09-07 Thread Rick Macklem

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

2011-09-07 Thread John Baldwin

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?

2011-09-07 Thread John Baldwin

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?

2011-09-07 Thread Daniel Eischen


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

2011-09-07 Thread Sebastian Chmielewski

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

2011-09-07 Thread Hartmann, O.


   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

2011-09-07 Thread Garrett Cooper

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

2011-09-07 Thread Ben Kelly

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

2011-09-07 Thread Kevin Oberman

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

2011-09-07 Thread David Wolfskill

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

2011-09-07 Thread Adrian Chadd

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

2011-09-07 Thread Peter Jeremy

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

2011-09-07 Thread Sergey Kandaurov

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

2011-09-07 Thread Hartmann, O.


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"

54 matches

Mail list logo