* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Alejandro Bonilla @ 2006-02-26 20:20 UTC (permalink / raw)
To: John Stoffel; +Cc: Matthieu CASTET, linux-kernel, netdev
In-Reply-To: <17408.55266.948833.168988@smtp.charter.net>
On Sat, 2006-02-25 at 17:19 -0500, John Stoffel wrote:
> >>>>> "Matthieu" == Matthieu CASTET <castet.matthieu@free.fr> 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, which
> has comletely different rules for these radios? Do I have to re-flash
> my firmware to make it work properly?
Intel has got the obligation to make sure they are not letting you use
not allowed channels. If you as a manufacturer allow with a certain
change to let people use the channels they want, you are actually
encouraging people to use those channels. Letting the option available
makes Intel liable to get sued. If you buy an US PC, you stick to the US
channels. If you are a world traveler, buy the PC in japan or in Europe.
Then, you will be able to use the US and ROW(Rest of World) channels.
This is just the way it works, else you are liable. Believe me, and not
only me. Intel does not do things to give you a hard time, it is because
of a reason and they have the best lawyers at it.
It is just the Law and the FCC's.
.Alejandro
>
> The big problem is the lack of global unity, but that will slowly get
> fixes as more countries realize it's a problem. The big issue will be
> military/govt radio spectrum users, they won't want to move if they
> can help it.
>
> John
^ permalink raw reply
* Re: [2.6 patch] make UNIX a bool
From: Diego Calleja @ 2006-02-26 18:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bunk, akpm, netdev, linux-kernel
In-Reply-To: <44009024.5050105@osdl.org>
El Sat, 25 Feb 2006 09:13:08 -0800,
Stephen Hemminger <shemminger@osdl.org> escribió:
> 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
I've been running with CONFIG_UNIX=m since the dawn of time and everything
seems to work - not that I care if it's disabled, I just wanted to
confirm that it works.
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Wolfgang Hoffmann @ 2006-02-26 18:13 UTC (permalink / raw)
To: pomac
Cc: Stephen Hemminger, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <1140966011.22812.2.camel@localhost>
On Sunday 26 February 2006 16:00, Ian Kumlien wrote:
> On Sun, 2006-02-26 at 09:57 +0100, Wolfgang Hoffmann wrote:
> > Stephen, if you want me (as suggested off-list) to bisect the individual
> > patches leading from 0.13a to current head, please give me a series of
> > patches to incrementally apply, eighter via mail/ftp/git, and I'll test.
> > I don't want to hack the patches together myself, because results would
> > be worthless if I screw up, and given that I have no networking
> > background chances are high ...
>
> There is a git bisect for that, and a link for it somewhere =)
Ok, I did some reading and just started a git bisect. I didn't find hints on
how to bisect if I'm only interested in changes to sky2.[ch], so I'm taking
the full kernel tree and skip testing those bisect steps that didn't change
sky2.[ch].
Looking at Carl-Danies 0.13a and Stephens patch against 0.15 in this thread,
I'll patch each bisect step such that sky2_poll() has
sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
}
after exit_loop. Is that ok?
I'll report as soon as I have results.
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Pavel Machek @ 2006-02-26 17:54 UTC (permalink / raw)
To: James Ketrenos; +Cc: NetDev, linux-kernel
In-Reply-To: <43FF88E6.6020603@linux.intel.com>
> 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, etc.) In order to meet the requirements of all
> geographies into which our adapters ship (over 100 countries) we have
> placed the regulatory enforcement logic into a user space daemon that
> we provide as a binary under the same license agreement as the
> microcode. We provide that binary pre-compiled as both a 32-bit and
> 64-bit application. The daemon utilizes a sysfs interface exposed by
> the driver in order to communicate with the hardware and configure the
> required regulatory parameters.
Well, that means no luck to sparc users.... And I hope kernel<->user
interface is nice, clean and documented.
--
Thanks, Sharp!
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-26 16:13 UTC (permalink / raw)
To: Arjan van de Ven
Cc: woho, Stephen Hemminger, Carl-Daniel Hailfinger, Jeff Garzik,
netdev, Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <1140968831.2934.32.camel@laptopd505.fenrus.org>
[-- Attachment #1: Type: text/plain, Size: 683 bytes --]
On Sun, 2006-02-26 at 16:47 +0100, Arjan van de Ven wrote:
> On Sun, 2006-02-26 at 16:00 +0100, Ian Kumlien wrote:
> > On Sun, 2006-02-26 at 09:57 +0100, Wolfgang Hoffmann wrote:
> > > On Sunday 26 February 2006 03:03, Stephen Hemminger wrote:
> > > > Instead of whining, try this.
> > >
> > > I tried and still see the hang.
> >
> > I'm at a record 12 hours with that patch.
>
> shhh don't jinx it ;)
Well it died 33 mins later... =)
I also saw some oddities... portage stopped working, i dunno if this can
be MSI related or so, else something is trashing memory in a very
special way =P
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Arjan van de Ven @ 2006-02-26 15:47 UTC (permalink / raw)
To: pomac
Cc: woho, Stephen Hemminger, Carl-Daniel Hailfinger, Jeff Garzik,
netdev, Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <1140966011.22812.2.camel@localhost>
On Sun, 2006-02-26 at 16:00 +0100, Ian Kumlien wrote:
> On Sun, 2006-02-26 at 09:57 +0100, Wolfgang Hoffmann wrote:
> > On Sunday 26 February 2006 03:03, Stephen Hemminger wrote:
> > > Instead of whining, try this.
> >
> > I tried and still see the hang.
>
> I'm at a record 12 hours with that patch.
shhh don't jinx it ;)
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-26 15:28 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Carl-Daniel Hailfinger, Jeff Garzik, netdev, Wolfgang Hoffmann,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <20060225180353.5908c955@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
On Sat, 2006-02-25 at 18:03 -0800, Stephen Hemminger wrote:
> Instead of whining, try this.
I'm sorry to say that this failed after 12h 33m =P
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Paul Rolland @ 2006-02-26 15:12 UTC (permalink / raw)
To: 'Jesper Juhl'
Cc: linux-kernel, netdev, linux.nics, cramerj, john.ronciak,
Ganesh.Venkatesan
In-Reply-To: <9a8748490602260700s2e82a623mcf2d778aa109bb00@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Hello,
> Ok, great, I was just wondering since I would have made one if you had
> no plans to do so.
Well, I was just waiting to make sure it was interesting for someone ;)
Here is it, verified with tab and not spaces... but attached as my mailer
is likely to cripple anything I try to inline...
Signed-off-by: Paul Rolland <rol@as2917.net>
Cheers,
Paul
[-- Attachment #2: e1000.patch-2.6.15.4 --]
[-- Type: application/octet-stream, Size: 1507 bytes --]
diff -urN linux-2.6.15.4.orig/drivers/net/e1000/e1000_main.c linux-2.6.15.4/drivers/net/e1000/e1000_main.c
--- linux-2.6.15.4.orig/drivers/net/e1000/e1000_main.c Fri Feb 10 07:22:48 2006
+++ linux-2.6.15.4/drivers/net/e1000/e1000_main.c Sun Feb 26 15:04:40 2006
@@ -4153,29 +4153,29 @@
/* Fiber NICs only allow 1000 gbps Full duplex */
if((adapter->hw.media_type == e1000_media_type_fiber) &&
- spddplx != (SPEED_1000 + DUPLEX_FULL)) {
+ spddplx != (SPEED_1000 + FULL_DUPLEX)) {
DPRINTK(PROBE, ERR, "Unsupported Speed/Duplex configuration\n");
return -EINVAL;
}
switch(spddplx) {
- case SPEED_10 + DUPLEX_HALF:
+ case SPEED_10 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_half;
break;
- case SPEED_10 + DUPLEX_FULL:
+ case SPEED_10 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_full;
break;
- case SPEED_100 + DUPLEX_HALF:
+ case SPEED_100 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_half;
break;
- case SPEED_100 + DUPLEX_FULL:
+ case SPEED_100 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_full;
break;
- case SPEED_1000 + DUPLEX_FULL:
+ case SPEED_1000 + FULL_DUPLEX:
adapter->hw.autoneg = 1;
adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL;
break;
- case SPEED_1000 + DUPLEX_HALF: /* not supported */
+ case SPEED_1000 + HALF_DUPLEX: /* not supported */
default:
DPRINTK(PROBE, ERR, "Unsupported Speed/Duplex configuration\n");
return -EINVAL;
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-26 15:00 UTC (permalink / raw)
To: woho
Cc: Stephen Hemminger, Carl-Daniel Hailfinger, Jeff Garzik, netdev,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <200602260957.04305.woho@woho.de>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
On Sun, 2006-02-26 at 09:57 +0100, Wolfgang Hoffmann wrote:
> On Sunday 26 February 2006 03:03, Stephen Hemminger wrote:
> > Instead of whining, try this.
>
> I tried and still see the hang.
I'm at a record 12 hours with that patch.
> Stephen, if you want me (as suggested off-list) to bisect the individual
> patches leading from 0.13a to current head, please give me a series of
> patches to incrementally apply, eighter via mail/ftp/git, and I'll test. I
> don't want to hack the patches together myself, because results would be
> worthless if I screw up, and given that I have no networking background
> chances are high ...
There is a git bisect for that, and a link for it somewhere =)
> It takes me between 5 - 20 GB of data transfer to reproduce the hang, so it
> will take a while, but I'm willing to help. If you see vendor chip specs
> arrive soon and feel it's not worth the hassle, that's fine for me, too.
My last real test with sky2 was at 205gb, which made me think that it's
more of a race and not data dependant (read, 2 boxes doing ping -f -s
8000)...
> In the meanwhile, I'll resort to 0.13a
>
> Wolfgang
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Jesper Juhl @ 2006-02-26 15:00 UTC (permalink / raw)
To: Paul Rolland
Cc: linux-kernel, netdev, linux.nics, cramerj, john.ronciak,
Ganesh.Venkatesan
In-Reply-To: <01d801c63ae4$b7d71b00$2001a8c0@cortex>
On 2/26/06, Paul Rolland <rol@witbe.net> wrote:
> Hello,
>
> > are you planning a 2.6 patch as well ?
> >
> I'm preparing it, and I'll be carefull with Tab/space ;)
>
Ok, great, I was just wondering since I would have made one if you had
no plans to do so.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Paul Rolland @ 2006-02-26 14:55 UTC (permalink / raw)
To: 'Jesper Juhl'
Cc: linux-kernel, netdev, linux.nics, cramerj, john.ronciak,
Ganesh.Venkatesan
In-Reply-To: <9a8748490602260459j76409f0cu287d7efad4d1781c@mail.gmail.com>
Hello,
> are you planning a 2.6 patch as well ?
>
I'm preparing it, and I'll be carefull with Tab/space ;)
Paul
^ permalink raw reply
* Re: RTL 8139 stops RX after receiving a jumbo frame
From: Francois Romieu @ 2006-02-26 14:44 UTC (permalink / raw)
To: John Zielinski; +Cc: linux-kernel, netdev
In-Reply-To: <44012D53.30700@undead.cc>
John Zielinski <john_ml@undead.cc> :
[8139 failure]
Can you send lspci -vx, dmesg and lsmod after the hang ?
--
Ueimor
^ permalink raw reply
* Re: [2.6.15] running tcpdump on 3c905b causes freeze (reproducable)
From: Folkert van Heusden @ 2006-02-26 14:03 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, linux-kernel
In-Reply-To: <20060114233648.GA24049@vanheusden.com>
> > > > > > > > Have you tried enabling the NMI watchdog? Enable CONFIG_X86_LOCAL_APIC and
> > > > > > > > boot with `nmi_watchdog=1' on the command line, make sure that the NMI line
> > > > > > > > of /proc/interrupts is incrementing.
> > > > > > > I'll give it a try. I've added it to the append-line in the lilo config.
> > > > > > > Am now compiling the kernel.
> > > > > > No change. Well, that is: the last message on the console now is
> > > > > > "setting eth1 to promiscues mode".
> > > > > Did you confirm that the NMI counters in /proc/interrupts are incrementing?
> > > > Yes:
> > > > root@muur:/home/folkert# for i in `seq 1 5` ; do cat /proc/interrupts | grep NMI ; sleep 1 ; done
> > > > NMI: 6949080 6949067
> ...
> > > > NMI: 6949488 6949475
> > >
> > > Is there anything else I can try?
> > argh. I haven't forgotten. Hopefully after -rc1 I'll have more time...
> Sorry :-)
> > Your report didn't mention whether that card work OK under earlier 2.6
> > kernels. If it does, a bit of bisection searching would really help.
> 2.6.15 crash
> 2.6.14.4 crash
> 2.6.14 crash
> 2.6.12.6 crash "NMI watchdog detected LOCKUP"
> 2.6.6 crash "NMI watchdog detected LOCKUP on CPU1 eip c02500aa, registers:"
> 2.6.1 would not boot
It is definately a 3com 3c905b problem: I swapped that card yesterday
with an adapter from a different brand (gigabit one) and now I can
tcpdump without any lockups.
Folkert van Heusden
--
iPod winnen? --> http://keetweej.vanheusden.com/redir.php?id=62
--------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Jesper Juhl @ 2006-02-26 12:59 UTC (permalink / raw)
To: rol
Cc: linux-kernel, netdev, linux.nics, cramerj, john.ronciak,
Ganesh.Venkatesan
In-Reply-To: <007801c639f3$79388060$2001a8c0@cortex>
On 2/25/06, Paul Rolland <rol@as2917.net> wrote:
> Hello,
>
> This patch is based on Linux 2.4.32, and I've verified the same problem
> exists on 2.6.15.4.
are you planning a 2.6 patch as well ?
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: RTL 8139 stops RX after receiving a jumbo frame
From: Alan Cox @ 2006-02-26 12:46 UTC (permalink / raw)
To: John Zielinski; +Cc: linux-kernel, netdev
In-Reply-To: <44012D53.30700@undead.cc>
On Sad, 2006-02-25 at 23:23 -0500, John Zielinski wrote:
> I'm surprised that the switch actually let the jumbo packet through onto
> a 100Mbit link. I'm going to see if I can find a non RTL 8139 card in
> my parts bin and see what that one does.
>
> What's the normal behavior for overruns on an interface?
Should drop the packet, but it may be triggering a driver path with a
bug. Is this repeatable and with multiple 8139 cards /
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Paul Rolland @ 2006-02-26 11:39 UTC (permalink / raw)
To: 'Willy TARREAU'
Cc: linux-kernel, netdev, linux.nics, cramerj, john.ronciak,
Ganesh.Venkatesan
In-Reply-To: <20060226104206.GA11434@w.ods.org>
> it's mangled, tabs have been turned into whitespaces. I fixed
> it so please
> use the appended one.
Sorry about that, thanks for the fix.
Paul
^ permalink raw reply
* Re: [2.4.32 - 2.6.15.4] e1000 - Fix mii interface
From: Willy TARREAU @ 2006-02-26 10:42 UTC (permalink / raw)
To: Paul Rolland
Cc: linux-kernel, netdev, linux.nics, cramerj, john.ronciak,
Ganesh.Venkatesan
In-Reply-To: <007801c639f3$79388060$2001a8c0@cortex>
Hello Paul,
On Sat, Feb 25, 2006 at 11:08:49AM +0100, Paul Rolland wrote:
> Hello,
>
> This patch is based on Linux 2.4.32, and I've verified the same problem
> exists on 2.6.15.4.
it's mangled, tabs have been turned into whitespaces. I fixed it so please
use the appended one.
> 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, I found that there is some confusion with :
> - DUPLEX_FULL and FULL_DUPLEX,
> - DUPLEX_HALF and HALF_DUPLEX
> in the code :
> ...
> spddplx += (mii_reg & 0x100)
> ? FULL_DUPLEX :
> HALF_DUPLEX;
> retval = e1000_set_spd_dplx(adapter,
> spddplx);
> ...
> and
> int
> e1000_set_spd_dplx(struct e1000_adapter *adapter, uint16_t spddplx)
> {
> adapter->hw.autoneg = 0;
>
> switch(spddplx) {
> case SPEED_10 + DUPLEX_HALF:
> adapter->hw.forced_speed_duplex = e1000_10_half;
> break;
> ....
> when the constants don't have the same value.
>
> This patch is simply changing the code in the e1000_set_spd_dplx to use the
> same constants as does the caller of the function : FULL_DUPLEX and
> HALF_DUPLEX
> whose values are not 0, to make sure we have had a successfull init
> (DUPLEX_HALF value is 0, and the DUPLEX_xxx are defined in ethtool.h, thus
> are probably not meant to be used in the mii interface).
>
> Signed-off-by: Paul Rolland <rol@as2917.net>
>
> diff -urN linux-2.4.32-orig/drivers/net/e1000/e1000_main.c
> linux-2.4.32/drivers/net/e1000/e1000_main.c
> --- linux-2.4.32-orig/drivers/net/e1000/e1000_main.c Mon Apr 4 01:42:19
> 2005
> +++ linux-2.4.32/drivers/net/e1000/e1000_main.c Sat Feb 25 09:36:23 2006
> @@ -2944,23 +2944,23 @@
> adapter->hw.autoneg = 0;
>
> switch(spddplx) {
> - case SPEED_10 + DUPLEX_HALF:
> + case SPEED_10 + HALF_DUPLEX:
> adapter->hw.forced_speed_duplex = e1000_10_half;
> break;
> - case SPEED_10 + DUPLEX_FULL:
> + case SPEED_10 + FULL_DUPLEX:
> adapter->hw.forced_speed_duplex = e1000_10_full;
> break;
> - case SPEED_100 + DUPLEX_HALF:
> + case SPEED_100 + HALF_DUPLEX:
> adapter->hw.forced_speed_duplex = e1000_100_half;
> break;
> - case SPEED_100 + DUPLEX_FULL:
> + case SPEED_100 + FULL_DUPLEX:
> adapter->hw.forced_speed_duplex = e1000_100_full;
> break;
> - case SPEED_1000 + DUPLEX_FULL:
> + case SPEED_1000 + FULL_DUPLEX:
> adapter->hw.autoneg = 1;
> adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL;
> break;
> - case SPEED_1000 + DUPLEX_HALF: /* not supported */
> + case SPEED_1000 + HALF_DUPLEX: /* not supported */
> default:
> DPRINTK(PROBE, ERR,
> "Unsupported Speed/Duplexity configuration\n");
>
>
> Paul Rolland, rol(at)as2917.net
> ex-AS2917 Network administrator and Peering Coordinator
Regards,
Willy
diff -urN linux-2.4.32-orig/drivers/net/e1000/e1000_main.c linux-2.4.32/drivers/net/e1000/e1000_main.c
--- linux-2.4.32-orig/drivers/net/e1000/e1000_main.c Mon Apr 4 01:42:19 2005
+++ linux-2.4.32/drivers/net/e1000/e1000_main.c Sat Feb 25 09:36:23 2006
@@ -2944,23 +2944,23 @@
adapter->hw.autoneg = 0;
switch(spddplx) {
- case SPEED_10 + DUPLEX_HALF:
+ case SPEED_10 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_half;
break;
- case SPEED_10 + DUPLEX_FULL:
+ case SPEED_10 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_10_full;
break;
- case SPEED_100 + DUPLEX_HALF:
+ case SPEED_100 + HALF_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_half;
break;
- case SPEED_100 + DUPLEX_FULL:
+ case SPEED_100 + FULL_DUPLEX:
adapter->hw.forced_speed_duplex = e1000_100_full;
break;
- case SPEED_1000 + DUPLEX_FULL:
+ case SPEED_1000 + FULL_DUPLEX:
adapter->hw.autoneg = 1;
adapter->hw.autoneg_advertised = ADVERTISE_1000_FULL;
break;
- case SPEED_1000 + DUPLEX_HALF: /* not supported */
+ case SPEED_1000 + HALF_DUPLEX: /* not supported */
default:
DPRINTK(PROBE, ERR,
"Unsupported Speed/Duplexity configuration\n");
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Wolfgang Hoffmann @ 2006-02-26 8:57 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Carl-Daniel Hailfinger, Jeff Garzik, netdev, Ian Kumlien,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <20060225180353.5908c955@localhost.localdomain>
On Sunday 26 February 2006 03:03, Stephen Hemminger wrote:
> Instead of whining, try this.
I tried and still see the hang.
Stephen, if you want me (as suggested off-list) to bisect the individual
patches leading from 0.13a to current head, please give me a series of
patches to incrementally apply, eighter via mail/ftp/git, and I'll test. I
don't want to hack the patches together myself, because results would be
worthless if I screw up, and given that I have no networking background
chances are high ...
It takes me between 5 - 20 GB of data transfer to reproduce the hang, so it
will take a while, but I'm willing to help. If you see vendor chip specs
arrive soon and feel it's not worth the hassle, that's fine for me, too.
In the meanwhile, I'll resort to 0.13a
Wolfgang
^ permalink raw reply
* RTL 8139 stops RX after receiving a jumbo frame
From: John Zielinski @ 2006-02-26 4:23 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
I was testing a patch for the VIA Velocity adapter and accidentally
pinged a jumbo packet to 192.168.0.1 instead of 192.168.0.10. The
machine I pinged is my Linux firewall box with a RTL 8139 card (8139 rev
K chip). When my internet connection went down I tried pinging the
firewall with regular sized packets and it wouldn't respond. I had to
ifdown/ifup the interface to get things going again. The output from
ifconfig shows I had an overrun.
I'm replacing that card with a VIA Velocity card as I'm upgrading my
entire network to GigE but a friend of mine is only doing a partial
upgrade and will have several boxes with RTL 8139's still in them. I'm
going to move the RTL card into my test box for further testing.
I'm surprised that the switch actually let the jumbo packet through onto
a 100Mbit link. I'm going to see if I can find a non RTL 8139 card in
my parts bin and see what that one does.
What's the normal behavior for overruns on an interface?
^ permalink raw reply
* Re: VIA Velocity massive memory corruption with jumbo frames
From: John Zielinski @ 2006-02-26 3:56 UTC (permalink / raw)
To: Francois Romieu; +Cc: linux-kernel, netdev
In-Reply-To: <20060225235346.GA18558@electric-eye.fr.zoreil.com>
Francois Romieu wrote:
> Try the patch below and Cc: netdev@vger.kernel.org on further messages
> please.
>
It worked. No more memory corruption and I can ping 9000 byte packets
to my Windows box.
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-26 2:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Carl-Daniel Hailfinger, Jeff Garzik, netdev, Wolfgang Hoffmann,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <20060225180353.5908c955@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 213 bytes --]
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 <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Ian Kumlien @ 2006-02-26 2:25 UTC (permalink / raw)
To: Carl-Daniel Hailfinger
Cc: Jeff Garzik, netdev, Wolfgang Hoffmann, Pavel Volkovitskiy,
Linux Kernel Mailing List, Stephen Hemminger
In-Reply-To: <4400FC28.1060705@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
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 think that this is constructive, the error must be locatable on
later versions, just reverting to a older version of the driver as a cop
out solves nothing... And it also means that we don't understand WHY it
breaks at all.
It would be much better if more ppl could hack the driver source, esp if
they themselves have a system that shows the breakage.
--
Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]
^ permalink raw reply
* Re: [PATCH] Revert sky2 to 0.13a
From: Stephen Hemminger @ 2006-02-26 2:03 UTC (permalink / raw)
To: Carl-Daniel Hailfinger
Cc: Jeff Garzik, netdev, Ian Kumlien, Wolfgang Hoffmann,
Pavel Volkovitskiy, Linux Kernel Mailing List
In-Reply-To: <4400FC28.1060705@gmx.net>
Instead of whining, try this.
--- drivers/net/sky2.c.orig 2006-02-25 18:02:10.000000000 -0800
+++ drivers/net/sky2.c 2006-02-25 18:03:13.000000000 -0800
@@ -1895,19 +1895,6 @@
u16 hwidx;
u16 tx_done[2] = { TX_NO_STATUS, TX_NO_STATUS };
- sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
-
- /*
- * Kick the STAT_LEV_TIMER_CTRL timer.
- * This fixes my hangs on Yukon-EC (0xb6) rev 1.
- * The if clause is there to start the timer only if it has been
- * configured correctly and not been disabled via ethtool.
- */
- if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
- sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
- sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
- }
-
hwidx = sky2_read16(hw, STAT_PUT_IDX);
BUG_ON(hwidx >= STATUS_RING_SIZE);
rmb();
@@ -1995,7 +1982,20 @@
sky2_write8(hw, STAT_TX_TIMER_CTRL, TIM_START);
}
- if (likely(work_done < to_do)) {
+ sky2_write32(hw, STAT_CTRL, SC_STAT_CLR_IRQ);
+
+ /*
+ * Kick the STAT_LEV_TIMER_CTRL timer.
+ * This fixes my hangs on Yukon-EC (0xb6) rev 1.
+ * The if clause is there to start the timer only if it has been
+ * configured correctly and not been disabled via ethtool.
+ */
+ if (sky2_read8(hw, STAT_LEV_TIMER_CTRL) == TIM_START) {
+ sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_STOP);
+ sky2_write8(hw, STAT_LEV_TIMER_CTRL, TIM_START);
+ }
+
+ if (sky2_read16(hw, STAT_PUT_IDX) == hw->st_idx) {
spin_lock_irq(&hw->hw_lock);
__netif_rx_complete(dev0);
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Stephen Evanchik @ 2006-02-26 1:09 UTC (permalink / raw)
To: gene.heskett; +Cc: Christoph Hellwig, James Ketrenos, NetDev, linux-kernel
In-Reply-To: <200602250619.04567.gene.heskett@verizon.net>
On 2/25/06, Gene Heskett <gene.heskett@verizon.net> 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 technology. The fact that it effectively put a stop to
> conference call type use of single sideband because no 2 radios were on
> the same, now non-adjustable frequency was an undesirable thing, but
> thats the breaks. I might try and look it up after I've had some zz's,
> as I just came from doing transmitter maintainance overnight.
I'm not really sure what you are describing but you probably want to
reference CFR Title 47 Telecommunications [1]. Particularly
interesting is 15.202 "Certified operating frequency range." which
says in part:
"... Master devices marketed within the United States must be
limited to operation on permissible part 15 frequencies. Client devices
that can also act as master devices must meet the requirements of a
master device. ..."
Also there is a general prohibition on "harmful interference" in 15.5
which says in part:
"(b) Operation of an intentional, unintentional, or incidental
radiator is subject to the conditions that no harmful interference is
caused and that interference must be accepted that may be caused by the
operation of an authorized radio station, by another intentional or
unintentional radiator, by industrial, scientific and medical (ISM)
equipment, or by an incidental radiator. .."
I am going to guess that these two excerpts provide strong evidence
that Intel has to keep their radios from being modified accidentally
or purposefully. I also suspect that they only have to make it
difficult for an end user and not a technologist. So the well defined
interface between the closed source binary only userspace daemon and
the open source kernel driver could be reverse engineered and an
unencumbered replacement created.
I am definitely not a lawyer and this stuff is always subject to
someone making an argument in court.
Stephen
[1] http://www.access.gpo.gov/nara/cfr/waisidx_05/47cfr15_05.html
^ permalink raw reply
* Re: [Announce] Intel PRO/Wireless 3945ABG Network Connection
From: Alan Cox @ 2006-02-26 0:58 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: James Ketrenos, NetDev, linux-kernel, okir
In-Reply-To: <20060225084139.GB22109@infradead.org>
On Sad, 2006-02-25 at 08:41 +0000, 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 reasonably
tamperproof. Some of the lawyers have decided that for a software radio
tamperproof means "binary".
Thats pretty dumb but given the hardware variant of this is "seal
anything adjustible in plastic gunge" you can see the logic at work -
and it *will* help make the product tamperproof to end users. Remember
Christoph you are not an "end user" any more than hardware like that is
designed to proof against a person who can use a scope and solder
surface mount components.
Now a smart vendor would have put MD5 sum checking into the chip so you
can only load register sets for the transmitter as a block and that
block is loaded such that
[Data] + Secret known only to chip = MD5sum with data
or a similar cookie signing scheme. Replay attacks don't matter here so
that should be sufficient.
^ 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