Problems with EeePC 1005HA wireless (Wireless Atheros 9285)
I'm new to the list, so hello everybody and pleased to meet you all. I have installed the recent 8.1 BETA 1 on an Eee PC 1005HA and I'm experiencing problems with the wireless card. It is correctly recognized and configured. I have an ath0 device and I can create an wlan0 without problems. I can even scan with wlan0 and sometimes I see my wireless router. The problem is when wpa_supplicant tries to register with the network that it fails. BTW, I have a WEP system with long key (13 hex digits). I have sniffed the wireless network with another computer and the packets seem to be all correct: the Eee PC sends correct packets to the air, and the wifi router replies them correctly, but wpa_supplicant reports "registration timed out", as if it wasn't receiving the packets. It is nevertheless very strange because around 2-3 weeks ago I had the STABLE branch installed on the same Eee PC and the wifi worked (not always, but it succedeed always when it was near the router and the PC was just being rebooted). Does anybody experience the same problem or has any hint on what could be happening? I have compiled my kernel with AH_DEBUG and ATH_DEBUG so I can also send dmesg traces if anyone can analyze them. Thanks in advance for your help, -- Ivan Zaera http://www.factoria2.com/desde/correo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: network deamons starting before network!
On 19/06/2010 11:06, Mark Stapper wrote: > On 06/18/10 12:20, Alfred Bartsch wrote: > >> Mark Stapper schrieb: >> >> >>> Hello, >>> >>> Since updating to 8.X I noticed that network services were started >>> before the network was up! >>> I use lagg failover configuration on both my FreeBSD boxes. >>> First, boot fails on mounting my nfs-shares. >>> After entering and exiting the "rescue" shell, the system boots as normal. >>> >>> >> Hello, >> >> adding: >> synchronous_dhclient="YES" >> to /etc/rc.conf solved some similar issues for me. >> The default behaviour of getting an IP via dhcp has changed. >> >> > I'll try that too. > That would explain why I didn't have this problem on 7.2 > I DO like the whole netwait idea though. > But for me, the synchronous_dhclient flag should be sufficient I think. > > Worked like a charm! Thank you again Regards, Mark signature.asc Description: OpenPGP digital signature
help
; irq 22 at device 2.0 on pci2 > bwn0 on siba_bwn0 > bwn0: WLAN (chipid 0x4318 rev 9) PHY (analog 3 type 2 rev 7) RADIO (manuf > 0x17f ver 0x2050 rev 8) > bwn0: DMA (32 bits) > bwn0: [FILTER] > wlan0: Ethernet address: 00:11:50:d0:2f:6f > bwn0: firmware version (rev 410 patch 2160 date 0x751a time 0x7c0a) > wlan0: ieee80211_new_state_locked: pending INIT -> SCAN transition lost > wlan0: link state changed to UP > bwn0: need multicast update callback > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > bwn0: RX decryption attempted (old 0 keyidx 0) > > Also, when I start tcpdump on wlan0, and try to ping this computer from > another one, I see all the ping requests and responses on FreeBSD, but > the other computer don't get any response. > > Does anyone knows what to do now ? > > Regards, > > Quentin Stievenart. > > > -- > > Message: 3 > Date: Mon, 21 Jun 2010 01:10:57 -0400 (Eastern Daylight Time) > From: "Brian Seklecki (Mobile)" > Subject: Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT > on PowerEdge 1850 > To: Jack Vogel > Cc: Brandon Gooch , freebsd-stable > , Jeremy Chadwick > > Message-ID: > Content-Type: text/plain; charset=us-ascii; format=flowed > > > > On Fri, 18 Jun 2010, Jack Vogel wrote: > >> Yes, the commits today are slated to get into 8.1, at least that's my >> understanding. > > Lets hope so; its looking very promising on the systems I'm able to test > on. > > We should ask 82541EI and Dell 9th gen PowerEdge users to test them right > away. > > ~BAS > > > -- > > Message: 4 > Date: Mon, 21 Jun 2010 09:21:07 +0200 > From: Iv?n Zaera Avell?n > Subject: Problems with EeePC 1005HA wireless (Wireless Atheros 9285) > To: freebsd-stable@freebsd.org > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > I'm new to the list, so hello everybody and pleased to meet you all. > > I have installed the recent 8.1 BETA 1 on an Eee PC 1005HA and I'm > experiencing problems > with the wireless card. It is correctly recognized and configured. I have an > ath0 device and I > can create an wlan0 without problems. I can even scan with wlan0 and > sometimes I see my > wireless router. The problem is when wpa_supplicant tries to register with > the network that it > fails. BTW, I have a WEP system with long key (13 hex digits). > > I have sniffed the wireless network with another computer and the packets > seem to be all > correct: the Eee PC sends correct packets to the air, and the wifi router > replies them correctly, > but wpa_supplicant reports "registration timed out", as if it wasn't > receiving the packets. > > It is nevertheless very strange because around 2-3 weeks ago I had the > STABLE branch installed > on the same Eee PC and the wifi worked (not always, but it succedeed always > when it was near > the router and the PC was just being rebooted). > > Does anybody experience the same problem or has any hint on what could be > happening? > > I have compiled my kernel with AH_DEBUG and ATH_DEBUG so I can also send > dmesg traces > if anyone can analyze them. > > Thanks in advance for your help, > -- > Ivan Zaera > http://www.factoria2.com/desde/correo > > > -- > > Message: 5 > Date: Mon, 21 Jun 2010 13:46:16 +0200 > From: Mark Stapper > Subject: Re: network deamons starting before network! > To: Alfred Bartsch > Cc: freebsd-stable@freebsd.org > Message-ID: <4c1f5108.8080...@mapper.nl> > Content-Type: text/plain; charset="utf-8" > > On 19/06/2010 11:06, Mark Stapper wrote: >> On 06/18/10 12:20, Alfred Bartsch wrote: >> >>> Mark Stapper schrieb: >>> >>> >>>> Hello, >>>> >>>> Since updating to 8.X I noticed that network services were started >>>> before the network was up! >>>> I use lagg failover configuration on both my FreeBSD boxes. >>>> First, boot fails on mounting my nfs-shares. >>>> After entering and exiting the "rescue" shell, the system boots as normal. >>>> >>>> >>> Hello, >>> >>> adding: >>> synchronous_dhclient="YES" >>> to /etc/rc.conf solved some similar issues for me. >>> The default behaviour of getting an IP via dhcp has changed. >>> >>> >> I'll try that too. >> That would explain why I didn't have this problem on 7.2 >> I DO like the whole netwait idea though. >> But for me, the synchronous_dhclient flag should be sufficient I think. >> >> > Worked like a charm! > Thank you again > Regards, > Mark > > -- next part -- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 260 bytes > Desc: OpenPGP digital signature > Url : > http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20100621/f92b75e9/signature-0001.pgp > > -- > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > End of freebsd-stable Digest, Vol 362, Issue 1 > ** > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.2-RELEASE-p4, IO errors & RAID1 failure
Hello Jeremy. I just wondered if you had any further thoughts on the
info below. Two new disks arrived over the weekend and I'm still unsure
if I'm best to replace ad0 or not...
Much appreciated indeed.
-- Matt
On Fri, 2010-06-18 at 20:28 +0100, Matthew Lear wrote:
> On Fri, 2010-06-18 at 10:42 -0700, Jeremy Chadwick wrote:
> > On Fri, Jun 18, 2010 at 04:47:11PM +0100, Matthew Lear wrote:
> > > Hello Jeremy,
> > > Thanks very much for the feedback.
> > >
> > > [snip]
> > > > Could you please provide the full output from "smartctl -a /dev/ad0"
> > > > here? Your drive may be completely fine and you may not have to swap it
> > > > at all; hard to say.
> > >
> > > Sure. See below:
> > > {snip}
> >
> > Your SMART statistics look completely OK. There's nothing there that
> > indicates there were any write failures or otherwise. I'll explain near
> > the end of the Email how to test a range of LBAs "just in case".
>
> Good. That's what I thought too :-)
>
> > I'll take a moment to point out that the error previously seen was a
> > timeout during a write transaction (WRITE_DMA48). Recap:
> >
> > > > > ad0: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=395032335
> > > > > ad0: FAILURE - WRITE_DMA48 status=51
> > > > > error=10 LBA=395032335
> > > > > ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode
> >
> > The status codes shown (status=51 and error=10) are hexadecimal. I'm
> > pointing this out because they aren't preceded by '0x' or '$' and it
> > clarifies my next point:
> >
> > NID_NOT_FOUND (bit 4 set in the ATA error field) is referred to as IDNF
> > per ATA6-ACS specification and onward, so I'll refer to it as that.
> > (I've always wondered why FreeBSD calls this NID_NOT_FOUND; IDFN stands
> > for ID Not Found, so what's with the extra "N"? I've always felt this
> > is a typo...)
> >
> > Using the ATA8-ACS specification working draft (2007/05/21), since it's
> > more recent, we see the following:
> >
> > Section 6.2 - Error field
> > Section 6.2.4 - ID Not Found (IDNF) bit
> >
> > Error bit 4. The IDNF bit shall be set to one if a user-accessible
> > address was not found. The IDNF bit shall be set to one if an
> > address outside of the range of user-accessible addresses is
> > requested when command aborted is not returned (see 4.11.3 and
> > 6.2.1).
> >
> > Section 4.11 - Host Protected Area (HPA) feature set
> > Section 4.11.3 - 28-bit and 48-bit HPA commands
> >
> > Any read or write command to an address above the maximum address
> > specified by the SET MAX ADDRESS or SET MAX ADDRESS EXT command shall
> > cause command completion with the IDNF bit set to one and ERR set to
> > one, or command aborted.
> >
> > There's no definition of what "address" means in 6.2.4, but the most
> > logical (pun intended) guess is an LBA. This error is returned by the
> > disk (e.g. not a controller-induced error). I've mentioned this problem
> > in the past:
> >
> > http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting
> >
> > I've always read IDNF to mean "OS requested access (read or write) to an
> > LBA which is out of bounds", where "out of bounds" means "not between 0
> > and ". How exactly is that possible? Alexander, do you have
> > any familiarity with this error code per ATA spec?
> >
> > Matthew, can you provide output from "atacontrol cap ad0"? Thanks.
>
> Sure thing. See below.
> [r...@meshuga /home/matt]# atacontrol cap ad0
>
> Protocol SATA revision 2.x
> device model WDC WD3200AAKS-00VYA0
> serial number WD-WCARW0164427
> firmware revision 12.01B02
> cylinders 16383
> heads 16
> sectors/track 63
> lba supported 268435455 sectors
> lba48 supported 625142448 sectors
> dma supported
> overlap not supported
>
> Feature Support EnableValue Vendor
> write cacheyesyes
> read ahead yesyes
> Native Command Queuing (NCQ) yes - 31/0x1F
> Tagged Command Queuing (TCQ) no no 31/0x1F
> SMART yesyes
> microcode download yesyes
> security yesno
> power management yesyes
> advanced power management no no 0/0x00
> automatic acoustic management yesno 254/0xFE128/0x80
> [r...@meshuga /home/matt]#
>
>
> >
> > Now regarding the LBA tests -- "smartctl -t select,start-end" will do
> > the trick. start should be a starting LBA, end should be an ending LBA.
> > The OS claims that LBA 395032335 is what was requested to be accessed
> > when the failure happened, so I would recommend picking start/end ranges
> > around that area. Remember that a single sector encapsulates a very
> > large number of blocks (especially given sizes of disks today), so it's
> > wise to pick a very large range of LBAs. I would recommend this in
Re: if_em problems, both 7 and 8-stable
On 06/19/2010 08:26 PM, Brandon Gooch wrote:
> On Sat, Jun 19, 2010 at 5:28 PM, Pete Carah wrote:
>
>> I cannot successfully create a vlan on if_em on either releng 7 or releng 8;
>> I have seen a patch for part of
>> the problem (checksum offsets end up incorrect) but not all. Even turning
>> off ALL hw_xxx flags leaves one
>> unacceptable bug - the interface gets hard-reset any time you add or delete
>> a vlan. I *know* that cisco
>> uses these interfaces without these problems, so it has to be possible. I
>> have used vlans in linux without
>> appearing to get the same problems, though I'm not sure the rest of the
>> configuration matches.
>>
>> What gives, especially since the patch for one of the problems (wrong
>> checksum offsets) was generated
>> about 6 months ago...
>>
>> We are trying to use an intel platform as a router; this is a show-stopper.
>> I could try linux though I prefer not to...
>>
> Would it be possible for you to provide more details about the
> hardware and software setup? The Intel chip and the revision (or
> relevant CVS info) about the builds of 7-RELENG and 8-RELENG would be
> useful, perhaps the dmesg of the machine and output of `pciconf -lv`?
>
> For what it's worth, I'm using vlans on an "Intel 82566DM Gigabit
> Ethernet Adapter (82566DM)", on-board in my Dell Optiplex 755, all
> hardware options on...
>
825{5,6,7,8,9}x and 8254x (ours are 82546EB) are totally different
animals. The bug we see
is definitely there for 54x; we are not the only ones seeing it - look
back in the stable
and net mailing-list archives for last December, a patch was sent in
back then and never
applied to the main tree, even -current. See PR's
kern-141285
kern-141843
kern-146358 (likely related since it seems the same as 141843)
and perhaps a couple more. All of those are still open and marked as
not yet
patched as of a half-hour ago.
Also, the patch (for 141285; the author thinks it fixes 141843 also) as
sent fixes some of
the offload problems but not all.
The problem with the interface resetting on vlan creation is there for
*all* if_em devices
and is independent of enabling hardware offloads; it causes a one or two
second pause in
forwarding (longer if you are connected to a Cisco without portfast, and
their newer
switches don't allow portfast on trunk ports); doesn't appear too
serious until you realize
how many packets per second one of these guys forwards in router service
- this is a LOT of
dropped packets. My reading of the reset code is such that once vlan
service is enabled then
there might well be problems on untagged packets sent out that same
interface (not a problem
in our network but we don't have any 3com switches which REQUIRE
untagged management)
I have successful vlan networks running on sis, fxp, and vr interfaces
with absolutely no
problems (well, vr in fbsd 6 required a patch to up the receive buffer
size, but 7 and later
is fine with all of these out of the box.)
-- Pete
> $ ifconfig em0
> em0: flags=8843 metric 0 mtu 1500
>
> options=219b
> ether 00:1e:4f:d5:84:b7
> inet 10.7.0.7 netmask 0xff00 broadcast 10.255.255.255
> media: Ethernet autoselect (1000baseT )
> status: active
>
> -Brandon
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
