Carl-Daniel Hailfinger wrote:
Could you all please test the attached patch against 2.6.16-rc4?
It is a straight forward-port of my sky2 version that worked for you.
Regards,
Carl-Daniel
diff -urN linux-2.6.16-rc4/dri
On Sat, Feb 25, 2006 at 07:51:06PM +0100, Patrick McHardy wrote:
>
> > I suppose you should treat CHECKSUM_UNNECESSARY as an indication that
> > you need to recompute the checksum from scratch instead of adjusting
> > it. So start by getting skb_checksum_help to only zap CHECKSUM_HW,
> > and then
On Sat, 2006-02-25 at 18:03 -0800, Stephen Hemminger wrote:
> Instead of whining, try this.
Applied and compiled, rebooting in a bit =)
--
Ian Kumlien -- http://pomac.netswarm.net
signature.asc
Description: This is a digitally signed message part
On Sun, 2006-02-26 at 01:54 +0100, Carl-Daniel Hailfinger wrote:
> Hi Jeff,
>
> you may want to push this patch into 2.6.16. The version it reverts to
> has been running stable for over four weeks for various folks (CC'ed)
> and we have had no success communicating with the maintainer.
I don't th
Instead of whining, try this.
--- drivers/net/sky2.c.orig 2006-02-25 18:02:10.0 -0800
+++ drivers/net/sky2.c 2006-02-25 18:03:13.0 -0800
@@ -1895,19 +1895,6 @@
u16 hwidx;
u16 tx_done[2] = { TX_NO_STATUS, TX_NO_STATUS };
- sky2_write32(hw, STAT_CTRL, SC
On Sat, 25 Feb 2006 23:40:19 +0100
Ian Kumlien <[EMAIL PROTECTED]> wrote:
> Hi, I'm sorry to say that sky2 still breaks for me...
>
> NETDEV WATCHDOG: eth0: transmit timed out
> sky2 transmit interrupt missed? recovered
> NETDEV WATCHDOG: eth0: transmit timed out
> sky2 eth0: tx timeout
> NETDEV
On 2/25/06, Gene Heskett <[EMAIL PROTECTED]> wrote:
> that apply to all". These rules go back to about the time of when they
> outlawed any transmit tunability in CB radios in the later 70's, so its
> not a new item by any means as its just an extension of that edict to
> cover this newer technolo
From: "Arnaldo Carvalho de Melo" <[EMAIL PROTECTED]>
Date: Sat, 25 Feb 2006 19:32:47 -0300
>Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.17.git
>
> I should have used git-send-email --compose even with just one cset, ah
> and include netdev too
Hi Jeff,
you may want to push this patch into 2.6.16. The version it reverts to
has been running stable for over four weeks for various folks (CC'ed)
and we have had no success communicating with the maintainer.
Regards,
Carl-Daniel
Revert sky2 to 0.13 with a four-line fix on top of it.
Later v
On Sad, 2006-02-25 at 08:41 +, Christoph Hellwig wrote:
> the regualatory problems are not true.
They are although the binary interpretation isn't AFAIK from law but
from lawyers. The same is actually true in much of the EU. The actual
requirement is that the transmitting device must be reas
On Sat, 2006-02-25 at 17:09 -0500, Jeff Garzik wrote:
> I strongly ACK the use of rtnetlink, but I leave it to John Linville
> (wireless maintainer) to do a full review, and merge...
The question is just -- do we really want another interface that is
going to be deprecated in the long run?
Sinc
matthieu castet wrote:
And what happen with the userspace binary blob ?
How it will know in which country you are ?
Does it access to a secret GPS on your computer ?
So there are 2 solutions :
- make the card work only for a country with a flag in a RO eeprom or in
another place in the hardwar
On Sat, Feb 25, Adrian Bunk wrote:
> CONFIG_UNIX=m doesn't make much sense.
There is likely more code to support a modular unix.ko, this has to go
as well.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
Hi, I'm sorry to say that sky2 still breaks for me...
NETDEV WATCHDOG: eth0: transmit timed out
sky2 transmit interrupt missed? recovered
NETDEV WATCHDOG: eth0: transmit timed out
sky2 eth0: tx timeout
NETDEV WATCHDOG: eth0: transmit timed out
sky2 transmit interrupt missed? recovered
NETDEV WATCH
Hi David,
Please consider pulling from:
master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.17.git
I should have used git-send-email --compose even with just one cset, ah
and include netdev too, sorry.
Now there are 4 outstanding changesets in this tree.
Regards,
- Arnaldo
On 2
Hi,
John Stoffel wrote:
"Matthieu" == Matthieu CASTET <[EMAIL PROTECTED]> writes:
Matthieu> I will say, why not put the restriction of the firmware
Matthieu> binary blob ? It run on the device so it will be difficult
Matthieu> for people to analyse it.
So what do I do when I take my US lapt
> "Matthieu" == Matthieu CASTET <[EMAIL PROTECTED]> writes:
Matthieu> I will say, why not put the restriction of the firmware
Matthieu> binary blob ? It run on the device so it will be difficult
Matthieu> for people to analyse it.
So what do I do when I take my US laptop and fly to country X
Hi everybody,
Le Sat, 25 Feb 2006 15:19:40 +0100, Jan Engelhardt a écrit :
>>If the modules crc changes,
>>it must do an instant disable of the transmitter functions and exit or
>>crash, thereby precluding any 'hot rodding' of the chipset.
>>
> Would not it be easiest to have the chipset enforc
Jean Tourrilhes wrote:
Hi Jeff,
This is version 20 of the Wireless Extensions. This is the
completion of the RtNetlink work I started early 2004, it enables the
full Wireless Extension API over RtNetlink.
The patch has been fully tested with 2.6.16-rc2 and 2.6.16-rc3
and
Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
to receive the following updates:
drivers/net/sis900.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
Daniele Venzano:
Fix Wake on LAN support in sis900
diff --g
Maxime Bizon wrote:
On Sat, 2006-02-25 at 16:14 +0100, Jean-Baptiste Note wrote:
Hi,
Obviously Intel doesn't want to manufacture one chipset for each subtle
difference in legislation in each and every country it sells its chips
in : Intel wants flexibility.
As pointed out by Jan, the
This patch ports the per-thread interface list list to the in-kernel linked
list implementation. In the general, the resulting code is a bit simpler.
Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
---
net/core/pktgen.c | 92 +
1 files
With all the previous changes, we're at a new version now.
Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
---
net/core/pktgen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
32d9b9951586e505b4b8bc587f9e170612a48a4d
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index 5d
Even if pktgen's thread initialization fails for all CPUs, the module
will be successfully loaded.
This patch changes that behaivor, by returning an error on module load time,
and also freeing all the resources allocated. It also prints a warning if a
thread initialization has failed.
Signed-o
Free all the alocated resources if kernel_thread() call fails.
Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
---
net/core/pktgen.c | 11 +--
1 files changed, 9 insertions(+), 2 deletions(-)
c3fd9c4bbddab18349563c0c5d90c4bf0002de99
diff --git a/net/core/pktgen.c b/net/core/pktg
The final result is a simpler and smaller code.
Note that I'm adding a new member in the struct pktgen_thread called
'removed'. The reason is that I didn't find a better wait condition to be
used in the place of the replaced one.
Signed-off-by: Luiz Capitulino <[EMAIL PROTECTED]>
---
net/co
This patch is not in-lined because it's 124K bytes long, you can get it at:
http://www.cpu.eti.br/patches/0001-pktgen-Lindent-run.patch
--
Luiz Fernando N. Capitulino
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordom
Hi David,
As you've asked, I'm sending again my patches for pktgen:
[PATCH 1/6] pktgen: Lindent run.
[PATCH 2/6] pktgen: Ports thread list to Kernel list implementation.
[PATCH 3/6] pktgen: Fix kernel_thread() fail leak.
[PATCH 4/6] pktgen: Fix Initialization fail leak.
[PATCH 5/6] pktgen: Por
Herbert Xu wrote:
> On Fri, Feb 24, 2006 at 04:57:33AM +, Patrick McHardy wrote:
>
>>So we could move checksum validation behind xfrm4_policy_check or
>>already set ip_summed to CHECKSUM_UNNECESSARY in esp_input. Already
>>setting ip_summed in esp4_input looks easier. But this still leaves
>
On Sat, 2006-02-25 at 09:13 -0800, Stephen Hemminger wrote:
> Adrian Bunk wrote:
> > CONFIG_UNIX=m doesn't make much sense.
> >
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> >
> >
> Why? You can build unix domain sockets as a loadable module and
> it runs fine (or it did last I tr
Adrian Bunk wrote:
CONFIG_UNIX=m doesn't make much sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Why? You can build unix domain sockets as a loadable module and
it runs fine (or it did last I tried). Whether that makes sense from a
distribution point of
view, because everybody w
On Sat, 2006-02-25 at 16:14 +0100, Jean-Baptiste Note wrote:
Hi,
> Obviously Intel doesn't want to manufacture one chipset for each subtle
> difference in legislation in each and every country it sells its chips
> in : Intel wants flexibility.
As pointed out by Jan, the binary approach does not
CONFIG_UNIX=m doesn't make much sense.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 20 Feb 2006
--- linux-2.6.16-rc4-mm1-full/net/unix/Kconfig.old 2006-02-20
14:40:19.0 +0100
+++ linux-2.6.16-rc4-mm1-full/net/unix/Kconfig 2006-02-20 14:40:
>
>This is, not even speaking about roaming your device from one country to
>another. End-users want flexibility too...
>
The end user... Even with the closed-source approach I could run on a
frequency that is legal in XYZ but is not in ABC. (Unless all 13 channels
are the same _all_ over the wo
Hi,
> Would not it be easiest to have the chipset enforce the acceptable bands?
> So that software can't switch the chipset to 1337 GHz no matter how hard
> you forward/reverse-engineer it.
Obviously Intel doesn't want to manufacture one chipset for each subtle
difference in legislation in each
On 2/25/06, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 24, 2006 at 03:10:02AM -0800, Andrew Morton wrote:
> >...
> > Changes since 2.6.16-rc4-mm1:
> >...
> > git-net.patch
> >...
> > git trees.
> >...
>
>
> There's no reason for struct dccp_v4_prot being global.
>
>
> Signed-off-by: Adr
>If the modules crc changes,
>it must do an instant disable of the transmitter functions and exit or
>crash, thereby precluding any 'hot rodding' of the chipset.
>
Would not it be easiest to have the chipset enforce the acceptable bands?
So that software can't switch the chipset to 1337 GHz no m
On Saturday 25 February 2006 00:48, you wrote:
>
> Awesome. Now all we need is someone to write the bcm series for wireless
> and ndiswrapper
> can go away.
What, eh? We have a bcm43xx driver. Or what do you mean?
--
Greetings Michael.
pgpg8UBeK0L6n.pgp
Description: PGP signature
On Fri, Feb 24, 2006 at 03:10:02AM -0800, Andrew Morton wrote:
>...
> Changes since 2.6.16-rc4-mm1:
>...
> git-net.patch
>...
> git trees.
>...
There's no reason for struct dccp_v4_prot being global.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.16-rc4-mm2-full/net/dccp/ipv4.c
On Saturday 25 February 2006 12:19, Gene Heskett wrote:
> On Saturday 25 February 2006 05:53, Christoph Hellwig wrote:
> >On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote:
> >> As someone (a broadcast engineer with 40+ years of carrying what
> >> used to be a 1st phone) obviously more f
Am Samstag 25 Februar 2006 11:53 schrieb Christoph Hellwig:
>From a short glance over the driver code, the protocol between the _open
source_ driver and the binary user space daemon seems to be quite defined and
unobfuscated. Obviously, someone owning the device has to verify that the
daemon do
On Saturday 25 February 2006 05:53, Christoph Hellwig wrote:
>On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote:
>> As someone (a broadcast engineer with 40+ years of carrying what
>> used to be a 1st phone) obviously more familiar with the FCC R&R
>> than you apparently are, Christoph,
On Sat, Feb 25, 2006 at 05:49:47AM -0500, Gene Heskett wrote:
> As someone (a broadcast engineer with 40+ years of carrying what used to
> be a 1st phone) obviously more familiar with the FCC R&R than you
> apparently are, Christoph, I'll have to argue that point.
Please stop spreading the bulls
On Saturday 25 February 2006 03:41, Christoph Hellwig wrote:
>On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos wrote:
>> As a result of this change, some of the capabilities currently
>> required to be provided on the host include enforcement of
>> regulatory limits for the radio transmitte
Hello,
This patch is based on Linux 2.4.32, and I've verified the same problem
exists on 2.6.15.4.
Working on a machine with a 2.4.32 kernel, I was surprised to see the driver
complaining when setting the speed to 100FD using mii-tool, but accepting
the setting with ethtool.
Digging into the code,
Hello James,
> The daemon utilizes a sysfs interface exposed by
> the driver in order to communicate with the hardware and configure the
> required regulatory parameters.
This seems to be the same kind of architecture as the one for the N770
(maemo.org). How do you expect to hide anything with th
On Fri, Feb 24, 2006 at 04:29:58PM -0600, James Ketrenos wrote:
> As a result of this change, some of the capabilities currently required
> to be provided on the host include enforcement of regulatory limits for
> the radio transmitter (radio calibration, transmit power, valid
> channels, 802.11h,
47 matches
Mail list logo
