Re: Status on igb crash

[Alexandre Martins]

Hi Eric,

Thank you for the reply.

Regards,

-- 
Alexandre Martins
NETASQ -- We secure IT

Le mercredi 26 février 2014 10:50:48 Eric Joyner a écrit :
> Hi Alexandre,
> 
> We didn't put the fix into the repository because we think it would have
> had a significant impact on throughput. It fixed a crash, but that gotcha
> could potentially annoy everyone else using the driver who wasn't
> experiencing the same type of crash. That said, I'm going to look into that
> performance impact, and will try to submit a patch later without one.
> 
> ---
> - Eric Joyner
> 
> 
> On Wed, Feb 26, 2014 at 3:06 AM, Alexandre Martins <
> 
> alexandre.mart...@netasq.com> wrote:
> > Hi Eric,
> > 
> > In January, I have report a bug into igb driver :
> > 
> > http://lists.freebsd.org/pipermail/freebsd-current/2014-January/047827.htm
> > l
> > 
> > You send me a patch, but nothing was done into kernel sources.
> > 
> > Will it be planed to put a fix into the repository ?
> > 
> > Kind regards
> > 
> > --
> > Alexandre Martins
> > NETASQ -- We secure IT




smime.p7s
Description: S/MIME cryptographic signature

Re: kqueue for usb_dev

[Hans Petter Selasky]

On 02/27/14 08:42, Kohji Okuno wrote:

From: Hans Petter Selasky 

On 02/27/14 08:13, Kohji Okuno wrote:

Hi John-Mark,

Thank you for you comment.

From: John-Mark Gurney 

Kohji Okuno wrote this message on Thu, Feb 27, 2014 at 14:26 +0900:

I tried add kqueue I/F to usb_dev.c. I attached my patch.
What do you think about my patch?


A few comments...

1) You should just drop the use of flag_iskevent and just
unconditionally call KNOTE... since you have the lock already held,
the cost is minimal (and w/ modern branch prediction, may be cheaper)...


Should we set the use of flag_iskevent, when usb_filter_read() and
usb_filter_write() return `0'?



2) Why do you try to start read/write transfers in the _filter?  You
should just check to see if data is available and not do work..  This
is also important since kqueue calls the filter just before delivering
the knote to userland to verify that there is still data, and it will
call your _event function for each knote on the fd...  The work should
be started through other mechanisms, like read/write syscall or
interrupt or timeout/callout...  If it's required to get results from
USB_IF_POLL, then it's fine..


I copied from usb_poll().
Should we try to start read/write transfers in usb_kqfilter()?
Or should not we try to start read/write transfers in poll and kqueue?


3) I don't see any calls to knlist_destroy... These calls are needed
to clean up the knlist...


I understood.


Obviously the #if 1's will need to go...

Also, I don't think your change is against HEAD..  The line numbers
in my version of usb_dev.c are different...


I'm sorry.



Hi,

I've found two bugs:

1)


+#if 1
+   knlist_init_mtx(&f_tx->selinfo.si_note, f_rx->priv_mtx);
+#endif

Should be:

+#if 1
+   knlist_init_mtx(&f_tx->selinfo.si_note, f_tx->priv_mtx);
+#endif


2)

Event filters need to lock the FIFO's mutex.

BTW: I'm working on getting the code into -HEAD. I'll run some test before it
goes in.


Hi,

Thank you for you comment.
1) You are right.

2) I think that priv_mtx is hold in caller function.
Would you refer to kqueue_scan() in kern/kern_event.c?



Hi,

You are right!

I will add an assert there instead.

--HPS

___
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

[Joe Nosay]

On Wed, Feb 26, 2014 at 11:19 PM, Xin Li  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/26/14 18:52, Joe Nosay wrote:
> > On Wed, Feb 26, 2014 at 9:19 PM, Brooks Davis 
> > 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,
> - --
> Xin LI https://www.delphij.net/
> FreeBSD - The Power to Serve!   Live free or die
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (FreeBSD)
>
> iQIcBAEBCgAGBQJTDrzbAAoJEJW2GBstM+nsJVoP/29XRcleHMnAVa1UOG0+CD2y
> 0e/pAmk5vay599gjmiKSAuTSeKNaawRF3FZP+QsxhKw/lNTYEHlppUw7FDc01NqO
> pk1GsIu+mVuLlzZBNSuAkXdMMzJz5OKfY9GeK7Uw4iumiNP5LKpoC1RaYqLVASGf
> JH6tqJdSVnD+apWxV/PF4orCXZECFLkQZhbgZe+2nni+te6OfzIbkjhBqn8ZIDNY
> m9GbYwkTEATBDcMGgl9F0wBfcLhQLF4p4+TnsCguP0HAbxCtbZmt3SXe6Xt4y2YE
> iHlO/qstGKrl61aiehtpasjiljJaN5ucmuv8XDGbix4cghiJCJAGmxXGxCoHs/Uq
> vkn88wfV901pjYWPWf9HmTdjSmsck0k2+srWYlJuRymVKvMsL2mwPky+QL9SZ6MY
> NJ8kXUl5szFwdN4OtO+1iUvVZNLkVDlV5bmnc5KOkciFRoLuTq1/f/xzGj/YDZpx
> 2DxjddVyvJ6YhrUSSAGoOcdxIpDejKfVif0ANoocsKLAnTHtNxdB76doJH4wBl+W
> LAl9a9IqVOiefFe9qb6tZky3lft3HUe4XvLJPraKTfbvA9VAKPqZbc2Z8eeoqb49
> LPC2n8WnlnaXB9KXKSWTLXbdcY2L+HnAt2+DEv4viSyKSXQg00aEbm+R95h1pTz7
> oMv/8VGg5akyRQtkTTIx
> =ukUF
> -END PGP SIGNATURE-
>

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.
___
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: kqueue for usb_dev

[Hans Petter Selasky]

Hi Kohji,

Can you verify this commit:

http://svnweb.freebsd.org/changeset/base/262550

Please test using both read and write direction. For example you can use 
the ULPT driver or a /dev/usb/X.X.X node which supports both read and write.


Thank you!

--HPS
___
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: kqueue for usb_dev

[Hans Petter Selasky]

On 02/27/14 10:00, Hans Petter Selasky wrote:

Hi Kohji,

Can you verify this commit:

http://svnweb.freebsd.org/changeset/base/262550

Please test using both read and write direction. For example you can use
the ULPT driver or a /dev/usb/X.X.X node which supports both read and
write.

Thank you!

--HPS


And this commit too:
http://svnweb.freebsd.org/changeset/base/262551

Thank you!

--HPS
___
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: kqueue for usb_dev

[Kohji Okuno]

Hi HPS and John-Mark,

We should wait for empty of knlist before knlist_destroy().
When I tried 262551, the kernel panic at KN_LIST_LOCK(kn) in
kern_event.c.

Regards,
 Kohji Okuno

> On 02/27/14 10:00, Hans Petter Selasky wrote:
>> Hi Kohji,
>>
>> Can you verify this commit:
>>
>> http://svnweb.freebsd.org/changeset/base/262550
>>
>> Please test using both read and write direction. For example you can use
>> the ULPT driver or a /dev/usb/X.X.X node which supports both read and
>> write.
>>
>> Thank you!
>>
>> --HPS
> 
> And this commit too:
> http://svnweb.freebsd.org/changeset/base/262551
> 
> Thank you!
> 
> --HPS
> ___
> 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: kqueue for usb_dev

[Kohji Okuno]

Hi HPS and John-Mark,

After I changed as the following, the kernel panic does not happen.
What do you think about this change?

+   knlist_clear(&f->selinfo.si_note, 0);
knlist_destroy(&f->selinfo.si_note);
 
Regards,
 Kohji Okuno

> We should wait for empty of knlist before knlist_destroy().
> When I tried 262551, the kernel panic at KN_LIST_LOCK(kn) in
> kern_event.c.
> 
> Regards,
>  Kohji Okuno
> 
>> On 02/27/14 10:00, Hans Petter Selasky wrote:
>>> Hi Kohji,
>>>
>>> Can you verify this commit:
>>>
>>> http://svnweb.freebsd.org/changeset/base/262550
>>>
>>> Please test using both read and write direction. For example you can use
>>> the ULPT driver or a /dev/usb/X.X.X node which supports both read and
>>> write.
>>>
>>> Thank you!
>>>
>>> --HPS
>> 
>> And this commit too:
>> http://svnweb.freebsd.org/changeset/base/262551
>> 
>> Thank you!
>> 
>> --HPS
>> ___
>> 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"
___
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: kqueue for usb_dev

[Hans Petter Selasky]

On 02/27/14 11:39, Kohji Okuno wrote:

Hi HPS and John-Mark,

After I changed as the following, the kernel panic does not happen.
What do you think about this change?

+   knlist_clear(&f->selinfo.si_note, 0);
 knlist_destroy(&f->selinfo.si_note);

Regards,
  Kohji Okuno



Can you try the attached patch instead?

--HPS

=== usb_dev.c
==
--- usb_dev.c	(revision 262555)
+++ usb_dev.c	(local)
@@ -561,8 +561,8 @@
 	return (0);
 }
 
-void
-usb_fifo_free(struct usb_fifo *f)
+static void
+usb_fifo_destroy(struct usb_fifo *f)
 {
 	uint8_t n;
 
@@ -618,7 +618,16 @@
 
 	/* take care of closing the device here, if any */
 	usb_fifo_close(f, 0);
+}
 
+static void
+usb_fifo_free(struct usb_fifo *f)
+{
+	if (f == NULL) {
+		/* be NULL safe */
+		return;
+	}
+
 	cv_destroy(&f->cv_io);
 	cv_destroy(&f->cv_drain);
 
@@ -1867,6 +1876,8 @@
 	f_rx = usb_fifo_alloc(priv_mtx);
 
 	if ((f_tx == NULL) || (f_rx == NULL)) {
+		usb_fifo_destroy(f_tx);
+		usb_fifo_destroy(f_rx);
 		usb_fifo_free(f_tx);
 		usb_fifo_free(f_rx);
 		return (ENOMEM);
@@ -1989,6 +2000,13 @@
 	if (f_sc == NULL) {
 		return;
 	}
+	usb_fifo_destroy(f_sc->fp[USB_FIFO_TX]);
+	usb_fifo_destroy(f_sc->fp[USB_FIFO_RX]);
+
+	usb_destroy_dev(f_sc->dev);
+
+	f_sc->dev = NULL;
+
 	usb_fifo_free(f_sc->fp[USB_FIFO_TX]);
 	usb_fifo_free(f_sc->fp[USB_FIFO_RX]);
 
@@ -1995,10 +2013,6 @@
 	f_sc->fp[USB_FIFO_TX] = NULL;
 	f_sc->fp[USB_FIFO_RX] = NULL;
 
-	usb_destroy_dev(f_sc->dev);
-
-	f_sc->dev = NULL;
-
 	DPRINTFN(2, "detached %p\n", f_sc);
 }
 
=== usbdi.h
==
--- usbdi.h	(revision 262555)
+++ usbdi.h	(local)
@@ -614,6 +614,5 @@
 void	*usb_fifo_softc(struct usb_fifo *fifo);
 void	usb_fifo_set_close_zlp(struct usb_fifo *, uint8_t);
 void	usb_fifo_set_write_defrag(struct usb_fifo *, uint8_t);
-void	usb_fifo_free(struct usb_fifo *f);
 #endif /* _KERNEL */
 #endif /* _USB_USBDI_H_ */
___
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: kqueue for KBD.

[Kohji Okuno]

Hi John-Mark,

Thank you for your comment.
I added knote_clear() and knote_destroy() in kbd_detach(). I attached
patch, again. But, maybe this patch can not resolve all cases you
pointed.

Regards,
 Kohji Okuno

> Kohji Okuno wrote this message on Thu, Feb 27, 2014 at 14:24 +0900:
>> I tried to add kqueue I/F to kbd.c. I attached patch.
>> What do you think about my patch?
> 
> So, knlist_destroy is missing in this patch too..
> 
> It also needs some style(9) loving in that some blank lines are missing
> and there are some extra curly braces...
> 
> So, knlist_clear is usually used for something like close where it
> cannot be used again...  You use knlist_clear when the kbd goes away,
> but this also means that the user will never be notified that the kbd
> has gone, and could possibly end up leaking resources...
> 
> I guess I should maybe write a function knlist_clearerr or something
> that detaches all the knotes from the knlist and sets the proper flag
> so that they can be reaped by userland...  I believe your usb patch
> had a similar issue and some of the other drivers have this issue too..
> 
> Otherwise looks good...
> 
> -- 
>   John-Mark GurneyVoice: +1 415 225 5579
> 
>  "All that I will do, has been done, All that I have, has not."
diff --git a/sys/dev/kbd/kbd.c b/sys/dev/kbd/kbd.c
index 8036762..26dcaad 100644
--- a/sys/dev/kbd/kbd.c
+++ b/sys/dev/kbd/kbd.c
@@ -59,6 +59,7 @@ typedef struct genkbd_softc {
 	char		gkb_q[KB_QSIZE];		/* input queue */
 	unsigned int	gkb_q_start;
 	unsigned int	gkb_q_length;
+	unsigned int	gkb_index;
 } genkbd_softc_t;
 
 static	SLIST_HEAD(, keyboard_driver) keyboard_drivers =
@@ -472,6 +473,7 @@ static d_read_t		genkbdread;
 static d_write_t	genkbdwrite;
 static d_ioctl_t	genkbdioctl;
 static d_poll_t		genkbdpoll;
+static d_kqfilter_t	genkbdkqfilter;
 
 
 static struct cdevsw kbd_cdevsw = {
@@ -483,12 +485,14 @@ static struct cdevsw kbd_cdevsw = {
 	.d_write =	genkbdwrite,
 	.d_ioctl =	genkbdioctl,
 	.d_poll =	genkbdpoll,
+	.d_kqfilter =	genkbdkqfilter,
 	.d_name =	"kbd",
 };
 
 int
 kbd_attach(keyboard_t *kbd)
 {
+	genkbd_softc_t *sc;
 
 	if (kbd->kb_index >= keyboards)
 		return (EINVAL);
@@ -498,8 +502,11 @@ kbd_attach(keyboard_t *kbd)
 	kbd->kb_dev = make_dev(&kbd_cdevsw, kbd->kb_index, UID_ROOT, GID_WHEEL,
 	0600, "%s%r", kbd->kb_name, kbd->kb_unit);
 	make_dev_alias(kbd->kb_dev, "kbd%r", kbd->kb_index);
-	kbd->kb_dev->si_drv1 = malloc(sizeof(genkbd_softc_t), M_DEVBUF,
+	sc = malloc(sizeof(genkbd_softc_t), M_DEVBUF,
 	M_WAITOK | M_ZERO);
+	kbd->kb_dev->si_drv1 = sc;
+	sc->gkb_index = KBD_INDEX(kbd->kb_dev);
+	knlist_init_mtx(&sc->gkb_rsel.si_note, NULL);
 	printf("kbd%d at %s%d\n", kbd->kb_index, kbd->kb_name, kbd->kb_unit);
 	return (0);
 }
@@ -507,12 +514,17 @@ kbd_attach(keyboard_t *kbd)
 int
 kbd_detach(keyboard_t *kbd)
 {
+	genkbd_softc_t *sc;
 
 	if (kbd->kb_index >= keyboards)
 		return (EINVAL);
 	if (keyboard[kbd->kb_index] != kbd)
 		return (EINVAL);
 
+	sc = kbd->kb_dev->si_drv1;
+	knlist_clear(&sc->gkb_rsel.si_note, 0);
+	knlist_destroy(&sc->gkb_rsel.si_note);
+
 	free(kbd->kb_dev->si_drv1, M_DEVBUF);
 	destroy_dev(kbd->kb_dev);
 
@@ -697,6 +709,71 @@ genkbdioctl(struct cdev *dev, u_long cmd, caddr_t arg, int flag, struct thread *
 	return (error);
 }
 
+static void
+genkbd_kqops_detach(struct knote *kn)
+{
+	genkbd_softc_t *sc;
+	sc = kn->kn_hook;
+	knlist_remove(&sc->gkb_rsel.si_note, kn, 0);
+}
+
+static int
+genkbd_kqops_event(struct knote *kn, long hint)
+{
+	keyboard_t *kbd;
+	genkbd_softc_t *sc;
+
+	sc = kn->kn_hook;
+	kbd = kbd_get_keyboard(sc->gkb_index);
+
+	if ((kbd == NULL) || !KBD_IS_VALID(kbd)) {
+		return 1;	/* the keyboard has gone */
+	}
+	else {
+		if (sc->gkb_q_length > 0)
+			return 1;
+		else
+			return 0;
+	}
+
+}
+static struct filterops genkbd_kqops =
+{
+	.f_isfd		= 1,
+	.f_attach	= NULL,
+	.f_detach	= genkbd_kqops_detach,
+	.f_event	= genkbd_kqops_event,
+};
+static int
+genkbdkqfilter(struct cdev *dev, struct knote *kn)
+{
+	keyboard_t *kbd;
+	genkbd_softc_t *sc;
+	int error = 0;
+	int s;
+
+	s = spltty();
+	sc = dev->si_drv1;
+	kbd = kbd_get_keyboard(KBD_INDEX(dev));
+	if ((sc == NULL) || (kbd == NULL) || !KBD_IS_VALID(kbd)) {
+		error = EIO;
+	}
+	else  {
+		switch (kn->kn_filter) {
+		case EVFILT_READ:
+			kn->kn_fop = &genkbd_kqops;
+			kn->kn_hook = (void *)sc;
+			knlist_add(&sc->gkb_rsel.si_note, kn, 0);
+			break;
+		default:
+			error = EOPNOTSUPP;
+			break;
+		}
+	}
+	splx(s);
+	return (error);
+}
+
 static int
 genkbdpoll(struct cdev *dev, int events, struct thread *td)
 {
@@ -744,6 +821,7 @@ genkbd_event(keyboard_t *kbd, int event, void *arg)
 			wakeup(sc);
 		}
 		selwakeuppri(&sc->gkb_rsel, PZERO);
+		KNOTE_UNLOCKED(&sc->gkb_rsel.si_note, 0);
 		return (0);
 	default:
 		return (EINVAL);
@@ -814,6 +892,7 @@ genkbd_event(keyboard_t *kbd, int event, void *arg)
 			wakeup(sc);
 		}
 		selwakeuppri(&sc->gkb_rsel, PZERO);
+		KNOTE_UNLOCKED(&sc->gkb_rsel.si_note, 0);
 	

Re: kqueue for KBD.

[Hans Petter Selasky]

On 02/27/14 11:59, Kohji Okuno wrote:

+   sc = kbd->kb_dev->si_drv1;
+   knlist_clear(&sc->gkb_rsel.si_note, 0);
+   knlist_destroy(&sc->gkb_rsel.si_note);
+
free(kbd->kb_dev->si_drv1, M_DEVBUF);
destroy_dev(kbd->kb_dev);


Hi,

You should put the "knlist_destroy()" after the "destroy_dev()" and 
leave out the "knlist_clear()" I think! Because "destroy_dev()" is a 
synchronous function which ensure that all character device refs are 
gone including knotes, if I'm not mistaken.


--HPS
___
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: kqueue for usb_dev

[Kohji Okuno]

Hi HPS,

Your patch did not resolve the kernel panic.
I think, we should check knlist_clear() before knlist_destroy().
When a device is lost suddenly, usb_dev notify to a process in
usb_fifo_close() and then calls knlist_destroy(). knlist_destroy()
clears knlist->kn_lock and knlist->kn_unlock.

But, the process that is notified will start over kqueue_scan() after
knlist_destroy(). And, in KN_LIST_LOCK(kn), the context will call NULL
function (kn->knlist->kn_lock).

Regards,
 Kohji Okuno

> On 02/27/14 11:39, Kohji Okuno wrote:
>> Hi HPS and John-Mark,
>>
>> After I changed as the following, the kernel panic does not happen.
>> What do you think about this change?
>>
>> +   knlist_clear(&f->selinfo.si_note, 0);
>>  knlist_destroy(&f->selinfo.si_note);
>>
>> Regards,
>>   Kohji Okuno
>>
> 
> Can you try the attached patch instead?
> 
> --HPS
> 
___
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: iwn(4) in -HEAD supporting Centrino Wireless-N 135

[Tom Murphy]

Hi Adrian,

  If I set -ht on wlan0 it works. I have to put it in rc.conf for it to
work, though.

ifconfig_wlan0="DHCP WPA -country GB -ht"

  So it does look like 11n isn't right.

Kind regards,
Tom

On Wed, Feb 26, 2014 at 11:32:17PM -0800, Adrian Chadd wrote:
> Yeah, try to verify if it's this or not.
> 
> It's quite possible that there's some NIC setup for 11n that isn't
> completely correct.
> 
> 
> -a
> 
> 
> 
> On 26 February 2014 23:23, Alexandr  wrote:
> > May be it is similar to my problem. It connects to AP for a few seconds
> > and then drop a connection. It situation 100% reproducible in 11n mode,
> > but in 11g works fine.
> >
> > http://docs.freebsd.org/cgi/mid.cgi?5304B48E.8070404
> >
> > 26.02.2014 17:09, Adrian Chadd пишет:
> >> Hi,
> >>
> >> Yeah, there's likely something missing. But I just at the moment have
> >> no time to debug this.
> >>
> >>
> >> -a
> >>
> >>
> >> On 26 February 2014 04:37, Tom Murphy  wrote:
> >>> Hi all,
> >>>
> >>>   I compiled a fresh kernel from -HEAD and rebooted in the hope that my
> >>> laptop's wifi would now be supported (I saw the commit messages in January
> >>> about it possibly supporting Centrino Wireless-N 135). However, while
> >>> it does attempt to bring the wifi up, the link just goes up and down
> >>> and does not work properly.
> >>>
> >>>   Knowing that the BSDs are fairly close and share some code, I did try
> >>> the OpenBSD driver and it works. Is there some code that could be missing
> >>> from the FreeBSD iwn(4) to stabilize it? I'd be happy to test any patches.
> >>>
> >>> Kind regards,
> >>> Tom
> >>>
> >>> wlan0: no link ..wlan0: link state changed to UP
> >>> wlan0 link stage up -> down
> >>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14
> >>> DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 7
> >>> wlan0: link state changed to UP
> >>> wlan0: link state down -> up
> >>> (more DHCPDISCOVER)
> >>> wlan0 link stage up -> down
> >>>
> >>> Rise and repeat.
> >>>
> >>> iwn0:  mem 0xf790-0xf7901fff irq 18 at 
> >>> device 0.0 on pci3
> >>>
> >>> ___
> >>> 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"
> >
> > ___
> > 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"

py.sqlite3 fails to build in firefox port

[buddha]

cc: error: unknown argument: '-R/usr/local/lib'

Python build finished, but the necessary bits to build these modules were not 
found:
_bsddb _tkinter   dl  
imageoplinuxaudiodev  ossaudiodev 
spwd   sunaudiodev
To find the necessary bits, look in setup.py in detect_modules() for the 
module's name.


Failed to build these modules:
_sqlite3  

running build_scripts


This is the output from the /py-sqlite3/work/Python-2.7.6 directory.

In the /www/firefox port the compilation fails with:
cc: error: unknown argument: '-R/usr/local/lib'
error: command 'cc' failed with exit status 1
*** Error code 1

Here is my pkg info for python utils
py27-libxml2-2.8.0 Python interface for XML parser library for GNOME
py27-setuptools-2.0.1  Python packages installer
python-2.7_1,2 The "meta-port" for the default version of 
Python interpreter
python2-2_2The "meta-port" for version 2 of the Python 
interpreter
python27-2.7.6_2   Interpreted object-oriented programming language
___
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: py.sqlite3 fails to build in firefox port

[Scot Hetzel]

On Thu, Feb 27, 2014 at 8:26 AM, buddha  wrote:
> cc: error: unknown argument: '-R/usr/local/lib'
>
> Python build finished, but the necessary bits to build these modules were not 
> found:
> _bsddb _tkinter   dl
> imageoplinuxaudiodev  ossaudiodev
> spwd   sunaudiodev
> To find the necessary bits, look in setup.py in detect_modules() for the 
> module's name.
>
>
> Failed to build these modules:
> _sqlite3
>
> running build_scripts
>
>
> This is the output from the /py-sqlite3/work/Python-2.7.6 directory.
>
> In the /www/firefox port the compilation fails with:
> cc: error: unknown argument: '-R/usr/local/lib'
> error: command 'cc' failed with exit status 1
> *** Error code 1
>
> Here is my pkg info for python utils
> py27-libxml2-2.8.0 Python interface for XML parser library for 
> GNOME
> py27-setuptools-2.0.1  Python packages installer
> python-2.7_1,2 The "meta-port" for the default version of 
> Python interpreter
> python2-2_2The "meta-port" for version 2 of the Python 
> interpreter
> python27-2.7.6_2   Interpreted object-oriented programming 
> language

Try the following patch to lang/python27:

http://docs.freebsd.org/cgi/mid.cgi?CAALwa8m9-dpiO4fpA_BG-QeZyo9wsRpDVXHz_CTNUYeFLK7GVA

If someone could commit the patch, it would fix this issue for all
users that are using clang 3.4.

-- 
DISCLAIMER:

No electrons were maimed while sending this message. Only slightly bruised.
___
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: firebox build fails post clang-3.4 merge

[Garrett Wollman]

In article <530ea5cd.2070...@protected-networks.net>,
i...@protected-networks.net writes:

> .. way back in the late 70's or maybe early 80's when I was
>actually doing some work on compilers, we had a saying: "produce correct
>code even if it's not optimal or exit and tell the user why".
>
>Producing non-working code for no apparent reason and without warning is
>counter-productive. It wastes everyone's time :-(

When the specification of "correct" says that anything can happen,
including but not limited to the program crashing at runtime, there's
no limit on what the compiler may emit.  (On the other hand, I agree
that if the compiler emits a "crashme" instruction, it really ought to
generate a diagnostic as well, even if it can't explain why.)

Originially this "escape hatch" was intended to apply to conditions
that the compiler could not detect (or at least, the historical PCC
could not detect), but nowadays the compiler writers take it upon
themselves to deliberately break programs that involve undefined
behavior, even when there is an entirely sensible way to define the
behavior which is consonant with the way the machine architecture
works and how historical compilers have implemented the same
construct.  For example, the following program:

#include 

extern long l;

int
main(void) {
l = LONG_MAX;
l++;
return l > 0;
}

..is permitted to crash, but it's also permitted to do nothing, and
it's permitted to set l to LONG_MIN (following the normal
two's-complement arithmetic on signed values).  The compilers I
checked actually did the obvious thing, but they are older versions.

-GAWollman

___
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: firebox build fails post clang-3.4 merge

[David Chisnall]

On 27 Feb 2014, at 02:41, Michael Butler  wrote:

>  .. way back in the late 70's or maybe early 80's when I was
> actually doing some work on compilers, we had a saying: "produce correct
> code even if it's not optimal or exit and tell the user why".

In the late '70s, the number of transforms that a compiler could do were quite 
limited.  By the time the code gets to the back end in a modern compiler, it is 
often very difficult to map back to the source code and print a diagnostic more 
helpful than 'something in your program was undefined behaviour'.  This is why 
clang includes both static and dynamic checkers for undefined behaviour, in the 
form of the static analyser (you do run it on all code you right, don't you?) 
and the undefined behaviour sanitiser.

LLVM uses ud2 for the trap intrinsic.  This can be generated for several 
reasons, for example:

- __builtin_trap() in the source code (sometimes used to trigger immediate 
termination when the program detects that it is in an indeterminate state)

- __builtin_unreachable() in some source code, which turns out to be reachable 
after all.  This builtin is used to produce better code by telling the compiler 
that certain code paths can't possibly be reached, but sometimes the compiler 
will leave in dynamic checks to abort if it detects that something that the 
user flagged as unreachable actually wasn't.

- Control flow hits a code path that the language semantics say is undefined or 
impossible.  This is generally considered better than continuing in an 
undefined state, on the basis that it's much easier to exploit a program that 
is running in an undefined state than one that has just exited.

- There is a compiler bug.

David

___
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: iwn(4) in -HEAD supporting Centrino Wireless-N 135

[Adrian Chadd]

On 26 February 2014 23:52, Alexandr  wrote:
> Tom, could you:
>
> 1. compile kernel WITH_IWNDEBUG
> 2. sysctl dev.iwn.0.debug=0x1
> 3. wlandebug -i wlan0 auth+assoc
> 4. Associate with AP in 11n mode
> 5. Send us appropriate /var/log/messages
>
> Then I try to compare it with my log.

Please do. I've been trying to track down the source of this "ht just
doesn't work!" but it works fine with all of the Intel NICs I have
here.

Can someone see if they can find a mtaching NIC online (amazon,ebay?)
Owning one that I can whack in a laptop is likely going ot help things
a lot.

Thanks,


-a
___
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: BSD XXI Manifesto [mDNS proposal]

[Matthew Rezny]

> On 21 February 2014 20:59, Allan Jude  wrote:
> > I can see the remote controlled installer being especially useful for
> > 'appliance' type devices, like FreeNAS, pfSense, FUDO, etc.
> > 
> > How would your phone find the address of the machine once it boots off
> > the USB, so you could access the web server?
> 
> "what apple does."
> 
> 
> 
> -a

The solution used by Apple is mDNS and it does work rather well. When 
installing in unstructured environments, I find it quite handy to install 
Apple's mDNSresponder as part of the basic FreeBSD configuration for no reason 
other than the ability to "ssh [hostname]" from any box to access any other 
box on the network. For completely ad-hoc networks, IPv4LL is also useful in 
conjunction with mDNS.

I think it is time that FreeBSD gains support in base for these ZeroConf 
technologies. Thus, I propose a simple plan to do so.

IPv4LL is supported by dhcpcd in NetBSD. We could use this code in our 
dhclient, or we could simply import their dhcpcd either as replacement for or 
alternate to our dhclient. The choice of approach I leave open to those more 
familiar with our dhclient. The import part is the configuration.

By default, the DHCP client should fallback to IPv4LL if no DHCP server is 
found. This should be the behavior for any interface configured for DHCP i.e. 
ifconfig_[ethif]="DHCP". There also must be a way to disable IPv4LL to enforce 
use of DHCP in environments where it should be present, for which I propose 
the notation ifconfig_[ethif]="DHCP-NOLL". If IPv4LL is in active use, the DHCP 
client should continue to periodically look for a DHCP server and obtain a 
lease without manual user intervention (which is unfortunately required on 
both OS X and Windows, leading to sub-optimal experience in cases of temporary 
unavailability of the DHCP server). When obtaining a lease later, the IPv4LL 
assigned address should still remain as an alias to prevent closure of active 
connections when DHCP becomes available.

Apple's mDNSresponder is currently available in ports. Their implementation 
uses the Apache license so I believe we should be able to import this into 
base without any license issues. The more feature-full Avahi, commonly used on 
Linux system, is also in ports but is LGPL so is not a good choice for base 
due to both size and license.

Use of mDNS should be based on the addressing scheme in use. If there are any 
static addresses, we should assume the admin knows how to reach the box, in 
which case they may enable mDNS. If the box is using purely dynamic addressing 
then we should assume the addresses may be unknown and mDNS will be useful, 
perhaps essential, for locating and accessing the machine. The admin should 
always be able to force mDNS either on or off. Therefore I suggest the rc.conf 
variable MDNS_ENABLE with possible values AUTO, YES, NO. MDNS_ENABLE="AUTO" 
should be the default and should implement the above logic; iff all interfaces 
mentioned in rc.conf are not using static addresses then equivalent to YES, 
otherwise NO. The YES and NO settings turn it on and off as expected.

The result is a fresh install that is configured for automatic addressing 
should always have some valid network address and be findable by a known name. 
For headless installation, the installer should have a timeout on the network 
configuration, after which all interfaces attempt DHCP with IPv4LL fallback and 
hostname defaults to "FreeBSD-Install". For the case of several machines all 
being installed at once, mDNS resolution should be used to check if that name 
is already in use and if so append a "-nnn" where nnn is a number to make the 
names unique. On first boot after installation, the configured hostname will be 
used if mDNS in enabled according to the above rules.

Comments?

___
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: BSD XXI Manifesto [mDNS proposal]

[Lyndon Nerenberg]

On Feb 27, 2014, at 12:20 PM, Matthew Rezny  wrote:

> If IPv4LL is in active use, the DHCP 
> client should continue to periodically look for a DHCP server and obtain a 
> lease without manual user intervention (which is unfortunately required on 
> both OS X and Windows, leading to sub-optimal experience in cases of 
> temporary 
> unavailability of the DHCP server).

That's not true for Mac OS.  If you have an interface configured to use DHCP, 
and the Mac is unable to renew the lease, it will automatically configure a 
169.254.x.y address on the interface.  All the while it continues its attempts 
to renew the DHCP lease and, once successful, removes the 169.254.x.y address 
from the interface.

--lyndon


signature.asc
Description: Message signed with OpenPGP using GPGMail

Feature Proposal: Transparent upgrade of crypt() algorithms

[Allan Jude]

With r262501
(http://svnweb.freebsd.org/base?view=revision&revision=262501) importing
the upgraded bcrypt from OpenBSD and eventually changing the default
identifier for bcrypt to $2b$ it reminded me of a feature that is often
seen in Forum software and other web apps.

Transparent algorithm upgrade.

Excuse the sloppy pseudo-code:

new_format = login_conf.get('passwd_format')

username = user.input()
plain_pass = user.input()

hash = master.passwd.get(username)
salt = hash.get_salt()

if (crypt(plain_pass, salt) == hash) {
/* Successful login */
if (crypt_get_format(hash) != new_format) {
/* Upgrade crypt() algorithm */
crypt_set_format(new_format)
new_salt = random()
new_hash = crypt(plain_pass, new_salt)
result = master.passwd.set_password(username, new_hash)
}
} else {
/* Unsuccessful login */
}

Basically, when a user successfully authenticates, if some new option is
enabled in login.conf, use the plain text password attempt while we have
it, to re-hash the password with the new algorithm and update the
master.passwd file

This would make it much easier to transition a very large userbase from
md5crypt to bcrypt or sha512crypt, rather than expiring the passwords or
something.

This might actually be more applicable with my next suggestion, exposing
tuneables to control the number of rounds for bcrypt and sha512crypt. As
this would make it easy to upgrade all existing bcrypt/sha512crypt
hashes from the default number of rounds (10^4 and 5000 respectively) to
higher values.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Feature Proposal: 'rounds' tuneables for crypt() algorithms

[Allan Jude]

Currently, you can change the password hashing algorithm used by crypt()
with the passwd_format in /etc/login.conf

However, as far as I could find, you cannot change the number of
'rounds', the dynamic adjustment factor using in bcrypt, and
sha256crypt, and sha512crypt.

bcrypt uses a log number, the default is 4 (so 2^4 rounds). The minimum
is currently 4, and the maximum 31

sha256 and sha512crypt default to 5000, with a minimum of 1000 and a
maximum of 9

OpenBSD implements this in login.conf with 'localcipher' similar to our
'passwd_format', except it takes an optional 2nd parameter, the number
of log2() rounds.

Arch implements this in pam_unix with rounds=

For compatibility, it might make most sense to use a separate variable
rather than adding the optional parameter to the existing passwd_format,
so older boxes do not choke on it.

Thoughts?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

Re: Feature Proposal: 'rounds' tuneables for crypt() algorithms

[John-Mark Gurney]

Allan Jude wrote this message on Thu, Feb 27, 2014 at 20:28 -0500:
> Currently, you can change the password hashing algorithm used by crypt()
> with the passwd_format in /etc/login.conf
> 
> However, as far as I could find, you cannot change the number of
> 'rounds', the dynamic adjustment factor using in bcrypt, and
> sha256crypt, and sha512crypt.
> 
> bcrypt uses a log number, the default is 4 (so 2^4 rounds). The minimum
> is currently 4, and the maximum 31
> 
> sha256 and sha512crypt default to 5000, with a minimum of 1000 and a
> maximum of 9
> 
> OpenBSD implements this in login.conf with 'localcipher' similar to our
> 'passwd_format', except it takes an optional 2nd parameter, the number
> of log2() rounds.
> 
> Arch implements this in pam_unix with rounds=
> 
> For compatibility, it might make most sense to use a separate variable
> rather than adding the optional parameter to the existing passwd_format,
> so older boxes do not choke on it.
> 
> Thoughts?

There is already a patch out there to do this..  It basicly adds a string
to login.conf that is the first part of the crypt that you want to
use which will provide the number of rounds too...  I think it was
posted to -current...

I've been meaning to look at adding it...  The reason I'm interested
in doing this is so that we can configure the number of rounds at boot
time...  Say always take 50ms to run the rounds or a minimum number of
rounds..  This way on faster boxes you get added security of extra


-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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"

Centrino Wireless-N 1000 support is also broken (Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135)

[Kaho Toshikazu]

  Hello, -current members

  I have a similar problem with Centrino Wireless-N 1000.
It operated until r257951 and have a trouble after r258030.
I use r262433 kernel with sys/dev/iwn reverted to r257951
and changed from IEEE80211_FC1_WEP to EEE80211_FC1_PROTECTED.

r262422 if_iwn module with IWN_DEBUG in opt_iwn.h and dev.iwn.0.debug=1 says:

-- output of `dmesg -a` --
iwn0:  mem 0xd250-0xd2501fff irq 19 at 
device 0.0 on pci2
wlan0: Ethernet address: 00:1e:64:45:f5:64
iwn0: iwn_setregdomain: invalid channel 8 freq 2447/0x20480
iwn_notif_intr: scanning channel 1 status 1
iwn_notif_intr: scanning channel 6 status 1
iwn_notif_intr: scanning channel 11 status 1
iwn_notif_intr: scanning channel 7 status 1
iwn_notif_intr: scanning channel 13 status 1
iwn_notif_intr: scanning channel 2 status 1
iwn_notif_intr: scanning channel 3 status 1
iwn_notif_intr: scanning channel 4 status 1
iwn_notif_intr: scanning channel 5 status 1
iwn_notif_intr: scanning channel 8 status 1
iwn_notif_intr: scanning channel 9 status 1
iwn_notif_intr: scanning channel 10 status 1
iwn_notif_intr: scanning channel 12 status 1
iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1
iwn5000_tx_done: qid 3 idx 0 retries 0 nkill 0 rate 420a duration 778 status 201
iwn_tx_data_raw: qid 3 idx 1 len 86 nsegs 1
iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 1418 status 
201
iwn_set_link_quality: 1stream antenna=0x01, 2stream antenna=0x03, ntxstreams=1
iwn_set_link_quality: i=0, txrate=7, rate=0x87
iwn_set_link_quality: i=1, txrate=6, rate=0x86
iwn_set_link_quality: i=2, txrate=5, rate=0x85
iwn_set_link_quality: i=3, txrate=4, rate=0x84
iwn_set_link_quality: i=4, txrate=3, rate=0x83
iwn_set_link_quality: i=5, txrate=2, rate=0x82
iwn_set_link_quality: i=6, txrate=1, rate=0x81
iwn_set_link_quality: i=7, txrate=0, rate=0x80
iwn_set_link_quality: i=8, txrate=0, rate=0x80
iwn_set_link_quality: i=9, txrate=0, rate=0x80
iwn_set_link_quality: i=10, txrate=0, rate=0x80
iwn_set_link_quality: i=11, txrate=0, rate=0x80
iwn_set_link_quality: i=12, txrate=0, rate=0x80
iwn_set_link_quality: i=13, txrate=0, rate=0x80
iwn_set_link_quality: i=14, txrate=0, rate=0x80
iwn_set_link_quality: i=15, txrate=0, rate=0x80
wlan0: link state changed to UP
iwn0: iwn_intr: fatal firmware error
firmware error log:
  error type  = "SYSASSERT" (0x0005)
  program counter = 0x00018DBC
  source line = 0x0032
  error data  = 0x0001
  branch link = 0x00018D6E00018D6E
  interrupt link  = 0x0826
  time= 1043083265
driver status:
  tx ring  0: qid=0  cur=0   queued=0  
  tx ring  1: qid=1  cur=0   queued=0  
  tx ring  2: qid=2  cur=0   queued=0  
  tx ring  3: qid=3  cur=2   queued=0  
  tx ring  4: qid=4  cur=57  queued=0  
  tx ring  5: qid=5  cur=0   queued=0  
  tx ring  6: qid=6  cur=0   queued=0  
  tx ring  7: qid=7  cur=0   queued=0  
  tx ring  8: qid=8  cur=0   queued=0  
  tx ring  9: qid=9  cur=0   queued=0  
  tx ring 10: qid=10 cur=0   queued=0  
  tx ring 11: qid=11 cur=0   queued=0  
  tx ring 12: qid=12 cur=0   queued=0  
  tx ring 13: qid=13 cur=0   queued=0  
  tx ring 14: qid=14 cur=0   queued=0  
  tx ring 15: qid=15 cur=0   queued=0  
  tx ring 16: qid=16 cur=0   queued=0  
  tx ring 17: qid=17 cur=0   queued=0  
  tx ring 18: qid=18 cur=0   queued=0  
  tx ring 19: qid=19 cur=0   queued=0  
  rx ring: cur=55

-- output of `pciconf -lvcb` --
iwn0@pci0:2:0:0:class=0x028000 card=0x13058086 chip=0x00838086 rev=0x00 
hdr=0x00
vendor = 'Intel Corporation'
device = 'Centrino Wireless-N 1000 [Condor Peak]'
class  = network
bar   [10] = type Memory, range 64, base 0xd250, size 8192, enabled
cap 01[c8] = powerspec 3  supports D0 D3  current D0
cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR link x1(x1)
 speed 2.5(2.5) ASPM L1(L0s/L1)
ecap 0001[100] = AER 1 0 fatal 0 non-fatal 3 corrected
ecap 0003[140] = Serial 1 001e6445f564

--
Kaho Toshikazu
___
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: firebox build fails post clang-3.4 merge

[Michael Butler]

On 02/27/14 12:24, David Chisnall wrote:
> On 27 Feb 2014, at 02:41, Michael Butler  wrote:
> 
>>  .. way back in the late 70's or maybe early 80's when I was
>> actually doing some work on compilers, we had a saying: "produce correct
>> code even if it's not optimal or exit and tell the user why".

> In the late '70s, the number of transforms that a compiler could do
> were quite limited.  By the time the code gets to the back end in a
> modern compiler, it is often very difficult to map back to the source
> code and print a diagnostic more helpful than 'something in your
> program was undefined behaviour'.  This is why clang includes both
> static and dynamic checkers for undefined behaviour, in the form of
> the static analyser (you do run it on all code you right, don't you?)
> and the undefined behaviour sanitiser.

I guess what I'm trying to get at is that I am used to a compiler which
takes one of two actions, irrespective of the complexities of the source
language or target architecture ..

1) the compiler has no definitive translation of "semantic intent"
because the code is ambiguous - produces an error for the programmer to
that effect

2) the compiler has no idea how to translate unambiguous code into
functional machine code - produces an error for the compiler author(s)
benefit to expose missing code-generation cases

It seems that the current approach adopts a third action: embed
"land-mines" in the code without warning. I find this disturbing in the
extreme.

Can anyone say, without doubt, that there are none of these "land-mines"
in the kernel, libraries and utilities? If not, we just took a huge step
away from any kind of Information Assurance ..

Michael


___
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: BSD XXI Manifesto [mDNS proposal]

[Lyndon Nerenberg]

On Feb 27, 2014, at 15:59, Matthew Rezny  wrote:

> If they corrected that, it was after I abandoned the platform years ago.

It has been like that since at least 10.8.


And I am also tempted to say that Windows 7 acts the same, but I don't have one 
at hand to double check.
___
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"

About kevent

[Kohji Okuno]

Hi,

I have a question about kevent.

How should the userland judge knote which is cleared from knlist by
knlist_clear() or knlist_delete()?

Best regards,
 Kohji Okuno


___
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: BSD XXI Manifesto [mDNS proposal]

[Matthew Rezny]

On Thursday 27 February 2014 14:55:55 Lyndon Nerenberg wrote:
> On Feb 27, 2014, at 12:20 PM, Matthew Rezny  wrote:
> > If IPv4LL is in active use, the DHCP
> > client should continue to periodically look for a DHCP server and obtain a
> > lease without manual user intervention (which is unfortunately required on
> > both OS X and Windows, leading to sub-optimal experience in cases of
> > temporary unavailability of the DHCP server).
> 
> That's not true for Mac OS.  If you have an interface configured to use
> DHCP, and the Mac is unable to renew the lease, it will automatically
> configure a 169.254.x.y address on the interface.  All the while it
> continues its attempts to renew the DHCP lease and, once successful,
> removes the 169.254.x.y address from the interface.
> 
> --lyndon

If they corrected that, it was after I abandoned the platform years ago. I 
remember repeatedly pushing the Renew Lease button in the Network section of 
System Settings in frustration, waiting to see the address change.

___
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: Centrino Wireless-N 1000 support is also broken (Re: iwn(4) in -HEAD supporting Centrino Wireless-N 135)

[Adrian Chadd]

Hi,

Yes there are issues; I'm too busy to try and chase them down.

I'd appreciate some help in chasing down why things are unhappy.

Thanks,


-a



On 27 February 2014 17:17, Kaho Toshikazu  wrote:
>   Hello, -current members
>
>   I have a similar problem with Centrino Wireless-N 1000.
> It operated until r257951 and have a trouble after r258030.
> I use r262433 kernel with sys/dev/iwn reverted to r257951
> and changed from IEEE80211_FC1_WEP to EEE80211_FC1_PROTECTED.
>
> r262422 if_iwn module with IWN_DEBUG in opt_iwn.h and dev.iwn.0.debug=1 says:
>
> -- output of `dmesg -a` --
> iwn0:  mem 0xd250-0xd2501fff irq 19 at 
> device 0.0 on pci2
> wlan0: Ethernet address: 00:1e:64:45:f5:64
> iwn0: iwn_setregdomain: invalid channel 8 freq 2447/0x20480
> iwn_notif_intr: scanning channel 1 status 1
> iwn_notif_intr: scanning channel 6 status 1
> iwn_notif_intr: scanning channel 11 status 1
> iwn_notif_intr: scanning channel 7 status 1
> iwn_notif_intr: scanning channel 13 status 1
> iwn_notif_intr: scanning channel 2 status 1
> iwn_notif_intr: scanning channel 3 status 1
> iwn_notif_intr: scanning channel 4 status 1
> iwn_notif_intr: scanning channel 5 status 1
> iwn_notif_intr: scanning channel 8 status 1
> iwn_notif_intr: scanning channel 9 status 1
> iwn_notif_intr: scanning channel 10 status 1
> iwn_notif_intr: scanning channel 12 status 1
> iwn_tx_data_raw: qid 3 idx 0 len 6 nsegs 1
> iwn5000_tx_done: qid 3 idx 0 retries 0 nkill 0 rate 420a duration 778 status 
> 201
> iwn_tx_data_raw: qid 3 idx 1 len 86 nsegs 1
> iwn5000_tx_done: qid 3 idx 1 retries 0 nkill 0 rate 420a duration 1418 status 
> 201
> iwn_set_link_quality: 1stream antenna=0x01, 2stream antenna=0x03, ntxstreams=1
> iwn_set_link_quality: i=0, txrate=7, rate=0x87
> iwn_set_link_quality: i=1, txrate=6, rate=0x86
> iwn_set_link_quality: i=2, txrate=5, rate=0x85
> iwn_set_link_quality: i=3, txrate=4, rate=0x84
> iwn_set_link_quality: i=4, txrate=3, rate=0x83
> iwn_set_link_quality: i=5, txrate=2, rate=0x82
> iwn_set_link_quality: i=6, txrate=1, rate=0x81
> iwn_set_link_quality: i=7, txrate=0, rate=0x80
> iwn_set_link_quality: i=8, txrate=0, rate=0x80
> iwn_set_link_quality: i=9, txrate=0, rate=0x80
> iwn_set_link_quality: i=10, txrate=0, rate=0x80
> iwn_set_link_quality: i=11, txrate=0, rate=0x80
> iwn_set_link_quality: i=12, txrate=0, rate=0x80
> iwn_set_link_quality: i=13, txrate=0, rate=0x80
> iwn_set_link_quality: i=14, txrate=0, rate=0x80
> iwn_set_link_quality: i=15, txrate=0, rate=0x80
> wlan0: link state changed to UP
> iwn0: iwn_intr: fatal firmware error
> firmware error log:
>   error type  = "SYSASSERT" (0x0005)
>   program counter = 0x00018DBC
>   source line = 0x0032
>   error data  = 0x0001
>   branch link = 0x00018D6E00018D6E
>   interrupt link  = 0x0826
>   time= 1043083265
> driver status:
>   tx ring  0: qid=0  cur=0   queued=0
>   tx ring  1: qid=1  cur=0   queued=0
>   tx ring  2: qid=2  cur=0   queued=0
>   tx ring  3: qid=3  cur=2   queued=0
>   tx ring  4: qid=4  cur=57  queued=0
>   tx ring  5: qid=5  cur=0   queued=0
>   tx ring  6: qid=6  cur=0   queued=0
>   tx ring  7: qid=7  cur=0   queued=0
>   tx ring  8: qid=8  cur=0   queued=0
>   tx ring  9: qid=9  cur=0   queued=0
>   tx ring 10: qid=10 cur=0   queued=0
>   tx ring 11: qid=11 cur=0   queued=0
>   tx ring 12: qid=12 cur=0   queued=0
>   tx ring 13: qid=13 cur=0   queued=0
>   tx ring 14: qid=14 cur=0   queued=0
>   tx ring 15: qid=15 cur=0   queued=0
>   tx ring 16: qid=16 cur=0   queued=0
>   tx ring 17: qid=17 cur=0   queued=0
>   tx ring 18: qid=18 cur=0   queued=0
>   tx ring 19: qid=19 cur=0   queued=0
>   rx ring: cur=55
>
> -- output of `pciconf -lvcb` --
> iwn0@pci0:2:0:0:class=0x028000 card=0x13058086 chip=0x00838086 
> rev=0x00 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Centrino Wireless-N 1000 [Condor Peak]'
> class  = network
> bar   [10] = type Memory, range 64, base 0xd250, size 8192, enabled
> cap 01[c8] = powerspec 3  supports D0 D3  current D0
> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
> cap 10[e0] = PCI-Express 1 endpoint max data 128(128) FLR link x1(x1)
>  speed 2.5(2.5) ASPM L1(L0s/L1)
> ecap 0001[100] = AER 1 0 fatal 0 non-fatal 3 corrected
> ecap 0003[140] = Serial 1 001e6445f564
>
> --
> Kaho Toshikazu
> ___
> 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: py.sqlite3 fails to build in firefox port

[chessmaster]

http://svnweb.freebsd.org/ports/head/lang/python27/files/patch-Lib__distutils__unixccompiler.py?view=markup&sortby=date

Thanks! For the Fix.


On Thu, Feb 27, 2014 at 9:26 AM, buddha wrote:

> cc: error: unknown argument: '-R/usr/local/lib'
>
> Python build finished, but the necessary bits to build these modules were
> not found:
> _bsddb _tkinter   dl
> imageoplinuxaudiodev  ossaudiodev
> spwd   sunaudiodev
> To find the necessary bits, look in setup.py in detect_modules() for the
> module's name.
>
>
> Failed to build these modules:
> _sqlite3
>
> running build_scripts
>
>
> This is the output from the /py-sqlite3/work/Python-2.7.6 directory.
>
> In the /www/firefox port the compilation fails with:
> cc: error: unknown argument: '-R/usr/local/lib'
> error: command 'cc' failed with exit status 1
> *** Error code 1
>
> Here is my pkg info for python utils
> py27-libxml2-2.8.0 Python interface for XML parser library for
> GNOME
> py27-setuptools-2.0.1  Python packages installer
> python-2.7_1,2 The "meta-port" for the default version of
> Python interpreter
> python2-2_2The "meta-port" for version 2 of the Python
> interpreter
> python27-2.7.6_2   Interpreted object-oriented programming
> language
>
___
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: About kevent

[John-Mark Gurney]

Kohji Okuno wrote this message on Fri, Feb 28, 2014 at 11:13 +0900:
> I have a question about kevent.
> 
> How should the userland judge knote which is cleared from knlist by
> knlist_clear() or knlist_delete()?

It looks like I need to read the code better...  knlist_clear (killkn=0)
and knlist_delete (killkn=1) are wrappers around knlist_cleardel...

Looking at the code of knlist_cleardel, if killkn is set
(knlist_delete) the knote will be dropped (free'd)... if it is not set,
the flags _EOF and _ONESHOT will be set such that it'll be returned
soon..

Now that I look at the code, KNOTE_ACTIVATE is never called to be put
on the list to be delivered, so now I'm not sure if it works the way
it's suppose to... I have a feeling that the notes might hang around
forever until the kq fd is closed...

I'm also puzzled as to why _DETACHED isn't set, which would seem to
mean that we'll call f_detach when we close the kq, which I assume
could cause a panic...

This needs to be investigated/tested...

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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: firebox build fails post clang-3.4 merge

[Don Lewis]

On 26 Feb, Benjamin Kaduk wrote:
> On Wed, 26 Feb 2014, Don Lewis wrote:
> 
>> On 26 Feb, Michael Butler wrote:
>>> On 02/18/14 12:10, Michael Butler wrote:
 Is anyone else seeing firefox failing to install after the clang-3.4
 merge? As in xpcshell dumping core ..
>>>
>>> An update ..
>>>
>>> Recompiling with GCC48 on -current yields the same result. Seems to run
>>> correctly when invoked from the command-line but seg-faults with "errno
>>> = 4" (invalid instruction) from the build
>>>
>>> Giving up and using the Linux port .. :-(
>>
>> I've also seen this problem with clang-3.4 on i386.  It looks like a
>> clang bug to me.  Clang is putting ud2 instructions in its output which
>> are guaranteed to fault when it compiles nsAppRunner.cpp.  See
>> .
> 
> That would seem to indicate that clang believes the source code in 
> question is exercising a case which is explicitly listed as giving 
> undefined behavior in the language specification. Presumably that means we 
> need a C++ language lawyer to look over the code in question.

After spending the last couple of days pounding my head on my desk, I
managed to come up with a standalone test case that reproduces this
problem.  The source is still on the hefty side because of all the C++
template goo (but more than an order of magnitude smaller than when I
started) but the assembly code is fairly small.  If updated my PR with
the relevant info.

___
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"