> Thanks for testing.
> Committed with r226123.
> I also noticed that bce(4) may support BCM5716S because brgphy(4)
> already supports BCM5709S. Can you test attached patch on BCM5716S?
I don't have a 5716S system or NIC for testing.
Dave
___
freebsd-n
On 8 October 2011 08:36, Chuck Burns wrote:
> I don't know what that means really. I consider myself a fairly advanced
> user, but nothing more, really.
I'm going to need some help to help Chuck here. :) Any takers?
Adrian
___
freebsd-net@freebsd.or
On Friday, October 07, 2011 7:26:37 PM Adrian Chadd wrote:
> On 8 October 2011 07:16, Chuck Burns wrote:
> > This is the latest kernel panic screenshot..
> >
> > http://imageshack.us/photo/my-images/707/newcrashw.png/
>
> Hm, it's crashing when calling ieee80211_process_callback().
> Is data->ni
That looks like a more general problem. None of those locks are
net80211/ath locks.
Adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.
On 8 October 2011 07:16, Chuck Burns wrote:
> This is the latest kernel panic screenshot..
>
> http://imageshack.us/photo/my-images/707/newcrashw.png/
Hm, it's crashing when calling ieee80211_process_callback().
Is data->ni == NULL ?
Adrian
___
freebs
On Fri, Oct 07, 2011 at 04:25:56PM -0700, David Christensen wrote:
> > > That's a typo then, 5709 and 5716 share the same ASIC ID.
> > >
> >
> > Thanks for confirmation.
> > Could you review the attached patch?
>
> Looks good. ASIC ID matches my Dell R210 system:
>
> bce0: mem
> 0xda00-0x
> > That's a typo then, 5709 and 5716 share the same ASIC ID.
> >
>
> Thanks for confirmation.
> Could you review the attached patch?
Looks good. ASIC ID matches my Dell R210 system:
bce0: mem 0xda00-0xdbff
irq 16 at device 0.0 on pci2
miibus0: on bce0
bce0: Ethernet address: b8:ac:6
This is the latest kernel panic screenshot..
http://imageshack.us/photo/my-images/707/newcrashw.png/
Thanks,
Chuck Burns
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "fre
> Because driver already initialized CPUs and context I thought
> moving bce_pulse() to bce_init() was too late. If that's doable it
> would be more correct way to address this issue.
>
Moving bce_pulse() is a minimum. It might be necessary to move
some other code out of bce_attach()/bce_detach(
On Fri, Oct 07, 2011 at 02:23:10PM -0700, David Christensen wrote:
> > > so, I cracked open my R410 this morning to see what the Ethernet
> > chipset
> > > had for a indentification mark. It is definitely stamped as a
> > BCM5716,
> > > so I'm confused.
> > >
> > > bce(4) has code to handle the 57
On Fri, Oct 07, 2011 at 02:17:06PM -0700, David Christensen wrote:
> > > Can't explain either but probably stable/6 bce(4) may have used old
> > > firmware.
> >
> > Ok, I can once again reach the IPMI controller if I remove this:
> >
> > http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1
The following reply was made to PR kern/159602; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/159602: commit references a PR
Date: Fri, 7 Oct 2011 22:22:29 + (UTC)
Author: qingli
Date: Fri Oct 7 22:22:19 2011
Hello,
I don't know if this is a atheros problem or a more general problem. But
since it happens with my atheros chip, here it goes.
I don't have any problem with normal operation. But when I run
"sh /etc/rc.d/netif restart" I get the lor below.
(the wierd freebsd version is because 10.0 breaks a
> Whoa ... ok, so now I've run into something horrible.
>
> According to dmidecode, a Dell R410 has a Broadcom 5716 chipset on it.
> On Board Device 2 Information
> Type: Ethernet
> Status: Enabled
> Description: Embedded Broadcom 5716 NIC 1
> On Board Device 3 Information
> > Can't explain either but probably stable/6 bce(4) may have used old
> > firmware.
>
> Ok, I can once again reach the IPMI controller if I remove this:
>
> http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210263&r2=21
> 0262&pathrev=210263
>
> Since the driver has control over the
> > so, I cracked open my R410 this morning to see what the Ethernet
> chipset
> > had for a indentification mark. It is definitely stamped as a
> BCM5716,
> > so I'm confused.
> >
> > bce(4) has code to handle the 5716 chipset, but its never being
> executed
> > AFAIK. What's going on here?
> >
On Fri, Oct 7, 2011 at 12:55 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Oct 7, 2011 at 3:24 PM, Mike Tancsa wrote:
> > When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the
> > board, or you disable multi-queue for the NIC, so it uses just one
> > interrupt, rather than separate
On Fri, Oct 7, 2011 at 12:55 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Oct 7, 2011 at 3:24 PM, Mike Tancsa wrote:
>
> When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the
> > board, or you disable multi-queue for the NIC, so it uses just one
> > interrupt, rather than separate
On Fri, Oct 07, 2011 at 04:09:34PM -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN wrote:
> > On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote:
> >> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote:
> >> > > > > I should probably say, this
On Fri, Oct 07, 2011 at 01:11:50PM -0700, Sean Bruno wrote:
> On Fri, 2011-10-07 at 12:11 -0700, YongHyeon PYUN wrote:
> > > What's even more strange is that our freebsd6 instances don't have
> > this
> > > problem.
> > >
> >
> > Can't explain either but probably stable/6 bce(4) may have used o
On Fri, Oct 7, 2011 at 12:24 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Oct 7, 2011 at 2:57 PM, Jason Wolfe wrote:
> > Jack,
> >
> > Entirely possible there are multiple moving pieces here, the only bit I
> know
> > for certain is it's related to the different operation when running with
> MSI
On 10/7/2011 4:26 PM, Arnaud Lacombe wrote:
>> em0: port 0x4040-0x405f mem
>> 0xb450-0xb451,0xb4525000-0xb4525fff irq 16 at device 25.0 on pci0
>> em0: Using an MSI interrupt
>> em0: [FILTER]
>> em0: Ethernet address: 00:15:17:ed:68:a5
>>
>> em1: port 0x2000-0x201f mem
>> 0xb410-0xb41
Hi,
On Fri, Oct 7, 2011 at 4:12 PM, Mike Tancsa wrote:
> On 10/7/2011 3:55 PM, Arnaud Lacombe wrote:
>>> When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the
>>> board, or you disable multi-queue for the NIC, so it uses just one
>>> interrupt, rather than separate ones for xmit an
On Fri, 2011-10-07 at 12:11 -0700, YongHyeon PYUN wrote:
> > What's even more strange is that our freebsd6 instances don't have
> this
> > problem.
> >
>
> Can't explain either but probably stable/6 bce(4) may have used old
> firmware.
Ok, I can once again reach the IPMI controller if I remov
On 10/7/2011 3:55 PM, Arnaud Lacombe wrote:
>> When you disable MSI-X, you mean via hw.pci.enable_msix=0 across the
>> board, or you disable multi-queue for the NIC, so it uses just one
>> interrupt, rather than separate ones for xmit and recv ?
>>
> em(4)'s multiqueue is misleading. By default, wi
Hi,
On Fri, Oct 7, 2011 at 3:11 PM, YongHyeon PYUN wrote:
> On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote:
>> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote:
>> > > > > I should probably say, this is freebsd7. So I'll peruse the
>> > > changelogs
>> > > > > and see if 7
Hi,
On Fri, Oct 7, 2011 at 3:24 PM, Mike Tancsa wrote:
> On 10/7/2011 2:59 PM, Jason Wolfe wrote:
>> Mike,
>>
>> I had a large pool of servers running 7.2.3 with MSI-X enabled during my
>> testing, but it didn't resolve the issue. I just pulled back the
>> sys/dev/e1000 directory from 8-STABLE an
Hi,
On Fri, Oct 7, 2011 at 2:57 PM, Jason Wolfe wrote:
> Jack,
>
> Entirely possible there are multiple moving pieces here, the only bit I know
> for certain is it's related to the different operation when running with MSI
> vs MSI-X. Here is also my loader.conf for reference. I'm currently runni
On 10/7/2011 2:59 PM, Jason Wolfe wrote:
> Mike,
>
> I had a large pool of servers running 7.2.3 with MSI-X enabled during my
> testing, but it didn't resolve the issue. I just pulled back the
> sys/dev/e1000 directory from 8-STABLE and ran it on 8-RELEASE-p2 though, so
> if there were changes mad
On Mon, Oct 03, 2011 at 04:06:18PM -0700, Sean Bruno wrote:
> On Mon, 2011-10-03 at 15:30 -0700, David Christensen wrote:
> > > > > I should probably say, this is freebsd7. So I'll peruse the
> > > changelogs
> > > > > and see if 7 is missing something here.
> > > > >
> > > > > sean
> > > >
> > >
Old Synopsis: RTL8169SC - re0: PHY write failed
New Synopsis: [re] RTL8169SC - re0: PHY write failed
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Oct 7 19:08:35 UTC 2011
Responsible-Changed-Why:
Over to maintainer(s).
http:/
Mike,
I had a large pool of servers running 7.2.3 with MSI-X enabled during my
testing, but it didn't resolve the issue. I just pulled back the
sys/dev/e1000 directory from 8-STABLE and ran it on 8-RELEASE-p2 though, so
if there were changes made outside of the actual driver code that helped I
may
Jack,
Entirely possible there are multiple moving pieces here, the only bit I know
for certain is it's related to the different operation when running with MSI
vs MSI-X. Here is also my loader.conf for reference. I'm currently running
the modular congestion control stuff with cubic in use, but the
Here is one of my specific responses to the PRs.
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026506.html
-- Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on behalf
of Li, Qing
Sent: Friday, October 07, 2
The important thing is if you have questions, just ask me.
You can start from this email thread.
http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026423.html
--Qing
From: owner-freebsd-...@freebsd.org [owner-freebsd-...@freebsd.org] on
Hi,
On Fri, Oct 7, 2011 at 2:10 PM, dfilter service wrote:
> The following reply was made to PR kern/159601; it has been noted by GNATS.
>
> From: dfil...@freebsd.org (dfilter service)
> To: bug-follo...@freebsd.org
> Cc:
> Subject: Re: kern/159601: commit references a PR
> Date: Fri, 7 Oct 2011
The following reply was made to PR kern/159601; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/159601: commit references a PR
Date: Fri, 7 Oct 2011 18:01:51 + (UTC)
Author: qingli
Date: Fri Oct 7 18:01:34 2011
On Fri, Oct 07, 2011 at 09:23:30AM -0700, Sean Bruno wrote:
>
> >
> > bce0@pci0:1:0:0:class=0x02 card=0x028c1028 chip=0x163b14e4
> > rev=0x20 hdr=0x00
> > vendor = 'Broadcom Corporation'
> > class = network
> > subclass = ethernet
> > bce1@pci0:1:0:1:cla
On 07.10.2011 17:54, Ryan Stone wrote:
Currently when FreeBSD responds to a ICMP Echo Request, it takes the
original mbuf, rewrites a couple of fields (like the src/dst IP and
the ICMP type), and then sends that mbuf back. As things are
currently implemented, the Don't Fragment bit is kept in th
On 10/7/2011 11:54 AM, Ryan Stone wrote:
> Currently when FreeBSD responds to a ICMP Echo Request, it takes the
> original mbuf, rewrites a couple of fields (like the src/dst IP and
> the ICMP type), and then sends that mbuf back. As things are
> currently implemented, the Don't Fragment bit is ke
>
> bce0@pci0:1:0:0:class=0x02 card=0x028c1028 chip=0x163b14e4
> rev=0x20 hdr=0x00
> vendor = 'Broadcom Corporation'
> class = network
> subclass = ethernet
> bce1@pci0:1:0:1:class=0x02 card=0x028c1028 chip=0x163b14e4
> rev=0x20 hdr=0x00
> vendor
Currently when FreeBSD responds to a ICMP Echo Request, it takes the
original mbuf, rewrites a couple of fields (like the src/dst IP and
the ICMP type), and then sends that mbuf back. As things are
currently implemented, the Don't Fragment bit is kept in the ICMP
replay. This can cause problems f
On 10/6/2011 7:15 PM, Jason Wolfe wrote:
> I'm seeing the interface wedge on a good number of systems with Intel 82574L
> chips under FBSD8.2 _only when MSI-X is enabled_, running either 7.1.9 from
> 8.2-RELEASE or 7.2.3 from 8.2-STABLE. I have em0 and em1 in a lagg, but
> only one side would fail
On Thu, Oct 6, 2011 at 19:34, dave jones wrote:
> Hi,
>
> Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using
> gpio-bitbang mii that I can refer to? Thanks.
> It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang
> mii,
> and it's useful for porting
On Fri, Oct 7, 2011 at 4:00 PM, Aleksandr Rybalko wrote:
> On Fri, 7 Oct 2011 10:34:58 +0800
> dave jones wrote:
>
>>> Hi,
>>>
>>> Does FreeBSD have gpio bitbang api for MII? If not, any driver in
>>> tree using gpio-bitbang mii that I can refer to? Thanks.
>>> It seems like OpenBSD, NetBSD and Li
On Fri, 7 Oct 2011 10:34:58 +0800
dave jones wrote:
>> Hi,
>>
>> Does FreeBSD have gpio bitbang api for MII? If not, any driver in
>> tree using gpio-bitbang mii that I can refer to? Thanks.
>> It seems like OpenBSD, NetBSD and Linux have added support to gpio
>> bitbang mii, and it's useful for
46 matches
Mail list logo
