On Tue, 2014-08-19 at 11:52 -0700, Benjamin Poirier wrote:
diff --git a/drivers/net/ethernet/broadcom/tg3.c
b/drivers/net/ethernet/broadcom/tg3.c
index 3ac5d23..b11c0fd 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -202,7 +202,8 @@ static
On Tue, 2014-08-19 at 11:52 -0700, Benjamin Poirier wrote:
@@ -7838,11 +7838,14 @@ static int tg3_tso_bug(struct tg3 *tp, struct
tg3_napi *tnapi,
struct netdev_queue *txq, struct sk_buff *skb)
{
struct sk_buff *segs, *nskb;
- u32 frag_cnt_est =
;+...
> - rcu_dereference
> + rcu_access_pointer
> (...)
> ...+>)) {...}
> )
>
> Signed-off-by: Andreea-Cristina Bernat
Acked-by: Michael Chan
> ---
> v2: Modified subject line from
> "rcu: Replace rcu_dereference() with rcu_access_pointer()"
> to
>
@gmail.com
Acked-by: Michael Chan mc...@broadcom.com
---
v2: Modified subject line from
rcu: Replace rcu_dereference() with rcu_access_pointer()
to
cnic: Replace rcu_dereference() with rcu_access_pointer(),
noted by David Miller da...@davemloft.net
drivers/net/ethernet/broadcom/cnic.c | 6
On Fri, 2014-01-31 at 14:29 +0100, Zoltan Kiss wrote:
> [ 5417.275472] WARNING: at net/sched/sch_generic.c:255
> dev_watchdog+0x156/0x1f0()
> [ 5417.275474] NETDEV WATCHDOG: eth1 (bnx2): transmit queue 2 timed out
The dump shows an internal IRQ pending on MSIX vector 2 which matches
the the
On Fri, 2014-01-31 at 14:29 +0100, Zoltan Kiss wrote:
[ 5417.275472] WARNING: at net/sched/sch_generic.c:255
dev_watchdog+0x156/0x1f0()
[ 5417.275474] NETDEV WATCHDOG: eth1 (bnx2): transmit queue 2 timed out
The dump shows an internal IRQ pending on MSIX vector 2 which matches
the the queue
On Thu, 2014-01-30 at 19:08 +, Zoltan Kiss wrote:
> I've experienced some queue timeout problems mentioned in the subject
> with igb and bnx2 cards.
Please provide the full tx timeout dmesg. bnx2 dumps some diagnostic
information during tx timeout that may be useful. Thanks.
--
To
On Thu, 2014-01-30 at 19:08 +, Zoltan Kiss wrote:
I've experienced some queue timeout problems mentioned in the subject
with igb and bnx2 cards.
Please provide the full tx timeout dmesg. bnx2 dumps some diagnostic
information during tx timeout that may be useful. Thanks.
--
To
On Tue, 2013-12-10 at 22:23 -0500, David Miller wrote:
> Ok, that may be true, but I'd like to consider the much larger issue
> at hand.
>
> If the indirect mechanism is enabled, some of the offsets that may be
> in there might be value, but would be entirely undesirable to be read
> because the
On Tue, 2013-12-10 at 22:23 -0500, David Miller wrote:
Ok, that may be true, but I'd like to consider the much larger issue
at hand.
If the indirect mechanism is enabled, some of the offsets that may be
in there might be value, but would be entirely undesirable to be read
because the read
On Tue, 2013-12-10 at 13:43 -0500, David Miller wrote:
> What if the kernel is booted via kexec, and the driver in the kernel
> we are kexec'ing from left indirect access enabled in MISC_HOST_CTRL?
That should be ok. The driver will only use valid register offsets in
indirect mode during run
On Tue, 2013-12-10 at 07:01 -0800, Natarajan Gurumoorthy wrote:
> The only time I see crashes is after the tg3 driver has been
> loaded into the system. I our use case we are poking around
> /sys/devices/pci//config.
David, please apply this first patch.
Acked-by: Mic
On Tue, 2013-12-10 at 13:43 -0500, David Miller wrote:
What if the kernel is booted via kexec, and the driver in the kernel
we are kexec'ing from left indirect access enabled in MISC_HOST_CTRL?
That should be ok. The driver will only use valid register offsets in
indirect mode during run
On Tue, 2013-12-10 at 07:01 -0800, Natarajan Gurumoorthy wrote:
The only time I see crashes is after the tg3 driver has been
loaded into the system. I our use case we are poking around
/sys/devices/pci//config.
David, please apply this first patch.
Acked-by: Michael Chan mc
On Mon, 2013-12-09 at 13:07 -0800, Michael Chan wrote:
> On Tue, 2013-12-10 at 00:18 +0300, Sergei Shtylyov wrote:
> > >We had crashes when the PCI config space got scanned via
> > > /sys/devices/pci/../config.
> >
> > > I agree that this f
On Tue, 2013-12-10 at 00:18 +0300, Sergei Shtylyov wrote:
> >We had crashes when the PCI config space got scanned via
> > /sys/devices/pci/../config.
>
> > I agree that this fix will not help if the scan happens before the tg3
> > driver gets loaded.
>
> Then perhaps a
On Mon, 2013-12-09 at 10:43 -0800, Nat Gurumoorthy wrote:
> The new tg3 driver leaves REG_BASE_ADDR (PCI config offset 120)
> uninitialized. From power on reset this register may have garbage in it. The
> Register Base Address register defines the device local address of a
> register. The data
On Mon, 2013-12-09 at 10:43 -0800, Nat Gurumoorthy wrote:
The new tg3 driver leaves REG_BASE_ADDR (PCI config offset 120)
uninitialized. From power on reset this register may have garbage in it. The
Register Base Address register defines the device local address of a
register. The data
On Tue, 2013-12-10 at 00:18 +0300, Sergei Shtylyov wrote:
We had crashes when the PCI config space got scanned via
/sys/devices/pci/../config.
I agree that this fix will not help if the scan happens before the tg3
driver gets loaded.
Then perhaps a better place for
On Mon, 2013-12-09 at 13:07 -0800, Michael Chan wrote:
On Tue, 2013-12-10 at 00:18 +0300, Sergei Shtylyov wrote:
We had crashes when the PCI config space got scanned via
/sys/devices/pci/../config.
I agree that this fix will not help if the scan happens before the tg3
On Mon, 2013-12-02 at 13:48 -0500, David Miller wrote:
> From: "Michael Chan"
> Date: Sun, 1 Dec 2013 12:39:19 -0800
>
> > I'm not familiar with the DS1. Does the tg3 device get removed through
> > tg3_remove_one() in this case? What happens when you
On Mon, 2013-12-02 at 13:48 -0500, David Miller wrote:
From: Michael Chan mc...@broadcom.com
Date: Sun, 1 Dec 2013 12:39:19 -0800
I'm not familiar with the DS1. Does the tg3 device get removed through
tg3_remove_one() in this case? What happens when you reconnect the DS1?
Michael
On Sun, 2013-12-01 at 02:34 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Modify tg3_chip_reset() and tg3_close() to check if the PCI network
> adapter device is accessible at all in order to skip poking it or
> trying to handle a carrier loss in vain when that's not the case.
>
On Sun, 2013-12-01 at 02:34 +0100, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
Modify tg3_chip_reset() and tg3_close() to check if the PCI network
adapter device is accessible at all in order to skip poking it or
trying to handle a carrier loss in vain when
On Wed, 2013-05-29 at 17:00 +0800, Yijing Wang wrote:
> Pci_enable_device() will set device pm state to D0, so
> it's no need to do it again in tg3_init_one().
>
> Signed-off-by: Yijing Wang
Acked-by: Michael Chan
> ---
> drivers/net/ethernet/broadcom/tg3.c | 20 +--
On Wed, 2013-05-29 at 17:00 +0800, Yijing Wang wrote:
Pci_enable_device() will set device pm state to D0, so
it's no need to do it again in tg3_init_one().
Signed-off-by: Yijing Wang wangyij...@huawei.com
Acked-by: Michael Chan mc...@broadcom.com
---
drivers/net/ethernet/broadcom/tg3.c
ev and tg3_chip_rev.
>
> These macros are not converted to static inline functions
> because gcc (tested with 4.7.2) is currently unable to
> optimize the object code it produces the same way and code
> is otherwise larger.
>
> Signed-off-by: Joe Perches
Acked-by: Mi
On Sat, 2013-02-16 at 13:20 -0800, Joe Perches wrote:
> It's the same value as tp->pci_chip_rev_id so use that
> instead. This makes all CHIPREV_ID_ tests the same.
>
> Signed-off-by: Joe Perches
Acked-by: Michael Chan
--
To unsubscribe from this list: send the line &qu
On Sat, 2013-02-16 at 13:20 -0800, Joe Perches wrote:
It's the same value as tp-pci_chip_rev_id so use that
instead. This makes all CHIPREV_ID_foo tests the same.
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Michael Chan mc...@broadcom.com
--
To unsubscribe from this list: send
because gcc (tested with 4.7.2) is currently unable to
optimize the object code it produces the same way and code
is otherwise larger.
Signed-off-by: Joe Perches j...@perches.com
Acked-by: Michael Chan mc...@broadcom.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
It was mistakenly defined to be 24 instead of the next higher number 25.
Reported-by: Alexander Shishkin
Cc: Stephen Hurd
Signed-off-by: Michael Chan
---
include/uapi/linux/serial_core.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/uapi/linux/serial_core.h
It was mistakenly defined to be 24 instead of the next higher number 25.
Reported-by: Alexander Shishkin alexander.shish...@linux.intel.com
Cc: Stephen Hurd sh...@broadcom.com
Signed-off-by: Michael Chan mc...@broadcom.com
---
include/uapi/linux/serial_core.h |2 +-
1 files changed, 1
to track this. It continues to reload the THR as long
as the THRE and TSRE bits are set in the LSR up to a specified limit (1024
is used here).
Signed-off-by: Stephen Hurd
Signed-off-by: Michael Chan
---
drivers/tty/serial/8250/8250.c | 11 ++
drivers/tty/serial/8250/8250.h
On Thu, 2013-01-17 at 17:59 +0100, Marcin Miotk wrote:
> root@XX ~ # cat miitool_non_working_3.4.11
> Using SIOCGMIIPHY=0x8947
> eth1: 100 Mbit, full duplex, no link
> registers for MII PHY 1:
> 2100 7949 0020 6340 0041 0004 2001
> 3000
>
On Thu, 2013-01-17 at 17:59 +0100, Marcin Miotk wrote:
root@XX ~ # cat miitool_non_working_3.4.11
Using SIOCGMIIPHY=0x8947
eth1: 100 Mbit, full duplex, no link
registers for MII PHY 1:
2100 7949 0020 6340 0041 0004 2001
3000
0001
capability was added to track this. It continues to reload the THR as long
as the THRE and TSRE bits are set in the LSR up to a specified limit (1024
is used here).
Signed-off-by: Stephen Hurd sh...@broadcom.com
Signed-off-by: Michael Chan mc...@broadcom.com
---
drivers/tty/serial/8250/8250.c
On Wed, 2013-01-09 at 08:03 +0100, Marcin Miotk wrote:
> 03:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715
> Gigabit Ethernet (rev a3)
> 03:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5715
> Gigabit Ethernet (rev a3)
I tested on 3.7 kernel and it seemed to work.
On Wed, 2013-01-09 at 08:03 +0100, Marcin Miotk wrote:
03:04.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5715
Gigabit Ethernet (rev a3)
03:04.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5715
Gigabit Ethernet (rev a3)
I tested on 3.7 kernel and it seemed to work.
Please tell us what tg3 device you're using. You can provide lspci
output or tg3 probing dmesg output. Thanks.
On Wed, 2013-01-09 at 11:20 +0800, 王金浦 wrote:
> For this kind of driver related question, I suggest you send mail to
> tg3 driver developers, who I already cced.
>
>
> I think they
Please tell us what tg3 device you're using. You can provide lspci
output or tg3 probing dmesg output. Thanks.
On Wed, 2013-01-09 at 11:20 +0800, 王金浦 wrote:
For this kind of driver related question, I suggest you send mail to
tg3 driver developers, who I already cced.
I think they
On Tue, 2012-10-02 at 18:49 +0200, Ferenc Wagner wrote:
> Going into the opposite direction: I found that Linux 3.6 does not
> permanently break the SoL console on upping eth0! I'll try to find
> the
> commit which (sort of) fixed it.
These are the likely fixes:
>
commit
t;
> This patch moves the code that asserts the TSO_CAPABLE flag closer
> to
> where the TSO capabilities flags are set. There isn't a good
> enough
> reason for the code to be separated.
>
> Signed-off-by: Matt Carlson
> Reviewed-by: Michael Cha
This patch moves the code that asserts the TSO_CAPABLE flag closer
to
where the TSO capabilities flags are set. There isn't a good
enough
reason for the code to be separated.
Signed-off-by: Matt Carlson mcarl...@broadcom.com
Reviewed-by: Michael Chan mc...@broadcom.com
On Tue, 2012-10-02 at 18:49 +0200, Ferenc Wagner wrote:
Going into the opposite direction: I found that Linux 3.6 does not
permanently break the SoL console on upping eth0! I'll try to find
the
commit which (sort of) fixed it.
These are the likely fixes:
commit
On Fri, 2012-09-28 at 22:45 +0200, Ferenc Wagner wrote:
> Hi,
>
> Upgrading the kernel on our HS20 blades resulted in their SoL (serial
> over LAN) connection being broken. The disconnection happens when eth0
> (the interface involved in SoL) is brought up during the boot sequence.
> If I later
On Fri, 2012-09-28 at 22:45 +0200, Ferenc Wagner wrote:
Hi,
Upgrading the kernel on our HS20 blades resulted in their SoL (serial
over LAN) connection being broken. The disconnection happens when eth0
(the interface involved in SoL) is brought up during the boot sequence.
If I later ip
On Thu, 2012-08-16 at 21:48 +, Jiang Wang wrote:
> I see. I was confused by the name of bnx2_set_power_state() and
> I think the PHY is actually powered up by bnx2_reset_nic, right?
bnx2_init_phy() in bnx2_init_nic() will bring up the PHY if it is down.
>
>
--
To unsubscribe from
On Thu, 2012-08-16 at 20:28 +, Jiang Wang wrote:
> Also, I have another comment related to link state.
>
> Right now, the bnx2 driver powers up the device in bnx2_init_board(),
> regardless the netif_carrier is on or off.
We actually don't power up the device. bnx2_init_board() just probes
is called. Can you please
elborate? Thanks.
> Regards,
>
> Jiang
>
> -
> Jiang Wang
> Member of Technical Staff
> Riverbed Technology
> Tel: (408) 522-5109
> Email: jiang.w...@riverbed.com
> www.riverbed.com
>
>
> -
On Thu, 2012-08-16 at 11:21 -0700, Jiang Wang wrote:
> The initialization state of bnx2 driver is wrong. It does not turn
> of the Linux network stack using netif_carrier_off. This may lead to
> inconsistent report from ethtool as the link is up but speed is
> unknown when the cable is not
On Thu, 2012-08-16 at 11:21 -0700, Jiang Wang wrote:
The initialization state of bnx2 driver is wrong. It does not turn
of the Linux network stack using netif_carrier_off. This may lead to
inconsistent report from ethtool as the link is up but speed is
unknown when the cable is not plugged
-
Jiang Wang
Member of Technical Staff
Riverbed Technology
Tel: (408) 522-5109
Email: jiang.w...@riverbed.com
www.riverbed.com
-Original Message-
From: Michael Chan [mailto:mc...@broadcom.com]
Sent: Thursday, August 16, 2012 11:57 AM
To: Jiang Wang
Cc
On Thu, 2012-08-16 at 20:28 +, Jiang Wang wrote:
Also, I have another comment related to link state.
Right now, the bnx2 driver powers up the device in bnx2_init_board(),
regardless the netif_carrier is on or off.
We actually don't power up the device. bnx2_init_board() just probes
the
On Thu, 2012-08-16 at 21:48 +, Jiang Wang wrote:
I see. I was confused by the name of bnx2_set_power_state() and
I think the PHY is actually powered up by bnx2_reset_nic, right?
bnx2_init_phy() in bnx2_init_nic() will bring up the PHY if it is down.
--
To unsubscribe from this
On Fri, 2012-07-13 at 15:09 +0100, Chris Webb wrote:
> Is there a more automatic method than going through the source for each
> configured driver and setting CONFIG_EXTRA_FIRMWARE manually to list the
> relevant firmwares? Is there any way to give the kernel the location of
> linux-firmware and
On Fri, 2012-07-13 at 15:09 +0100, Chris Webb wrote:
Is there a more automatic method than going through the source for each
configured driver and setting CONFIG_EXTRA_FIRMWARE manually to list the
relevant firmwares? Is there any way to give the kernel the location of
linux-firmware and have
On Wed, 2008-02-20 at 15:08 -0800, David Miller wrote:
> From: Tony Battersby <[EMAIL PROTECTED]>
> Date: Wed, 20 Feb 2008 18:04:09 -0500
>
> > The following patch fixes the problem for me. Do we want to accept this
> > patch and call it a day or continue investigating the source of the problem?
On Wed, 2008-02-20 at 15:08 -0800, David Miller wrote:
From: Tony Battersby [EMAIL PROTECTED]
Date: Wed, 20 Feb 2008 18:04:09 -0500
The following patch fixes the problem for me. Do we want to accept this
patch and call it a day or continue investigating the source of the problem?
On Tue, 2008-02-19 at 17:14 -0500, Tony Battersby wrote:
>
> Update: when I revert Herbert's patch in addition to applying your
> patch, the iSCSI performance goes back up to 115 MB/s again in both
> directions. So it looks like turning off SG for TX didn't itself cause
> the performance drop,
On Tue, 2008-02-19 at 11:16 -0500, Tony Battersby wrote:
> iSCSI
> performance drops to 6 - 15 MB/s when the 3Com NIC is doing heavy rx
> with light tx,
That's strange. The patch should only affect TX performance slightly
since we are just turning off SG for TX. Please take an ethereal trace
to
On Tue, 2008-02-19 at 11:16 -0500, Tony Battersby wrote:
iSCSI
performance drops to 6 - 15 MB/s when the 3Com NIC is doing heavy rx
with light tx,
That's strange. The patch should only affect TX performance slightly
since we are just turning off SG for TX. Please take an ethereal trace
to
On Tue, 2008-02-19 at 17:14 -0500, Tony Battersby wrote:
Update: when I revert Herbert's patch in addition to applying your
patch, the iSCSI performance goes back up to 115 MB/s again in both
directions. So it looks like turning off SG for TX didn't itself cause
the performance drop, but
On Mon, 2008-02-18 at 16:35 -0800, David Miller wrote:
> One consequence of Herbert's change is that the chip will see a
> different datastream. The initial skb->data linear area will be
> smaller, and the transition to the fragmented area of pages will be
> quicker.
>
I see. Perhaps when we
On Mon, 2008-02-18 at 17:41 -0500, Tony Battersby wrote:
> I am experiencing network data corruption with a 3Com 3C996B-T NIC
> (Broadcom NetXtreme BCM5701; driver tg3.ko). I have identified the
> following patch as the trigger:
Assuming this problem is unique to the 5701, I'm not sure how it is
On Mon, 2008-02-18 at 16:35 -0800, David Miller wrote:
One consequence of Herbert's change is that the chip will see a
different datastream. The initial skb-data linear area will be
smaller, and the transition to the fragmented area of pages will be
quicker.
I see. Perhaps when we get to
On Mon, 2008-02-18 at 17:41 -0500, Tony Battersby wrote:
I am experiencing network data corruption with a 3Com 3C996B-T NIC
(Broadcom NetXtreme BCM5701; driver tg3.ko). I have identified the
following patch as the trigger:
Assuming this problem is unique to the 5701, I'm not sure how it is
for 1000Base-X twice instead
checking for both the 1000Base-X bit and the 10/100/1000Base-T bit.
The purpose of the logic is to tell the firmware that ASYM_PAUSE is
set on either the Serdes or Copper interface.
Problem was discovered by Roel Kluin <[EMAIL PROTECTED]>
Signed-off-by: Michael Ch
the 1000Base-X bit and the 10/100/1000Base-T bit.
The purpose of the logic is to tell the firmware that ASYM_PAUSE is
set on either the Serdes or Copper interface.
Problem was discovered by Roel Kluin [EMAIL PROTECTED]
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/bnx2.c b
On Tue, 2007-11-27 at 01:35 -0800, [EMAIL PROTECTED] wrote:
>
> Issue:
>
> I (for unrelated reasons) run powertop, and it suggests I conserve power
> by doing 'ethtool -s eth0 wol d'. I look at it, and think that it's daft,
> because (a) the Dell factory default is WOL disabled and (b) if it
[EMAIL PROTECTED] wrote:
> (a) the Dell factory default is WOL disabled and (b)
> if it wasn't
> the default, I'd have *set* it to disabled, and (c) I even
> went back and
> rebooted and checked the BIOS setting - disabled. Nonetheless:
>
> # ethtool eth0 | grep Wake
> Supports
[EMAIL PROTECTED] wrote:
(a) the Dell factory default is WOL disabled and (b)
if it wasn't
the default, I'd have *set* it to disabled, and (c) I even
went back and
rebooted and checked the BIOS setting - disabled. Nonetheless:
# ethtool eth0 | grep Wake
Supports Wake-on: g
On Tue, 2007-11-27 at 01:35 -0800, [EMAIL PROTECTED] wrote:
Issue:
I (for unrelated reasons) run powertop, and it suggests I conserve power
by doing 'ethtool -s eth0 wol d'. I look at it, and think that it's daft,
because (a) the Dell factory default is WOL disabled and (b) if it wasn't
On Thu, 2007-11-15 at 13:17 -0600, Jon Nelson wrote:
> Is this what you mean? I pulled this from the quoted text:
>
> Nov 10 22:45:52 frank kernel: NETDEV WATCHDOG: eth0: transmit timed out
>
Right. This explains the reset at 22:45:52, but not the earlier reset
at 22:24:40. Link never came
On Thu, 2007-11-15 at 10:47 +0100, Jarek Poplawski wrote:
> On 13-11-2007 19:57, Jon Nelson wrote:
> > The best info I've got is this:
It looks like the card is being reset periodically. Every time the card
gets reset, you'll see those PM messages in the version of the driver
you're using. Do
On Thu, 2007-11-15 at 10:47 +0100, Jarek Poplawski wrote:
On 13-11-2007 19:57, Jon Nelson wrote:
The best info I've got is this:
It looks like the card is being reset periodically. Every time the card
gets reset, you'll see those PM messages in the version of the driver
you're using. Do you
On Thu, 2007-11-15 at 13:17 -0600, Jon Nelson wrote:
Is this what you mean? I pulled this from the quoted text:
Nov 10 22:45:52 frank kernel: NETDEV WATCHDOG: eth0: transmit timed out
Right. This explains the reset at 22:45:52, but not the earlier reset
at 22:24:40. Link never came up
On Tue, 2007-11-13 at 18:04 -0800, Joe Perches wrote:
> Remove defconfig ptr comparison to 0
>
> Remove sparse warning: Using plain integer as NULL pointer
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
Acked-by: Michael Chan <[EMAIL PROTECTED]>
Thanks.
-
On Tue, 2007-11-13 at 18:04 -0800, Joe Perches wrote:
Remove defconfig ptr comparison to 0
Remove sparse warning: Using plain integer as NULL pointer
Signed-off-by: Joe Perches [EMAIL PROTECTED]
Acked-by: Michael Chan [EMAIL PROTECTED]
Thanks.
-
To unsubscribe from this list: send
ix VLAN on ASF
> >
> > Always set up the device to strip incoming VLAN tags when ASF is
> > enabled. ASF firmware will not parse packets correctly if VLAN tags
> > are not stripped.
> >
> > Signed-off-by: Michael Chan <[EMAIL PROT
incoming VLAN tags when ASF is
enabled. ASF firmware will not parse packets correctly if VLAN tags
are not stripped.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
GIT: e29054f92d7d575631691865c1b95bee5bc974cc
and
[EMAIL
PCI_DEVICE_ID_TIGON3_5714S,
> + quirk_msi_intx_disable_bug);
> +
Please add PCI_DEVICE_ID_TIGON3_5715 and
PCI_DEVICE_ID_TIGON3_5715S as well.
Other than that,
Acked-by: Michael Chan <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscrib
,
+ quirk_msi_intx_disable_bug);
+
Please add PCI_DEVICE_ID_TIGON3_5715 and
PCI_DEVICE_ID_TIGON3_5715S as well.
Other than that,
Acked-by: Michael Chan [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
ll try to do so as well
> tonight.
>
I've already reviewed the earlier versions of the patch and have made
some suggestions. This latest one looks ok to me and tested ok.
I'll follow up later with another patch to remove all the zeros in other
firmware sections, and to remove the gzip head
already reviewed the earlier versions of the patch and have made
some suggestions. This latest one looks ok to me and tested ok.
I'll follow up later with another patch to remove all the zeros in other
firmware sections, and to remove the gzip headers completely.
Acked-by: Michael Chan [EMAIL
On Thu, 2007-09-20 at 15:49 +0100, Denys Vlasenko wrote:
>
>
> Please test these two patches.
> I updated them according to your comments.
>
>
I've only tested patch #1. It worked after some minor modifications
below.
>
>
>
>
>
> plain text
> document
> attachment
> (linux-2.6.23-
>
On Thu, 2007-09-20 at 15:49 +0100, Denys Vlasenko wrote:
Please test these two patches.
I updated them according to your comments.
I've only tested patch #1. It worked after some minor modifications
below.
plain text
document
attachment
(linux-2.6.23-
rc6.bnx2-1.patch)
On Wed, 2007-09-19 at 21:29 +0100, Denys Vlasenko wrote:
> Are you saying that you successfully run-tested it?
I've only reviewed the code. Let's resolve these issues first before
testing the code.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, 2007-09-19 at 09:30 +0100, Denys Vlasenko wrote:
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+* is stripped, 32-bit unpacked size (LE) is prepended instead */
+ sz = *zbuf++;
+ sz = (sz << 8) + *zbuf++;
+ sz = (sz << 8) + *zbuf++;
On Wed, 2007-09-19 at 09:30 +0100, Denys Vlasenko wrote:
+ /* gzip header (1f,8b,08... 10 bytes total + possible asciz filename)
+* is stripped, 32-bit unpacked size (LE) is prepended instead */
+ sz = *zbuf++;
+ sz = (sz 8) + *zbuf++;
+ sz = (sz 8) + *zbuf++;
+
On Wed, 2007-09-19 at 21:29 +0100, Denys Vlasenko wrote:
Are you saying that you successfully run-tested it?
I've only reviewed the code. Let's resolve these issues first before
testing the code.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Tue, 2007-09-18 at 23:37 +0200, Willy Tarreau wrote:
> > > Michael, doesn't a functional-yet-suboptimal firmware exist ? I mean,
> > > just the same principle as we all have kernels, boot CDs, statically
> > > built tools, etc... which run everywhere. If you have such a beast,
> > > maybe it
On Tue, 2007-09-18 at 11:23 -0700, David Miller wrote:
> I don't like it because it means people have to setup full initrd's
> in order to do network booting with such network cards.
>
> But the days of my opinion mattering on that issue are long gone,
> the momentum is just too greatly behind
On Tue, 2007-09-18 at 18:55 +0100, Denys Vlasenko wrote:
> On Tuesday 18 September 2007 19:45, Michael Chan wrote:
> > We can compress all the different sections of the firmware. Currently,
> > we only compress the biggest chunks and the rest are uncompressed.
>
> > The
On Tue, 2007-09-18 at 18:23 +0100, Denys Vlasenko wrote:
> Hi Michael,
>
> In bnx2_fw.h I see the following:
>
> static u32 bnx2_RXP_b06FwBss[(0x13dc/4) + 1] = { 0x0 };
>
> static struct fw_info bnx2_rxp_fw_06 = {
> ...
> .bss= bnx2_RXP_b06FwBss,
> ...
> };
>
On Tue, 2007-09-18 at 18:23 +0100, Denys Vlasenko wrote:
Hi Michael,
In bnx2_fw.h I see the following:
static u32 bnx2_RXP_b06FwBss[(0x13dc/4) + 1] = { 0x0 };
static struct fw_info bnx2_rxp_fw_06 = {
...
.bss= bnx2_RXP_b06FwBss,
...
};
I grepped
On Tue, 2007-09-18 at 18:55 +0100, Denys Vlasenko wrote:
On Tuesday 18 September 2007 19:45, Michael Chan wrote:
We can compress all the different sections of the firmware. Currently,
we only compress the biggest chunks and the rest are uncompressed.
These zeros should compress to almost
On Tue, 2007-09-18 at 11:23 -0700, David Miller wrote:
I don't like it because it means people have to setup full initrd's
in order to do network booting with such network cards.
But the days of my opinion mattering on that issue are long gone,
the momentum is just too greatly behind using
On Tue, 2007-09-18 at 23:37 +0200, Willy Tarreau wrote:
Michael, doesn't a functional-yet-suboptimal firmware exist ? I mean,
just the same principle as we all have kernels, boot CDs, statically
built tools, etc... which run everywhere. If you have such a beast,
maybe it would be a
On Fri, 2007-09-14 at 09:18 -0700, Roland Dreier wrote:
> However, do you have any plans to support iSCSI offload for targets?
> Also, looking at the first CNIC patch, I can't help but notice that
> you seem to have at least some support for iWARP there. How does the
> CNIC look? Does it share
On Fri, 2007-09-14 at 09:18 -0700, Roland Dreier wrote:
However, do you have any plans to support iSCSI offload for targets?
Also, looking at the first CNIC patch, I can't help but notice that
you seem to have at least some support for iWARP there. How does the
CNIC look? Does it share the
101 - 200 of 228 matches
Mail list logo
