Re: [PATCH] Let DAC960 supply entropy to random pool
On 2/23/06, Anders K. Pedersen [EMAIL PROTECTED] wrote: Hello, We have a couple of servers with Mylex RAID controllers (handled by the DAC960 block device driver). There's normally no keyboard or mouse attached, and neither the DAC960 nor the NIC driver (e100) provides entropy to the random pool, so it was impossible to get any data from /dev/random. Is there any reason that other network drivers shouldn't be setting SA_SAMPLE_RANDOM? I ask this because I run into this all the time when I try to use rpmbuild --rebuild on a redhat kernel source over ssh. There is no way to introduce entropy for gpg when you're ssh'd in. Jesse - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert sky2 to 0.13a
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 signature.asc Description: This is a digitally signed message part
Re: [PATCH] Revert sky2 to 0.13a
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 signature.asc Description: This is a digitally signed message part
wan: fix section mismatch warning in sbni
In latest -mm sbni gives following warning:
WARNING: drivers/net/wan/sbni.o - Section mismatch: reference to\
.init.data: from .text between 'init_module' (at offset 0x14ef) and \
'cleanup_module'
The warning is caused by init_module() calling a function declared
__init.
Declare init_module() __init too to fix warning.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
Compile tested with allmodconfig on amd64.
diff --git a/drivers/net/wan/sbni.c b/drivers/net/wan/sbni.c
index db2c798..175ba13 100644
--- a/drivers/net/wan/sbni.c
+++ b/drivers/net/wan/sbni.c
@@ -1495,8 +1495,7 @@ module_param(skip_pci_probe, bool, 0);
MODULE_LICENSE(GPL);
-int
-init_module( void )
+int __init init_module( void )
{
struct net_device *dev;
int err;
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert sky2 to 0.13a
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 ;) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
de620: fix section mismatch warning
In latest -mm de620 gave following warning:
WARNING: drivers/net/de620.o - Section mismatch: reference to \
.init.text:de620_probe from .text between 'init_module' (at offset \
0x1682) and 'cleanup_module'
init_module() call de620_probe() which is declared __init.
Fix is to declare init_module() __init too.
Signed-off-by: Sam Ravnborg [EMAIL PROTECTED]
---
Compile tested with allmodconfig on amd64.
diff --git a/drivers/net/de620.c b/drivers/net/de620.c
index 0069f5f..22fc5b8 100644
--- a/drivers/net/de620.c
+++ b/drivers/net/de620.c
@@ -1012,7 +1012,7 @@ static int __init read_eeprom(struct net
#ifdef MODULE
static struct net_device *de620_dev;
-int init_module(void)
+int __init init_module(void)
{
de620_dev = de620_probe(-1);
if (IS_ERR(de620_dev))
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert sky2 to 0.13a
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 signature.asc Description: This is a digitally signed message part
Re: [PATCH] Revert sky2 to 0.13a
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.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] make UNIX a bool
El Sat, 25 Feb 2006 09:13:08 -0800, Stephen Hemminger [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL 8139 stops RX after receiving a jumbo frame
Alan Cox wrote: Should drop the packet, but it may be triggering a driver path with a bug. Is this repeatable and with multiple 8139 cards I took the card out of my firewall and put it into my test box. The test procedure was to ping a third machine from the text box and then start pinging the test box from the second machine using large packets. The rev K card would always stop receiving permanently until a ifdown/ifup was done. I tried three other cards and they only showed heavy packet loss from the ping running on the test box. The packet loss went away when the second machine stopped pinging it with the large packets. Here's the list of cards: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 eth0: Identified 8139 chip type 'RTL-8139 rev K' Ethernet controller: Accton Technology Corporation SMC2-1211TX (rev 10) Subsystem: Accton Technology Corporation EN-1207D Fast Ethernet Adapter eth0: Identified 8139 chip type 'RTL-8139B' Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10) Subsystem: D-Link System Inc DFE-538TX 10/100 Ethernet Adapter eth0: Identified 8139 chip type 'RTL-8139C' Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 eth0: Identified 8139 chip type 'RTL-8139C' - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RTL 8139 stops RX after receiving a jumbo frame
Francois Romieu wrote: Can you send lspci -vx, dmesg and lsmod after the hang ? :00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) Subsystem: Asustek Computer, Inc.: Unknown device 80e7 Flags: bus master, medium devsel, latency 0 Memory at fc00 (32-bit, prefetchable) [size=32M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00: 06 11 91 06 06 00 10 22 c4 00 00 06 00 00 00 00 10: 08 00 00 fc 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 80 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 :00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: f600-f75f Prefetchable memory behind bridge: f770-fbff Capabilities: [80] Power Management version 2 00: 06 11 98 85 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00 20: 00 f6 50 f7 70 f7 f0 fb 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 08 00 :00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) Subsystem: Asustek Computer, Inc.: Unknown device 80e7 Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00: 06 11 86 06 87 00 10 02 40 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 e7 80 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 :00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) Flags: bus master, stepping, medium devsel, latency 32 I/O ports at d800 [size=16] Capabilities: [c0] Power Management version 2 00: 06 11 71 05 87 00 90 02 06 8a 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 c0 00 00 00 00 00 00 00 00 00 00 00 :00:04.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d400 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 1a 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d4 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00 :00:04.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 1a) (prog-if 00 [UHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID) USB Controller Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d000 [size=32] Capabilities: [80] Power Management version 2 00: 06 11 38 30 17 00 10 02 1a 00 03 0c 08 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 01 d0 00 00 00 00 00 00 00 00 00 00 25 09 34 12 30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 04 00 00 :00:04.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Flags: medium devsel, IRQ 9 Capabilities: [68] Power Management version 2 00: 06 11 57 30 00 00 90 02 40 00 00 06 00 00 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 68 00 00 00 00 00 00 00 00 00 00 00 :00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at b800 [size=128] Memory at f580 (32-bit, non-prefetchable) [size=128] Expansion ROM at 2000 [disabled] [size=64K] 00: ec 10 39 81 07 00 00 02 10 00 00 02 00 20 00 00 10: 01 b8 00 00 00 00 80 f5 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 ec 10 39 81 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 01 20 40 :01:00.0 VGA compatible controller: nVidia Corporation NV20 [GeForce3] (rev a3) (prog-if 00 [VGA]) Subsystem: VISIONTEK: Unknown device 001b Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10 Memory at f600 (32-bit, non-prefetchable) [size=16M] Memory at f800 (32-bit, prefetchable) [size=64M] Memory at f780 (32-bit, prefetchable) [size=512K] Expansion ROM at f77f [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 00: de 10 00 02 07 00 b0 02 a3 00 00 03 00 40 00 00 10: 00 00 00 f6 08 00 00 f8 08 00 80 f7 00 00 00 00 20: 00
Re: [PATCH] Revert sky2 to 0.13a
On Sunday 26 February 2006 23:31, Wolfgang Hoffmann wrote:
On Sunday 26 February 2006 19:13, Wolfgang Hoffmann wrote:
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-Daniels 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.
Bisect done:
4d52b48b43d0d1d5959fa722ee0046e3542e5e1b is first bad commit
[PATCH] sky2: support msi interrupt (revised)
Reverting this commit in git head seems to work, at least the driver builds
and loads. Is that sane?
I'm currently testing this (without any further modifications), let's see
if it hangs or not.
Ok, no hangs yet.
This version passed a test scenario only 0.13a has survived so far. I'll
continue to use this to give it more testing tomorrow.
Looking at the reverted commit, I wonder if modprobing sky2 with disable_msi=1
is equivalent to reverting the commit?
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ANNOUNCE: new DHCP client for linux 2.6.x
Hi, Am Freitag 17 Februar 2006 20:39 schrieb Simon Barber: In 802.11 networks when connecting to a new AP on the same networks (same SSID security settings) you typically don't have to do DHCP again - but with some networks setups you do. In order to detect this, when connecting to a new AP always issue an ARP request for the default gateway - if you don't get a response, then kick off a dhcp request. I've just implemented the feature. As the client does not know the specific wireless settings, I've chosen this approach to verify the IP address: -downtime must be lower than 60 seconds -T1 (RENEWal time) has not passed yet -IP address of default gateway is ARP probed and must answer with the known MAC address of the default gateway. Maximum 3 (is configurable) tries with .5 sec delay. If any of this fails, the client tries to verify the IP address via DHCP for four seconds, then drops IP configuration and restarts if it is NAKed or not answered. Got to do more tests of course, but this sounds like a workable solution to me. Jamal: Your idea of influencing the statemachine from the called scripts hasn't been forgotten, but a communication channel from script to daemon must be well designed and there is still too much other stuff on my todo list. Stefan shameless readvertisement http://www.flamewarmaster.de/software/dhcpclient/ /shameless readvertisement - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert sky2 to 0.13a
On Sun, 2006-02-26 at 23:38 +0100, Carl-Daniel Hailfinger wrote: Ian Kumlien schrieb: 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 Yes, 0.15 causes memory corruption even if MSI is disabled. So if i run with iommu=forced or what the hell the option is called i should be able to catch these trashings? I also found it odd that it was only python that suffered... Starting large and long running C apps worked just fine. -- Ian Kumlien pomac () vapor ! com -- http://pomac.netswarm.net signature.asc Description: This is a digitally signed message part
ieee80211_rx.c: is_beacon
Fix broken is_beacon().
Signed-off-by: Pete Zaitcev [EMAIL PROTECTED]
---
This wart came with -rc3. The -rc2 was ok. It's not like nobody noticed:
Johannes' snapshot has a different fix (which is somewhat defective,
he declared a CPU-order word as __be16). But the strangest thing is, the
git tree wireless-2.6 is not fixed even though it contains a softmac
branch. I suppose Johannes simply forgot to push his fix out to John.
-- Pete
--- linux-2.6.16-rc5/net/ieee80211/ieee80211_rx.c 2006-02-26
23:04:57.0 -0800
+++ linux-2.6.16-rc5-lem/net/ieee80211/ieee80211_rx.c 2006-02-26
23:11:49.0 -0800
@@ -1301,7 +1301,7 @@ static void update_network(struct ieee80
/* dst-last_associate is not overwritten */
}
-static inline int is_beacon(int fc)
+static inline int is_beacon(__le16 fc)
{
return (WLAN_FC_GET_STYPE(le16_to_cpu(fc)) == IEEE80211_STYPE_BEACON);
}
@@ -1348,9 +1348,7 @@ static void ieee80211_process_probe_resp
escape_essid(info_element-data,
info_element-len),
MAC_ARG(beacon-header.addr3),
-is_beacon(le16_to_cpu
- (beacon-header.
- frame_ctl)) ?
+is_beacon(beacon-header.frame_ctl) ?
BEACON : PROBE RESPONSE);
return;
}
@@ -1400,9 +1398,7 @@ static void ieee80211_process_probe_resp
escape_essid(network.ssid,
network.ssid_len),
MAC_ARG(network.bssid),
-is_beacon(le16_to_cpu
- (beacon-header.
- frame_ctl)) ?
+is_beacon(beacon-header.frame_ctl) ?
BEACON : PROBE RESPONSE);
#endif
memcpy(target, network, sizeof(*target));
@@ -1412,16 +1408,14 @@ static void ieee80211_process_probe_resp
escape_essid(target-ssid,
target-ssid_len),
MAC_ARG(target-bssid),
-is_beacon(le16_to_cpu
- (beacon-header.
- frame_ctl)) ?
+is_beacon(beacon-header.frame_ctl) ?
BEACON : PROBE RESPONSE);
update_network(target, network);
}
spin_unlock_irqrestore(ieee-lock, flags);
- if (is_beacon(le16_to_cpu(beacon-header.frame_ctl))) {
+ if (is_beacon(beacon-header.frame_ctl)) {
if (ieee-handle_beacon != NULL)
ieee-handle_beacon(dev, beacon, network);
} else {
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
