* Re: [patch 2.6.14-rc4] via-rhine: change mdelay to msleep and remove from ISR path
From: Jeff Garzik @ 2005-10-19 2:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, rl
In-Reply-To: <10182005213102.12948@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc3] epic100: fix counting of work_done in epic_poll
From: Jeff Garzik @ 2005-10-19 2:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev
In-Reply-To: <10182005213101.12633@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc3] 8139too: fix resume for Realtek 8100B/8139D
From: Jeff Garzik @ 2005-10-19 2:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev
In-Reply-To: <10182005213100.12557@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc4] bonding: fix typos in bonding documentation
From: Jeff Garzik @ 2005-10-19 2:26 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, ctindel, fubar, bonding-devel
In-Reply-To: <10182005213059.12167@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc4] b44: alternate allocation option for DMA descriptors
From: Jeff Garzik @ 2005-10-19 2:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, pp
In-Reply-To: <10182005213059.12243@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc4] orinoco: remove redundance skb length check before padding
From: Jeff Garzik @ 2005-10-19 2:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, proski, hermes, orinoco-devel
In-Reply-To: <10182005213058.12015@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc4] bonding: cleanup comment for mode 1 IGMP xmit hack
From: Jeff Garzik @ 2005-10-19 2:27 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, ctindel, fubar, bonding-devel
In-Reply-To: <10182005213058.12091@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc4 0/3] sk98lin: neuter and prepare for removal
From: Jeff Garzik @ 2005-10-19 2:28 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, shemminger, mlindner, rroesler
In-Reply-To: <10182005213059.12304@bilbo.tuxdriver.com>
John W. Linville wrote:
> These patches take steps towards removing sk98lin from the upstream
> kernel.
>
> -- Remove sk98lin's MODULE_DEVICE_TABLE to avoid
> confusing userland tools about which driver to load;
>
> -- Mark sk98lin as Obsolete in the MAINTAINERS file; and,
>
> -- Add sk98lin to the feature-removal-schedule.txt file in the
> Documentation directory.
>
> I accept the possibility that I may be jumping the gun on this.
> However, I think it is worth opening this discussion.
I'll let Stephen make the call on this one (as he did...).
Jeff
^ permalink raw reply
* Re: [patch 2.6.14-rc3 1/3] sundance: remove if (1) { ... } block in sundance_probe1
From: Jeff Garzik @ 2005-10-19 2:29 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev
In-Reply-To: <10182005213101.12750@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc3 3/3] sundance: expand reset mask
From: Jeff Garzik @ 2005-10-19 2:29 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev
In-Reply-To: <10182005213102.12871@bilbo.tuxdriver.com>
applied
^ permalink raw reply
* Re: [patch 2.6.14-rc3 2/3] sundance: probe PHYs from MII address 0
From: Jeff Garzik @ 2005-10-19 2:31 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev
In-Reply-To: <10182005213101.12810@bilbo.tuxdriver.com>
John W. Linville wrote:
> Probe for PHYs starting at MII address 0 instead of MII address 1.
> This covers the entire range of MII addresses.
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
>
> drivers/net/sundance.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
> --- a/drivers/net/sundance.c
> +++ b/drivers/net/sundance.c
> @@ -608,7 +608,7 @@ static int __devinit sundance_probe1 (st
>
> np->phys[0] = 1; /* Default setting */
> np->mii_preamble_required++;
> - for (phy = 1; phy < 32 && phy_idx < MII_CNT; phy++) {
> + for (phy = 0; phy < 32 && phy_idx < MII_CNT; phy++) {
NAK. MII address 0 should be scanned _last_, after all other addresses.
In some phys, it is a ghost, mirroring another address.
Take a look at some of the original Becker MII scan code from
ftp://ftp.scyld.com/pub/network/ to see an elegant method for this.
Becker's scan code would utilize a mask to keep the loop nice and
elegant, eliminating an "if (phy == 32) phy = 0;" test.
Jeff
^ permalink raw reply
* group Global trusts pharmaceutical. exalt
From: travis schoborg @ 2005-10-19 3:28 UTC (permalink / raw)
To: Carson Serrett
Cc: owner-linux-xfs, tucker, netdev, lockmeter, murray, ljp, arnold,
dev
Hard to locate meddiccine, get them all at this site.
Allay your pressure by consuming our finest tablet.
Fully Tracked Parcel will arrive to you normally in 46hrs.
Therapy your discomfort at much affordable expenditure.
FOC check up details with our qualified physician.
3 words for you! You are amazing. Daisy G --Florida.
http://uk.geocities.com/abilitystrutb/?hfobh
He is gradually emerging from Tom-all-Alone's in the morning light,
thinking about it, when he hears running feet behind him, and looking round,
sees the boy scouring towards him at great speed, followed by the woman.
"Stop him, stop him." cries the woman, almost breath less. "Stop him, sir."
felhevizi erutsop fbmtab sz03 fixraw fkq
"I can't help it, Charley."
^ permalink raw reply
* Re: [patch 2.6.14-rc3 2/3] sundance: probe PHYs from MII address 0
From: John W. Linville @ 2005-10-19 12:00 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, netdev
In-Reply-To: <4355B017.4040509@pobox.com>
On Tue, Oct 18, 2005 at 10:31:51PM -0400, Jeff Garzik wrote:
> John W. Linville wrote:
> >--- a/drivers/net/sundance.c
> >+++ b/drivers/net/sundance.c
> >@@ -608,7 +608,7 @@ static int __devinit sundance_probe1 (st
> >
> > np->phys[0] = 1; /* Default setting */
> > np->mii_preamble_required++;
> >- for (phy = 1; phy < 32 && phy_idx < MII_CNT; phy++) {
> >+ for (phy = 0; phy < 32 && phy_idx < MII_CNT; phy++) {
>
> NAK. MII address 0 should be scanned _last_, after all other addresses.
> In some phys, it is a ghost, mirroring another address.
>
> Take a look at some of the original Becker MII scan code from
> ftp://ftp.scyld.com/pub/network/ to see an elegant method for this.
Hmmm...that is clever...patch to follow...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [patch 2.6.14-rc3] sundance: include MII address 0 in PHY probe
From: John W. Linville @ 2005-10-19 12:07 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: jgarzik
In-Reply-To: <20051019120022.GA15438@tuxdriver.com>
Include MII address 0 at the end of the PHY scan. This covers the
entire range of possible MII addresses.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/sundance.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/sundance.c b/drivers/net/sundance.c
--- a/drivers/net/sundance.c
+++ b/drivers/net/sundance.c
@@ -608,16 +608,17 @@ static int __devinit sundance_probe1 (st
np->phys[0] = 1; /* Default setting */
np->mii_preamble_required++;
- for (phy = 1; phy < 32 && phy_idx < MII_CNT; phy++) {
+ for (phy = 1; phy <= 32 && phy_idx < MII_CNT; phy++) {
int mii_status = mdio_read(dev, phy, MII_BMSR);
+ int phyx = phy & 0x1f;
if (mii_status != 0xffff && mii_status != 0x0000) {
- np->phys[phy_idx++] = phy;
- np->mii_if.advertising = mdio_read(dev, phy, MII_ADVERTISE);
+ np->phys[phy_idx++] = phyx;
+ np->mii_if.advertising = mdio_read(dev, phyx, MII_ADVERTISE);
if ((mii_status & 0x0040) == 0)
np->mii_preamble_required++;
printk(KERN_INFO "%s: MII PHY found at address %d, status "
"0x%4.4x advertising %4.4x.\n",
- dev->name, phy, mii_status, np->mii_if.advertising);
+ dev->name, phyx, mii_status, np->mii_if.advertising);
}
}
np->mii_preamble_required--;
^ permalink raw reply
* Re: [patch 2.6.14-rc4] e1000: Driver version, white space, comments, device id & other
From: John W. Linville @ 2005-10-19 14:31 UTC (permalink / raw)
To: Jeff Garzik
Cc: linux-kernel, netdev, john.ronciak, ganesh.venkatesan,
mallikarjuna.chilakala
In-Reply-To: <4355AE62.7080605@pobox.com>
On Tue, Oct 18, 2005 at 10:24:34PM -0400, Jeff Garzik wrote:
> John W. Linville wrote:
> >From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
> >
> >Driver version, white space, comments, device id & other
> patch is ok, but doesn't apply to 'upstream' branch of netdev-2.6.git,
> which has several e1000 patches in it.
I see...looks like some fuzz...I'll rediff and repost...
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* [patch netdev-2.6] e1000: Driver version, white space, comments, device id & other
From: John W. Linville @ 2005-10-19 14:40 UTC (permalink / raw)
To: linux-kernel, netdev
Cc: jgarzik, john.ronciak, ganesh.venkatesan, mallikarjuna.chilakala
In-Reply-To: <20051019143154.GA16830@tuxdriver.com>
From: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Driver version, white space, comments, device id & other
Originally posted on 8/31 (and perhaps before)...I think it has not
been committed because the patch from that posting was damaged. I'm
reposting to make sure it gets in... :-)
Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
Signed-off-by: John Ronciak <john.ronciak@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/e1000/e1000_main.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -43,7 +43,7 @@ char e1000_driver_string[] = "Intel(R) P
#else
#define DRIVERNAPI "-NAPI"
#endif
-#define DRV_VERSION "6.0.60-k2"DRIVERNAPI
+#define DRV_VERSION "6.1.16-k2"DRIVERNAPI
char e1000_driver_version[] = DRV_VERSION;
char e1000_copyright[] = "Copyright (c) 1999-2005 Intel Corporation.";
@@ -80,6 +80,9 @@ static struct pci_device_id e1000_pci_tb
INTEL_E1000_ETHERNET_DEVICE(0x1026),
INTEL_E1000_ETHERNET_DEVICE(0x1027),
INTEL_E1000_ETHERNET_DEVICE(0x1028),
+ INTEL_E1000_ETHERNET_DEVICE(0x105E),
+ INTEL_E1000_ETHERNET_DEVICE(0x105F),
+ INTEL_E1000_ETHERNET_DEVICE(0x1060),
INTEL_E1000_ETHERNET_DEVICE(0x1075),
INTEL_E1000_ETHERNET_DEVICE(0x1076),
INTEL_E1000_ETHERNET_DEVICE(0x1077),
@@ -88,10 +91,13 @@ static struct pci_device_id e1000_pci_tb
INTEL_E1000_ETHERNET_DEVICE(0x107A),
INTEL_E1000_ETHERNET_DEVICE(0x107B),
INTEL_E1000_ETHERNET_DEVICE(0x107C),
+ INTEL_E1000_ETHERNET_DEVICE(0x107D),
+ INTEL_E1000_ETHERNET_DEVICE(0x107E),
+ INTEL_E1000_ETHERNET_DEVICE(0x107F),
INTEL_E1000_ETHERNET_DEVICE(0x108A),
INTEL_E1000_ETHERNET_DEVICE(0x108B),
INTEL_E1000_ETHERNET_DEVICE(0x108C),
- INTEL_E1000_ETHERNET_DEVICE(0x1099),
+ INTEL_E1000_ETHERNET_DEVICE(0x109A),
/* required last entry */
{0,}
};
@@ -398,8 +404,7 @@ e1000_down(struct e1000_adapter *adapter
e1000_clean_all_tx_rings(adapter);
e1000_clean_all_rx_rings(adapter);
- /* If WoL is not enabled
- * and management mode is not IAMT
+ /* If WoL is not enabled and management mode is not IAMT
* Power down the PHY so no link is implied when interface is down */
if(!adapter->wol && adapter->hw.mac_type >= e1000_82540 &&
adapter->hw.media_type == e1000_media_type_copper &&
^ permalink raw reply
* [PATCH] skge support for Marvell chips in Toshiba laptops
From: Jesse Barnes @ 2005-10-19 17:47 UTC (permalink / raw)
To: shemminger, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 493 bytes --]
Here's a small patch to add the PCI ID and chip type of the chip in my
Toshiba laptop to the skge driver. I haven't tested it much (just
insmoded it and run ethtool against the corresponding eth1 device), but
it doesn't crash my system, so unless this configuration has already
been tested and is known to have problems, it might be good to add this
patch.
I'll test some more with a real network when I get home.
Thanks,
Jesse
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[-- Attachment #2: skge-toshiba.patch --]
[-- Type: text/x-diff, Size: 816 bytes --]
--- linux-2.6.14-rc4.orig/drivers/net/skge.c 2005-10-10 18:19:19.000000000 -0700
+++ linux-2.6.14-rc4/drivers/net/skge.c 2005-10-19 10:40:56.000000000 -0700
@@ -77,6 +77,7 @@
{ PCI_DEVICE(PCI_VENDOR_ID_SYSKONNECT, PCI_DEVICE_ID_SYSKONNECT_YU) },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, PCI_DEVICE_ID_DLINK_DGE510T), },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4320) },
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x4351), },
{ PCI_DEVICE(PCI_VENDOR_ID_MARVELL, 0x5005) }, /* Belkin */
{ PCI_DEVICE(PCI_VENDOR_ID_CNET, PCI_DEVICE_ID_CNET_GIGACARD) },
{ PCI_DEVICE(PCI_VENDOR_ID_LINKSYS, PCI_DEVICE_ID_LINKSYS_EG1064) },
@@ -2932,6 +2933,7 @@
case CHIP_ID_YUKON:
case CHIP_ID_YUKON_LITE:
case CHIP_ID_YUKON_LP:
+ case CHIP_ID_YUKON_FE:
if (phy_type < SK_PHY_MARV_COPPER && pmd_type != 'S')
hw->copper = 1;
^ permalink raw reply
* [PATCH] ipconfig.c: fix dhcp timeout leading to bad requested address.
From: Maxime Bizon @ 2005-10-19 19:43 UTC (permalink / raw)
To: davem; +Cc: netdev
Hello,
There is still a little bug in dhcp timeout handling.
When DHCPOFFER is received, offered and server addresses are kept. If no
ack is received, ic_myaddr is reset to INADDR_NONE, but not ic_servaddr.
The problem is that ic_dhcp_init_options() checks only ic_servaddr to
known if it has to send a DHCPOFFER or a DHCPREQUEST. So packets sent
after a timeout will be DHCPREQUEST with requested address INADDR_NONE.
If the the dhcp server does not NAK it, this request is done forever.
The following patch fixes this.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
--- linux-2.6.13.4/net/ipv4/ipconfig.c.orig 2005-10-18 18:11:54.000000000 +0200
+++ linux-2.6.13.4/net/ipv4/ipconfig.c 2005-10-19 20:44:07.000000000 +0200
@@ -1151,6 +1151,7 @@
if (!ic_got_reply) {
ic_myaddr = INADDR_NONE;
+ ic_servaddr = INADDR_NONE;
return -1;
}
--
Maxime
^ permalink raw reply
* Re: [PATCH] skge support for Marvell chips in Toshiba laptops
From: Daniel Drake @ 2005-10-19 19:43 UTC (permalink / raw)
To: Jesse Barnes; +Cc: shemminger, netdev, linux-kernel
In-Reply-To: <200510191047.53212.jbarnes@virtuousgeek.org>
Hi Jesse,
Jesse Barnes wrote:
> Here's a small patch to add the PCI ID and chip type of the chip in my
> Toshiba laptop to the skge driver. I haven't tested it much (just
> insmoded it and run ethtool against the corresponding eth1 device), but
> it doesn't crash my system, so unless this configuration has already
> been tested and is known to have problems, it might be good to add this
> patch.
>
> I'll test some more with a real network when I get home.
The device ID you added (0x4351) is already claimed by the new sky2 driver.
Unless theres a mistake in sky2's device table, your laptop contains a
Yukon-II adapter which is incompatible with the original Yukon chips (skge =
Yukon, sky2 = Yukon-II).
On the other hand, I believe Stephen could do with some extra sky2 testing :)
You can find it in the latest -mm releases.
Daniel
^ permalink raw reply
* Re: [PATCH] skge support for Marvell chips in Toshiba laptops
From: Jesse Barnes @ 2005-10-19 19:58 UTC (permalink / raw)
To: Daniel Drake; +Cc: shemminger, netdev, linux-kernel
In-Reply-To: <4356A1F5.5010200@gentoo.org>
On Wednesday, October 19, 2005 12:43 pm, Daniel Drake wrote:
> The device ID you added (0x4351) is already claimed by the new sky2
> driver.
>
> Unless theres a mistake in sky2's device table, your laptop contains a
> Yukon-II adapter which is incompatible with the original Yukon chips
> (skge = Yukon, sky2 = Yukon-II).
>
> On the other hand, I believe Stephen could do with some extra sky2
> testing :) You can find it in the latest -mm releases.
Oh cool, I'll try that driver instead. Thanks.
Jesse
^ permalink raw reply
* Re: [PATCH] X25: Add ITU-T facilites
From: Andrew Hendry @ 2005-10-20 1:10 UTC (permalink / raw)
To: linux-os (Dick Johnson)
Cc: Arnaldo Carvalho de Melo, YOSHIFUJI Hideaki / ?$B5HF#1QL@, eis,
linux-x25, linux-kernel, netdev
In-Reply-To: <Pine.LNX.4.61.0510181144320.28065@chaos.analogic.com>
On Wed, 2005-10-19 at 01:48, linux-os (Dick Johnson) wrote:
> On Tue, 18 Oct 2005, Arnaldo Carvalho de Melo wrote:
>
> > Em Tue, Oct 18, 2005 at 03:23:18PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ escreveu:
> >> In article <1129615767.3695.15.camel@localhost.localdomain> (at Tue, 18 Oct 2005 16:09:27 +1000), Andrew Hendry <ahendry@tusc.com.au> says:
> >>
> >>> +/*
> >>> +* ITU DTE facilities
> >>> +* Only the called and calling address
> >>> +* extension are currently implemented.
> >>> +* The rest are in place to avoid the struct
> >>> +* changing size if someone needs them later
> >>> ++ */
> >>> +struct x25_dte_facilities {
> >>> + unsigned int calling_len, called_len;
> >>> + char calling_ae[20];
> >>> + char called_ae[20];
> >>> + unsigned char min_throughput;
> >>> + unsigned short delay_cumul;
> >>> + unsigned short delay_target;
> >>> + unsigned short delay_max;
> >>> + unsigned char expedited;
> >>> +};
> >>
> >> Why don't you use fixed size members?
> >> And we can eliminate 8bit hole.
> >>
> >> struct x25_dte_facilities {
> >> u32 calling_len
> >> u32 called_len;
> >
> > I guess the two above can be 'u8' as they refer to calling_ae and called_ae
> > that at most will be '20'?
> >
> >> u8 calling_ae[20];
> >> u8 called_ae[20];
> >
> > - Arnaldo
>
> At the very least put the 32-bit in the beginning and 8-bit stuff at
> the end so natural alignment occurs where possible.
>
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.6.13.4 on an i686 machine (5589.46 BogoMips).
> Warning : 98.36% of all statistics are fiction.
> .
Thanks everyone for the feedback, will fix up the alignment.
A quick question on the use of u8 and u32 types in x25.h.
/usr/src/linux-2.6.13.4/include/linux/x25.h and
/usr/include/linux/x25.h
have been identical between the kernel and glibc-kernheaders type
packages, using u8 and u32 would require extra changes to the userspace
version.
__u32 or unsigned int look to be the norm for other similar headers,
whats the recommended type of types to be used?
Thanks,
Andrew.
^ permalink raw reply
* incoherent Easy deals captured. Magic specials on curing generics. mutiny
From: allan witham @ 2005-10-20 2:10 UTC (permalink / raw)
To: Deon Cubillo, owner-linux-xfs, tucker, netdev, lockmeter, murray
Better snips + more 'plus'.
Ours does ease any internal injury.
Check without much effort with our following up system.
Overdrawn? Will not to be turned out on this e-supplier.
Zilch specialist appointments, Gain gratis discussion.
Never remain pleased until I discovered this web. Jen A --DC.
http://uk.geocities.com/rxinfono1b/?ern
"No doubt," is Mr. Tulkinghorn's composed reply.
Rosa sobs out that she is very sorry to leave my Lady, and that she was
happy at Chesney Wold, and blues happy with my Lady, and that she thanks my
Lady over and over again. "Out, you silly little puss." says the ironmaster,
checking her in a low voice, though not angrily. "Have a spirit, if you're
fond of Watt." My Lady merely waves her off with indifference, saying,
"There, there, child. You are a good girl. Go away." Sir Leicester has
magnificently disengaged himself from the subject and retired into the
sanctuary of his blue coat. Mr. Tulkinghorn, an indistinct form against the
dark street now dotted with lamps, looms in my Lady's view, bigger and
blacker than before.
frel freee death-denying sz03 elkman evuestra
"I give it," was the reply. '"But it wasn't handsome in you, Mr. Bucket."
^ permalink raw reply
* [PATCH]behavior of ip6_route_input() for link local address.
From: Yan Zheng @ 2005-10-20 4:51 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Hi
I find that linux will reply echo request destined to an address which belongs to an interface other than the one from which the request received.
This behavior doesn't make sense for link local address.
Index: net/ipv6/route.c
===================================================================
--- linux-2.6.14-rc4-git6/net/ipv6/route.c 2005-10-20 12:02:49.000000000 +0800
+++ linux/net/ipv6/route.c 2005-10-20 12:21:03.000000000 +0800
@@ -483,7 +483,7 @@
goto out;
}
- rt = rt6_device_match(rt, skb->dev->ifindex, 0);
+ rt = rt6_device_match(rt, skb->dev->ifindex, strict);
BACKTRACK();
if (!rt->rt6i_nexthop && !(rt->rt6i_flags & RTF_NONEXTHOP)) {
^ permalink raw reply
* Re: [patch 2.6.14-rc4] b44: alternate allocation option for DMA descriptors
From: Benjamin Herrenschmidt @ 2005-10-20 7:17 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-kernel, netdev, jgarzik, pp
In-Reply-To: <10182005213059.12243@bilbo.tuxdriver.com>
On Tue, 2005-10-18 at 21:30 -0400, John W. Linville wrote:
> This is a (final?) hack to support the odd DMA allocation requirements
> of the b44 hardware. The b44 hardware has a 30-bit DMA mask. On x86,
> anything less than a 32-bit DMA mask forces allocations into the 16MB
> GFP_DMA range. The memory there is somewhat limited, often resulting
> in an inability to initialize the b44 driver.
>
> This hack uses streaming DMA allocation APIs in order to provide an
> alternative in case the GFP_DMA allocation fails. It is somewhat ugly,
> but not much worse than the similar existing hacks to support SKB
> allocations in the same driver. FWIW, I have received positive
> feedback on this from several Fedora users.
I'm not sure what you are trying to do here ... If pci_alloc_* failed,
you do kmalloc(...,GFP_KERNEL) which can give you memory above your DMA
mask. Then, you use dma_map_* but that won't help much more neither.
Unless you have an iommu (or swiotlb) _and_ that implements arbitrary
DMA masks support (which it typically doesn't it's often 32 bits vs. 64
bits) it won't help, you'll get into your error case.
So basically, what you are doing is: if allocation fails, you try to get
memory using GFP_KERNEL. If it happens to be in the low 2Gb of memory,
use it, if not, drop it.
Did I get that right ?
Note that the Broadcom wireless (which is currently being reverse
engineered) seem to suffer from the same stupid DMA engine...
Ben.
^ permalink raw reply
* Re: [PATCH] X25: Add ITU-T facilites
From: Bernd Jendrissek @ 2005-10-20 7:41 UTC (permalink / raw)
To: Andrew Hendry
Cc: linux-os (Dick Johnson), Arnaldo Carvalho de Melo,
YOSHIFUJI Hideaki / ?$B5HF#1QL@, eis, linux-x25, linux-kernel,
netdev
In-Reply-To: <1129770654.3574.1154.camel@localhost.localdomain>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, Oct 20, 2005 at 11:10:54AM +1000, Andrew Hendry wrote:
> __u32 or unsigned int look to be the norm for other similar headers,
> whats the recommended type of types to be used?
Dunno if this helps, but AFAIK the C language (as of 1999 or is it 2000)
blesses uint32_t and friends.
Indeed, <linux/types.h> (in the kernel source tree) defines these
*standard* sized types.
HTH
- --
A PC without Windows is like ice cream without ketchup.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Please fetch my new key 804177F8 from hkp://wwwkeys.eu.pgp.net/
iD8DBQFDV0ohwyMv24BBd/gRAnOAAKCpTJLsIIQCGW4X/KMyoIMwZ0TNewCff2vE
IO7gmOpr1zuFa515lmIPWno=
=uytG
-----END PGP SIGNATURE-----
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox