t usbus1Root mount waiting for:ugen0.1: at usbus0
> usbus1
> usbus0
> uhub0: on usbus0
> uhub1: on usbus1
> uhub0: 2 ports with 2 removable, self powered
> uhub1: 2 ports with 2 removable, self powered
> Root mount waiting for: usbus1 usbus0
> ugen0.2: at usbus0
> u
The device subfamily on those motherboards is called PCH, and its only in
the em driver as of
last December, The CVS delta of if_em is 1.27. You can either update to
STABLE/8 or CURRENT.
If you wish to just pull the e1000 driver directory it should work fine in
8.0 RELEASE also.
Cheers,
Jack
On
OH, as to my last statement, the code in CURRENT will NOT work on 8.0
RELEASE,
it would require a change to sys/conf/files, and it also has a fix in the
stack that is not
in RELEASE. SO taking the latest would require you take the whole tree.
Jack
On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel
oming first thing Monday.
Jack
On Thu, Apr 1, 2010 at 9:11 AM, Jan Henrik Sylvester wrote:
> On 01/-10/-28163 20:59, Jack Vogel wrote:
>
>> OH, as to my last statement, the code in CURRENT will NOT work on 8.0
>> RELEASE,
>> it would require a change to sys/conf/files,
Someone else also pointed this out. I'm dubious about its claim.
This happens because there is an RX lock taken in rxeof, its held
thru the call into the stack, it then encounters another lock there
and hence this complaint. I've had the RX hold as it is for a long
while and would rather not have t
On Fri, Apr 9, 2010 at 1:13 PM, Pyun YongHyeon wrote:
> On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote:
> > Someone else also pointed this out. I'm dubious about its claim.
>
> I can't reproduce the LOR with latest em(4)(r206429).
>
>
Hmmm, wonder what
Don't know, but I would just ignore it, I think its a false warning anyway.
Jack
On Fri, Apr 9, 2010 at 2:05 PM, Mike Tancsa wrote:
> At 04:13 PM 4/9/2010, Pyun YongHyeon wrote:
>
>> On Fri, Apr 09, 2010 at 12:09:24PM -0700, Jack Vogel wrote:
>> > Someone else
Added the missing locks around calls to rxeof and checked it in a minute
ago.
Sorry guys!
Jack
On Sat, Apr 10, 2010 at 9:05 AM, Bjoern A. Zeeb <
bzeeb-li...@lists.zabbadoz.net> wrote:
> On Sat, 10 Apr 2010, Mike Tancsa wrote:
>
> Hi Mike,
>
>
> At 05:11 PM 4/
nefit. At least try it
and see.
Jack
On Sat, Apr 10, 2010 at 3:07 PM, Mike Tancsa wrote:
> At 03:29 PM 4/10/2010, Jack Vogel wrote:
>
>> Added the missing locks around calls to rxeof and checked it in a minute
>> ago.
>>
>> Sorry guys!
>>
>
> Looks good
On Mon, Apr 12, 2010 at 7:52 AM, John Baldwin wrote:
> On Friday 09 April 2010 3:09:24 pm Jack Vogel wrote:
> > Someone else also pointed this out. I'm dubious about its claim.
> > This happens because there is an RX lock taken in rxeof, its held
> > thru the ca
On Tue, Sep 14, 2010 at 4:29 AM, Jakub Lach wrote:
>
>
> Alexander Best-4 wrote:
> >
> > any thoughts on using http://pciids.sourceforge.net/ for pciids instead
> of
> > the
> > Hart and Boemler lists. the SF site seems to be updated more regularly
> and
> > would get rid of the need to decide fo
On Mon, Oct 18, 2010 at 12:13 PM, Garrett Cooper wrote:
> On Mon, Oct 18, 2010 at 11:36 AM, Alexander Best
> wrote:
> > On Mon Oct 18 10, Garrett Cooper wrote:
> >> On Mon, Oct 18, 2010 at 8:28 AM, Alexander Best
> wrote:
> >> > On Mon Oct 18 10, Alexander Best wrote:
> >> >> On Fri Sep 17 10, A
I had occasion to think about this, and I was wondering if someone is
working to add
either or both of these features, Intel's hardware supports it, it does not
seem that
hard to add, or am I missing something?
Cheers,
Jack
___
freebsd-current@freebsd.o
, but the protocol checksums
might as well be available too.
Jack
On Wed, Oct 20, 2010 at 3:20 PM, Bjoern A. Zeeb wrote:
> On Wed, 20 Oct 2010, Jack Vogel wrote:
>
> Hi,
>
>
> I had occasion to think about this, and I was wondering if someone is
>> working to add
>&g
Oh crap, sorry, fix coming shortly.
Jack
On Tue, Nov 23, 2010 at 4:17 PM, Michael Butler
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Seems there are a couple of defines missing from an e1000_hw.h
>
> ===> igb (all)
>
> [ .. snip .. ]
>
> /usr/home/imb/svn/head/sys/modules/igb/
Looks like something to do with system C, you might isolate it, and try a
back
to back connection with its NICs, change cables, look at BIOS settings,
change
the slot the nic is in... All just off the top of my head.
Jack
On Sat, May 8, 2010 at 9:41 AM, joe wrote:
> On 05/08/2010 11:17 AM, Ian
10 at 10:04 AM, joe wrote:
> On 05/08/2010 01:31 PM, Jack Vogel wrote:
>
>> Looks like something to do with system C, you might isolate it, and try
>> a back
>> to back connection with its NICs, change cables, look at BIOS settings,
>> change
>> the slot the nic
The cable, its a simple thing but make SURE you try that, a slightly
damaged one can do weird things and its quick to check, don't overlook
it.
Jack
On Sat, May 8, 2010 at 10:22 AM, joe wrote:
> On 05/08/2010 01:53 PM, Jack Vogel wrote:
>
>> I still am not clear on this syste
On Sun, May 9, 2010 at 2:54 AM, joe wrote:
> On 05/08/2010 02:21 PM, Jack Vogel wrote:
>
>> The cable, its a simple thing but make SURE you try that, a slightly
>> damaged one can do weird things and its quick to check, don't overlook
>> it.
>>
>> Jack
What if you use amd64, have you tried that? Low level code is different.
Interesting however, maybe I can get access to one around here, will see.
Jack
On Tue, May 18, 2010 at 2:32 PM, Ryan Stone wrote:
> I'm trying to bring up a new board based on Intel's Jasper Forest x86
> processor. I ca
LOL, ok, I'm beating the bushes here Ryan, and I think I can get a system
although it may be a day or two. Will let you know.
Jack
On Tue, May 18, 2010 at 4:40 PM, Ryan Stone wrote:
> amd64 exhibits the same problem, except that it's not even polite and
> panics without even asking.
>
I have gotten access to a system this morning, I booted and installed
8.0 RELEASE on it, it had no problems installing or afterwords booting
the SMP kernel.
So, is it possible there's a regression/issue in HEAD, or perhaps you
have something in the PCIE expansion slots that cause it, the system
I'
Cool, glad its resolved.
Jack
On Fri, May 21, 2010 at 10:43 AM, Ryan Stone wrote:
> Just wanted to give everybody some closure on this issue: Through the
> magic of a JTAG debugger, I was able to identify that the problem was
> an infinite loop in the BIOS's SMI handler. I'm not sure why thi
If you have this adapter and have been getting watchdogs you need to pick up
the small
update I checked into HEAD today. When I added the SR-IOV support for the
82576
adapter I removed a call to set the MAC type in an early routine, thinking
it was unnecessary,
since a slightly later shared code in
/buildkernel on r279466 just completed successfully so
> please make sure that you have at least that revision. If you still
> have problems, please let me know.
>
> I do want to thank John Baldwin for advice about the PCI Subsystem and
> newbus and Jack Vogel for his help with the
But if you've disabled interrupts why would an "interrupt-handling task"
even run??
Jack
On Wed, Jul 1, 2015 at 12:44 PM, Ryan Stone wrote:
> I'm trying to figure out how a driver is supposed to shut down its
> interrupt-handling taskqueue when it detaches. taskqueue(9) recommends
> disabling
Ya, that seems elegant.
Jack
On Wed, Jul 1, 2015 at 3:28 PM, Ryan Stone wrote:
> On Wed, Jul 1, 2015 at 5:32 PM, Konstantin Belousov
> wrote:
>
>> Do you mean, you want some KPI like
>> boolean taskqueue_is_draining(struct taskqueue *p);
>> so that e.g. executed task could see if it i
You can't get line rate with ixgbe, in what configuration/hardware?
We surely do get line rate in validation here, but its sensitive to
your hardware and config.
Jack
On Mon, Dec 5, 2011 at 2:28 PM, Luigi Rizzo wrote:
> On Mon, Dec 05, 2011 at 11:15:09PM +0200, Daniel Kalchev wrote:
> >
> > On
Set the storm threshold to 0, that will disable it, its going to throttle
your performance
when it happens.
Jack
On Tue, Dec 6, 2011 at 6:24 AM, Daniel Kalchev wrote:
> Some tests with updated FreeBSD to 8-stable as of today, compared with the
> previous run
>
>
>
> On 06.12.11 13:18, Daniel K
Someone with sparc build experience want to look at this and maybe see
something I'm missing,
this error makes no sense to me, these are defined in ixgbe_type.h and I
see nothing architecture sensitive??
Jack
On Mon, Jan 30, 2012 at 10:51 AM, FreeBSD Tinderbox
wrote:
> TB --- 2012-01-30 17:49:3
Yes, it was. Now if I can just figure out what's going on with sparc
Jack
On Mon, Jan 30, 2012 at 3:11 PM, Glen Barber wrote:
> On Mon, Jan 30, 2012 at 11:55:48PM +0100, O. Hartmann wrote:
> > The follwoing error occurs hwen trying to compile a kernel (make
> > buildworld works fine):
> >
Look again closely, AFBR-703SDZ-IN2 and AFBR-703SDDZ-IN1 are supported,
AFBR-703SDZ-IN is not.
Jack
On Tue, Dec 4, 2012 at 3:47 AM, Ian FREISLICH wrote:
> Hi
>
> I've just had this card installed in our servers:
>
> ix0@pci0:12:0:0:class=0x02 card=0x7a118086 chip=0x10fb8086
> rev=0
LOL, it's ironic, my intention in creating lem was to isolate the old
pre-PCIE driver from active changes so as to assure it's stability...
but virtualization comes around to bit me in the butt :)
I guess I'm agreeable in principle with what you're doing Luigi, but
can you do me a favor and hold o
52 PM, Luigi Rizzo wrote:
> On Thu, Dec 27, 2012 at 10:46 AM, Jack Vogel wrote:
>
>> LOL, it's ironic, my intention in creating lem was to isolate the old
>> pre-PCIE driver from active changes so as to assure it's stability...
>> but virtualization comes around to
For those that may have run across the story on Slashdot about this NIC,
here is our statement:
Recently there were a few stories published, based on a blog post by an
end-user, suggesting specific network packets may cause the Intel® 82574L
Gigabit Ethernet Controller to become unresponsive until
Interesting, lem is all the non-pcie hardware, and if you see better
performance
out of the LEGACY path then I'm OK with changing the default.
Jack
On Tue, Jul 24, 2012 at 1:20 PM, Luigi Rizzo wrote:
> if_lem.c ("lem", one of the e1000 drivers) has 2 possible interrupt modes:
> EM_LEGACY_IRQ u
The changes to igb were to add IPV6 support which previously was only in
ixgbe, the
transmit path code came from that code base, we did not see this issue in
testing. Its
not a simple matter of a few lines of code, I think we need to go forward
not back... I'll
look at the code.
Jack
On Fri, Ja
on
>> > > Linux.
>> > > > Can you show us the way to resolve this problem?
>> > >
>> > > While the e1000 drivers share the same common code, there are some
>> > > differences
>> > > in the OS-dependent bits (e.g. if_igb.c, et
No, you do not need to commit this, the next drop of my internal
code already has this in it, and should be coming shortly, but thanks
anyway.
Jack
On Sat, May 25, 2013 at 4:44 AM, Sergey Kandaurov wrote:
> Hi.
>
> I'd like to commit this patch.
> PCI-E Bus Speed is measured in GT/s (transfers
Sigh, this ends up being ugly I'm afraid. I need some time to look at code
and think about it.
Jack
On Mon, Aug 5, 2013 at 10:36 AM, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 7:17 PM, Adrian Chadd wrote:
>
> > I'm travelling back to San Jose today; poke me tomorrow and I'll brain
> > dump
What do you think about this change?
Cheers,
Jack
On Mon, Aug 5, 2013 at 10:58 AM, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 7:49 PM, Jack Vogel wrote:
>
>> Sigh, this ends up being ugly I'm afraid. I need some time to look at
>> code and think about it.
>
This problem happens for only one reason, you have insufficient mbufs to
fill your rx ring. Its odd that it would differ when its static versus a
loadable
module though!
With the 7.2.2 driver you also will use different mbuf pools depending on
the MTU you are using. If you use jumbo frames it will
If you get "cannot setup receive structures" you cannot go on and try to
use the thing :) It means you have inadequate mbuf clusters to setup
your receive side, you simply have to increase it and reload the driver.
Jack
On Wed, Apr 27, 2011 at 5:39 AM, Olivier Smedts wrote:
> 2
Yes Mike, already have had a couple others bug me to get the MFC, I'm hoping
to get it in this week :)
Jack
On Wed, Apr 27, 2011 at 12:04 PM, Mike Tancsa wrote:
> On 4/27/2011 2:45 PM, Olivier Smedts wrote:
> >> Are you testing with what is in HEAD ? ie. 7.2.3 or something else ?
> >> Your sub
If you get the setup receive structures fail, then increase the nmbclusters.
If you use standard MTU then what you need are mbufs, and standard size
clusters (2K).
Only when you use jumbo frames will you need larger.
You must configure enough, its that simple.
Jack
On Tue, May 3, 2011 at 2:13
faces beside Intel they also consume mbufs
remember.
Jack
On Tue, May 3, 2011 at 2:50 PM, Michael Schmiedgen wrote:
> On 03.05.2011 23:24, Jack Vogel wrote:
>
>> If you get the setup receive structures fail, then increase the
>> nmbclusters.
>>
>> If you use standa
No, I do not Arnaud. But I refuse to rise to rude and uncivil behavior. Its
your
behavior again and again which causes you to not get responses, not my
willingness to help and respond to those that behave like respectful
customers
and adults.
Jack
On Wed, May 4, 2011 at 10:20 AM, Arnaud Lacombe
Who makes your motherboard? The problem you are having is that MSIX AND
MSI are both failing as em0 comes up, so it falls back to Legacy interrupt
mode,
and must be having some issue with sharing the line, causing the storm.
This is the second report in a matter of a week perhaps about a problemat
Will you please set it back to a default and then boot and capture the
message for me?
Thank you,
Jack
On Wed, May 4, 2011 at 11:19 AM, Daan Vreeken wrote:
> Hi Jack,
>
> Wednesday 04 May 2011 19:46:05 Jack Vogel wrote:
> > Who makes your motherboard? The problem you are havi
I have had my validation engineer busy all day, we have tried both
a 9 kernel as well as 8.2, using the code from HEAD, and we
cannot reproduce this problem.
The data your netstat -m shows suggests to me that what's happening
is somehow setup of the receive ring is running more than once maybe??
This all looks completely kosher, what IRQ is the storm on??
Jack
On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote:
> Hi,
>
> On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote:
> > Will you please set it back to a default and then boot and capture the
> > message f
Right, it was you Wiktor :) Oh, so yours is sort of a special case.
Thanks,
Jack
On Wed, May 4, 2011 at 3:27 PM, Wiktor Niesiobedzki wrote:
> 2011/5/4 Jack Vogel :
> > This is the second report in a matter of a week perhaps about a
> problematic
> > motherboard, I woul
is a list of devices that share the
> IRQ
> according to 'dmesg'.
>
>
> > On Wed, May 4, 2011 at 3:04 PM, Daan Vreeken wrote:
> > > Hi,
> > >
> > > On Wednesday 04 May 2011 20:47:32 Jack Vogel wrote:
> > > > Will you please set it b
, Arnaud Lacombe wrote:
> Hi,
>
> On Thu, May 5, 2011 at 1:20 AM, Arnaud Lacombe wrote:
> > Hi,
> >
> > On Wed, May 4, 2011 at 5:38 PM, Jack Vogel wrote:
> >> I have had my validation engineer busy all day, we have tried both
> >> a 9 kernel as w
On Thu, May 5, 2011 at 7:21 AM, Arnaud Lacombe wrote:
> Hi,
>
> On Thu, May 5, 2011 at 2:59 AM, Jack Vogel wrote:
> > OK, but what this does not explain is why I do not see this if
> > its so easily reproduced, what causes the failure case, any idea?
> >
> It is c
medts wrote:
> 2011/5/5 Jack Vogel :
> > Anyway, I see the problematic code path, its only when
> > you skip the while loop altogether. I'm surprised the compiler
> > did not complain about this, its usually so anal.
>
> Could it be related to the compil
Cool, thanks for the update! Good luck.
Jack
On Thu, May 5, 2011 at 1:17 PM, Daan Vreeken wrote:
> Hi Peter,
>
> On Thursday 05 May 2011 21:28:02 Peter Jeremy wrote:
> > On 2011-May-05 13:22:59 +0200, Daan Vreeken wrote:
> > >Not yet. I'll reboot the machine later today when I have physical a
I don't see why you are blaming em, you can see its on MSIX vectors
that are NOT storming, its something with USB as noted. Trying to
disable em from using MSIX is in exactly the wrong direction IMHO.
Jack
On Fri, May 6, 2011 at 8:32 AM, Daan Vreeken wrote:
> Hi Steven,
>
> On Friday 06 May 20
Awesome, glad to see this happening :)
Jack
On Wed, Jun 1, 2011 at 11:21 AM, Attilio Rao wrote:
> Current maximum number of CPUs supported by the FreeBSD kernel is 32.
> That number cames from indirectly by the fact that we have a cpumask_t
> type, representing a mask of CPUs, which is an unsi
Interrupts are not enabled til after that is set, so I don't think this
theory
works, sorry.
Jack
On Fri, Jun 10, 2011 at 12:48 PM, K. Macy wrote:
> This recent commit changed the way that the value for size being
> passed to m_getjcl is initialized. Not seeing any obvious bugs, and
> not havi
60 matches
Mail list logo
