On Wed, Sep 05, 2007 at 01:00:15PM -0400, Luis R. Rodriguez wrote:
> On 9/5/07, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Wednesday 05 September 2007, Reyk Floeter wrote:
> > > I'm the author of the free hardware driver layer for wireless Atheros
> > > devices in OpenBSD, also known as "Open
Hi Dave,
Last week i sent out the rev-3 of the age patch set,
and i got no comments . So i assume the people who reviewed it earlier
are ok with it. Can you please go through it and push it upstream?
Regards,
Varun
-
To unsubscribe from this list: send the line "unsubscribe net
Hi James,
I like the idea of staying in poll longer.
My comments are similar to what Jamal and Stephen have already said.
A tunable (via sysfs) would be nice.
A timer might be preferred to jiffy polling. Jiffy polling will not increase
latency the way a timer would. However, jiffy polling will
Joseph Southwell wrote:
scenario
Machine A
eth0 is plugged into network.
192.168.1.201
eth0:1
192.168.1.2
Machine B
eth1 is plugged into network.
192.168.1.101
eth0 is not plugged into network. so I can test locally before
switching the wire.
192.168.1.201
eth0:1
192.168.1.2
arp request fo
scenario
Machine A
eth0 is plugged into network.
192.168.1.201
eth0:1
192.168.1.2
Machine B
eth1 is plugged into network.
192.168.1.101
eth0 is not plugged into network. so I can test locally before
switching the wire.
192.168.1.201
eth0:1
192.168.1.2
arp request for 192.168.1.2 is responde
> On Fri, 7 Sep 2007 01:21:41 +0200 Matteo Croce <[EMAIL PROTECTED]> wrote:
> > The patch introduces vast number of volatile structure fields. Please see
> > Documentation/volatile-considered-harmful.txt.
>
> Removing them and the kernel hangs at module load
They can't just be removed. Please s
Il Friday 07 September 2007 00:30:25 Andrew Morton ha scritto:
> > On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce <[EMAIL PROTECTED]> wrote:
> > Driver for the cpmac 100M ethernet driver.
> > It works fine disabling napi support, enabling it gives a kernel panic
> > when the first IPv6 packet has t
On Thu, 2007-06-09 at 15:16 +0100, James Chapman wrote:
> First, do we need to encourage consistency in NAPI poll drivers? A
> survey of current NAPI drivers shows different strategies being used
> in their poll(). Some such as r8169 do the napi_complete() if poll()
> does less work than their
On Thu, 6 Sep 2007 15:30:25 -0700 Andrew Morton wrote:
> > On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce <[EMAIL PROTECTED]> wrote:
> > Driver for the cpmac 100M ethernet driver.
> > It works fine disabling napi support, enabling it gives a kernel panic
> > when the first IPv6 packet has to be fo
Andrew Morton wrote:
On Thu, 06 Sep 2007 12:44:22 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 11:31:47 -0700
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
> On Thu, 06 Sep 2007 12:44:22 -0700 (PDT) David Miller <[EMAIL PROTECTED]>
> wrote:
> From: "Kok, Auke" <[EMAIL PROTECTED]>
> Date: Thu, 06 Sep 2007 11:31:47 -0700
>
> > Also available through git:// and http:// here:
> >
> >http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
> >
> On Thu, 6 Sep 2007 17:34:10 +0200 Matteo Croce <[EMAIL PROTECTED]> wrote:
> Driver for the cpmac 100M ethernet driver.
> It works fine disabling napi support, enabling it gives a kernel panic
> when the first IPv6 packet has to be forwarded.
> Other than that works fine.
>
I'm not too sure why
On Thu, Sep 06, 2007 at 03:25:55PM +0530, Satyam Sharma wrote:
> This is a GCC bug (regression, actually, as you've found out) -- no two
> ways about it. Although different from the kind Jeff mentioned couple days
> back -- that was about wising GCC up to false positives and /not/ emitting
> warn
Stephen Hemminger wrote:
On Tue, 4 Sep 2007 13:20:47 -0700 (PDT)
Rick Jones <[EMAIL PROTECTED]> wrote:
Build upon David Miller's initial patches to set the per-route rto_min
so users can specify the rto_min in the same units (milliseconds) in
which they are displayed. This is desirable becaus
On Thu, Sep 06, 2007 at 12:47:11PM +0200, Thomas Graf wrote:
> * Milan Kocian <[EMAIL PROTECTED]> 2007-08-29 23:51
> > Because RTM_NEWLINK is used to notify about device status change
> > (as I see in net/core/rtnetlink.c) and RTM_DELLINK to inform about
> > NETDEV_UNREGISTER. Why should it be else
From: Bernhard Walle <[EMAIL PROTECTED]>
Date: Thu, 6 Sep 2007 22:01:52 +0200
> [PATCH] Fix config requirements of IPv6
>
> net/ipv6/inet6_connection_sock.c in function __inet6_csk_dst_store() requires
> flow_cache_genid which is defined in net/core/flow.c which is compiled when
> CONFIG_XFRM is
[PATCH] Fix config requirements of IPv6
net/ipv6/inet6_connection_sock.c in function __inet6_csk_dst_store() requires
flow_cache_genid which is defined in net/core/flow.c which is compiled when
CONFIG_XFRM is set.
This patch expresses that dependency.
Signed-off-by: Bernhard Walle <[EMAIL PROTE
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Wed, 5 Sep 2007 22:04:11 +0300 (EEST)
> Main obstacle to FRTO use is its deployment as it has to be on the
> sender side where as wireless link is often the receiver's access
> link but if one can tune tcp_min_rto (or equal) on the sender side,
> one
On Thu, Sep 06, 2007 at 12:50:19PM -0700, David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Thu, 06 Sep 2007 12:05:30 -0700
>
> > The HT1000 bridge may very well have an MSI issue. I'm checking with
> > ServerWorks and I will do some testing to confirm. If confirmed, we can
From: [EMAIL PROTECTED]
Date: Wed, 05 Sep 2007 19:07:29 +0200
> Fixes for 3 typos in Kconfig files
While these fixes are appreciated, I do not think they fall
under the networking umbrella.
Please resubmit them to linux-kernel or similar.
Thanks.
-
To unsubscribe from this list: send the line "
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 12:05:30 -0700
> The HT1000 bridge may very well have an MSI issue. I'm checking with
> ServerWorks and I will do some testing to confirm. If confirmed, we can
> disable MSI behind the HT1000 bridge instead of globally. The 5714
>
From: "Kok, Auke" <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 11:31:47 -0700
> Also available through git:// and http:// here:
>
>http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
>http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch.bz2
>(git-am formatted!)
>
>
From: Andy Gospodarek <[EMAIL PROTECTED]>
Date: Thu, 6 Sep 2007 15:07:40 -0400
>
> Removed sparse warnings from tg3 driver. The new logic seems fine (I
> don't immediately see where we are running over values for any of the
> variables that need to be saved).
>
> This patch compiles fine and I'
Already reported in an answer to the 2.6.23-rc4-mm1 announcement on
linux-kernel [1].
cu
Adrian
[1] http://lkml.org/lkml/2007/9/1/18
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise
Removed sparse warnings from tg3 driver. The new logic seems fine (I
don't immediately see where we are running over values for any of the
variables that need to be saved).
This patch compiles fine and I'm currently using a tg3 with the patched
driver to post this patch as a basic proof of conce
From: Stephen Hemminger <[EMAIL PROTECTED]>
Since E100 timer is 2HZ, use rounding to make timer occur on the
correct boundary.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
drivers/net/e100.c |3 ++-
1 files changed, 2 insertions(+), 1
Auke Kok wrote:
This patch adds support for the Intel 82598 PCI-Express 10GbE
chipset. Devices will be available on the market soon.
Also available through git:// and http:// here:
http://foo-projects.org/~sofar/ixgbe-20070905-submission.patch
http://foo-projects.org/~sofar/ixgbe-20070905-
On Thu, Sep 06, 2007 at 12:05:30PM -0700, Michael Chan wrote:
> On Thu, 2007-09-06 at 11:41 -0400, Andy Gospodarek wrote:
> > On Thu, Sep 06, 2007 at 07:34:23AM -0700, David Miller wrote:
> > > From: Andy Gospodarek <[EMAIL PROTECTED]>
> > > Date: Thu, 6 Sep 2007 09:45:16 -0400
> > >
> > > > Is is
Stephen Hemminger wrote:
Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
Not all ips are shown by "ip addr show" command when IPs number assigned to an
interface is more than 60-80 (in fact it depends on broadcast/label etc
presence on each address).
Steps to reproduce:
It's terribly simpl
On Thu, 2007-09-06 at 11:41 -0400, Andy Gospodarek wrote:
> On Thu, Sep 06, 2007 at 07:34:23AM -0700, David Miller wrote:
> > From: Andy Gospodarek <[EMAIL PROTECTED]>
> > Date: Thu, 6 Sep 2007 09:45:16 -0400
> >
> > > Is is really necessary to get rid of the HT1000 patch?
> >
> > Yes, absolutely
Hi Aurelien,
More comments.
Aurélien Charbon wrote:
This is a small part of missing pieces of IPv6 support for the server.
It deals with the ip_map caching code part.
/* Insert client into hashtable. */
- for (i = 0; i < ncp->cl_naddr; i++)
- auth_unix_add_addr(nc
* Stephen Hemminger <[EMAIL PROTECTED]> 2007-09-06 16:10
> Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
>
> Not all ips are shown by "ip addr show" command when IPs number assigned to an
> interface is more than 60-80 (in fact it depends on broadcast/label etc
> presence on each address).
Hi,
This patch addresses a couple of issues related to interfamily ipsec
modes. The problem is that the structure of the routing info changes
with the family during the __xfrmX_bundle_create, which hasn't been
taken properly into account. Seems that by coincidence it hasn't
caused problems on 32bi
Stephen Hemminger wrote:
On Thu, 06 Sep 2007 16:30:30 +0100
James Chapman <[EMAIL PROTECTED]> wrote:
Stephen Hemminger wrote:
What about the latency that NAPI imposes? Right now there are certain
applications that
don't like NAPI because it add several more microseconds, and this may make it
On Thu, Sep 06, 2007 at 03:36:55PM +0200, Johannes Berg wrote:
> On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
>
> > Yeah I think they're all under RTNL too. So you don't need to
> > take the lock here at all since you should already have the RTNL.
>
> Ok, this patch gets rid of the lock.
On Thu, Sep 06, 2007 at 07:34:23AM -0700, David Miller wrote:
> From: Andy Gospodarek <[EMAIL PROTECTED]>
> Date: Thu, 6 Sep 2007 09:45:16 -0400
>
> > Is is really necessary to get rid of the HT1000 patch?
>
> Yes, absolutely and without a single doubt.
>
> > commit e3008dedff4bdc96a5f67224cd3d8
On Thu, 06 Sep 2007 16:30:30 +0100
James Chapman <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger wrote:
>
> > What about the latency that NAPI imposes? Right now there are certain
> > applications that
> > don't like NAPI because it add several more microseconds, and this may make
> > it worse.
Stephen Hemminger wrote:
What about the latency that NAPI imposes? Right now there are certain
applications that
don't like NAPI because it add several more microseconds, and this may make it
worse.
Latency is something that I think this approach will actually improve,
at the expense of add
On Thursday, September 6 2007 9:04:01 am Tetsuo Handa wrote:
> (1) It uses userspace intervention to allow/reject
> connections and/or packets based on the application's domain.
> Since existent hooks can't be used for this purpose,
> I inserted a new hook post_recv_datagram() at skb_re
On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug is. You cannot call dev_close f
Andy Gospodarek wrote:
> This patch was designed to address tg3 and bnx2 messages printed on
> systems with HT1000 chips IIRC. Are we going back to those
> messages on
> bnx2 or is there a workaround in that driver needed too?
>
Andy, I've checked all the Broadcom chips including bnx2 chips, o
Bug: http://bugzilla.kernel.org/show_bug.cgi?id=8876
Not all ips are shown by "ip addr show" command when IPs number assigned to an
interface is more than 60-80 (in fact it depends on broadcast/label etc
presence on each address).
Steps to reproduce:
It's terribly simple to reproduce:
# for i in
On 9/6/07, David Miller <[EMAIL PROTECTED]> wrote:
> From: Andy Gospodarek <[EMAIL PROTECTED]>
> Date: Thu, 6 Sep 2007 09:45:16 -0400
>
> > Is is really necessary to get rid of the HT1000 patch?
>
> Yes, absolutely and without a single doubt.
>
> > commit e3008dedff4bdc96a5f67224cd3d8d12237082a0
>
On Thu, 6 Sep 2007 15:16:00 +0100
James Chapman <[EMAIL PROTECTED]> wrote:
> This RFC suggests some possible improvements to NAPI in the area of
> minimizing interrupt rates. A possible scheme to reduce interrupt rate for
> the low packet rate / fast CPU case is described.
>
> First, do we nee
From: Andy Gospodarek <[EMAIL PROTECTED]>
Date: Thu, 6 Sep 2007 09:45:16 -0400
> Is is really necessary to get rid of the HT1000 patch?
Yes, absolutely and without a single doubt.
> commit e3008dedff4bdc96a5f67224cd3d8d12237082a0
> Author: Andy Gospodarek <[EMAIL PROTECTED]>
> Date: Thu May 10
On Thu, Sep 06, 2007 at 03:50:23PM +0200, maximilian attems wrote:
> b/drivers/net/wireless/rtl8187_dev.c |1
> 15 files changed, 1 insertion(+), 12846 deletions(-)
urrgs that was not meant to be there,
resending..
--
maks
-
To unsubscribe from this list: send the line "unsubscribe netdev"
On Thu, Sep 06, 2007 at 04:02:35AM -0700, David Miller wrote:
> From: "Michael Chan" <[EMAIL PROTECTED]>
> Date: Wed, 05 Sep 2007 13:07:08 -0700
>
> > [TG3]: Workaround MSI bug on 5714/5780.
> >
> > A hardware bug was revealed after a recent PCI MSI patch was made to
> > always disable legacy INT
Hello.
Thank you very much for your time, Paul.
Yes, you understood what I wanted to do.
TOMOYO Linux's approach:
(1) It uses userspace intervention to allow/reject
connections and/or packets based on the application's domain.
Since existent hooks can't be used for this purpose,
I in
On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
> Yeah I think they're all under RTNL too. So you don't need to
> take the lock here at all since you should already have the RTNL.
Ok, this patch gets rid of the lock. I'd appreciate if you could give it
a quick look for obvious RCU abuse as
On Thu, Sep 06, 2007 at 01:55:47PM +0100, Stephen Hemminger wrote:
> The dgrs driver is crap and assumes direct access to PCI iomem.
>
dgrs wants to be removed, it has no users.
(no bug report in bugzilla nor in debian nor in google)
the firmware is not distrutable.
i'll resend my removal patch
On Wed, 2007-05-09 at 22:06 -0700, Mandeep Singh Baines wrote:
> jamal ([EMAIL PROTECTED]) wrote:
> > If you read the paper: There are no issues with high throughput - NAPI
> > kicks in.
> > The challenge to be overcome is at low traffic, if you have a real fast
> > processor your cpu-cycles-used/
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Tue, 4 Sep 2007 09:59:58 +0200
> This patch seems the correct fix for this longstanding problem.
>
> Please note that if wireshark/tcpdump processes really want precise
> timestamps,
> they still can ask this by using setsockopt(SO_TIMESTAMP or SO_TI
The dgrs driver is crap and assumes direct access to PCI iomem.
CHECK drivers/net/dgrs.c
drivers/net/dgrs.c:314:20: warning: cast removes address space of expression
drivers/net/dgrs.c:330:12: warning: incorrect type in argument 1 (different
address spaces)
drivers/net/dgrs.c:330:12:expec
On Thu, 2007-09-06 at 18:22 +0530, Satyam Sharma wrote:
> Unless I missed something obvious (let me know if that's the case! :-)
> an RCU-protected list would suffer the same fate. list_for_each_xxx_rcu()
> must be under rcu_read_lock() which == preempt_disable() ...
Right. But I'm thinking that
On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
> Johannes Berg <[EMAIL PROTECTED]> wrote:
> >
> > Hah, I suspected as much but didn't have a chance to look yet. I had
> > plans to replace that sub_if_list with an RCU list and not require the
> > lock there, but that's far off. Any ideas how t
On Thu, 6 Sep 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> > On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> > >
> > > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d
> > > > > [mac8
Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> Hah, I suspected as much but didn't have a chance to look yet. I had
> plans to replace that sub_if_list with an RCU list and not require the
> lock there, but that's far off. Any ideas how to fix this? We can't
> reject the master stop so we have to wal
On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug is. You cannot call dev_close f
Thanks Chuck and Brian for your comments.
Here is some correction for the ip_map caching code part.
I have updated the code to use Brian's ipv6_addr_v4mapped function, and
corrected some mistake you pointed out.
I have checked this patch with the checkpatch.pl script and i do not understand
wh
From: "Michael Chan" <[EMAIL PROTECTED]>
Date: Wed, 05 Sep 2007 13:07:08 -0700
> [TG3]: Workaround MSI bug on 5714/5780.
>
> A hardware bug was revealed after a recent PCI MSI patch was made to
> always disable legacy INTX when enabling MSI. The 5714/5780 chips
> will not generate MSI when INTX
Upstream got a backport of my netdev->priv fixes for the
cxgb3 driver, creating a bunch of conflicts with the napi_struct
changes, so I took the opportunity to refresh the tree and
combine some bug fixes into the changes that introduced those
bugs :-) (bug fix attributions were added to the change
- Code Optimization of s2io_isr function.
- Isr check using per device napi variable instead of driver global.
- Reduced from 3 to 1 if condition before check for processing packet receive
packets.
- Implemented Jeff's comment to use synchronize_irq. Removed the isr_cnt
variable as it became re
- Added check to return from the traffic handling function, if the card status
is DOWN.
- Implemented Jeff's comments on incorrect return value in s2io_poll function.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ramkris
* Milan Kocian <[EMAIL PROTECTED]> 2007-08-29 23:51
> Because RTM_NEWLINK is used to notify about device status change
> (as I see in net/core/rtnetlink.c) and RTM_DELLINK to inform about
> NETDEV_UNREGISTER. Why should it be else in ipv6 subsystem ? And
> userspace programs (quagga) suppose it. No
- Removed the unused variable, intr_type, in device private structure.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -urpN patch_2/drivers/net/s2io.c patch_3/drivers/net/s2io.c
- Added support to poll entire set of device errors and alarams.
- A note on how device errors and alarms are handled:
- The adapter will automatically recover from uncorrectable ECC errors.
Packets containing corrupted data will be dropped (not transmitted) or tagged
as invalid before being pa
Hi,
>> Thu, 6 Sep 2007 10:13:26 +0200
>> [Subject: Re: net-26.24 broken with XFRM off]
>> Eric Dumazet <[EMAIL PROTECTED]> wrote...
> Hi Divy
>
> I believe this problem is known.
>
> Please check http://marc.info/?l=linux-netdev&m=118881627028135&w=2
I'm sorry not to check more precisely.
- Added support to unmask entire set of device errors and alarams.
Alarm interrupts are generated for a myriad of purposes, ranging from
illegal operations or requests to internal state machine errors and
uncorrectable data corruption errors. In several cases the adapter can
recover g
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Thu, 6 Sep 2007 10:13:26 +0200
> I believe this problem is known.
>
> Please check http://marc.info/?l=linux-netdev&m=118881627028135&w=2
I'll toss that fix into the tree, thanks.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
On Tue, 4 Sep 2007, Mark Hindley wrote:
> On Tue, Sep 04, 2007 at 02:09:47PM +0530, Satyam Sharma wrote:
> > Hi Steffen,
> >
> >
> > On Tue, 4 Sep 2007, Steffen Klassert wrote:
> >
> > > On Tue, Sep 04, 2007 at 03:45:55AM +0530, Satyam Sharma wrote:
> > > >
> > > > drivers/net/3c59x.c: In fu
On Thu, Sep 06, 2007 at 02:11:46PM +0530, Satyam Sharma wrote:
> On Thu, 6 Sep 2007, Herbert Xu wrote:
>
> > On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> > >
> > > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d
> > > >
On Thu, 6 Sep 2007, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug is. You cannot call dev_close from an
> ato
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
>
> > > [ 382.529041] [] dev_close+0x24/0x67
> > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
This is where the bug is. You cannot call dev_close from an
atomic context as i33380211_master_stop does it within spi
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
>
> Probably tangential, but Herbert, is the call to synchronize_rcu() in
> dev_deactivate() really correct?
Yes it's still correct as of today's tree. Of course patches
such as preemptible RCU may change things but they'll need to
a
On Thu, 06 Sep 2007 00:25:51 -0700
Divy Le Ray <[EMAIL PROTECTED]> wrote:
> Hi Dave,
>
> I get this error compiling net-2.6.24 with XFRM off:
>
> [EMAIL PROTECTED] net-2.6.24]# make O=/opt/build/net-2.6.24
> fatal: corrupted pack file
> .git/objects/pack/pack-39c494e9d4c6488e5911ee5c06926450679
Hi Dave,
I get this error compiling net-2.6.24 with XFRM off:
[EMAIL PROTECTED] net-2.6.24]# make O=/opt/build/net-2.6.24
fatal: corrupted pack file
.git/objects/pack/pack-39c494e9d4c6488e5911ee5c06926450679e6b78.pack
fatal: corrupted pack file
.git/objects/pack/pack-39c494e9d4c6488e5911ee5c06
76 matches
Mail list logo