Re: Wireless TCP aborts
On Sun, Mar 07, 2010 at 03:08:38PM -0800, Chuck Swiger wrote: > Hi, Tim-- > > On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote: > [ ... ] > > Corrupted MAC on input. > > Disconnecting: Packet corrupt > > rsync: connection unexpectedly closed ... [receiver] > > > > and then the rsync session is dead. > > > > It seems odd that a single corrupt packet would terminate the TCP > > connection. > > It's not TCP itself which is closing the connection; if a garbage packet as > far as TCP or IP layer checksums was seen, it would be dropped and normal > resend mechanisms would compensate. However, SSH adds it's own layer of data > integrity checking called HMAC, which uses block-based hashes like MD5 or > SHA, and is much stronger than the 32-bit CRCs used at TCP/IP layers. > > See: > >/usr/src/crypto/openssh/packet.c >http://en.wikipedia.org/wiki/HMAC > > The implication is that the data is being corrupted before it gets munged > into network packets; failing memory is a likely cause, but bugs in the > network stack, the NIC driver, or OpenSSL are also lower-order possibilities. long ago, with the 'iwi' driver, there was the following problem leading the the sae problem you are seeing: the driver was doing WEP in software, and wrote back the result to the original mbuf (actually, cluster). As a result, the first transmission of a segment was correct, but in case a rxmt, data would be encrypted twice, and the remote ssh end detected the garbage and dropped the connection. This was fixed with Sam's help around early 2007 if i remember well. An easy way to see if it is a similar problem is use ipfw to drop some packets e.g. ipfw add 100 prob 0.1 deny tcp out xmit wi0 // use your interface name cheers luigi ___ 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: propose: all arch move into a separate dir
On Sun, Mar 7, 2010 at 4:49 PM, M. Warner Losh wrote:
> In message: <20100308000203.ga70...@dragon.nuxi.org>
> "David O'Brien" writes:
> : On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
> : > In message: <20100307054423.ge70...@dragon.nuxi.org>
> : > "David O'Brien" writes:
> : > : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
> : > : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
> : > : >> In message ,
> Robert
> : > : >> Watso n writes:
> : > : >>> Doing that kind of rearrangement [...] would be a nightmare for
> anyone
> : > : >>> with large [...] patches, so I'd say we could pretty much rule that
> out
> : > : >>> outright.
> : > : >>
> : > : >> I would say that we should do it occasionally, to encourage these
> : > : >> FreeBSD users to contribute as many of their local changes back to
> : > : >> the project, as possible :-)
> : > : >
> : > : > Absolutely -- and rearranging a tree is a good way to invalidate
> : > : > all those patches as well :-).
> : > :
> : > : No, not it isn't. Provide a script to convert path's in the diff.
> : > : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
> : >
> : > You are joking, right? This would be a nightmare for people that
> : > integrate early and often.
> :
> :
> : No I am not joking. I was responding to the point that a large patch
> : (that is a the output of running '$SCM diff') can be easily modified to
> : match a new directory layout. Thus patches in GNATS aren't "useless".
>
> It seems like it would be a nightmare for anybody tracking the system
> on a regular basis.
>
> : I'm not sure what operation you are specifically speaking to . But, if
> : FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
> : do:
> :
> : cd sys
> : mkdir arch
> : svn add arch
> : svn mv {list of dirs} arch
> : svn ci
> :
> : and be done with it. Branches would merge that change - get a trivial
> : tree conflict, resolve it - and move on with life.
>
> And everybody who was tracking FreeBSD with their own changes would
> have to scramble. It wouldn't be trivial by any stretch of the
> imagination. The project is much larger than svn, and svn doesn't
> lend itself well to having external agents track it.
>
> : I would expect folks working in project branches to do the same.
> :
> : For merging changes from FreeBSD HEAD to FreeBSD stable - that is
> : trivial:
> :
> : cd sys
> : svn merge -c $GRN ^/head/sys/arch/amd64 amd64
> : svn ci
> :
> : Subversion makes this a lot easier than CVS did.
>
> Just because the task is doable with svn, where it was impossible with
> CVS doesn't mean there wouldn't be a significant amount of pain to the
> folks using FreeBSD. It is cool that Juniper kinda has it worked out,
> but even there I'm skeptical about your claims. Especially since
> Juniper imports source rarely, where as other firms do it more often,
> and there'd be more pain for them.
There are also folks (like Ironport) who don't import changes back
into the tree as often, and I'd rather not put more of a crimp on
folks' time for getting things back in because of this forced CVS ->
SVN upgrade (I'd rather convince others gradually over time to switch
to svn as opposed to using CVS).
As long as CVS continues to be in base, some folks will prefer it
over SVN (not saying because it's better, but just because it's there
and it's established).
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Wireless TCP aborts
On Sun, Mar 7, 2010 at 1:08 PM, Chuck Swiger wrote: > Hi, Tim-- > > On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote: > [ ... ] > > Corrupted MAC on input. > > Disconnecting: Packet corrupt > > rsync: connection unexpectedly closed ... [receiver] > > > > and then the rsync session is dead. > > > > It seems odd that a single corrupt packet would terminate the TCP > connection. > > It's not TCP itself which is closing the connection; if a garbage packet as > far as TCP or IP layer checksums was seen, it would be dropped and normal > resend mechanisms would compensate. However, SSH adds it's own layer of > data integrity checking called HMAC, which uses block-based hashes like MD5 > or SHA, and is much stronger than the 32-bit CRCs used at TCP/IP layers. > > See: > > /usr/src/crypto/openssh/packet.c > http://en.wikipedia.org/wiki/HMAC > > The implication is that the data is being corrupted before it gets munged > into network packets; failing memory is a likely cause, but bugs in the > network stack, the NIC driver, or OpenSSL are also lower-order > possibilities. > > Regards, > -- > -Chuck > > I have seen this same symptom many times with PCEngines ALIX boards but on the vr interfaces. It seems to come and go as I update kernels and worse yet, it seems to vary by board - have four boards all purchased at the same time a couple of years ago and some seem more prone to it than others. All have worked and failed at one time or another. I had, at one point, thought it to be related to power problems, because a high-power mini-PCI WiFi card seemed to exacerbate the problem, but removing the card made no difference, and the problem cleared up with an update and recompile of my source tree. It's a very disconcerting problem because FTP'ed files were being silently corrupted, so it's not just an SSH problem either. dave c ___ 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: propose: all arch move into a separate dir
In message: <20100308000203.ga70...@dragon.nuxi.org>
"David O'Brien" writes:
: On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
: > In message: <20100307054423.ge70...@dragon.nuxi.org>
: > "David O'Brien" writes:
: > : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
: > : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
: > : >> In message ,
Robert
: > : >> Watso n writes:
: > : >>> Doing that kind of rearrangement [...] would be a nightmare for
anyone
: > : >>> with large [...] patches, so I'd say we could pretty much rule that
out
: > : >>> outright.
: > : >>
: > : >> I would say that we should do it occasionally, to encourage these
: > : >> FreeBSD users to contribute as many of their local changes back to
: > : >> the project, as possible :-)
: > : >
: > : > Absolutely -- and rearranging a tree is a good way to invalidate
: > : > all those patches as well :-).
: > :
: > : No, not it isn't. Provide a script to convert path's in the diff.
: > : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
: >
: > You are joking, right? This would be a nightmare for people that
: > integrate early and often.
:
:
: No I am not joking. I was responding to the point that a large patch
: (that is a the output of running '$SCM diff') can be easily modified to
: match a new directory layout. Thus patches in GNATS aren't "useless".
It seems like it would be a nightmare for anybody tracking the system
on a regular basis.
: I'm not sure what operation you are specifically speaking to . But, if
: FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
: do:
:
: cd sys
: mkdir arch
: svn add arch
: svn mv {list of dirs} arch
: svn ci
:
: and be done with it. Branches would merge that change - get a trivial
: tree conflict, resolve it - and move on with life.
And everybody who was tracking FreeBSD with their own changes would
have to scramble. It wouldn't be trivial by any stretch of the
imagination. The project is much larger than svn, and svn doesn't
lend itself well to having external agents track it.
: I would expect folks working in project branches to do the same.
:
: For merging changes from FreeBSD HEAD to FreeBSD stable - that is
: trivial:
:
: cd sys
: svn merge -c $GRN ^/head/sys/arch/amd64 amd64
: svn ci
:
: Subversion makes this a lot easier than CVS did.
Just because the task is doable with svn, where it was impossible with
CVS doesn't mean there wouldn't be a significant amount of pain to the
folks using FreeBSD. It is cool that Juniper kinda has it worked out,
but even there I'm skeptical about your claims. Especially since
Juniper imports source rarely, where as other firms do it more often,
and there'd be more pain for them.
Warner
___
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: propose: all arch move into a separate dir
On Sun, Mar 07, 2010 at 08:51:22PM +, Robert Watson wrote: > On Sat, 6 Mar 2010, David O'Brien wrote: >> No, not it isn't. Provide a script to convert path's in the diff. This is >> what $LARGE_FREEBSD_USER did when it rearranged it source tree. >> >> It was done by creating a copy of the CVS repo and moved files around. Old >> releases stayed in the old repo, and new releases done from the new repo. >> 'diff | fixpatch | patch -p0' were used to move code between sandboxes. > > Indeed, this is precisely the problem: rearranging the tree upstream means > that you most likely can't use the revision control system to manage your > local difference set downstream. It does not mean downstream users cannot their revision control system manage changes - it only means those using CVS cannot easily. Lets say I'm a 3rd party based on FreeBSD. One "vendor imports" the FreeBSD sources for what ever version they are based on. When new FreeBSD version comes out with 'sys/arch/' that would be reflected in the SCM on that vendor branch. The SCM would track that directories moved. Now when the new FreeBSD import was merged into the working sources branch, the SCM would track that the directory moves would need to happen there also. Done deal. > Instead, you have to manually extract > your local changes, rework them to match arbitrary upstream rearrangement, > and re-apply them as a single changeset creating a discontinuity in your > revision history. No, you could use the SCM to do it. All modern SCM's that I'm familiar with track directory moves. Resulting in a situation where there is not lossage with "log", "blame", etc.. I am speaking as one of the downstream users of FreeBSD - $WORK could consume such a move - so please don't hold them up as a reason to not consider moving the CPU directories under arch/. I know of two 3rd parties with product based on FreeBSD - one uses subversion, and the other uses Perforce. Granted I don't know what the others use - but we could query them. > However, other downstream users (including our > own development branches in Subversion, P4, etc) reasonably expect to > be able to use contemporary tools to manage the merge on a more > frequent basis. Yes - have you had a bad experience with merging such changes from HEAD to a project branch in our own subversion tree? My experience is, given a HEADS UP to a directory move, it is not hard to handle merges in subversion. -- -- David (obr...@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: propose: all arch move into a separate dir
On Sun, Mar 07, 2010 at 02:49:04PM -0700, M. Warner Losh wrote:
> In message: <20100307054423.ge70...@dragon.nuxi.org>
> "David O'Brien" writes:
> : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote:
> : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote:
> : >> In message ,
> Robert
> : >> Watso n writes:
> : >>> Doing that kind of rearrangement [...] would be a nightmare for anyone
> : >>> with large [...] patches, so I'd say we could pretty much rule that out
> : >>> outright.
> : >>
> : >> I would say that we should do it occasionally, to encourage these
> : >> FreeBSD users to contribute as many of their local changes back to
> : >> the project, as possible :-)
> : >
> : > Absolutely -- and rearranging a tree is a good way to invalidate
> : > all those patches as well :-).
> :
> : No, not it isn't. Provide a script to convert path's in the diff.
> : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree.
>
> You are joking, right? This would be a nightmare for people that
> integrate early and often.
No I am not joking. I was responding to the point that a large patch
(that is a the output of running '$SCM diff') can be easily modified to
match a new directory layout. Thus patches in GNATS aren't "useless".
I'm not sure what operation you are specifically speaking to . But, if
FreeBSD were to move the CPU directories under 'arch/', at $WORK we would
do:
cd sys
mkdir arch
svn add arch
svn mv {list of dirs} arch
svn ci
and be done with it. Branches would merge that change - get a trivial
tree conflict, resolve it - and move on with life.
I would expect folks working in project branches to do the same.
For merging changes from FreeBSD HEAD to FreeBSD stable - that is
trivial:
cd sys
svn merge -c $GRN ^/head/sys/arch/amd64 amd64
svn ci
Subversion makes this a lot easier than CVS did.
--
-- David (obr...@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: Wireless TCP aborts
Hi, Tim-- On Mar 7, 2010, at 2:16 PM, Tim Kientzle wrote: [ ... ] > Corrupted MAC on input. > Disconnecting: Packet corrupt > rsync: connection unexpectedly closed ... [receiver] > > and then the rsync session is dead. > > It seems odd that a single corrupt packet would terminate the TCP connection. It's not TCP itself which is closing the connection; if a garbage packet as far as TCP or IP layer checksums was seen, it would be dropped and normal resend mechanisms would compensate. However, SSH adds it's own layer of data integrity checking called HMAC, which uses block-based hashes like MD5 or SHA, and is much stronger than the 32-bit CRCs used at TCP/IP layers. See: /usr/src/crypto/openssh/packet.c http://en.wikipedia.org/wiki/HMAC The implication is that the data is being corrupted before it gets munged into network packets; failing memory is a likely cause, but bugs in the network stack, the NIC driver, or OpenSSL are also lower-order possibilities. Regards, -- -Chuck ___ 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: Wireless TCP aborts
On Sun, Mar 07, 2010 at 02:16:36PM -0800, Tim Kientzle wrote: > Using ssh and rsync to copy a lot of stuff from my > old desktop to my new laptop. The old desktop is using > a wired connection to an (admittedly crappy) D-Link router, > the new one is using an Atheros wireless connection to the > same router. I periodically see the transfer fail with > the following messages on the wireless side: > > Corrupted MAC on input. > Disconnecting: Packet corrupt I guess this message came from ssh. > rsync: connection unexpectedly closed ... [receiver] > > and then the rsync session is dead. > > It seems odd that a single corrupt packet would terminate > the TCP connection. > I think it's default behavior of ssh if it detect malformed packet. I used to see this forced disconnection of ssh when driver incorrectly set RX checksum flag OK for corrupted packets which were caused by hardware bug. > uname: FreeBSD 9.0-CURRENT r201154M: Tue Dec 29 09:27:29 PST 2009 ___ 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"
Wireless TCP aborts
Using ssh and rsync to copy a lot of stuff from my old desktop to my new laptop. The old desktop is using a wired connection to an (admittedly crappy) D-Link router, the new one is using an Atheros wireless connection to the same router. I periodically see the transfer fail with the following messages on the wireless side: Corrupted MAC on input. Disconnecting: Packet corrupt rsync: connection unexpectedly closed ... [receiver] and then the rsync session is dead. It seems odd that a single corrupt packet would terminate the TCP connection. uname: FreeBSD 9.0-CURRENT r201154M: Tue Dec 29 09:27:29 PST 2009 ___ 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: propose: all arch move into a separate dir
In message: <20100307054423.ge70...@dragon.nuxi.org> "David O'Brien" writes: : On Fri, Mar 05, 2010 at 09:41:40AM +, Robert Watson wrote: : > On Fri, 5 Mar 2010, Poul-Henning Kamp wrote: : >> In message , Robert : >> Watso n writes: : >>> Doing that kind of rearrangement [...] would be a nightmare for anyone : >>> with large [...] patches, so I'd say we could pretty much rule that out : >>> outright. : >> : >> I would say that we should do it occasionally, to encourage these FreeBSD : >> users to contribute as many of their local changes back to the project, as : >> possible :-) : > : > Absolutely -- and rearranging a tree is a good way to invalidate all those : > patches as well :-). : : No, not it isn't. Provide a script to convert path's in the diff. : This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. You are joking, right? This would be a nightmare for people that integrate early and often. Warner ___ 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: Call for Test and Review: bwn(4) - another Broadcom Wireless driver
In message: <261c29701003040928h7aa70b3fm37611f974e0b9...@mail.gmail.com> Miki writes: : Rising FIRMWARE_MAX from 30 to 60 did the trick ! thanks ! : Are there any reasons to have such a "low" default value ? I thought I'd committed this change already :) Warner ___ 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: propose: all arch move into a separate dir
In message: <20100307052949.gb70...@dragon.nuxi.org> "David O'Brien" writes: : On Sat, Mar 06, 2010 at 01:28:24AM -0800, Garrett Cooper wrote: : > FWIW, NetBSD's charter has been to run their OS on a number of : > architectures, not just a primary set of architectures; OpenBSD's : > charter differs -- if we all were NetBSD or OpenBSD, then we'd all be : > using the same thing. But we aren't and that's probably not going to : > change anytime soon [at least not without community backing and a : : We aren't? At this point it seems any architecture an be brought into : FreeBSD without regard to critical mass or ability to support it to the : standards of our past. I do believe FreeBSD's character does not include : chasing every embedded platform where there is energy and talent for the : initial port. FreeBSD's charter includes whatever people have the time and energy to support. This means a lot more embedded platforms that I ever thought possible because FreeBSD is getting easier to move to new embedded platforms. This is a good thing, as it brings more people and energy to the project and makes the base support for those platforms better. We don't have quite as many problems as the NetBSD/OpenBSD crowd in this respect. They tend to define a new MACHIINE more often then we have (or will). The need for sys/arch is less severe here than there because we don't have 40 different MACHINEs. Warner ___ 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: propose: all arch move into a separate dir
On Sat, 6 Mar 2010, David O'Brien wrote: No, not it isn't. Provide a script to convert path's in the diff. This is what $LARGE_FREEBSD_USER did when it rearranged it source tree. It was done by creating a copy of the CVS repo and moved files around. Old releases stayed in the old repo, and new releases done from the new repo. 'diff | fixpatch | patch -p0' were used to move code between sandboxes. Indeed, this is precisely the problem: rearranging the tree upstream means that you most likely can't use the revision control system to manage your local difference set downstream. Instead, you have to manually extract your local changes, rework them to match arbitrary upstream rearrangement, and re-apply them as a single changeset creating a discontinuity in your revision history. This in turn creates problems with annotate, log, backing out changes prior to the merge, etc. All the reasons we like to use revision control for significant work. What you describe may work OK(ish) if you have to do it once every 3-6 years as a single massive merge and you were planning to do it by hand anyway (CVS and patches). However, other downstream users (including our own development branches in Subversion, P4, etc) reasonably expect to be able to use contemporary tools to manage the merge on a more frequent basis. As I said before: this isn't a vote not to rearrange things once in a while, it's instead a caution to say: this has a significant cost beyond "svn mv" that has to be taken into account when making the decision, so we should only do it with significant forethought and where there is significant benefit. Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sunday 07 March 2010 11:46:58 Garrett Cooper wrote: > On Sun, Mar 7, 2010 at 2:24 AM, Garrett Cooper wrote: > > On Sun, Mar 7, 2010 at 2:07 AM, Garrett Cooper wrote: > >> Hi Alexander and Hans, > >>I recently did the following which generated a panic on a > >> 9-CURRENT kernel compiled on the 26th: > >> > >> 1. Executed reboot > >> 2. Removed keyboard. > >> 3. Some time after `All buffers synced\nUptime: ...' was displayed, > >> the keyboard was registered disconnected. > >> 4. The interrupt was delivered to my twa(4) enabled card and the > >> kernel panicked, like so: > >> > >> ugen2.2: at usbus2 (disconnected) > >> uhub8: at uhub2, port 1, addr 2 (disconnected) > >> ugen2.3: at usbus2 (disconnected) > >> ukbd0: at uhub8, port 3, addr 3 (disconnected) > >> uhid0: at uhub8, port 3, addr 3 (disconnected) > >> panic: mtx_lock_spin() of destroyed mutex @ > >> /usr/src/sys/dev/twa/tw_cl_intr.c:88 > >> > >> cpuid = 1 > >> KDB: enter: panic > >> [thread pid 12 tid 100025 ] > >> Stopped at kdb_enter+0x3d: movq $0,0x40289c(%rip) > >> db> > >> > >>I wish I could provide you with more details, but unfortunately I > >> the USB bus isn't registering the fact that I'm reattaching the > >> keyboard right now and the box won't reboot automatically :( (didn't > >> set the right sysctl beforehand to panic automatically). I'll try and > >> reproduce the issue again, but I was just wondering whether or not you > >> guys had seen this problem before. > > > >Phew... it's reproducible with that kernel. Here's what I did > > exactly (because my original directions were incorrect): > >1. Hit power button (for S5). > >2. Disconnect keyboard RIGHT as `Uptime: ...' is displayed. > >Kernel panicked on my system again. Now to figure out if it still > > exists with a kernel compiled today, and also how to debug it if it > > still does exist :/... > > 1. It still does exist with today's kernel. > 2. Here's the backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x17d > _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x126 > tw_cl_interrupt() at tw_cl_interrupt+0x14c > twa_pci_intr() at twa_pci_intr+0x11 > intr_event_execute_handlers() at intr_event_execute_handlers+0x67 > ithread_loop() at ithread_loop+0xae > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff80751d6d30, rbp = 0 --- > KDB: enter: panic > [ithread pid 12 tid 100025 ] > Stopped at kdb_enter+0x3d: movq $0, 0x40289c(%rip) > > I'll have to wait until tomorrow to grab a PS/2 keyboard to get more > helpful info :/... > Thanks, > -Garrett > Hi, The reason you get this panic when you unplug the USB keyboard is probably because the twa interrupt handler is shared with the USB one. It does not look like a USB problem to me but rather a problem inside the twa_pci_intr() code. --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: Core i5 AES acceleration
On 3/7/10 1:44 AM, Norikatsu Shigemura wrote: Hi Devid and Julian. On Sat, 06 Mar 2010 22:10:28 -0800 Julian Elischer wrote: David Ehrmann wrote: Does FreeBSD currently support cryptographic acceleration for AES on the Core i5 CPU? I searched, but couldn't find anything, and the crypto(4) manpage only lists these divers in "see also:" no, but if you write a driver for it we will... :-) (most things in open source happen because someone needs it.) I found Linux's code: http://lwn.net/Articles/311094/ I think that it looks too easy, maybe, we should implement aesni(4) like padlock(4). I was thinking that if I did do it, I'd start with padlock as a base. It looks like there are maybe 6 new opcodes. Maybe we could ask the contributor of the Linux code (an Intel employee) if he'd be willing to also release the code under a BSD license. My problem is that I don't have a Core i5 system--I was asking because it's an option for my new system--and I'm far from an x86 assembly expert. ___ 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: Call for tester: VirtualBox 3.1.2 for FreeBSD (take 2)
On Sun, 07 Mar 2010 19:47:37 +0300, "Azim" wrote: > I am using FreeBSD 9.0 CURRENT (201002) as the host OS and I am trying > to run XP64-SP2 as Guest on VirtualBOX version 3.1.2_OSE r56127 > > I have vboxnet_enable="YES" in /etc/rc.conf and vboxdrv_load="YES" in > /boot/loader.conf for Networking support. > > VirtualBox allows me to add an existing vhd but when I click Start the > Guest Windows appears and gets cloded and the status below the Guest OS > name is seen as "Aborted". > > Below are the few end lines of the log file > XP64-SP2-2010-03-07-21-48-52.log : > > LOG FILE > 00:00:01.278 > 00:00:01.278 * End of CFGM dump > ** > 00:00:01.278 MM: cbHyperHeap=0x14 (1310720) > 00:00:01.284 > 00:00:01.284 !!Assertion Failed!! > 00:00:01.284 Expression: paPages[i].Phys != 0 && paPages[i].Phys != > NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) > 00:00:01.284 Location : > /work/a/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) > int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const > char*, RTGCPTR64*) > 00:00:01.284 i=0x0 Phys= Heap > LOG FILE > > Is this a known error ? Yes and it is already investigated. It only happens with current and stable after beginning of February. A testing patch was send to freebsd-emulators@ last week. -- Bernhard Fröhlich http://www.bluelife.at/ ___ 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: Call for tester: VirtualBox 3.1.2 for FreeBSD (take 2)
I am using FreeBSD 9.0 CURRENT (201002) as the host OS and I am trying to run XP64-SP2 as Guest on VirtualBOX version 3.1.2_OSE r56127 I have vboxnet_enable="YES" in /etc/rc.conf and vboxdrv_load="YES" in /boot/loader.conf for Networking support. VirtualBox allows me to add an existing vhd but when I click Start the Guest Windows appears and gets cloded and the status below the Guest OS name is seen as "Aborted". Below are the few end lines of the log file XP64-SP2-2010-03-07-21-48-52.log : LOG FILE 00:00:01.278 00:00:01.278 * End of CFGM dump ** 00:00:01.278 MM: cbHyperHeap=0x14 (1310720) 00:00:01.284 00:00:01.284 !!Assertion Failed!! 00:00:01.284 Expression: paPages[i].Phys != 0 && paPages[i].Phys != NIL_RTHCPHYS && !(paPages[i].Phys & PAGE_OFFSET_MASK) 00:00:01.284 Location : /work/a/ports/emulators/virtualbox-ose/work/VirtualBox-3.1.2_OSE/src/VBox/VMM/MMHyper.cpp(610) int MMR3HyperMapPages(VM*, void*, RTR0PTR, size_t, const SUPPAGE*, const char*, RTGCPTR64*) 00:00:01.284 i=0x0 Phys= Heap LOG FILE Is this a known error ? Regards, -- Azim http://my.opera.com/quakerdoomer http://solidmecca.co.nr http://winautopwn.co.nr -- http://www.fastmail.fm - Accessible with your email software or over the web ___ 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: net.inet.tcp.timer_race: does anyone have a non-zero value?
On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote: > Please check the results of the following command: > > % sysctl net.inet.tcp.timer_race > net.inet.tcp.timer_race: 0 Are the results for FreeBSD7 look interesting for you? Because currently we have mostly FreeBSD7.1 hosts in production and I observe nonzero values on 8 hosts (about 15%). I would send more details to you privately if you are interested. -- Mikolaj Golub ___ 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: net.inet.tcp.timer_race: does anyone have a non-zero value?
On Mar 7, 2010, at 12:33 PM, Mikolaj Golub wrote: > On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote: > >> Please check the results of the following command: >> >> % sysctl net.inet.tcp.timer_race >> net.inet.tcp.timer_race: 0 > > Are the results for FreeBSD7 look interesting for you? Because currently we > have mostly FreeBSD7.1 hosts in production and I observe nonzero values on 8 > hosts (about 15%). I would send more details to you privately if you are > interested. Yes, 7.x is also of interest, thanks! Robert___ 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"
net.inet.tcp.timer_race: does anyone have a non-zero value?
Dear all: I'm embarking on some new network stack locking work, which requires me to address a number of loose ends in the current model. A few years ago, my attention was drawn to a largly theoretical race, which had existed in the BSD code since inception. It is detected and handled in practice, but relies on type stability of TCP connection data structures, which will need to change in the future due to on-going virtualization work. I didn't fix it at the time, but did add a counter so that we could see if it was happening in the field -- that counter, net.inet.tcp.timer_race, indicates whether or not the stack has detected it happening (and then handled it). This e-mail is to collect the results of that in-the-field survey. Please check the results of the following command: % sysctl net.inet.tcp.timer_race net.inet.tcp.timer_race: 0 If your system shows a non-zero value, please send me a *private e-mail* with the output of that command, plus also the output of "sysctl kern.smp", "uptime", and a brief description of the workload and network interface configuration. For example: it's a busy 8-core web server with roughly X connections/second, and that has three em network interfaces used to load balance from an upstream source. IPSEC is used for management purposes (but not bulk traffic), and there's a local MySQL database. I've already seen one non-zero report, but would be interested in knowing a bit more about the kinds of situations where it's happening so that I can prioritize fixing it appropriately, but also reason about the frequency at which it happens so we can select a fix that avoids adding significant overhead in the common case. Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
On Sun, Mar 7, 2010 at 2:07 AM, Garrett Cooper wrote: > Hi Alexander and Hans, > I recently did the following which generated a panic on a > 9-CURRENT kernel compiled on the 26th: > > 1. Executed reboot > 2. Removed keyboard. > 3. Some time after `All buffers synced\nUptime: ...' was displayed, > the keyboard was registered disconnected. > 4. The interrupt was delivered to my twa(4) enabled card and the > kernel panicked, like so: > > ugen2.2: at usbus2 (disconnected) > uhub8: at uhub2, port 1, addr 2 (disconnected) > ugen2.3: at usbus2 (disconnected) > ukbd0: at uhub8, port 3, addr 3 (disconnected) > uhid0: at uhub8, port 3, addr 3 (disconnected) > panic: mtx_lock_spin() of destroyed mutex @ > /usr/src/sys/dev/twa/tw_cl_intr.c:88 > > cpuid = 1 > KDB: enter: panic > [thread pid 12 tid 100025 ] > Stopped at kdb_enter+0x3d: movq $0,0x40289c(%rip) > db> > > I wish I could provide you with more details, but unfortunately I > the USB bus isn't registering the fact that I'm reattaching the > keyboard right now and the box won't reboot automatically :( (didn't > set the right sysctl beforehand to panic automatically). I'll try and > reproduce the issue again, but I was just wondering whether or not you > guys had seen this problem before. Phew... it's reproducible with that kernel. Here's what I did exactly (because my original directions were incorrect): 1. Hit power button (for S5). 2. Disconnect keyboard RIGHT as `Uptime: ...' is displayed. Kernel panicked on my system again. Now to figure out if it still exists with a kernel compiled today, and also how to debug it if it still does exist :/... Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Removing USB keyboard after filesystems synced causes panic with destroyed mutex twa(4)?
Hi Alexander and Hans, I recently did the following which generated a panic on a 9-CURRENT kernel compiled on the 26th: 1. Executed reboot 2. Removed keyboard. 3. Some time after `All buffers synced\nUptime: ...' was displayed, the keyboard was registered disconnected. 4. The interrupt was delivered to my twa(4) enabled card and the kernel panicked, like so: ugen2.2: at usbus2 (disconnected) uhub8: at uhub2, port 1, addr 2 (disconnected) ugen2.3: at usbus2 (disconnected) ukbd0: at uhub8, port 3, addr 3 (disconnected) uhid0: at uhub8, port 3, addr 3 (disconnected) panic: mtx_lock_spin() of destroyed mutex @ /usr/src/sys/dev/twa/tw_cl_intr.c:88 cpuid = 1 KDB: enter: panic [thread pid 12 tid 100025 ] Stopped at kdb_enter+0x3d: movq $0,0x40289c(%rip) db> I wish I could provide you with more details, but unfortunately I the USB bus isn't registering the fact that I'm reattaching the keyboard right now and the box won't reboot automatically :( (didn't set the right sysctl beforehand to panic automatically). I'll try and reproduce the issue again, but I was just wondering whether or not you guys had seen this problem before. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Core i5 AES acceleration
Hi Devid and Julian. On Sat, 06 Mar 2010 22:10:28 -0800 Julian Elischer wrote: > David Ehrmann wrote: > > Does FreeBSD currently support cryptographic acceleration for AES on the > > Core i5 CPU? I searched, but couldn't find anything, and the crypto(4) > > manpage only lists these divers in "see also:" > no, but if you write a driver for it we will... :-) > (most things in open source happen because someone needs it.) I found Linux's code: http://lwn.net/Articles/311094/ I think that it looks too easy, maybe, we should implement aesni(4) like padlock(4). ___ 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"
