Re: swapping is completely broken in -CURRENT r334649?

[Kevin Lo]

On Fri, Jun 15, 2018 at 04:40:22AM -0400, Mark Johnston wrote:
> 
> On Fri, Jun 15, 2018 at 01:10:25PM +0800, Kevin Lo wrote:
> > On Tue, Jun 05, 2018 at 05:48:08PM -0400, Mark Johnston wrote:
> > > 
> > > On Wed, Jun 06, 2018 at 12:22:08AM +0300, Lev Serebryakov wrote:
> > > > On 05.06.2018 19:17, Gary Jennejohn wrote:
> > > > 
> > > > 
> > > > > I complained about this also and alc@ gave me this hint:
> > > > >   sysctl vm.pageout_update_period=0
> > > > 
> > > >  Really, situation is worse than stated in subject, because processes
> > > > are being killed AFTER memory pressure, when here are a lot of free
> > > > memory already!
> > > > 
> > > >  It looks like very serious bug.
> > > 
> > > The issue was identified earlier this week and is being worked on. It's
> > > a regression from r329882 which appears only on certain hardware. You
> > > can probably work around it by setting vm.pageout_oom_seq to a large
> > > value (try 1000 for instance), though this will make the "true" OOM
> > > killer take longer to kick in. The problem is unrelated to the
> > > pageout_update_period.
> > 
> > I have a large swap space and I've encountered this issue as well
> > 
> > pid 90707 (getty), uid 0, was killed: out of swap space
> > pid 90709 (getty), uid 0, was killed: out of swap space
> > pid 90709 (getty), uid 0, was killed: out of swap space
> > ...
> > 
> > Setting vm.pageout_oom_seq to 1000 doesn't help.  If you have a patch I'll 
> > be
> > happy to test it, thanks.
> 
> The change was committed as r334752.  Are you seeing unexpected OOM
> kills on or after that revision?

The box is running -CURRENT r334983.  I'll investigate further, thanks.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: swapping is completely broken in -CURRENT r334649?

[Kevin Lo]

On Tue, Jun 05, 2018 at 05:48:08PM -0400, Mark Johnston wrote:
> 
> On Wed, Jun 06, 2018 at 12:22:08AM +0300, Lev Serebryakov wrote:
> > On 05.06.2018 19:17, Gary Jennejohn wrote:
> > 
> > 
> > > I complained about this also and alc@ gave me this hint:
> > >   sysctl vm.pageout_update_period=0
> > 
> >  Really, situation is worse than stated in subject, because processes
> > are being killed AFTER memory pressure, when here are a lot of free
> > memory already!
> > 
> >  It looks like very serious bug.
> 
> The issue was identified earlier this week and is being worked on. It's
> a regression from r329882 which appears only on certain hardware. You
> can probably work around it by setting vm.pageout_oom_seq to a large
> value (try 1000 for instance), though this will make the "true" OOM
> killer take longer to kick in. The problem is unrelated to the
> pageout_update_period.

I have a large swap space and I've encountered this issue as well

pid 90707 (getty), uid 0, was killed: out of swap space
pid 90709 (getty), uid 0, was killed: out of swap space
pid 90709 (getty), uid 0, was killed: out of swap space
...

Setting vm.pageout_oom_seq to 1000 doesn't help.  If you have a patch I'll be
happy to test it, thanks.

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Kevin Lo]

On Wed, May 30, 2018 at 03:50:39PM +, Glen Barber wrote:
> Hi,
> 
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
> 
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
> 
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
> 
> Please help test, and report back (both successes and failures).

Tested memstick.img in both UEFI and legacy mode on :

Lenovo ThinkPad T430s
MSI Cubi 3 Silent

Both work for me.

> Thanks,
> 
> Glen

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Maintainershjip status regarding re(4) Ethernet driver?

[Kevin Lo]

On Sun, May 21, 2017 at 04:38:46AM +, Thomas Mueller wrote:
> 
> Who is the maintainer, if any, for re(4) Ethernet driver that is again giving 
> me trouble on Intel Ivy Bridge computer with MSI Z77 MPOWER motherboard?
> 
> I remember Kevin Lo, but have checked the web archives for freebsd-current 
> and freebsd-net, and find Kevin Lo's last posts were during October 2016.
> 
> Is Kevin Lo still with FreeBSD?
> 
> I just opened a bugzilla account with this Ethernet re(4) connectivity 
> problem on my mind.
> 
> I posted the details on this list five days ago but haven't had any response.

I have no idea why you cc'd me.  I'm not the maintainer of re(4).

> Tom

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ELF binary type "3" not known.

[Kevin Lo]

On Mon, Mar 20, 2017 at 09:11:44PM -0700, Chris H wrote:
> 
> On Mon, 20 Mar 2017 20:56:05 -0700 "Chris H"  wrote
> 
> > I'm not sure which of the two lists I'm directing
> > this to is the best/correct one. So I picked both.
> > 
> > To the point; I received this message during a big
> > build session. I was only able to catch the one from
> > x11/nvidia-driver in such a way as to actually get
> > the entire message:
> > 
> > Installing nvidia-driver-375.26_1...
> > ELF binary type "3" not known.
> > /bin/sh: /compat/linux/sbin/ldconfig: Exec format error
> > 
> > I built && installed emulators/linux_base-c7 *prior*
> > to installing this. This is on a:
> > 
> > FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314700:
> > Sun Mar 5 09:01:30 PST 2017 amd64
> Sorry. Forgot to add the ports revision.
> 
> revision 435383

Did you do kldload linux64 ?

> > 
> > Should I anticipate any problems? All and all, it seems
> > to work. But are there going to be some subtle repercussions?
> > 
> > Is this a 32bit-v-64bit problem with linux_base || the nvidia
> > blob?
> > 
> > Thanks.
> > 
> > --Chris

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

On Fri, Oct 14, 2016 at 03:03:41AM +0300, Andriy Voskoboinyk wrote:
> 
> Wed, 12 Oct 2016 07:34:15 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> 
> Thanks for testing! (I have got another one to simplify the process)
> Can you approve that current tree (master) works without any (new)  
> problems?

Sure.  For usb wireless adapters, they work quite well :)  Thanks.

> P.S. Known issue (present in the current driver too):
>   - the card ACKs only some frames that were sent using CCK rates
> (whilst sees all retransmissions - that can be seen in 'rx discard 'cuz  
> dup'
> counter via wlanstats)
> 
> > I tried to use https://github.com/s3erios/rtwn/tree/pci_modified,
> > still no luck.  BTW, there's a compilation error:  
> > http://pastebin.com/hCFfYVSj
> >
> > To ensure that the adapter is not faulty, I tested with the snapshots  
> > image
> > (FreeBSD-12.0-CURRENT-amd64-20160829-r305028-memstick.img), rtwn(4)  
> > works fine.
> >
> > Kevin
> >
> > On Tue, Oct 11, 2016 at 11:21:24PM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Tue, 11 Oct 2016 04:27:02 +0300 було написано Kevin Lo  
> >> <ke...@freebsd.org>:
> >>
> >> I have created 'pci_modified' branch to speed-up the process (RTL881*AU
> >> will
> >> not work with it for now); right now it contains (mostly) unmodified
> >> initialization path from rtwn(4) driver.
> >>
> >> If this version will work, I will revert some 'RTWN_PCI_WORKAROUND'
> >> temporary blocks until the culprit is found.
> >>
> >> > On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote:
> >> >>
> >> >> Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo
> >> >> <ke...@freebsd.org>:
> >> >>
> >> >> Hi!
> >> >
> >> > Hi Andriy,
> >> >
> >> >> Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ?
> >> >
> >> > I refreshed the tree and retested it, unfortunately it's still the  
> >> same.
> >> > Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog
> >> >>
> >> >> P.S. If Rx is still broken (status is always 0) try to execute
> >> >> 'ifconfig wlan0 promisc'
> >> >
> >> > It doesn't help either :(
> >>
> 
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

I tried to use https://github.com/s3erios/rtwn/tree/pci_modified, 
still no luck.  BTW, there's a compilation error: http://pastebin.com/hCFfYVSj

To ensure that the adapter is not faulty, I tested with the snapshots image
(FreeBSD-12.0-CURRENT-amd64-20160829-r305028-memstick.img), rtwn(4) works fine.

Kevin

On Tue, Oct 11, 2016 at 11:21:24PM +0300, Andriy Voskoboinyk wrote:
> 
> Tue, 11 Oct 2016 04:27:02 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> 
> I have created 'pci_modified' branch to speed-up the process (RTL881*AU  
> will
> not work with it for now); right now it contains (mostly) unmodified
> initialization path from rtwn(4) driver.
> 
> If this version will work, I will revert some 'RTWN_PCI_WORKAROUND'
> temporary blocks until the culprit is found.
> 
> > On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo  
> >> <ke...@freebsd.org>:
> >>
> >> Hi!
> >
> > Hi Andriy,
> >
> >> Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ?
> >
> > I refreshed the tree and retested it, unfortunately it's still the same.
> > Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog
> >>
> >> P.S. If Rx is still broken (status is always 0) try to execute
> >> 'ifconfig wlan0 promisc'
> >
> > It doesn't help either :(
> 
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

On Sat, Oct 08, 2016 at 02:18:54AM +0300, Andriy Voskoboinyk wrote:
> 
> Mon, 03 Oct 2016 03:55:23 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> 
> Hi!

Hi Andriy,

> Can you refresh the tree and retest it (dev.rtwn.0.debug=0x829f) ?

I refreshed the tree and retested it, unfortunately it's still the same.  
Here's the log: https://people.freebsd.org/~kevlo/rtl8188ce-debuglog
> 
> P.S. If Rx is still broken (status is always 0) try to execute
> 'ifconfig wlan0 promisc'

It doesn't help either :(

> > On Sun, Oct 02, 2016 at 10:15:49AM -0700, Adrian Chadd wrote:
> >>
> >> hi,
> >
> > Hi Adrian,
> >
> >> can you turn on debugging? Do you see RX frames?
> >
> > No Rx frames.  The log is pretty much the same one I sent on the list:
> > https://lists.freebsd.org/pipermail/freebsd-wireless/2016-September/007093.html
> >
> >> -a
> >
> > Thanks,
> > Kevin
> >
> >> On 1 October 2016 at 08:09, Kevin Lo <ke...@freebsd.org> wrote:
> >> > Strange, rtwn(4) stops working.  I tried to scan for the available  
> >> network,
> >> > but it just returns empty results.
> >> >
> >> > On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote:
> >> >>
> >> >> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo  
> >> <ke...@freebsd.org>:
> >> >>
> >> >> Few more questions:
> >> >> 1) does it work with h/w encryption support? (enabled by default)
> >> >> (if 'yes' - I will remove 'hardware crypto enabled' warning).
> >> >> 2) is there rate control support? (wlandebug -i wlan0 rate ; then  
> >> transmit
> >> >> something - if it works then AMRR will print it's current status
> >> >> periodically)
> >> >> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n)
> >> >> (see r92ce_adj_devcaps() in  
> >> sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c).
> >> >>
> >> >> > It works for me, thanks :)
> >> >> >
> >> >> > Kevin
> >> >> >
> >> >> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
> >> >> >>
> >> >> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo
> >> >> >> <ke...@freebsd.org>:
> >> >> >>
> >> >> >> Thanks for the log file,
> >> >> >>
> >> >> >> Tx 'device timeouts' should be fixed in
> >> >> >>  
> >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
> >> >> >> (currently I'm reviewing PCI-specific code to see if there are any
> >> >> >> additional
> >> >> >> issues - e.g., there are no Rx events in the log file).
> >> >> >>
> >> >> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk  
> >> wrote:
> >> >> >> >>
> >> >> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo
> >> >> >> >> <ke...@freebsd.org>:
> >> >> >> >>
> >> >> >> >> Hi,
> >> >> >> >>
> >> >> >> >> So, the driver was fully tested. Thanks!
> >> >> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how  
> >> big
> >> >> >> >> the problem is?
> >> >> >> >
> >> >> >> > Sure.  Here you go
> >> >> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
> >> >> >> >
> >> >> >> > Thanks,
> >> >> >> > Kevin
> >> >> >> >
> >> >> >> >> > Hi Andriy,
> >> >> >> >> >
> >> >> >> >> > First of all, THANK YOU!  You're doing amazing work!
> >> >> >> >> > Second, I've done some testing on the following devices,
> >> >> >> downloading
> >> >> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
> >> >> >> >> > ftp.freebsd.org:
> >> >> >> >> >
> >> >> >> >> > - ASUS USB-N10 NANO (RTL8188CUS):
> >> >> >> >> >   rtwn0:  >> 2.00/2.00,
> &

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

On Sun, Oct 02, 2016 at 10:15:49AM -0700, Adrian Chadd wrote:
> 
> hi,

Hi Adrian,

> can you turn on debugging? Do you see RX frames?

No Rx frames.  The log is pretty much the same one I sent on the list:
https://lists.freebsd.org/pipermail/freebsd-wireless/2016-September/007093.html

> -a

Thanks,
Kevin

> On 1 October 2016 at 08:09, Kevin Lo <ke...@freebsd.org> wrote:
> > Strange, rtwn(4) stops working.  I tried to scan for the available network,
> > but it just returns empty results.
> >
> > On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> >>
> >> Few more questions:
> >> 1) does it work with h/w encryption support? (enabled by default)
> >> (if 'yes' - I will remove 'hardware crypto enabled' warning).
> >> 2) is there rate control support? (wlandebug -i wlan0 rate ; then transmit
> >> something - if it works then AMRR will print it's current status
> >> periodically)
> >> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n)
> >> (see r92ce_adj_devcaps() in sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c).
> >>
> >> > It works for me, thanks :)
> >> >
> >> > Kevin
> >> >
> >> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
> >> >>
> >> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo
> >> >> <ke...@freebsd.org>:
> >> >>
> >> >> Thanks for the log file,
> >> >>
> >> >> Tx 'device timeouts' should be fixed in
> >> >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
> >> >> (currently I'm reviewing PCI-specific code to see if there are any
> >> >> additional
> >> >> issues - e.g., there are no Rx events in the log file).
> >> >>
> >> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
> >> >> >>
> >> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo
> >> >> >> <ke...@freebsd.org>:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> So, the driver was fully tested. Thanks!
> >> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
> >> >> >> the problem is?
> >> >> >
> >> >> > Sure.  Here you go
> >> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
> >> >> >
> >> >> > Thanks,
> >> >> > Kevin
> >> >> >
> >> >> >> > Hi Andriy,
> >> >> >> >
> >> >> >> > First of all, THANK YOU!  You're doing amazing work!
> >> >> >> > Second, I've done some testing on the following devices,
> >> >> downloading
> >> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
> >> >> >> > ftp.freebsd.org:
> >> >> >> >
> >> >> >> > - ASUS USB-N10 NANO (RTL8188CUS):
> >> >> >> >   rtwn0:  >> >> addr
> >> >> >> > 3> on usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> >> >> >> >
> >> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU):
> >> >> >> >   rtwn0:  on
> >> >> >> > usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
> >> >> >> >
> >> >> >> > - D-Link DWA-131 (RTL8192CU):
> >> >> >> >   rtwn0:  >> >> addr
> >> >> >> > 3> on usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
> >> >> >> >
> >> >> >> > - TP-Link Archer T4U (RTL8812AU):
> >> >> >> >   rtwn0:  on
> >> >> >> > usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
> >> >> >> >
> >> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU):
> >> >> >> >   rtwn0: <802.11n WLAN Adapter> on usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
> >> >> >> >
> >> >> >> > - RTL8188CE

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

Strange, rtwn(4) stops working.  I tried to scan for the available network,
but it just returns empty results.

On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote:
> 
> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> 
> Few more questions:
> 1) does it work with h/w encryption support? (enabled by default)
> (if 'yes' - I will remove 'hardware crypto enabled' warning).
> 2) is there rate control support? (wlandebug -i wlan0 rate ; then transmit
> something - if it works then AMRR will print it's current status  
> periodically)
> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n)
> (see r92ce_adj_devcaps() in sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c).
> 
> > It works for me, thanks :)
> >
> > Kevin
> >
> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo  
> >> <ke...@freebsd.org>:
> >>
> >> Thanks for the log file,
> >>
> >> Tx 'device timeouts' should be fixed in
> >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
> >> (currently I'm reviewing PCI-specific code to see if there are any
> >> additional
> >> issues - e.g., there are no Rx events in the log file).
> >>
> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
> >> >>
> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo
> >> >> <ke...@freebsd.org>:
> >> >>
> >> >> Hi,
> >> >>
> >> >> So, the driver was fully tested. Thanks!
> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
> >> >> the problem is?
> >> >
> >> > Sure.  Here you go  
> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
> >> >
> >> > Thanks,
> >> > Kevin
> >> >
> >> >> > Hi Andriy,
> >> >> >
> >> >> > First of all, THANK YOU!  You're doing amazing work!
> >> >> > Second, I've done some testing on the following devices,  
> >> downloading
> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
> >> >> > ftp.freebsd.org:
> >> >> >
> >> >> > - ASUS USB-N10 NANO (RTL8188CUS):
> >> >> >   rtwn0:  >> addr
> >> >> > 3> on usbus0
> >> >> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> >> >> >
> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU):
> >> >> >   rtwn0:  on
> >> >> > usbus0
> >> >> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
> >> >> >
> >> >> > - D-Link DWA-131 (RTL8192CU):
> >> >> >   rtwn0:  >> addr
> >> >> > 3> on usbus0
> >> >> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
> >> >> >
> >> >> > - TP-Link Archer T4U (RTL8812AU):
> >> >> >   rtwn0:  on
> >> >> > usbus0
> >> >> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
> >> >> >
> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU):
> >> >> >   rtwn0: <802.11n WLAN Adapter> on usbus0
> >> >> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
> >> >> >
> >> >> > - RTL8188CE mini pcie:
> >> >> >   rtwn0:  port 0xd000-0xd0ff mem
> >> >> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1
> >> >> >   rtwn0: r92ce_attach: warning: hardware crypto enabled
> >> >> >   rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
> >> >> >
> >> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't work:
> >> >> >
> >> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used
> >> >> > rtwn0: device timeout
> >> >> >
> >> >> >   Kevin
> >> >> >
> >> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
> >> >> >>
> >> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
> >> >> >> <a...@freebsd.org>:
> >> >> >>
> >> >> >> Now it resides on https://github.com/s3erios/freebsd-rtwn  
> >> (integrated
> >> >> >> into 

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

It works for me, thanks :)

Kevin

On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
> 
> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> 
> Thanks for the log file,
> 
> Tx 'device timeouts' should be fixed in
> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
> (currently I'm reviewing PCI-specific code to see if there are any  
> additional
> issues - e.g., there are no Rx events in the log file).
> 
> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo  
> >> <ke...@freebsd.org>:
> >>
> >> Hi,
> >>
> >> So, the driver was fully tested. Thanks!
> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
> >> the problem is?
> >
> > Sure.  Here you go https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
> >
> > Thanks,
> > Kevin
> >
> >> > Hi Andriy,
> >> >
> >> > First of all, THANK YOU!  You're doing amazing work!
> >> > Second, I've done some testing on the following devices, downloading
> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
> >> > ftp.freebsd.org:
> >> >
> >> > - ASUS USB-N10 NANO (RTL8188CUS):
> >> >   rtwn0:  >> > 3> on usbus0
> >> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> >> >
> >> > - TP-Link TL-WN725N v2 (RTL8188EU):
> >> >   rtwn0:  on
> >> > usbus0
> >> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
> >> >
> >> > - D-Link DWA-131 (RTL8192CU):
> >> >   rtwn0:  >> > 3> on usbus0
> >> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
> >> >
> >> > - TP-Link Archer T4U (RTL8812AU):
> >> >   rtwn0:  on
> >> > usbus0
> >> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
> >> >
> >> > - D-Link DWA-171 rev A1 (RTL8821AU):
> >> >   rtwn0: <802.11n WLAN Adapter> on usbus0
> >> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
> >> >
> >> > - RTL8188CE mini pcie:
> >> >   rtwn0:  port 0xd000-0xd0ff mem
> >> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1
> >> >   rtwn0: r92ce_attach: warning: hardware crypto enabled
> >> >   rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
> >> >
> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't work:
> >> >
> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used
> >> > rtwn0: device timeout
> >> >
> >> >  Kevin
> >> >
> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
> >> >>
> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
> >> >> <a...@freebsd.org>:
> >> >>
> >> >> Now it resides on https://github.com/s3erios/freebsd-rtwn (integrated
> >> >> into src tree, so it can be built with 'make buildkernel' / 'make
> >> >> buildworld').
> >> >>
> >> >> This the last stage; once all reported issues will be resolved, I'm
> >> >> going to merge it into HEAD.
> >> >>
> >> >> > Hi everyone,
> >> >> >
> >> >> > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were  
> >> merged
> >> >> > into a
> >> >> > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the  
> >> code is
> >> >> > available on https://github.com/s3erios/rtwn repository. Among
> >> >> bugfixes /
> >> >> > code deduplication, there some new features too:
> >> >> >
> >> >> > 1) multi-vap support (one any wireless interface + one STA  
> >> interface +
> >> >> > any number of monitor mode interfaces).
> >> >> > 2) few new sysctls:
> >> >> >   * dev.rtwn.#.crypto - controls how to use hardware crypto
> >> >> acceleration
> >> >> >   * dev.rtwn.#.ratectl_selected
> >> >> >   * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
> >> >> > (currently only 'none' and 'net80211' are supported; RTL8192CE  
> >> needs
> >> >> > testing
> >> >> > with the last).
> >> >> > 3) (incomplete) power managem

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
> 
> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo <ke...@freebsd.org>:
> 
> Hi,
> 
> So, the driver was fully tested. Thanks!
> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
> the problem is?

Sure.  Here you go https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt

Thanks,
Kevin

> > Hi Andriy,
> >
> > First of all, THANK YOU!  You're doing amazing work!
> > Second, I've done some testing on the following devices, downloading
> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from  
> > ftp.freebsd.org:
> >
> > - ASUS USB-N10 NANO (RTL8188CUS):
> >   rtwn0:  > 3> on usbus0
> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> >
> > - TP-Link TL-WN725N v2 (RTL8188EU):
> >   rtwn0:  on  
> > usbus0
> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
> >
> > - D-Link DWA-131 (RTL8192CU):
> >   rtwn0:  > 3> on usbus0
> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
> >
> > - TP-Link Archer T4U (RTL8812AU):
> >   rtwn0:  on  
> > usbus0
> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
> >
> > - D-Link DWA-171 rev A1 (RTL8821AU):
> >   rtwn0: <802.11n WLAN Adapter> on usbus0
> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
> >
> > - RTL8188CE mini pcie:
> >   rtwn0:  port 0xd000-0xd0ff mem  
> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1
> >   rtwn0: r92ce_attach: warning: hardware crypto enabled
> >   rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
> >
> > All seems to be ok, except RTL8188CE PCIe adapter doesn't work:
> >
> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used
> > rtwn0: device timeout
> >
> > Kevin
> >
> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
> >> <a...@freebsd.org>:
> >>
> >> Now it resides on https://github.com/s3erios/freebsd-rtwn (integrated
> >> into src tree, so it can be built with 'make buildkernel' / 'make
> >> buildworld').
> >>
> >> This the last stage; once all reported issues will be resolved, I'm
> >> going to merge it into HEAD.
> >>
> >> > Hi everyone,
> >> >
> >> > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged
> >> > into a
> >> > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
> >> > available on https://github.com/s3erios/rtwn repository. Among  
> >> bugfixes /
> >> > code deduplication, there some new features too:
> >> >
> >> > 1) multi-vap support (one any wireless interface + one STA interface +
> >> > any number of monitor mode interfaces).
> >> > 2) few new sysctls:
> >> >   * dev.rtwn.#.crypto - controls how to use hardware crypto  
> >> acceleration
> >> >   * dev.rtwn.#.ratectl_selected
> >> >   * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
> >> > (currently only 'none' and 'net80211' are supported; RTL8192CE needs
> >> > testing
> >> > with the last).
> >> > 3) (incomplete) power management support for RTL8188EU (requires
> >> > firmware).
> >> > 4) Short Guard Interval support.
> >> >
> >> > It's known to work with RTL8188CUS, RTL8188EU and RTL8821AU; however,
> >> > it was never tested with RTL8192CE or RTL8812AU.
> >> >
> >> > How-to-build:
> >> > 1) download / checkout the repository.
> >> > 2) apply 'patch-usbdevs.diff' against '/usr/src'
> >> > 3) build and install rtwn module:
> >> > cd $repository/sys/modules/rtwn && make && make install
> >> > 4) build and install rtwn_usb/rtwn_pci:
> >> > cd ../rtwn_usb && make && make install
> >> > cd ../rtwn_pci && make && make install
> >> > 5) unload previous && load current drivers:
> >> > kldunload if_urtwn if_rtwn
> >> > kldload /boot/modules/if_rtwn.ko /boot/modules/if_rtwn_usb.ko
> >> > /boot/modules/if_rtwn_pci.ko
> >> > 6) Use.
> >> ___
> >> freebsd-wirel...@freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> >> To unsubscribe, send any mail to  
> >> "freebsd-wireless-unsubscr...@freebsd.org"
> >>
> 
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

Hi Andriy,

First of all, THANK YOU!  You're doing amazing work!
Second, I've done some testing on the following devices, downloading
FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from ftp.freebsd.org:

- ASUS USB-N10 NANO (RTL8188CUS):
  rtwn0:  on 
usbus0
  rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R

- TP-Link TL-WN725N v2 (RTL8188EU):
  rtwn0:  on usbus0
  rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R

- D-Link DWA-131 (RTL8192CU):
  rtwn0:  on 
usbus0
  rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R

- TP-Link Archer T4U (RTL8812AU):
  rtwn0:  on usbus0
  rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R

- D-Link DWA-171 rev A1 (RTL8821AU):
  rtwn0: <802.11n WLAN Adapter> on usbus0
  rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R

- RTL8188CE mini pcie:
  rtwn0:  port 0xd000-0xd0ff mem 0x9080-0x90803fff irq 
17 at device 0.0 on pci1
  rtwn0: r92ce_attach: warning: hardware crypto enabled
  rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R

All seems to be ok, except RTL8188CE PCIe adapter doesn't work:

rtwn0: r92ce_post_init: warning: net80211 ratectl is used
rtwn0: device timeout

Kevin

On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
> 
> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk  
> :
> 
> Now it resides on https://github.com/s3erios/freebsd-rtwn (integrated
> into src tree, so it can be built with 'make buildkernel' / 'make  
> buildworld').
> 
> This the last stage; once all reported issues will be resolved, I'm
> going to merge it into HEAD.
> 
> > Hi everyone,
> >
> > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged  
> > into a
> > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is
> > available on https://github.com/s3erios/rtwn repository. Among bugfixes /
> > code deduplication, there some new features too:
> >
> > 1) multi-vap support (one any wireless interface + one STA interface +
> > any number of monitor mode interfaces).
> > 2) few new sysctls:
> >   * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration
> >   * dev.rtwn.#.ratectl_selected
> >   * dev.rtwn.#.ratectl - selects current 'rate control' algorithm
> > (currently only 'none' and 'net80211' are supported; RTL8192CE needs  
> > testing
> > with the last).
> > 3) (incomplete) power management support for RTL8188EU (requires  
> > firmware).
> > 4) Short Guard Interval support.
> >
> > It's known to work with RTL8188CUS, RTL8188EU and RTL8821AU; however,
> > it was never tested with RTL8192CE or RTL8812AU.
> >
> > How-to-build:
> > 1) download / checkout the repository.
> > 2) apply 'patch-usbdevs.diff' against '/usr/src'
> > 3) build and install rtwn module:
> > cd $repository/sys/modules/rtwn && make && make install
> > 4) build and install rtwn_usb/rtwn_pci:
> > cd ../rtwn_usb && make && make install
> > cd ../rtwn_pci && make && make install
> > 5) unload previous && load current drivers:
> > kldunload if_urtwn if_rtwn
> > kldload /boot/modules/if_rtwn.ko /boot/modules/if_rtwn_usb.ko  
> > /boot/modules/if_rtwn_pci.ko
> > 6) Use.
> ___
> freebsd-wirel...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
> 
> 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Realtek MMC/MMCSD reader?

[Kevin Lo]

On Fri, Feb 19, 2016 at 11:25:45PM -0500, Gary Corcoran wrote:
> 
> On 2/19/2016 11:08 PM, Larry Rosenman wrote:
> > On 2016-02-19 22:05, Mehmet Erol Sanliturk wrote:
> >> On Fri, Feb 19, 2016 at 7:58 PM, Larry Rosenman  wrote:
> >>
> >>> Great.  Since I've never done that
> >>>
> >>> Any ideas of anyone that might be able to help?
> >>>
> >>> Or where to even start?
> >>>
> >>>
> >>>
> >>
> >>
> >> Perhaps
> >>
> >> https://www.nostarch.com/bsddrivers.htm
> >> FreeBSD Device Drivers
> >>
> >>
> >> ?
> >>
> >>
> >> Mehmet Erol Sanliturk
> >>
> >>
> > perhaps.  But I'd need an NDA with RealTek to get the chip specs, and I'm 
> > not sure I can do that working for Nokia during the day
> > as I do.
> >
> > I'd love for one of the current folks that do realtek stuff to look.
> Sometimes people look to see if Linux has a driver, and if so, you might be 
> able to get enough
> programming info from their driver to be able to write a FreeBSD driver, 
> without getting the
> full chip specs.

Or do a port of the OpenBSD's rtsx(4).

> Gary

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Realtek 8168/8111 if_re not working in current r295091

[Kevin Lo]

On Wed, Feb 03, 2016 at 08:57:01PM +0100, s@web.de wrote:
> 
> After updating -current at Jan, 31st (r295091) the Realtek ethernet device 
> driver of my Zotac ZBox RI323 mini pc seems to be broken: I can neither 
> connect to the host even though the interface is shown as active, nor can I 
> initiate connection from the host through re0.
> Reverting the kernel to my previous build -current r290151 (install date Nov 
> 1st, 2015) the re0 interface is working OK.
> 
> Looking through the svn logs regarding /head/sys/dev/re/if_re.c I supect, 
> that Revision 290566 might have someting to do with this and that I have to 
> include my Realtek Chipset to the exclusion list for "enabling RX/TX after 
> initial configuration (or viceversa; I am really confused here), but I havent 
> got a clue how; as I do not know how to find the right RL_HWREV_XXX flag for 
> my device.
> 
> dmesg shows RealTek 8168/8111 B/C/CP/D/DP/E/F/G PCIe Gigabit Ethernet and 
> pciconf -l -v re0 shows:
> re0@pci0:2:0:0: class=0x02 card=0x816819da chip=0x816810ec rev=0x07 
> hdr=0x00
> vendor = 'Realtek Semiconductor Co., Ltd.'
> device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
> 
> I am grateful for any suggestion towards a solution and I am willing (and 
> able) to assist by patching or debugging my kernel or giving further hw 
> information about my system.

Hmm, mine works fine.

# pciconf -l -v re1
re1@pci0:4:0:0: class=0x02 card=0x57531462 chip=0x816810ec rev=0x0c hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
class  = network
subclass   = ethernet

# dmesg |grep re1
re1:  port 
0xb000-0xb0ff mem 0x90604000-0x90604fff,0x9060-0x90603fff irq 19 at device 
0.0 on pci4
re1: Using 1 MSI-X message
re1: ASPM disabled
re1: Chip rev. 0x4c00
re1: MAC rev. 0x

> Regards, Stefan

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Kevin Lo]

On Tue, Dec 29, 2015 at 12:12:26PM +0200, Daniel Braniss wrote:
> 
> > On 29 Dec 2015, at 11:53, Hans Petter Selasky  wrote:
> > 
> > On 12/29/15 10:42, Daniel Braniss wrote:
> >> 
> >>> On 29 Dec 2015, at 11:33, Vladimir Botka  wrote:
> >>> 
> >>> Hi Danny,
> >>> 
> >>> On Tue, 29 Dec 2015 11:16:27 +0200
> >>> Daniel Braniss  wrote:
>  Hi All,
>  I have a working tp-link usb (realtek), but can’t get a d-link(also 
>  realtek) to work.
>  usbconfig:
>   ugen0.4:  at usbus0, cfg=0 md=HOST 
>  spd=HIGH (480Mbps) pwr=ON (500mA)
>  This is on a raspberry pi running a resent current.
>  cheers & season greetings,
>   danny
> >>> 
> >>> I've added freebsd-wireless list.
> >>> 
> >>> My 2 cents. It might be helpful to see more details about the adapters.
> >>> For example:
> >>> 
> >>> # usbconfig -u 0 -a 7 dump_device_desc
> >>> ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=0 md=HOST spd=HIGH
> >>> (480Mbps) pwr=ON (450mA)
> >>>  bLength = 0x0012
> >>>  bDescriptorType = 0x0001
> >>>  bcdUSB = 0x0200
> >>>  bDeviceClass = 0x  
> >>>  bDeviceSubClass = 0x
> >>>  bDeviceProtocol = 0x
> >>>  bMaxPacketSize0 = 0x0040
> >>>  idVendor = 0x148f
> >>>  idProduct = 0x5370
> >>>  bcdDevice = 0x0101
> >>>  iManufacturer = 0x0001  
> >>>  iProduct = 0x0002  <802.11 n WLAN>
> >>>  iSerialNumber = 0x0003  <1.0>
> >>>  bNumConfigurations = 0x0001
> >> 
> >> 
> >> so here it is:
> >> root@:~ # usbconfig -u 0 -a 4 dump_device_desc
> >> ugen0.4:  at usbus0, cfg=0 md=HOST 
> >> spd=HIGH (480Mbps) pwr=ON (500mA)
> >> 
> >>   bLength = 0x0012
> >>   bDescriptorType = 0x0001
> >>   bcdUSB = 0x0210
> >>   bDeviceClass = 0x  
> >>   bDeviceSubClass = 0x
> >>   bDeviceProtocol = 0x
> >>   bMaxPacketSize0 = 0x0040
> >>   idVendor = 0x2001
> >>   idProduct = 0x3319
> >>   bcdDevice = 0x0200
> >>   iManufacturer = 0x0001  
> >>   iProduct = 0x0002  
> >>   iSerialNumber = 0x0003  <00e04c01>
> >>   bNumConfigurations = 0x0001
> >> 
> >> thanks,
> >>danny
> >> 
> > 
> > Did you google the idVendor and idProduct values and see if Linux has a 
> > driver already?
> > 
> > —HPS
> > 
> 
> 
> https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c
>  
> 
> and look at line 216

Your device (D-Link DWA-131 rev E1) is rtl8192eu, which is not supported by
FreeBSD.

> danny

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Kevin Lo]

On Tue, Dec 29, 2015 at 03:02:35PM +0100, Hans Petter Selasky wrote:
> On 12/29/15 14:00, Daniel Braniss wrote:
> >
> >> On 29 Dec 2015, at 14:44, Hans Petter Selasky  wrote:
> >>
> >> On 12/29/15 13:36, Daniel Braniss wrote:
> >>>
> >>
> >> Until /etc/devd/usb.conf is regenerated, you'll need to manually load the 
> >> kernel module for urtwn. Did you do that?
> >>
> >> --HPS
> >>
> > ok, set if_urtwn_load=yes
> > and now I get:
> >
> > ugen0.4:  at usbus0
> > urtwn0:  on usbus0
> > urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
> > Fatal kernel mode data abort: 'Translation Fault (L1)' on write
> > trapframe: 0xda29fb88
> > FSR=0805, FAR=, spsr=6013
> > r0 =, r1 =, r2 =c0a72cb0, r3 =0165
> > r4 =c2cd, r5 =c0a86650, r6 =c2cd1a80, r7 =
> > r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20
> > r12=, ssp=da29fc18, slr=0004, pc =c0a3f7cc
> >
> > [ thread pid 13 tid 100045 ]
> > Stopped at  ieee80211_ifdetach+0x4c:str r0, [r1]
> > db>
> >
> > btw, as long as you are willing to help, I will keep testing,
> > in other words, i’m ok.
> 
> Hi Andriy,
> 
> Can you fix the crash above and verify this error patch?
> 
> Andriy:
> 
> After:
>  usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER);
> There is no need for:
>   usbd_transfer_drain(sc->sc_xfer[x]);

As I mentioned previously we don't support rtl8192eu.  One difference 
between those is the the number of endpoints and its addresses.

> --HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD64 disk1.iso dont create /home (/usr/home)

[Kevin Lo]

I hit this and poked bapt@ two weeks ago, he said he couldn't reproduce
this problem...

Kevin

On Thu, Aug 20, 2015 at 08:29:32PM -0700, Adrian Chadd wrote:
 
 I just hit this; i'll hit up gjb@ about it.
 
 
 -a
 
 
 On 20 August 2015 at 19:04, Outback Dingo outbackdi...@gmail.com wrote:
  On Fri, Aug 21, 2015 at 11:30 AM, Allan Jude allanj...@freebsd.org wrote:
 
  On 2015-08-20 21:04, Keynes Augusto wrote:
  
  
  
   The ISO (r286893/r284969) does not create the folder / home or /usr/home
  and the user created during installation disappears.
  
   All files em skel disappears too.
  
   Sorry my english, i use Google for translate.
  
   Keynes Deus
  
  
   ___
   freebsd-current@freebsd.org mailing list
   https://lists.freebsd.org/mailman/listinfo/freebsd-current
   To unsubscribe, send any mail to 
  freebsd-current-unsubscr...@freebsd.org
  
 
  Did you use UFS or ZFS?
 
  Normally the /home symlink is not created until you add the first user.
 
 
  and it still fails even then if you create a user during install
 
 
 
  --
  Allan Jude
 
 
  ___
  freebsd-current@freebsd.org mailing list
  https://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 ___
 freebsd-current@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn: ioctl[SIOCS80211, op=16, arg_len=0]: Invalid argument

[Kevin Lo]

On Tue, Aug 18, 2015 at 11:32:48AM +0300, Gleb Smirnoff wrote:
 
 On Tue, Aug 18, 2015 at 09:27:09AM +0100, Anton Shterenlikht wrote:
 A I'm trying to setup Asus USB-N10 nano wireless
 A adapter. I get:
 A 
 A urtwn0: vendor 0x0b05 product 0x17ba,
 A  class 0/0, rev 2.00/2.00, addr 1 on usbus0
 A urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
 A 
 A urtwn0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 2290
 A ether 1c:87:2c:c7:c2:6e
 A nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
 A media: IEEE 802.11 Wireless Ethernet autoselect (autoselect)
 A status: no carrier
 A 
 A # wpa_supplicant -i urtwn0 -c /etc/wpa_supplicant.conf
 A Successfully initialized wpa_supplicant
 A ioctl[SIOCS80211, op=16, arg_len=0]: Invalid argument
 A urtwn0: Failed to initialize driver interface
 A ELOOP: remaining socket: sock=4 eloop_data=0x801c11600
 A  user_data=0x801c2c100 handler=0x422dd0 
 A 
 A # cat /boot/loader.conf
 A kern.vty=vt
 A linux_load=YES
 A #cuse4bsd_load=YES
 A if_urtwn_load=YES
 A legal.realtek.license_ack=1
 A 
 A # uname -a
 A FreeBSD rat 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r286741:
 A  Thu Aug 13 22:13:28 BST 2015
 A   root@rat:/usr/obj/usr/src/sys/GENERIC  amd64
 
 You need to create a wlan(4) interface and run wpa_supplicant on it.
 
 https://www.freebsd.org/doc/en/books/handbook/network-wireless.html

You also have to run kldload urtwn-rtl8192cfwT or add this to
/boot/loader.conf:

urtwn-rtl8192cfwT_load=YES

The latter will require a reboot to take effect.

 -- 
 Totus tuus, Glebius.

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: urtwn: ioctl[SIOCS80211, op=16, arg_len=0]: Invalid argument

[Kevin Lo]

On Tue, Aug 18, 2015 at 10:17:39AM +0100, Anton Shterenlikht wrote:
 From ke...@ns.kevlo.org Tue Aug 18 09:59:59 2015
 
  A urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
  
  You need to create a wlan(4) interface and run wpa_supplicant on it.
 
 ok, my bad, sorry.
 
 You also have to run kldload urtwn-rtl8192cfwT or add this to
 /boot/loader.conf:
 
 urtwn-rtl8192cfwT_load=YES
 
 yes, missed that too.
 
 Shouldn't it be urtwn-rtl8188eufw_load=YES?

Nope.  Your device is RTL8188CU not RTL8188EU.

 Thank you
 
 Anton

Kevin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: converted urtw(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Thu, Jun 18, 2015 at 01:40:30PM +0300, Gleb Smirnoff wrote:
 
 On Thu, Jun 18, 2015 at 04:16:55PM +0800, Kevin Lo wrote:
 Kyou signed up as tester of urtw(4). I have converted urtw(4)
 K  and uploaded new patch at:
 K  
 K  https://reviews.freebsd.org/D2655
 K  
 K  Please try, report and update the project page.
 K  
 K  https://wiki.freebsd.org/projects/ifnet/net80211
 K  
 K  Thanks a lot for your help with the project.
 K 
 K After bringing interface up I'm getting:
 K http://i.imgur.com/XhOVJ68.jpg
 
 I've found the problem and updated the diff. Please test once more.
 
 Thanks for help! Without you the bug could leak into subversion.

Thank you Gleb.  urtw(4) works fine on amd64.

# dmesg |grep urtw
urtw0: vendor 0x0bda product 0x8187, class 0/0, rev 2.00/1.00, addr 2 on 
usbus4
urtw0: unknown RTL8187L type: 0x800
urtw0: rtl8187l rf rtl8225u hwrev none

One minor problem, I got an compiler error and this diff below fixes it.

--- D2655.diff.orig 2015-06-22 09:45:48.836385086 +0800
+++ D2655.diff  2015-06-22 09:47:56.121431950 +0800
@@ -10421,14 +10421,6 @@
struct urtw_vap *uvp = URTW_VAP(vap);
struct ieee80211_node *ni;
usb_error_t error = 0;
-@@ -1905,7 +1858,6 @@
-   default:
-   break;
-   }
--fail:
-   URTW_UNLOCK(sc);
-   IEEE80211_LOCK(ic);
-   return (uvp-newstate(vap, nstate, arg));
 @@ -1915,12 +1867,11 @@
  urtw_watchdog(void *arg)
  {

 
 -- 
 Totus tuus, Glebius.

Kevin
___
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: converted urtw(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Wed, Jun 17, 2015 at 11:28:55AM +0300, Gleb Smirnoff wrote:
 
   Hi Kevin,
 
   you signed up as tester of urtw(4). I have converted urtw(4)
 and uploaded new patch at:
 
 https://reviews.freebsd.org/D2655
 
 Please try, report and update the project page.
 
 https://wiki.freebsd.org/projects/ifnet/net80211
 
 Thanks a lot for your help with the project.

After bringing interface up I'm getting:
http://i.imgur.com/XhOVJ68.jpg

 -- 
 Totus tuus, Glebius.

Kevin
___
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: converted zyd(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Tue, Jun 16, 2015 at 07:34:36PM +0300, Gleb Smirnoff wrote:
 
   Hi Kevin,

Hi Gleb,

   you signed up as tester of zyd(4). I have converted zyd(4)
 and uploaded new patch at:
 
 https://reviews.freebsd.org/D2655
 
 Please try, report and update the project page.
 
 https://wiki.freebsd.org/projects/ifnet/net80211
 
 Thanks a lot for your help.

Works for me, thanks.

# dmesg |grep zyd
zyd0: SMC USB2.0 WLAN, rev 2.00/48.10, addr 2 on usbus4
zyd0: HMAC ZD1211B, FW 47.25, RF AL2230 S1, PA0 LED 0 BE0 NP1 Gain1 F0

# netstat -hI wlan0 1
input  wlan0   output
   packets  errs idrops  bytespackets  errs  bytes colls
   418   198 0   610K2122422K 0
   278   117 0   403K1382614K 0
   362   142 0   530K1653317K 0
   329   180 0   477K1801118K 0
   413   178 0   601K1972120K 0
   446   206 0   655K2202223K 0
   344   163 0   500K1823019K 0
   400   176 0   583K1892019K 0
   377   175 0   548K1912620K 0
   393   183 0   573K1912120K 0
   338   147 0   494K1642917K 0
   386   186 0   565K1982020K 0
   446   234 0   654K2351424K 0
   390   170 0   570K1892519K 0
   348   169 0   507K1791618K 0
   366   165 0   533K1751418K 0
   336   150 0   491K1611717K 0
   378   183 0   553K1981820K 0
   382   191 0   559K197 920K 0
   397   173 0   581K1841419K 0
   368   172 0   536K1882119K 0

 
 -- 
 Totus tuus, Glebius.

Kevin
___
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: converted run(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Mon, Jun 15, 2015 at 09:26:10AM +0300, Gleb Smirnoff wrote:
 
 On Mon, Jun 15, 2015 at 09:52:29AM +0800, Kevin Lo wrote:
 Kyou signed up as tester of run(4). I have converted run(4)
 K  and uploaded new patch at:
 K  
 K  https://reviews.freebsd.org/D2655
 K  
 K  Please try, report and update the project page.
 K  
 K  https://wiki.freebsd.org/projects/ifnet/net80211
 K  
 K  Thanks a lot for your help.
 K 
 K run(4) loses statistics after conversion.
 
 I have uplodaded corrected patch. Please, test it.

I tested it on various chipsets and it now works fine for me, thanks.

 -- 
 Totus tuus, Glebius.

Kevin
___
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: converted run(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Sat, Jun 13, 2015 at 06:00:20PM +0300, Gleb Smirnoff wrote:
 
   Hi Kevin,

Hi Gleb,

 
   you signed up as tester of run(4). I have converted run(4)
 and uploaded new patch at:
 
 https://reviews.freebsd.org/D2655
 
 Please try, report and update the project page.
 
 https://wiki.freebsd.org/projects/ifnet/net80211
 
 Thanks a lot for your help.

run(4) loses statistics after conversion.

# netstat -hI wlan0 1
input  wlan0   output
   packets  errs idrops  bytespackets  errs  bytes colls
79 0 091K  0 2  0 0
85 0 0   121K  0 1  0 0
92 0 0   133K  0 3  0 0
60 0 083K  0 1  0 0
32 0 046K  0 0  0 0
32 0 037K  0 1  0 0
29 0 032K  0 0  0 0
21 0 031K  0 0  0 0
22 0 025K  0 0  0 0
31 0 036K  0 0  0 0
83 0 0   107K  0 0  0 0
   114 0 0   164K  0 0  0 0
62 0 089K  0 0  0 0
22 0 033K  0 1  0 0
16 0 024K  0 0  0 0
19 0 025K  0 0  0 0
22 0 028K  0 0  0 0
26 0 034K  0 0  0 0
31 0 035K  0 0  0 0
91 0 0   123K  0 0  0 0

 
 -- 
 Totus tuus, Glebius.

Kevin
___
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: converted ral(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Fri, Jun 05, 2015 at 11:16:06AM +0800, Kevin Lo wrote:
 
 On Thu, Jun 04, 2015 at 02:18:08PM +0300, Gleb Smirnoff wrote:
  
Hi Kevin and Olivier,
 
 Hi Gleb,
 
  
you signed up as testers of ral(4). I have converted ral(4)
  and uploaded new patch at:
  
  https://reviews.freebsd.org/D2655
  
  Please try, report and update the project page.
  
  https://wiki.freebsd.org/projects/ifnet/net80211
  
  Thanks a lot for your help.
 
 It works fine for me.  Tested on RT5390, thanks.

As I mentioned in a private message, the diff below changes ifp-if_drv_flags
to sc-sc_flags, thanks.

--- D2655.diff.orig 2015-06-08 10:20:12.220844488 +0800
+++ D2655.diff  2015-06-08 10:20:38.020180596 +0800
@@ -6279,7 +6279,7 @@
RAL_LOCK_ASSERT(sc);
  
 -  KASSERT(ifp-if_drv_flags  IFF_DRV_RUNNING, (not running));
-+  KASSERT(ifp-if_drv_flags  RAL_RUNNING, (not running));
++  KASSERT(sc-sc_flags  RAL_RUNNING, (not running));
  
if (sc-sc_invalid) /* card ejected */
return;
@@ -7109,7 +7109,7 @@
RAL_LOCK_ASSERT(sc);
  
 -  KASSERT(ifp-if_drv_flags  IFF_DRV_RUNNING, (not running));
-+  KASSERT(ifp-if_drv_flags  RT2860_RUNNNING, (not running));
++  KASSERT(sc-sc_flags  RT2860_RUNNNING, (not running));
  
if (sc-sc_invalid) /* card ejected */
return;
___
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: converted ral(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Thu, Jun 04, 2015 at 02:18:08PM +0300, Gleb Smirnoff wrote:
 
   Hi Kevin and Olivier,

Hi Gleb,

 
   you signed up as testers of ral(4). I have converted ral(4)
 and uploaded new patch at:
 
 https://reviews.freebsd.org/D2655
 
 Please try, report and update the project page.
 
 https://wiki.freebsd.org/projects/ifnet/net80211
 
 Thanks a lot for your help.

It works fine for me.  Tested on RT5390, thanks.

 
 -- 
 Totus tuus, Glebius.

Kevin
___
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: converted urtwn(4) Was: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Thu, Jun 04, 2015 at 03:52:56PM +0300, Gleb Smirnoff wrote:
 
   Hi Kevin and Glen,

Hi Gleb,

   you signed up as testers of urtwn(4). I have converted urtwn(4)
 and uploaded new patch at:
 
 https://reviews.freebsd.org/D2655
 
 Please try, report and update the project page.
 
 https://wiki.freebsd.org/projects/ifnet/net80211
 
 Thanks a lot for your help.

Seems to be working fine.  Tested on RTL8188CUS, RTL8192CU and RTL8188EUS.
Thanks.

 -- 
 Totus tuus, Glebius.
 
Kevin
___
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: [Testers needed!] WiFi drivers changes

[Kevin Lo]

On Fri, May 29, 2015 at 04:35:35PM +0300, Gleb Smirnoff wrote:
 
   Hi!

Hi Gleb,

   As part of the opaque ifnet project [1], we are doing some code shake
 with all IEEE802.11 (read WiFi) drivers. The drivers, that provide a parent
 interface for the wlan(4) interface.

Thanks for putting the effort into making this happen. :)

   The core idea is that parent device loses its ifnet(9) structure. The
 code is already complete for the stack, but only 2 drivers are converted
 to new KPI: iwn(4) and bwi(4). We got 22 more drivers left. The changes
 are quite mechanical, but nevertheless testing is required before committing.
 
 So, if you run FreeBSD head and wlan(4), please sign up here as tester:
 
 https://wiki.freebsd.org/projects/ifnet/net80211
 
 As soon as I see testers there, I will start converting more drivers.
 
 For those who want to review the patch, or even help with converting,
 you are welcome here:
 
 https://reviews.freebsd.org/D2655
 
 Waiting for your feedback :)

I have a bunch of usb wifi dongles, I would like to help with converting.

 [1] https://wiki.freebsd.org/projects/ifnet
 
 -- 
 Totus tuus, Glebius.

Kevin
___
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: CTF: wpa_supplicant/hostapd 2.4 import

[Kevin Lo]

On Sun, Apr 19, 2015 at 02:35:17PM -0700, Rui Paulo wrote:
 
 Hi,
 
 Please test the new wpa_supplicant/hostapd.  Here's the patch against FreeBSD 
 HEAD:
 
   https://people.freebsd.org/~rpaulo/wpa-2.4.diff

Seems to be working fine on amd64.  Tested on ral(4) and run(4).
Thanks.

 Thanks,
 -- 
 Rui Paulo

Kevin
___
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: [CFT/CFR] machine independent sf_bufs

[Kevin Lo]

On Tue, Jul 29, 2014 at 10:00:43PM +0400, Gleb Smirnoff wrote:
 
 On Tue, Jul 29, 2014 at 07:29:43PM +0200, Michael Tuexen wrote:
 M   Sorry for top quoting, this is to annoy you :) I got zero
 M  replies on the below email during a week. I'd really appreciate
 M  testing on different platforms. Any takers?
 M OK, it works on an Raspberry pi running r269231 with your patch.
 M The only suspicious thing I observed was that the number of
 M 'requests for I/O initiated by sendfile' in netstat -m doesn't
 M always increase. I would expect that. However, I'm not sure if
 M this is ARM related (I would not think so) or is related to your
 M patch at all.
 
 Thanks a lot, Michael!
 
 The observation on number of I/Os is absolutely okay, since VM
 cashes pages.

Hi Gleb,

I tested your patch on FreeBSD/arm (OpenBlocks AX3), it seems to be working
fine.

 -- 
 Totus tuus, Glebius.

Kevin
___
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 and utf-8 directory names

[Kevin Lo]

Thanks for confirming this.  I just closed that bug. :-)

Kevin

On Thu, Jul 03, 2014 at 05:24:54PM +0200, MS - Krasznai András wrote:
 Hi, Kevin,
 
 
 I made the experiment and there was no fault, the result contains the stat 
 outputs. 
 I used login-class (according to the handbook) to set the environment, and 
 added the -L hu_HU.UTF-8 option to the appropriate line in fstab
 
 
 rgds
 
 András
 
 From: owner-freebsd-curr...@freebsd.org [owner-freebsd-curr...@freebsd.org] 
 On Behalf Of Kevin Lo [ke...@freebsd.org]
 Sent: Thursday, July 03, 2014 5:33 AM
 To: d...@gmx.com
 Cc: freebsd-current@freebsd.org; David Chisnall
 Subject: Re: freebsd and utf-8 directory names
 
 On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote:
 
  David Chisnall wrote, On 07/01/2014 19:06:
   Please note that forums.freebsd.org is not a bug tracker.  I tried 
   searching the bug tracker for bugs with FAT and filename or FAT and 
   utf-8/utf8/character in their names and could not find any reference to 
   this issue.
  
   If you actually want to see bugs fixed, rather than just complain about 
   them, please file them here: 
   https://bugs.freebsd.org/bugzilla/enter_bug.cgi  Make sure that you 
   provide all of the steps required to reproduce them.
 
  I neglected to submit a bug report because:
  (1) there were already at least 3 bug reports related to (FAT32 and) 
  character sets or encodings, some of them even had patches;
  (2) the reports were very old, indicating that the FreeBSD developers don't 
  care about FAT32;
  (3) at least one report was seemingly related, and I didn't want to create 
  a(nother) possible duplicate.
 
  But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540
 
 Well, I'm going to close that PR. :-)
 First, set LANG environment variable to hu_HU.UTF-8 in your case:
 
 # setenv LANG hu_HU.UTF-8
 
 Second, mount the FAT32 partition in Hungarian locale:
 
 # mount_msdosfs -L hu_HU.UTF-8 /dev/da0s1 /mnt
 
 Third, untar your attachement file:
 
 # tar xvf /mnt/files.zip
 x 1’.txt
 x 2–.txt
 
 # stat 1’.txt
 128 244744 -rwxr-xr-x 1 root wheel 4294967295 0 Jan  1 08:00:00 1980 Aug  
 1 16:57:52 2011 Aug  1 16:57:52 2011 Jul  3 11:28:24 2014 16384 0 0x800 
 1’.txt
 
 # stat 2–.txt
 128 244746 -rwxr-xr-x 1 root wheel 4294967295 0 Jan  1 08:00:00 1980 Aug  
 1 16:55:20 2011 Aug  1 16:55:20 2011 Jul  3 11:28:24 2014 16384 0 0x800 
 2–.txt
 
 Let me know if that works for you, thanks.
 
 Kevin
 ___
 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: freebsd and utf-8 directory names

[Kevin Lo]

On Wed, Jul 02, 2014 at 12:27:07AM +0200, d...@gmx.com wrote:
 
 David Chisnall wrote, On 07/01/2014 19:06:
  Please note that forums.freebsd.org is not a bug tracker.  I tried 
  searching the bug tracker for bugs with FAT and filename or FAT and 
  utf-8/utf8/character in their names and could not find any reference to 
  this issue.
 
  If you actually want to see bugs fixed, rather than just complain about 
  them, please file them here: 
  https://bugs.freebsd.org/bugzilla/enter_bug.cgi  Make sure that you provide 
  all of the steps required to reproduce them.
 
 I neglected to submit a bug report because:
 (1) there were already at least 3 bug reports related to (FAT32 and) 
 character sets or encodings, some of them even had patches;
 (2) the reports were very old, indicating that the FreeBSD developers don't 
 care about FAT32;
 (3) at least one report was seemingly related, and I didn't want to create 
 a(nother) possible duplicate.
 
 But now, eat this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191540

Well, I'm going to close that PR. :-)
First, set LANG environment variable to hu_HU.UTF-8 in your case:

# setenv LANG hu_HU.UTF-8

Second, mount the FAT32 partition in Hungarian locale:

# mount_msdosfs -L hu_HU.UTF-8 /dev/da0s1 /mnt

Third, untar your attachement file:

# tar xvf /mnt/files.zip
x 1’.txt
x 2–.txt

# stat 1’.txt
128 244744 -rwxr-xr-x 1 root wheel 4294967295 0 Jan  1 08:00:00 1980 Aug  1 
16:57:52 2011 Aug  1 16:57:52 2011 Jul  3 11:28:24 2014 16384 0 0x800 
1’.txt

# stat 2–.txt
128 244746 -rwxr-xr-x 1 root wheel 4294967295 0 Jan  1 08:00:00 1980 Aug  1 
16:55:20 2011 Aug  1 16:55:20 2011 Jul  3 11:28:24 2014 16384 0 0x800 
2–.txt

Let me know if that works for you, thanks.

Kevin
___
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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Kevin Lo]

On 2013/12/20 15:31, Alexey Dokuchaev wrote:

On Fri, Dec 20, 2013 at 01:35:37PM +0800, Kevin Lo wrote:

I'd like to port it after finishing RT5373 driver support. :-)

Nice, looking forward to it. :)


As promised, I have committed support for the RTL8188EUS chipset.
The driver is a work in progress.  The connection is slow but it's better
than nothing. :-)




Here's a site you could use for info about your wireless device:
http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3

Thank you Kevin.

./danfe


Kevin

___
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: Wifi compatibility

[Kevin Lo]

On 2014/04/09 04:10, Parker Gibson wrote:

I am looking at the TP-Link TL-WN722N high gain USB dongle.
I was curious if anyone knew if the rum(4) driver will support this hardware, 
if I could run it in HOSTAP mode, and if not, what high gain adapter would that 
you all would suggest?


Your dongle uses AR9271 chip which is currently not supported, but
it seems that Adrian has been working on it [1].

I recommend using run(4).  It supports hostapd.

[1] 
http://lists.freebsd.org/pipermail/freebsd-wireless/2013-December/004220.html




Thanks in advanced.


Kevin
___
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: UDP Lite support

[Kevin Lo]

Joe Nosay wrote:

On Mon, Mar 31, 2014 at 10:20 PM, Kevin Lo ke...@freebsd.org wrote:


On 2014/03/28 00:21, John Baldwin wrote:


On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote:


Are you interested in working on these and report back?

The revised patch is available at:
http://people.freebsd.org/~kevlo/udplite.diff


Thank you for your suggestions.

  A few suggestions:

- I would just drop the INP lock and return EOPNOTSUPP directly rather
 than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
 UDP-lite options are self-contained.


Fixed.


Thanks.

  - I'm not a super big fan of all the udp_common_* macros only because

 I think it obfuscates things.  At the very least, please move these
 things out of the header and into udp_usrreq.c so they are closer
 to the implementation.  I would even suggest making them inline
 functions instead of macros.


Okay, I removed two udp_common_* macros.  I also renamed
udp_common_init()
to udp_udplite_init() and moved it into udp_usrreq.c.  Using a macro here
to follow the style used in SCTP (sctp_os_bsd.h).

Here's a third version of the udp-lite patch:
http://people.freebsd.org/~kevlo/udplite.diff


Ok, I would say that udp_common_init() is actually a better name if you
keep
the macro (which I think is fine) rather than udp_udplite_init() as the
macro
is not specific to UDP Lite.  However, thanks for moving the macros out
of the
header.


Thank you John.  glebius@ suggests we don't need to have two absolutely
equal uma zones since most systems don't run UDP-Lite.
If practice shows that a differentiation at zone level between UDP and
UDP-Lite PCBs is important, then it could be done later.

Following up with a fourth version of the udp-lite patch.
http://people.freebsd.org/~kevlo/udplite.diff

On top of the previous versions, this:
 - removes a uma zone for udp-lite
 - udp_common_ctlinput() belongs under #ifdef INET
 - removes sysctl nodes for udp-lite.
 - bumps version and adds my copyright.

 Kevin




Do I patch over the current src- which was already patched with version 3-
or do I just start new?


Start new, thanks.

Kevin

___
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: UDP Lite support

[Kevin Lo]

On 2014/04/02 04:53, Adrian Chadd wrote:

Hi!


Hi Adrian,



On 31 March 2014 19:20, Kevin Lo ke...@freebsd.org wrote:



Thank you John.  glebius@ suggests we don't need to have two absolutely
equal uma zones since most systems don't run UDP-Lite.
If practice shows that a differentiation at zone level between UDP and
UDP-Lite PCBs is important, then it could be done later.

Following up with a fourth version of the udp-lite patch.
http://people.freebsd.org/~kevlo/udplite.diff

On top of the previous versions, this:
 - removes a uma zone for udp-lite
 - udp_common_ctlinput() belongs under #ifdef INET
 - removes sysctl nodes for udp-lite.
 - bumps version and adds my copyright.

I've just briefly review this.

I recommend turning the places where you do this:

+ pcbinfo = (pr == IPPROTO_UDP) ? V_udbinfo : V_ulitecbinfo;

.. into some inline function which returns the correct pcbinfo based
on what 'pr' is.

That way if someone wants to add another derivative UDP handler they
won't have to go and change those conditionals to yet another set of
nested conditionals.

Same for:

+ pcblist = (pr == IPPROTO_UDP) ? V_udb : V_ulitecb;

Other than that, it looks good.


Thanks for the review.  I added two inline functions get_inpcbinfo() and
get_pcblist() which return the correct pcbinfo and pcblist respectively.

The current version of the patch is in the same location, thanks.




-a


Kevin

___
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: Re: UDP Lite support

[Kevin Lo]

On 2014/03/28 00:21, John Baldwin wrote:

On Thursday, March 27, 2014 5:32:16 am Kevin Lo wrote:

Are you interested in working on these and report back?

The revised patch is available at:
http://people.freebsd.org/~kevlo/udplite.diff

Thank you for your suggestions.


A few suggestions:

- I would just drop the INP lock and return EOPNOTSUPP directly rather
than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
UDP-lite options are self-contained.

Fixed.

Thanks.


- I'm not a super big fan of all the udp_common_* macros only because
I think it obfuscates things.  At the very least, please move these
things out of the header and into udp_usrreq.c so they are closer
to the implementation.  I would even suggest making them inline
functions instead of macros.

Okay, I removed two udp_common_* macros.  I also renamed udp_common_init()
to udp_udplite_init() and moved it into udp_usrreq.c.  Using a macro here
to follow the style used in SCTP (sctp_os_bsd.h).

Here's a third version of the udp-lite patch:
http://people.freebsd.org/~kevlo/udplite.diff

Ok, I would say that udp_common_init() is actually a better name if you keep
the macro (which I think is fine) rather than udp_udplite_init() as the macro
is not specific to UDP Lite.  However, thanks for moving the macros out of the
header.


Thank you John.  glebius@ suggests we don't need to have two absolutely
equal uma zones since most systems don't run UDP-Lite.
If practice shows that a differentiation at zone level between UDP and
UDP-Lite PCBs is important, then it could be done later.

Following up with a fourth version of the udp-lite patch.
http://people.freebsd.org/~kevlo/udplite.diff

On top of the previous versions, this:
- removes a uma zone for udp-lite
- udp_common_ctlinput() belongs under #ifdef INET
- removes sysctl nodes for udp-lite.
- bumps version and adds my copyright.

Kevin


___
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: UDP Lite support

[Kevin Lo]

On 2014/03/26 23:22, John Baldwin wrote:

On Friday, March 21, 2014 3:38:19 am Kevin Lo wrote:

On 2014/03/03 04:08, Xin Li wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 3/2/14, 10:42 AM, Joe Nosay wrote:

On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com
wrote:



On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net
wrote:


On 02/26/14 18:52, Joe Nosay wrote:

On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis
bro...@freebsd.org wrote:


On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay
wrote:

The last thread on this was in 2006. Has it ever been
reconsidered or is the likelihood of too many damaged
packets the reason for not supporting? I'm not sure
where to put this question. Apologies for the noise.

You've provided next to no context.  What is the
question?  What thread are you referring to?  If this is
the usual UDP then freebsd-net would be vastly more
appropriate than -current.

-- Brooks


Thanks. I will ask kevlo and maybe bring it up on
freebsd-net. It has to do with an implementation of the
JACK server using UDP Lite for transferring data.



http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html

   Looks
like nobody proposed a patch?

I think the concern was that this is not very useful in real-world
scenarios due to link layer error detection mechanism but that
doesn't raise a red flag to me assuming this is sufficiently self
contained feature as it would improve compatibility with other
operating systems.

Cheers,

https://github.com/torelizer/jack_trauma

Not my project;  but, I want to port it to FreeBSD. First is to
get it to build from source. Use  your raspberry pi with FreeBSD
to broadcast your tunes and all.


Thanks for all of the input. The project is being reworked to
improve the code.

Kevin Lo have a patchset but needs someone to do performance testing
(its impact on non-UDPLite applications), test with vimage, etc:

http://people.freebsd.org/~kevlo/udplite.diff
http://people.freebsd.org/~kevlo/udp-v.diff

Are you interested in working on these and report back?

The revised patch is available at:
http://people.freebsd.org/~kevlo/udplite.diff


Thank you for your suggestions.


A few suggestions:

- I would just drop the INP lock and return EOPNOTSUPP directly rather
   than using goto's to 'bad_setoptname' and 'bad_getoptname' so the
   UDP-lite options are self-contained.


Fixed.


- I'm not a super big fan of all the udp_common_* macros only because
   I think it obfuscates things.  At the very least, please move these
   things out of the header and into udp_usrreq.c so they are closer
   to the implementation.  I would even suggest making them inline
   functions instead of macros.


Okay, I removed two udp_common_* macros.  I also renamed udp_common_init()
to udp_udplite_init() and moved it into udp_usrreq.c.  Using a macro here
to follow the style used in SCTP (sctp_os_bsd.h).

Here's a third version of the udp-lite patch:
http://people.freebsd.org/~kevlo/udplite.diff



However, I think the patch generally looks ok.


Cool!  Thanks again for your review of udp-lite's patch :-)

Kevin
___
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: Re: UDP Lite support

[Kevin Lo]

On 2014/03/03 04:08, Xin Li wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 3/2/14, 10:42 AM, Joe Nosay wrote:

On Thu, Feb 27, 2014 at 3:22 AM, Joe Nosay superbisq...@gmail.com
wrote:




On Wed, Feb 26, 2014 at 11:19 PM, Xin Li delp...@delphij.net
wrote:


On 02/26/14 18:52, Joe Nosay wrote:

On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis
bro...@freebsd.org wrote:


On Wed, Feb 26, 2014 at 07:36:29PM -0500, Joe Nosay
wrote:

The last thread on this was in 2006. Has it ever been
reconsidered or is the likelihood of too many damaged
packets the reason for not supporting? I'm not sure
where to put this question. Apologies for the noise.

You've provided next to no context.  What is the
question?  What thread are you referring to?  If this is
the usual UDP then freebsd-net would be vastly more
appropriate than -current.

-- Brooks


Thanks. I will ask kevlo and maybe bring it up on
freebsd-net. It has to do with an implementation of the
JACK server using UDP Lite for transferring data.



http://freebsd.1045724.n5.nabble.com/UDP-lite-for-FreeBSD-td4010236.html

  Looks
like nobody proposed a patch?

I think the concern was that this is not very useful in real-world
scenarios due to link layer error detection mechanism but that
doesn't raise a red flag to me assuming this is sufficiently self
contained feature as it would improve compatibility with other
operating systems.

Cheers,

https://github.com/torelizer/jack_trauma

Not my project;  but, I want to port it to FreeBSD. First is to
get it to build from source. Use  your raspberry pi with FreeBSD
to broadcast your tunes and all.



Thanks for all of the input. The project is being reworked to
improve the code.

Kevin Lo have a patchset but needs someone to do performance testing
(its impact on non-UDPLite applications), test with vimage, etc:

http://people.freebsd.org/~kevlo/udplite.diff
http://people.freebsd.org/~kevlo/udp-v.diff

Are you interested in working on these and report back?


The revised patch is available at:
http://people.freebsd.org/~kevlo/udplite.diff

I measure and compare the performance of UDP with/without UDP-lite patch,
the udp-lite patch doesn't affect the performance.

Tested system is FreeBSD/amd64 -CURRENT(r263301), machines were connected
via cross-link cable.

Machines:
-
Dragon (connected to Monkey)

CPU: Intel(R) Core(TM) i3-2330E CPU @ 2.20GHz (2195.06-MHz K8-class CPU)
 Origin=GenuineIntel  Id=0x206a7  Family=0x6  Model=0x2a Stepping=7
RAM: 2GB
NIC: on-board em(4)

Monkey (connected to Dragon)

CPU: Intel(R) Core(TM) i3-2330E CPU @ 2.20GHz (2195.06-MHz K8-class CPU)
 Origin=GenuineIntel  Id=0x206a7  Family=0x6  Model=0x2a Stepping=7
RAM: 1GB
NIC: on-board em(4)

Monkey runs 'netserver'.

All tests done with netperf software:
UDP Stream test:
-
% netperf -c -l 60 -H Monkey -t UDP_STREAM -i 10,2 -I 99,5 -- -m 64 -s 
57344 -S 57344
% netperf -c -l 60 -H Monkey -t UDP_STREAM -i 10,2 -I 99,5 -- -m 4096 -s 
57344 -S 57344
% netperf -c -l 60 -H Monkey -t UDP_STREAM -i 10,2 -I 99,5 -- -m 16384 
-s 57344 -S 57344


Without UDP-Lite patch:
Netperf test   MTU BW BSIZE
      --  --
UDP_STREAM 1500   211.3   64
UDP_STREAM 1500   950.4 4096
UDP_STREAM 1500   948.616384


With UDP-Lite patch:
Netperf test   MTU BW BSIZE
      --  --
UDP_STREAM 1500   216.5   64
UDP_STREAM 1500   950.3 4096
UDP_STREAM 1500   948.616384



Cheers,
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJTE4+mAAoJEJW2GBstM+nsthoQAIW67l7yDfIPvxDsNIWWJcRd
8brFYCAOPYE4LpuLGjtSgy370aBe9JmwAm41tE4qF0WhGpcu6TLsKjgMGWa/lHCc
JId8+WBfbbQT8XJj/d+3oOETn5/rglvlRhJbnNIwaQpTXxuMC5oz2nGW7rIpIkaA
OHo0D20DzGj4nxrQvijZ7DsMkk3F+KJu/4p7M6lpsIPCakknW1WD7IHRfbZ4Oldz
2xH4HfIk7cAdA7i/YUNjlpSgWFQ5OU03J5HAYfC6W37wiGbjdBYf/PKVhJ8hz7+D
OCl+yCV00u4fCjlY6zXFea9pGr7Cl1P+sapwKDZ4g+NpNHxBUVY+ahbjQUHYON2W
sdzAsLpMMqavCr1o8mcXdm7IPRlLUK9QZUySC9DitPvoF8G2llTAz1mWa4/Oj7/S
JMiUERcaL5gdFN8EgEKkamFgLJguYquAjGtiowa51EMbnZG0Q2yWUcrEBFHWBEZT
RW1u6r4ChIrPE9X5ljfFpQyKG6jFhYFXG+iVlgTB7F2ZWhjPAXi/tLbBnvIcci1m
Md4XFm/bBJj/yNXdPuCi+CtvvdpZ/d4LQn4B7By5bIo1QjCb4Zx5n2Tq5xnYZUOI
CnSVnNSkwLbbrAVtYOVWnrSuwR33JQnqeGHdM+XYBBwKBRhrx+ZgFWD7N6Gm95PU
xXSxkgYVXI4sgi7Lh3Ia
=2Vmc
-END PGP SIGNATURE-


Kevin

___
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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Kevin Lo]

On 2014/03/10 15:47, Alexey Dokuchaev wrote:

On Mon, Mar 10, 2014 at 03:41:16PM +0800, Kevin Lo wrote:

On 2014/02/10 20:21, Alexey Dokuchaev wrote:

To augment this a bit: I also came across one of these dongles (vendor
0x0bda product 0x8176) that gave me this timeout waiting for checksum
report message.  Retrying didn't help, but plugging the dongle out and
then back in did.  After powercycling the machine, I had to replug it
again.  Once replugged, the dongle seems to work fine (I rebuilt kernel
and some ports via NFS over it thus far).

This suggests that the driver (or more generic part of the USB stack)
does not initialize something correctly, while full plug-and-play thing
does it.  Any ideas?

We have to reset the bit of the R92C_MCUFWDL associated with checksum report
before writing firmware.  Could you try this patch? Thanks.

Shit.  I'd like to help, but no longer have access to the dongle.  If I find
anything similar (or find a way to get access to original dongle remotely),
I'll let you know. :(


No worries.  I committed it as r263154.  Hope this problem get fixed. :-)



Thanks for working on these things Kevin, I appreciate it.

./danfe


Kevin

___
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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Kevin Lo]

On 2014/02/10 20:21, Alexey Dokuchaev wrote:

On Tue, Oct 15, 2013 at 11:13:56PM -0700, Rui Paulo wrote:

On 8 Oct 2013, at 10:41, Julian H. Stacey j...@berklix.com wrote:

I too am seeing
urtwn0: timeout waiting for checksum report

Sorry, this is a know problem that I haven't been able to figure out...
It probably exists in the OpenBSD driver as well. Usually retrying works.

To augment this a bit: I also came across one of these dongles (vendor
0x0bda product 0x8176) that gave me this timeout waiting for checksum
report message.  Retrying didn't help, but plugging the dongle out and
then back in did.  After powercycling the machine, I had to replug it
again.  Once replugged, the dongle seems to work fine (I rebuilt kernel
and some ports via NFS over it thus far).

This suggests that the driver (or more generic part of the USB stack)
does not initialize something correctly, while full plug-and-play thing
does it.  Any ideas?


We have to reset the bit of the R92C_MCUFWDL associated with checksum 
report

before writing firmware.  Could you try this patch? Thanks.

Index: sys/dev/usb/wlan/if_urtwn.c
===
--- sys/dev/usb/wlan/if_urtwn.c (revision 262971)
+++ sys/dev/usb/wlan/if_urtwn.c (working copy)
@@ -2071,6 +2071,10 @@ urtwn_load_firmware(struct urtwn_softc *sc)
urtwn_write_1(sc, R92C_MCUFWDL + 2,
urtwn_read_1(sc, R92C_MCUFWDL + 2)  ~0x08);

+   /* Reset the FWDL checksum. */
+   urtwn_write_1(sc, R92C_MCUFWDL,
+   urtwn_read_1(sc, R92C_MCUFWDL) | R92C_MCUFWDL_CHKSUM_RPT);
+
for (page = 0; len  0; page++) {
mlen = min(len, R92C_FW_PAGE_SIZE);
error = urtwn_fw_loadpage(sc, page, ptr, mlen);

___
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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Kevin Lo]

On 2013/12/19 17:51, Alexey Dokuchaev wrote:

On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote:

Your usb wlan dongles use RTL8188EU chip which is currently not
supported by any of drivers.

I see; I guess I should not have believed when I was told that most likely
all it would take is id-patch urtwn(4). ;-)

Does anyone know if support is being worked on?


Don't know either.  I'd like to port it after finishing RT5373
driver support. :-)


   Given an increased
popularity of these dongles, perhaps a wiki page would be nice for
those of us who want to get an idea if some particular chip is supported
before buying them (online).


Here's a site you could use for info about your wireless device:
http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3



./danfe


Kevin

___
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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Kevin Lo]

On 2013/12/18 23:48, Alexey Dokuchaev wrote:

On Sun, Oct 06, 2013 at 10:24:09AM -0700, Alfred Perlstein wrote:

I got one of these (if_urtwn) and it works enough to download about a meg
or so before the watchdog kicks in and I have to ifconfig down/up it to
get it to respond again.

I even have a patch pending to add the usb identifier for this.

Same here; someone at $work bought couple of these teeny dongles.  I've
applied small id patch (attached), and tried to use it (it reportedly
works flawlessly under Linux using this [*] driver).  I could load the
module, but MAC address was clearly bogus (00:00:30:34:43:30); yet I've
created wlan0 just to find out that there is no list scan results, and
wpa_supplicant(8) gives me this in an endless loop (GENERIC kernel, so
I presume all wlan-related stuff should be in place):

Successfully initialized wpa_supplicant
ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured
wlan0: Failed to initiate AP scan

This is on relatively fresh 11-CURRENT as of Oct 18th, i386.  Any clues?
It would be nice to get more of these little guys to work, esp. there is
working Linux driver available for reference.


Your usb wlan dongles use RTL8188EU chip which is currently not
supported by any of drivers.



./danfe

[*] https://github.com/liwei/rpi-rtl8188eu


Kevin
___
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: [rfc] removing the NDISulator

[Kevin Lo]

Thomas Mueller wrote:
  

The later driver model isn't supported by ndisulator. We'd have to
implement all the newer NDIS stuff for wifi and ethernet.
 

In the later NDIS layer the Microsoft Wireless Services implement a bunch
of stuff that used to be up to the driver. Ie, the driver just exposed an
ethernet device with some extra bits for wifi. Ie, the whole stack runs
in the driver. That has changed.
 
...



This is why I'd rather us bite the bullet now and deprecate it, versus have
it in there and put in the work to upgrade it to handle NDIS 6.x drivers
with the Microsoft wireless extensions stuff.
 


-adrian

How much extra work would there be to update the ndis(ulator/wrapper)?

Would it be more than writing native FreeBSD drivers which might be ported
from NetBSD, OpenBSD and Linux?

What about cases where specifications might be a trade secret?

How difficult is it to port or write a wifi or Ethernet driver for FreeBSD?

I have no experience writing device drivers but have some experience with C and 
C++.

I notice NetBSD and OpenBSD have drivers for some chips that FreeBSD lacks.

I have motherboard (MSI Z77 MPOWER) with Realtek 8111E Ethernet that fails to
connect in FreeBSD or OpenBSD, OK with NetBSD-current and Linux, and
Atheros AR9271 onboard wifi: device athn is included in NetBSD (current only)
and OpenBSD.


No offence, but you have mentioned several times that Realtek 8111E Ethernet
and athn(4) do not work on FreeBSD, just wondering why you don't sit down
and start coding then all your questions will be answered.



Tom




Kevin
___
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: problems with threads/destructors in -current with llvm/clang

[Kevin Lo]

Dimitry Andric wrote:
 On 2012-12-07 13:59, Dimitry Andric wrote:
  On 2012-12-06 18:12, Mark Atkinson wrote:
  Short backstory, I had recently upgraded my workstation to the latest
  current which included clang as default cc now.
  ...
  qdbus under kde segfaults in malloc with a huge recursion stack:
 ...
  This is a bug in qdbus; it uses a global static QDBusConnection object,
  and the order in which global destructors are called is undefined:
 ...
  The global static QDBusConnection object should be replaced by a
  singleton, as suggested here:
 
 Here is an alternative solution, where the QDBusConnection object is
 just a local variable in main(), and passed around as a const reference.
 To make the destructors work properly, I also replaced the exit() calls
 in main() with return statements.
 
 With this patch (placed in /usr/ports/devel/dbus-qt4/files), qdbus
 starts up and exits normally for me.  I did not do any other rigorous
 testing, though. :)

Works for me, thanks. I think your patch should go in. 

Kevin

___
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: Is this a typo in if_tap.c?

[Kevin Lo]

On 2012/11/22 17:39, David Xu wrote:

When I was trying to create a second tap device, kernel crashed.
Is this patch correct ?


Index: sys/net/if_tap.c
===
--- sys/net/if_tap.c(revision 243397)
+++ sys/net/if_tap.c(working copy)
@@ -186,7 +186,7 @@
 /* Find any existing device, or allocate new unit number. */
 i = clone_create(tapclones, tap_cdevsw, unit, dev, 0);
 if (i) {
-dev = make_dev(tap_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600,
+dev = make_dev(tap_cdevsw, unit, UID_ROOT, GID_WHEEL, 0600,
 %s%d, tapname, unit);
 }



The patch looks right to me.

Kevin
___
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: Tmpfs panic in -current

[Kevin Lo]

On 四, 2012-06-28 at 10:09 +0300, Gleb Kurtsou wrote:
 On (27/06/2012 13:29), Kevin Lo wrote:
  Kevin Lo wrote:
   Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
   I've observed a panic in recent -current several times but I only
   have a picture of the backtrace:
   http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
   
   Does this look at all familiar to anyone?
  
  Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
  address
  in your kernel ?
 
 Sure.
 
  The screenshot looks strange. The instruction on which the kernel 
  trapped
  is int 0x28 which should not appear in the compiled code.
 
 Kevin, do you have fuse modules loaded? It looks much like memmory
 corruption issue.

No, I don't have that module loaded.
# kldstat
Id Refs AddressSize Name
 1   14 0xc040 bab9e8   kernel
 21 0xc0fac000 1d58 msdosfs_iconv.ko
 32 0xc0fae000 67a8 libiconv.ko
 41 0xc728e000 9000 tmpfs.ko
 51 0xc789b000 4000 uhid.ko



___
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: Tmpfs panic in -current

[Kevin Lo]

Konstantin Belousov wrote:
 On Wed, Jun 27, 2012 at 01:29:14PM +0800, Kevin Lo wrote:
  Kevin Lo wrote:
   Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
   I've observed a panic in recent -current several times but I only
   have a picture of the backtrace:
   http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
   
   Does this look at all familiar to anyone?
  
  Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
  address
  in your kernel ?
 
 Sure.
 
  The screenshot looks strange. The instruction on which the kernel 
  trapped
  is int 0x28 which should not appear in the compiled code.
 
 # gdb tmpfs.ko
 (gdb) l *tmpfs_reg_resize+0x627
 0xbf37 is in tmpfs_reg_resize 
 (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
 1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
 
 In tmpfs_subr.c:
  999 if (m != NULL) {
 1000 if ((m-oflags  VPO_BUSY) != 0 
 ||
 1001 m-busy != 0) {
 1002 vm_page_sleep(m, 
 tmfssz);
 1003 goto retry;
 1004 }
 1005 MPASS(m-valid == 
 VM_PAGE_BITS_ALL);
 1006 } else if (vm_pager_has_page(uobj, idx, 
 NULL, NU
 LL)) {
 
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?

The only possible 'new size' value for the truncation from open(2) is 
zero,
so I do not understand why the asserted block was executed at all.
   
   Thanks for looking into it. Unfortunately I can't get a crash dump 
   due to lack of disk space and memory.
  
  I triggered the KASSERT on a different machine in the last hour.
 It is not 'the' KASSERT, it is something different.
 
 Are you sure that you do not have some systematic build issues on your
 machines ? Although I do not think that tmpfs is 'ready for production use'
 for arbitrary low value of this statement, there is no steady flow of
 similar reports from other users. This makes me somewhat suspicious that
 either you might have inconsistent build issues, or unrelated memory
 corruption problems.

As I mentioned, I'm running -CURRENT on a number of systems.
I haven't seen tmpfs panics on machines running FreeBSD 9.

Kevin

___
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: Tmpfs panic in -current

[Kevin Lo]

Konstantin Belousov wrote:
 On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
  Konstantin Belousov wrote:
   On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg

Does this look at all familiar to anyone?
   
   Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
   in your kernel ?
  
  Sure.
  
   The screenshot looks strange. The instruction on which the kernel trapped
   is int 0x28 which should not appear in the compiled code.
  
  # gdb tmpfs.ko
  (gdb) l *tmpfs_reg_resize+0x627
  0xbf37 is in tmpfs_reg_resize 
  (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
  1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
  
  In tmpfs_subr.c:
   999 if (m != NULL) {
  1000 if ((m-oflags  VPO_BUSY) != 0 ||
  1001 m-busy != 0) {
  1002 vm_page_sleep(m, tmfssz);
  1003 goto retry;
  1004 }
  1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
  1006 } else if (vm_pager_has_page(uobj, idx, NULL, 
  NU
  LL)) {
  
 Hm, can you get a core and
 - obtain backtrace in kgdb;
 - print the *m content for the page that triggered the assertion ?
 
 The only possible 'new size' value for the truncation from open(2) is zero,
 so I do not understand why the asserted block was executed at all.

Thanks for looking into it. Unfortunately I can't get a crash dump 
due to lack of disk space and memory.

Kevin

___
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: Tmpfs panic in -current

[Kevin Lo]

Kevin Lo wrote:
 Konstantin Belousov wrote:
  On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
   Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
 I've observed a panic in recent -current several times but I only
 have a picture of the backtrace:
 http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
 
 Does this look at all familiar to anyone?

Can you look up the line corresponding to tmpfs_reg_resize + 0x627 
address
in your kernel ?
   
   Sure.
   
The screenshot looks strange. The instruction on which the kernel 
trapped
is int 0x28 which should not appear in the compiled code.
   
   # gdb tmpfs.ko
   (gdb) l *tmpfs_reg_resize+0x627
   0xbf37 is in tmpfs_reg_resize 
   (/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
   1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
   
   In tmpfs_subr.c:
999 if (m != NULL) {
   1000 if ((m-oflags  VPO_BUSY) != 0 ||
   1001 m-busy != 0) {
   1002 vm_page_sleep(m, tmfssz);
   1003 goto retry;
   1004 }
   1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
   1006 } else if (vm_pager_has_page(uobj, idx, 
   NULL, NU
   LL)) {
   
  Hm, can you get a core and
  - obtain backtrace in kgdb;
  - print the *m content for the page that triggered the assertion ?
  
  The only possible 'new size' value for the truncation from open(2) is zero,
  so I do not understand why the asserted block was executed at all.
 
 Thanks for looking into it. Unfortunately I can't get a crash dump 
 due to lack of disk space and memory.

I triggered the KASSERT on a different machine in the last hour.

panic: Assertion (vp) !=NULL  (vp)-v_data != NULL failed at 
@/fs/tmpfs/tmpfs.h:527

The bad news is my coworker rebooted that machine after panic :-(

Kevin

___
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: Tmpfs panic in -current

[Kevin Lo]

Konstantin Belousov wrote:
 On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
  I've observed a panic in recent -current several times but I only
  have a picture of the backtrace:
  http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
  
  Does this look at all familiar to anyone?
 
 Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
 in your kernel ?

Sure.

 The screenshot looks strange. The instruction on which the kernel trapped
 is int 0x28 which should not appear in the compiled code.

# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize 
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c

In tmpfs_subr.c:
 999 if (m != NULL) {
1000 if ((m-oflags  VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU
LL)) {

Thanks!

Kevin

___
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

Tmpfs panic in -current

[Kevin Lo]

I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg

Does this look at all familiar to anyone?

Kevin

___
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

[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: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed)

[Kevin Lo]

On Mon, 2011-08-08 at 16:57 +0200, Svatopluk Kraus wrote:
 Thanks for committing the fix.
 
 I've continued with work on two NIC on same NET. Now, with
 point-to-point interfaces too and I have more small fixes which I
 submitted today:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=159600
 http://www.freebsd.org/cgi/query-pr.cgi?pr=159601
 http://www.freebsd.org/cgi/query-pr.cgi?pr=159602
 http://www.freebsd.org/cgi/query-pr.cgi?pr=159603
 
 I have one more related problem, but I'm not sure how complex the fix should 
 be.
 
 When an interface is marked down a network route is deleted (or
 replaced) and a loopback route persists in routing table. It is OK.
 However, when an interface is marked up again, then a network route is
 installed unconditionally (but error is ignored) and a loopbak route
 is deleted and added immediately and unconditionally too. IMHO, it is
 not correct behaviour. I think that a second half of in_ifinit()
 should be here starting by in_addprefix() call with some small or
 bigger changes.
 
 Maybe, adding network route and ignoring error could be OK, but
 deleting loopback route should be done under IFA_RTSELF flag is set
 condition (with existing route refcount check). V_useloopback should
 be check before re-adding the route and existing route must be check
 to evaluate refcount correctly. The proposed patch is attached.
 
 However, I prefer to call in_addprefix() (which is static now) instead
 of rtinit() and add some more checks from in_ifinit(). Can you (or
 anyone) review the patch?

Hi Svatopluk,

Thanks for working so hard to figure the issue out.
kern/159600 looks good to me also, committed to HEAD.
The rest needs more review, thanks!

  Thanks once again,
 
 Svata

Kevin


___
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: [patch] Problem with two NIC on same NET (in_scrubprefix: err=17, new prefix add failed)

[Kevin Lo]

Hi Andrew,

I just committed Svatopluk's fix to HEAD, thanks!

Kevin

On Wed, 2011-08-03 at 11:11 -0400, Andrew Boyer wrote:
 We found and fixed a similar issue with an identical patch.  It has been 
 working fine for us under stable/8.
 
 Unfortunately I am weeks and weeks behind on pushing fixes back to the tree, 
 so you had to duplicate the work.  If it can be committed (and MFC'd to 8, 
 please) it would save others the trouble.
 
 -Andrew
 
 On Aug 3, 2011, at 10:51 AM, Svatopluk Kraus wrote:
 
  I have two NIC on same NET (both are up). If a NIC which installs
  network route is going down then an error happens during network route
  replacement (in_scrubprefix: err=17, new prefix add failed).
  
   I've done a little bit investigation. In rtinit1(), before
  rtrequest1_fib() is called, info.rti_flags is initialized by flags
  (function argument) or-ed with ifa-ifa_flags. Both NIC has a loopback
  route to itself, so IFA_RTSELF is set on ifa(s). As IFA_RTSELF is
  defined by RTF_HOST, rtrequest1_fib() is called with RTF_HOST flag
  even if netmask is not NULL. Consequently, netmask is set to zero in
  rtrequest1_fib(), and request to add network route is changed under
  hands to request to add host route. It is the reason of logged info
  and my problem.
  
   When I've done more investigation, it looks similar to
  http://svnweb.freebsd.org/base?view=revisionrevision=201543. So, I
  propose the following patch.
  
  Index: sys/net/route.c
  ===
  --- sys/net/route.c (revision 224635)
  +++ sys/net/route.c (working copy)
  @@ -1478,7 +1478,7 @@
   */
  bzero((caddr_t)info, sizeof(info));
  info.rti_ifa = ifa;
  -   info.rti_flags = flags | ifa-ifa_flags;
  +   info.rti_flags = flags | (ifa-ifa_flags  ~IFA_RTSELF);
  info.rti_info[RTAX_DST] = dst;
  /*
   * doing this for compatibility reason
  
  
   Is the patch sufficient?
  
   Svata
  ___
  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
 
 --
 Andrew Boyer  abo...@averesystems.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


___
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: Only display ACPI bootmenu key if ACPI is present

[Kevin Lo]

John Baldwin wrote:
 This patch changes the Forth code for the Beastie menu to only display the
 menu option to enable or disable ACPI if the loader detects ACPI.  This avoids
 displaying a menu item prompting to enable ACPI if the BIOS doesn't actually
 include ACPI.  Any objections?

I have no objection. This patch makes sense to me.

Kevin

___
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