On 8/24/06, Brice Goglin <[EMAIL PROTECTED]> wrote:
During the submission of the myri10ge driver, some people raised the
question of using pages (or any kind of non-contiguous skb) instead of
our current 16kB contiguous skb. We are looking at this right now and it
is not clear what solution is th
On 8/28/06, Ian McDonald <[EMAIL PROTECTED]> wrote:
On 8/28/06, David Miller <[EMAIL PROTECTED]> wrote:
> From: Ian McDonald <[EMAIL PROTECTED]>
> Date: Mon, 28 Aug 2006 16:34:50 +1200
>
> > Arnaldo has pointed this one out to me in latest series of
> > patches. Can this go into 2.6.18 please?
>
On 8/28/06, David Miller <[EMAIL PROTECTED]> wrote:
From: Ian McDonald <[EMAIL PROTECTED]>
Date: Mon, 28 Aug 2006 16:34:50 +1200
> Arnaldo has pointed this one out to me in latest series of
> patches. Can this go into 2.6.18 please?
It's not a bug fix, so we'll defer it to 2.6.19
I guess that
From: Ian McDonald <[EMAIL PROTECTED]>
Date: Mon, 28 Aug 2006 16:34:50 +1200
> Arnaldo has pointed this one out to me in latest series of
> patches. Can this go into 2.6.18 please?
It's not a bug fix, so we'll defer it to 2.6.19
-
To unsubscribe from this list: send the line "unsubscribe netdev"
As Arnaldo Carvalho de Melo points out I should be using list_entry in case
the structure changes in future. Current code functions but is reliant
on position and requires type cast.
Noticed when doing this that I have one more variable than I needed so
removing that also.
Signed off by: Ian McDo
Dave,
Arnaldo has pointed this one out to me in latest series of patches. Can this go
into 2.6.18 please?
(And I've checked for white space too!)
Ian
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://
On Sun, 2006-08-27 at 14:03 -0700, Ulrich Drepper wrote:
[ note: there was lots of good stuff that I cut out because it was a
long email and I'm only replying to some of its points ]
> Events to wait for are basically all those with syscalls which can
> potentially block indefinitely:
>
> - file
On Sun, 2006-08-27 at 18:57 -0700, David Miller wrote:
> From: Ulrich Drepper <[EMAIL PROTECTED]>
> Date: Sun, 27 Aug 2006 14:03:33 -0700
>
> > The biggest problem I see so far is the integration into the existing
> > interfaces. kevent notification *really* should be usable as a new
> > sigevent
David Miller wrote:
> SigEvent, and signals in general, are crap. They are complex
> and userland gets it wrong more often than not. Interfaces
> for userland should be simple, signals are not simple.
You miss the point.
sigevent has nothing necessarily to do with signals. I don't want
signals
From: Ulrich Drepper <[EMAIL PROTECTED]>
Date: Sun, 27 Aug 2006 14:03:33 -0700
> The biggest problem I see so far is the integration into the existing
> interfaces. kevent notification *really* should be usable as a new
> sigevent type. Whether the POSIX interfaces are liked by kernel folks
> or
It's Ok. Thanks for that.
Jesse
- Original Message -
From: "Francois Romieu" <[EMAIL PROTECTED]>
To: "Jesse Huang" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
; ;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, August 28, 2006 6:08 AM
Sub
Hi,
There are a couple of ARM boards out there with on-board e1000s but
without any kind of eeprom. The boot loader and kernel board support
code have all the info necessary to configure the e1000, but the e1000
driver bombs out because there isn't an eeprom connected -- how are
we supposed to de
On Mon, Aug 28, 2006 at 10:16:56AM +1000, Herbert Xu wrote:
> cagri coltekin <[EMAIL PROTECTED]> wrote:
> >
> > Aug 25 04:03:35 ns kernel: [ cut here ]
> > Aug 25 04:03:35 ns kernel: kernel BUG at net/ipv6/ip6_output.c:718!
> > Aug 25 04:03:35 ns kernel: invalid operand: 00
cagri coltekin <[EMAIL PROTECTED]> wrote:
>
> Aug 25 04:03:35 ns kernel: [ cut here ]
> Aug 25 04:03:35 ns kernel: kernel BUG at net/ipv6/ip6_output.c:718!
> Aug 25 04:03:35 ns kernel: invalid operand: [#1]
> Aug 25 04:03:35 ns kernel: SMP
> Aug 25 04:03:35 ns kernel:
On 8/27/06, Andrea Bittau <[EMAIL PROTECTED]> wrote:
> The two sets of patches are at:
> http://darkircop.org/dccp
>
These look good in general and I know you have done a lot of work on these.
Here are some comments. NB I haven't actually compiled or tested -
just from reading the code.
You ne
I demand that Francois Romieu may or may not have written...
> Darren Salt <[EMAIL PROTECTED]> :
> [...]
>> Whoops. I'd not noticed the -rc4 patches...
>> These seem to help a little: mii-tool can reset it and bring the link up
>> regardless of RTL_CFG_{1,2}. After that, RTL_CFG_1 allows sending
Francois Romieu <[EMAIL PROTECTED]> :
> Jesse Huang <[EMAIL PROTECTED]> :
> [...]
>
> Added:
> 0039-ip1000-cosmetic-in-ipg_interrupt_handler.txt
> 0040-ip1000-irq-handler-and-device-close-race.txt
> 0041-ip1000-schedule-the-host-error-recovery-to-user-context.txt
> 0042-ip1000-no-need-to-mask-a-co
Darren Salt <[EMAIL PROTECTED]> :
[...]
> Whoops. I'd not noticed the -rc4 patches...
>
> These seem to help a little: mii-tool can reset it and bring the link up
> regardless of RTL_CFG_{1,2}. After that, RTL_CFG_1 allows sending to work,
> and RTL_CFG_2 allows both sending and receiving to work
[Sorry for the length, but I want to be clear.]
As promised, before Monday (at least my time), here are my thoughts on
the proposed kevent interfaces. Not necessarily well ordered:
- one point of critique which applied to many proposals over the years:
multiplexer syscalls a bad, really bad.
Andrew Morton wrote:
Jeremy reported that a while back too. I do not know what is causing it
and as far as I know no net developers have yet looked into it.
It went away with -rc4-mm[23] for me...
J
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a mes
When setting the ARCSR registers we could use a better/more descriptive
and already available variable name than plain "value".
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3
wireless-dev-rt2x00-netif/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-variable/dr
Add ieee80211_netif_oper() calls on the correct places
for better flow control.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3
wireless-dev-rt2x00-return/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-netif/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
--- w
We don't need a seperate array when reading the mac address from eeprom.
Read it directly into the perm_addr array which has been correctly memsetted.
Also to prevent confusing add eeprom addresses for each eeprom word for the
mac address.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff
EEPROM_SIZE should be a value dividable by sizeof(u16)
CSR_REG_SIZE should be dividable by sizeof(u32)
In USB adapters the eeprom offset is in bytes and not words.
Short slot time is 9 instead of 7
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3
wireless-dev-rt2x00-txd/drivers/n
Allow correct configuration of the register depending on working mode.
This can only be done by configuring the register before calling
rt2x00_add_interface.
Second fix is to disable the radio when all monitor interfaces
_and_ the non-monitor interface has been removed.
Signed-off-by Ivo van Door
This fixes several issues with TXD and RTS control.
excessive_retries is not a counter and should be set to
either 1 or 0. Otherwise all folluw up frames will be marked
as excessive retry...
ENTRY_RTS_FRAME should be cleared when frame has been send,
otherwise the next frame for this txd will als
When chipset is detected it is also a good idea to read the
revision number from the register. This can than also
be used with "ethtool -d".
For rt61pci and rt73usb the firmware version should be stored
so it can be accessed for "ethtool -i"
For the other device just set firmware version to "N/A"
Various register initialization fixes to make the device work properly.
This will fix the RX/TX issue for rt61pci.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3
wireless-dev-rt2x00-interface/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
wireless-dev-rt2x00-register/drivers/net
Respect the return values given from various functions.
The return code should be handed upstream and not
replaced by some other (possibly wrong) error code.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3
wireless-dev-rt2x00-register/drivers/net/wireless/d80211/rt2x00/rt2400pci.c
Hi,
Here is a new update for rt2x00.
After these patches rt2x00 seems to slowly become active.
Current problematic issues:
Solid association but high packet loss (rt2400pci)
Very short association duration (rt2500pci)
On big endian machines device doesn't wake up (rt2500usb)
Hard to start associa
The enabled rates register apparently only requires the basic rates.
For this we add a define containing the basic rates.
Now we are working on it anyway, also add a OFDM and CCK rate mask,
to clear up some code.
Signed-off-by Ivo van Doorn <[EMAIL PROTECTED]>
---
diff -rU3
wireless-dev-rt2x00-
Hi,
[ Apologies for possible duplicates, and if I'm addressing wrong
people. ]
The following is the standard bug report form. I believe I have
included enough information for the starters. I'd be happy to try
to provide more if you need it. Please let me know.
Kind Regards,
--
Cagri Coltekin
I demand that I definitely did write...
> I demand that Francois Romieu may or may not have written...
>> Darren Salt <[EMAIL PROTECTED]> :
>>> In case you don't yet have an lspci dump for an RTL8136, here's one for a
>>> device which is working with the r1000 driver which is supplied with
>>> Ubu
On Sunday 27 August 2006 00:17, Ivo van Doorn wrote:
> But in the end this is something that should be fixed in the stack right?
> rt2x00 indeed seems to miss the ieee80211_netif_oper() commands,
> I'll add them immediately.
>
I'm pretty sure it's entirely in the stack, and you shouldn't need to do
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sun, 27 Aug 2006 00:19:43 -0700
> Jeremy reported that a while back too. I do not know what is causing it
> and as far as I know no net developers have yet looked into it.
A debugging patch like this one should help figure out the culprit.
If we don
Please copy relevant mailing lists and maintainers on bug reports.
On Sun, 27 Aug 2006 00:07:50 -0700
"Miles Lane" <[EMAIL PROTECTED]> wrote:
> I have a:
>
> eth0: RealTek RTL8139 at 0xf8fa2800, 00:c0:9f:95:18:1b, IRQ 10
> eth0: Identified 8139 chip type 'RTL-8100B/8139D'
>
> and a:
>
> ipw2
On Sunday 27 August 2006 07:14, Michael Wu wrote:
> On Friday 11 August 2006 01:34, Johannes Berg wrote:
> > This is running wireless-dev from yesterday. All I did was plug in a
> > rt2500usb device into a usb port on a freshly booted system. I have a
> > feeling that this is could be one of the pr
37 matches
Mail list logo
