Re: My WLI-UC-GNM up crash
Last night, I use the latest FreeBSD source (r253827) and
crochet-freebsd compile img
My WLI-UC-GNM will be disconnected after a period of operation
run0: device timeout
run0: at uhub0, port 1, addr 2 (disconnected)
Another log prompted
ti_mmchs0: Error: current cmd NULL, already done?
My BB-Black broken?
--
Regards.
By: XiaoQI Ge; PGP:8B09D5F7
WWW: https://www.7axu.com/
2013/7/30 Ian Lepore i...@freebsd.org:
On Mon, 2013-07-29 at 14:15 -0700, John-Mark Gurney wrote:
Hans Petter Selasky wrote this message on Mon, Jul 29, 2013 at 19:58 +0200:
The aligned will make sure that the structure gets padded properly to the
size specified. Only on ARM/MIPS etc, structures get automatically aligned
according to the element in the structure requiring the greatest
alignment. I've test-compiled the USB WLAN drivers, and the aligned makes
a difference. The problem is that the radiotap header skews some following
elements, so that they are no longer aligned. The radiotap header itself
is packed, and this is not a problem.
Ouch, has anyone looked at the code that caused this?
in ieee80211_radiotap.c, it looks like the original fault was in either
set_channel, or set_xchannel, and both do (the equivalent of):
struct {
uint16_tfreq;
uint16_tflags;
} *rc = p;
rc-freq = htole16(c-ic_freq);
rc-flags = htole16(c-ic_flags);
If there's any chance the pointer isn't aligned in code like this, then
htole16() is the wrong function, it should be using le16enc() such as
le16enc(rc-freq, c-ic_freq);
le16enc(rc-flags, c-ic_flags);
With any luck, an x86 compiler can optimize the inline code for the
endian enc/dec functions to take advantage of the platform's ability to
do unaligned accesses. But that's a side issue to code correctness --
portable code has to get these things right even when it's inefficient.
-- Ian
And then there is complicated code that calculates offsets, etc, in
radiotap_offset.. What we probably really need is to mark the above
as __packed or equiv so that we don't assume that the passed in pointer
is aligned...
The whole management of this radiochan and radiotap_offset is pretty
nasty... If marking the structures __packed works, it's probably
because two bugs are offsetting, and magicly making things align
again...
-Original message-
From:Warner Losh i...@bsdimp.com mailto:i...@bsdimp.com
Sent: Monday 29th July 2013 17:04
To: Adrian Chadd adr...@freebsd.org mailto:adr...@freebsd.org
Cc: Hans Petter Selasky hans.petter.sela...@bitfrost.no
mailto:hans.petter.sela...@bitfrost.no ; freebsd-arm
freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org ;
freebsd-wireless@freebsd.org mailto:freebsd-wireless@freebsd.org
Subject: Re: My WLI-UC-GNM up crash
Aren't structures already aligned to 4 bytes when placed inside other
structures (unless marked __packed)?
Warner
On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote:
As long as that results in the radiotap structures being 4 or 8 byte
padded when it's embedded in the softc - then yes, indeed.
Xiao, can you try?
-adrian
On 28 July 2013 03:35, Hans Petter Selasky h...@bitfrost.no
mailto:h...@bitfrost.no wrote:
Hi,
Can you try the attached patch?
--HPS
___
freebsd-...@freebsd.org mailto:freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to freebsd-arm-unsubscr...@freebsd.org
mailto:freebsd-arm-unsubscr...@freebsd.org
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to freebsd-arm-unsubscr...@freebsd.org
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to freebsd-arm-unsubscr...@freebsd.org
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
RE: Wifi rates
Hello, Right, there's HT elements in there, so it looks likely you properly negotiated HT. And the amrr output : Test kernel: wlan0: [00:24:d4:97:80:20] amrr_node_init: non-11n node Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: nrates=0, initial rate 0 That's the initial I don't know what you are yet selection. Test kernel: wlan0: [00:24:d4:97:80:20] amrr_node_init: 11n node Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: nrates=16, initial rate 128 Here it negotiated 11n. The initial rate is 0x80, so MCS 0. I made progress : Jul 31 14:59:40 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 14:59:48 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 14:59:50 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 14:59:59 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:01 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:02 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=158, retrycnt=0 Jul 31 15:00:02 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=255, retrycnt=0 Jul 31 15:00:03 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=260, retrycnt=4 Jul 31 15:00:03 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=160, retrycnt=0 Jul 31 15:00:04 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=132, retrycnt=0 Jul 31 15:00:04 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=213, retrycnt=0 Jul 31 15:00:05 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=203, retrycnt=0 Jul 31 15:00:05 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=214, retrycnt=0 Jul 31 15:00:06 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=186, retrycnt=1 Jul 31 15:00:06 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=216, retrycnt=2 Jul 31 15:00:07 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=243, retrycnt=1 Jul 31 15:00:08 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=185, retrycnt=0 Jul 31 15:00:08 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=122, retrycnt=0 Jul 31 15:00:09 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=133, retrycnt=0 Jul 31 15:00:09 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=185, retrycnt=2 Jul 31 15:00:10 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=165, retrycnt=0 Jul 31 15:00:11 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=114, retrycnt=0 Jul 31 15:00:28 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:29 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=227, retrycnt=0 Jul 31 15:00:29 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=255, retrycnt=0 Jul 31 15:00:30 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=241, retrycnt=0 Jul 31 15:00:30 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=99, retrycnt=0 Jul 31 15:00:31 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=199, retrycnt=0 Jul 31 15:00:31 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=111, retrycnt=2 Jul 31 15:00:32 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=171, retrycnt=0 Jul 31 15:00:33 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=210, retrycnt=3 Jul 31 15:00:33 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=122, retrycnt=1 Jul 31 15:00:34 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=218, retrycnt=0 Jul 31 15:00:35 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=95, retrycnt=1 Jul 31 15:00:43 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:44 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=22, retrycnt=0 Jul 31 15:01:56 Test kernel: wlan0: [60:36:dd:93:34:56] amrr_node_init: non-11n node Jul 31 15:01:56 Test kernel: wlan0: [60:36:dd:93:34:56] AMRR: nrates=0, initial rate 0 File transfer is still chaotic but start well. I've done a TCP dump during transfer. It's seem that TCP window fill up and it's why transfer stop and speed going down. Sometime transfer restart, sometime just hang. Just to be sure: window size value in TCP packet is the window size available from emitter ? -adrian Cedric ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: My WLI-UC-GNM up crash
On Wed, 2013-07-31 at 16:28 +0800, XiaoQI Ge wrote: Last night, I use the latest FreeBSD source (r253827) and crochet-freebsd compile img My WLI-UC-GNM will be disconnected after a period of operation run0: device timeout run0: at uhub0, port 1, addr 2 (disconnected) Another log prompted ti_mmchs0: Error: current cmd NULL, already done? My BB-Black broken? The ti_mmchs0 error is not new. My old BBW has done that for months. I'm not sure it's totally harmless, but it's not related to the run0 timeouts. -- Ian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Wifi rates
Hi, Let's merge some more stuff into -HEAD first. it's likely there's some RF configuration problem which we can dig into in more detail but I can't do it whilst we've got broken Intel 5100 support (as then MY laptop doesn't work!) I have a spectrum analyser and I'm not afraid to use it. -adrian On 31 July 2013 06:36, Cedric GROSS c...@cgross.info wrote: Hello, Right, there's HT elements in there, so it looks likely you properly negotiated HT. And the amrr output : Test kernel: wlan0: [00:24:d4:97:80:20] amrr_node_init: non-11n node Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: nrates=0, initial rate 0 That's the initial I don't know what you are yet selection. Test kernel: wlan0: [00:24:d4:97:80:20] amrr_node_init: 11n node Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: nrates=16, initial rate 128 Here it negotiated 11n. The initial rate is 0x80, so MCS 0. I made progress : Jul 31 14:59:40 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 14:59:48 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 14:59:50 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 14:59:59 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:01 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:02 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=158, retrycnt=0 Jul 31 15:00:02 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=255, retrycnt=0 Jul 31 15:00:03 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=260, retrycnt=4 Jul 31 15:00:03 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=160, retrycnt=0 Jul 31 15:00:04 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=132, retrycnt=0 Jul 31 15:00:04 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=213, retrycnt=0 Jul 31 15:00:05 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=203, retrycnt=0 Jul 31 15:00:05 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=214, retrycnt=0 Jul 31 15:00:06 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=186, retrycnt=1 Jul 31 15:00:06 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=216, retrycnt=2 Jul 31 15:00:07 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=243, retrycnt=1 Jul 31 15:00:08 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=185, retrycnt=0 Jul 31 15:00:08 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=122, retrycnt=0 Jul 31 15:00:09 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=133, retrycnt=0 Jul 31 15:00:09 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=185, retrycnt=2 Jul 31 15:00:10 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=165, retrycnt=0 Jul 31 15:00:11 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=114, retrycnt=0 Jul 31 15:00:28 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:29 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=227, retrycnt=0 Jul 31 15:00:29 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=255, retrycnt=0 Jul 31 15:00:30 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=241, retrycnt=0 Jul 31 15:00:30 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=99, retrycnt=0 Jul 31 15:00:31 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=199, retrycnt=0 Jul 31 15:00:31 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=111, retrycnt=2 Jul 31 15:00:32 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=171, retrycnt=0 Jul 31 15:00:33 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=210, retrycnt=3 Jul 31 15:00:33 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=122, retrycnt=1 Jul 31 15:00:34 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=218, retrycnt=0 Jul 31 15:00:35 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=95, retrycnt=1 Jul 31 15:00:43 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=11, retrycnt=0 Jul 31 15:00:44 Test kernel: wlan0: [00:24:d4:97:80:20] AMRR: current rate 15, txcnt=22, retrycnt=0 Jul 31 15:01:56 Test kernel: wlan0: [60:36:dd:93:34:56] amrr_node_init: non-11n node Jul 31 15:01:56 Test kernel: wlan0: [60:36:dd:93:34:56] AMRR: nrates=0, initial rate 0 File transfer is still chaotic but start well. I've done a TCP dump during transfer. It's seem that TCP window fill up and it's why transfer stop and speed going down. Sometime transfer restart,
Re: [IWN] Reviw split 2
Hi,
There's some more whitespace things to fix in your diff.
-
-bus_dmamap_sync(sc-rxq.data_dmat, data-map,
-BUS_DMASYNC_POSTREAD);
-DPRINTF(sc, IWN_DEBUG_ANY,
+...DPRINTF(sc, IWN_DEBUG_ANY,
%s: scanning channel %d status %x\n,
__func__, scan-chan, le32toh(scan-status));
.. notice how you've indented DPRINTF there? You should fix that. :)
+#ifdefIWN_DEBUG
+#define IWN_DESC(x) case x:...return #x
+#define COUNTOF(array) (sizeof(array) / sizeof(array[0]))
There should be a tab between the #define and the thing you're
defining, rather than a space.
+ * This function print firmawre register
.. typo, that should be firmware :)
+..};
+..DPRINTF(sc, IWN_DEBUG_REGISTER,
+CSR values: (2nd byte of IWN_INT_COALESCING is IWN_INT_PERIODIC)%s,
+\n);
+..for (i = 0; i COUNTOF(csr_tbl); i++){
.. there needs to be a tab in front of the two lines after the
DPRINTF(). Well, strictly speaking, there should be a tab (to bring it
to the same indent level) and then four spaces (as it's a continuation
of the line above it.)
Now, you're making IWN_DEBUG an option, right? Once you've done this,
I'll go make sure you can put it in the kernel config file as a build
option (and I'll enable it by default on i386/amd64.)
Thanks!
-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
RE: [IWN] Reviw split 2
-Message d'origine-
De : adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] De la part
de Adrian Chadd
Envoyé : mercredi 31 juillet 2013 17:08
À : Cedric GROSS
Cc : freebsd-wireless@freebsd.org
Objet : Re: [IWN] Reviw split 2
Hi,
There's some more whitespace things to fix in your diff.
-
-bus_dmamap_sync(sc-rxq.data_dmat, data-map,
-BUS_DMASYNC_POSTREAD);
-DPRINTF(sc, IWN_DEBUG_ANY,
+...DPRINTF(sc, IWN_DEBUG_ANY,
%s: scanning channel %d status %x\n,
__func__, scan-chan, le32toh(scan-
status));
.. notice how you've indented DPRINTF there? You should fix that. :)
Fixed.
+#ifdefIWN_DEBUG
+#define IWN_DESC(x) case x:...return #x #define COUNTOF(array)
+(sizeof(array) / sizeof(array[0]))
There should be a tab between the #define and the thing you're
defining, rather than a space.
Done.
+ * This function print firmawre register
.. typo, that should be firmware :)
Yep fixed.
+..};
+..DPRINTF(sc, IWN_DEBUG_REGISTER,
+CSR values: (2nd byte of IWN_INT_COALESCING is
IWN_INT_PERIODIC)%s,
+\n);
+..for (i = 0; i COUNTOF(csr_tbl); i++){
.. there needs to be a tab in front of the two lines after the
DPRINTF(). Well, strictly speaking, there should be a tab (to bring it
to the same indent level) and then four spaces (as it's a continuation
of the line above it.)
Fixed
Now, you're making IWN_DEBUG an option, right? Once you've done this,
I'll go make sure you can put it in the kernel config file as a build
option (and I'll enable it by default on i386/amd64.)
Yes, I think should be a good thing.
Thanks!
-adrian
register3.patch
Description: Binary data
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: Chenchong's work on net80211_ratectl
Boo! Do you have another update? -adrian On 24 July 2013 06:44, Adrian Chadd adr...@freebsd.org wrote: On 24 July 2013 06:38, Chenchong Qin qinchench...@gmail.com wrote: My pleasure! It's also against HEAD. Thanks! Ok. This is looking great! Next - we need to update the rate control API to now populate an rc array rather than just returning the rix. This is the tricky part - as we're going to have to modify all the drivers that use the rate control API to use this. Which is fine, as there's only a handful. It's just annoying. Then we have to provide the rate control information during frame _completion_, so the rate control code knows which transmission rates succeeded or failed. I'm still not sure what to do about it here. Maybe do something like Linux and attach TX rate control and completion information as an mbuf tag? _Then_ we can start doing interesting thing with it. :) -adrian ___ freebsd-wireless@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
Re: [IWN] Reviw split 2
Looks good! I'll commit this soon.
Thanks!
-adrian
On 31 July 2013 08:36, Cedric GROSS c...@cgross.info wrote:
-Message d'origine-
De : adrian.ch...@gmail.com [mailto:adrian.ch...@gmail.com] De la part
de Adrian Chadd
Envoyé : mercredi 31 juillet 2013 17:08
À : Cedric GROSS
Cc : freebsd-wireless@freebsd.org
Objet : Re: [IWN] Reviw split 2
Hi,
There's some more whitespace things to fix in your diff.
-
-bus_dmamap_sync(sc-rxq.data_dmat, data-map,
-BUS_DMASYNC_POSTREAD);
-DPRINTF(sc, IWN_DEBUG_ANY,
+...DPRINTF(sc, IWN_DEBUG_ANY,
%s: scanning channel %d status %x\n,
__func__, scan-chan, le32toh(scan-
status));
.. notice how you've indented DPRINTF there? You should fix that. :)
Fixed.
+#ifdefIWN_DEBUG
+#define IWN_DESC(x) case x:...return #x #define COUNTOF(array)
+(sizeof(array) / sizeof(array[0]))
There should be a tab between the #define and the thing you're
defining, rather than a space.
Done.
+ * This function print firmawre register
.. typo, that should be firmware :)
Yep fixed.
+..};
+..DPRINTF(sc, IWN_DEBUG_REGISTER,
+CSR values: (2nd byte of IWN_INT_COALESCING is
IWN_INT_PERIODIC)%s,
+\n);
+..for (i = 0; i COUNTOF(csr_tbl); i++){
.. there needs to be a tab in front of the two lines after the
DPRINTF(). Well, strictly speaking, there should be a tab (to bring it
to the same indent level) and then four spaces (as it's a continuation
of the line above it.)
Fixed
Now, you're making IWN_DEBUG an option, right? Once you've done this,
I'll go make sure you can put it in the kernel config file as a build
option (and I'll enable it by default on i386/amd64.)
Yes, I think should be a good thing.
Thanks!
-adrian
___
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to freebsd-wireless-unsubscr...@freebsd.org
