On Sun, 12 Aug 2007, Segher Boessenkool wrote:
Note that last line.
Segher, how about you just accept that Linux uses gcc as per reality, and
that sometimes the reality is different from your expectations?
+m works. We use it. It's better than the alternatives. Pointing to
stale
On Sun, 2007-08-12 at 07:53 +0200, Segher Boessenkool wrote:
Yes, though I would use =m on the output list and m on the input
list. The reason is that I've seen gcc fall on its face with an ICE on
s390 due to +m. The explanation I've got from our compiler people was
quite esoteric, as far
On Sat, 2007-08-11 at 23:09 -0700, Linus Torvalds wrote:
Segher, how about you just accept that Linux uses gcc as per reality, and
that sometimes the reality is different from your expectations?
+m works. We use it. It's better than the alternatives. Pointing to
stale documentation
On Sun, 12 Aug 2007, Martin Schwidefsky wrote:
The duplication =m and m with the same constraint is rather
annoying.
It's not only annoying, it causes gcc to generate bad code too. At least
certain versions of gcc will generate the address *twice*, even if there
is obviously only one
Note that last line.
Segher, how about you just accept that Linux uses gcc as per reality,
and
that sometimes the reality is different from your expectations?
+m works.
It works _most of the time_. Ask Martin. Oh you don't even have to,
he told you two mails ago. My last mail simply
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
it does not give too much implementation detail (would be inapropriate
for conference proceedings,
Yes, though I would use =m on the output list and m on the input
list. The reason is that I've seen gcc fall on its face with an ICE
on
s390 due to +m. The explanation I've got from our compiler people
was
quite esoteric, as far as I remember gcc splits +m to an input
operand
and an output
On Aug 12 2007 13:35, Al Boldi wrote:
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
but it does give a good overview about what DRBD actually is,
On Sun, Aug 12, 2007 at 01:35:17PM +0300, Al Boldi ([EMAIL PROTECTED]) wrote:
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
it does not give
Ok, I'll give it a try, with small modifications.
On Sunday 12 August 2007, Adrian Bunk wrote:
Additional changes in this patch:
- small help text changes
- B44_PCI is no longer usr visible (automatically enabled when possible)
I think we want that to be selectable, as it's not needed
on some
All against mac80211 tree
--
mac80211, remove bitfields from struct ieee80211_tx_packet_data
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 10e9252a35d42fb92e65dfaaef136d81dbb71c4f
tree f8579cff30dc8053b770b78582a30961b7320046
parent a050b807aede7f9c6bee0bef1c07cd9c5fc4
author Jiri
mac80211, remove bitfields from struct ieee80211_txrx_data
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 37d65bd9e26732c7ec33a58eab6bda750b3be113
tree ac8e2b83c426b03007ea0bd7c5092e351598053c
parent 10e9252a35d42fb92e65dfaaef136d81dbb71c4f
author Jiri Slaby [EMAIL PROTECTED] Sun, 12 Aug
mac80211, remove bitfields from struct ieee80211_if_sta
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 3fe2e620fcc758be03b87e3ca5265b10fbd60e1a
tree 2f3e78c8f801af86ac42b8de1ab4495cdcd24bc3
parent 37d65bd9e26732c7ec33a58eab6bda750b3be113
author Jiri Slaby [EMAIL PROTECTED] Sun, 12 Aug
mac80211, remove bitfields from struct ieee80211_sub_if_data
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 086d27164f6a040ea24efe6baab3e6b9075942a5
tree 61fb84b9bb528c8321a86a6afbf980eafb28ee3f
parent 3fe2e620fcc758be03b87e3ca5265b10fbd60e1a
author Jiri Slaby [EMAIL PROTECTED] Sun, 12
Hi Oliver,
On Fri, Aug 10, 2007 at 07:34:03PM +0200, Oliver Hartkopp wrote:
Checking some other source with the current net-2.6.24 GIT, i just
discovered this:
CC drivers/net/mii.o
CC drivers/net/Space.o
CC drivers/net/loopback.o
CC drivers/net/b44.o
CC
Evgeniy Polyakov wrote:
Al Boldi ([EMAIL PROTECTED]) wrote:
Look at ZFS; it illegally violates layering by combining md/dm/lvm with
the fs, but it does this based on a realistic understanding of the
problems involved, which enables it to improve performance, flexibility,
and functionality
Ramkrishna Vepa [EMAIL PROTECTED] writes:
In one of the variations of this driver that is not
released to netdev, the received packets are steered to a channel based
on hashing on a preconfigured criteria such as sockets on tcp_ipv4,
udp_ipv4, tcp_ipv6, udp_ipv6 or addresses in ipv4/6.
Why
+m works. We use it. It's better than the alternatives. Pointing to
stale documentation doesn't change anything.
Well, perhaps on i386. I've seen some older versions of the s390 gcc
die
with an ICE because I have used +m in some kernel inline assembly.
I'm
happy to hear that this issue is
On Sun, 12 Aug 2007, Jan Engelhardt wrote:
On Aug 12 2007 13:35, Al Boldi wrote:
Lars Ellenberg wrote:
meanwhile, please, anyone interessted,
the drbd paper for LinuxConf Eu 2007 is finalized.
http://www.drbd.org/fileadmin/drbd/publications/
drbd8.linux-conf.eu.2007.pdf
but it does give a
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:
now, I am not an expert on either option, but three are a couple things that I
would question about the DRDB+MD option
1. when the remote machine is down, how does MD deal with it for reads and
writes?
I suppose it kicks the drive and you'd
On Sun, 12 Aug 2007, Segher Boessenkool wrote:
It works _most of the time_.
It used to have problems. Gcc has had problems in various areas.
Ask Martin. Oh you don't even have to,
he told you two mails ago. My last mail simply pointed out that this
isn't a GCC
On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote:
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:
now, I am not an expert on either option, but three are a couple things
that I
would question about the DRDB+MD option
1. when the remote machine is down, how does MD deal
On Sun, 12 Aug 2007, Segher Boessenkool wrote:
Yeah. Compiler errors are more annoying though I dare say ;-)
Actually, compile-time errors are fine, and easy to work around. *Much*
more annoying is when gcc actively generates subtly bad code. We've had
use-after-free issues due to
Hi!
I need help from developers, may be, because I have some troubles with
r8169 card.
I use laptop ASUS a6tc. The network card in this laptop is r8169. Video
is GeForce Go 7300. When I load linux (I use linux almost always), the
network and video cards take the same IRQ every time.
Yeah. Compiler errors are more annoying though I dare say ;-)
Actually, compile-time errors are fine,
Yes, they don't cause data corruption or anything like that,
but I still don't think the 390 people want to ship a kernel
that doesn't build -- and it seems they still need to support
GCC
Vadim Dyadkin wrote:
Hi!
I need help from developers, may be, because I have some troubles with
r8169 card.
I use laptop ASUS a6tc. The network card in this laptop is r8169. Video
is GeForce Go 7300. When I load linux (I use linux almost always), the
network and video cards take the same IRQ
Robert Hancock пишет:
This could well be a problem with the nvidia driver as it shares the
same IRQ. The first step would be to see if the problem still shows up
without the nvidia binary module loaded.
Thank for your answer. This problem never shows up if I use only nvidia
driver (the work
Alistair John Strachan пишет:
Thank for your answer. This problem never shows up if I use only nvidia
driver (the work without network), or if I use only r8169 (without
x.org). If I use both of them I have the hang. Usually the hang appears
if OpenGL is used or network rate is maximal. I
Implement set_mac_address() for the dm9000 driver. This allows changing
the mac address of the interface.
Signed-off-by: Michael Trimarchi [EMAIL PROTECTED]
---
--- linux-2.6.22/drivers/net/dm9000.c.orig 2007-07-09 01:32:17.0
+0200
+++ linux-2.6.22/drivers/net/dm9000.c
On Sunday 12 August 2007 21:27:41 Michael Trimarchi wrote:
Implement set_mac_address() for the dm9000 driver. This allows changing
the mac address of the interface.
Signed-off-by: Michael Trimarchi [EMAIL PROTECTED]
---
--- linux-2.6.22/drivers/net/dm9000.c.orig2007-07-09
On Sunday 12 August 2007 23:38:08 Michael Buesch wrote:
On Sunday 12 August 2007 21:27:41 Michael Trimarchi wrote:
Implement set_mac_address() for the dm9000 driver. This allows changing
the mac address of the interface.
Signed-off-by: Michael Trimarchi [EMAIL PROTECTED]
---
---
On Sun, Aug 12, 2007 at 11:45:30PM +0200, Michael Buesch wrote:
On Sunday 12 August 2007 23:38:08 Michael Buesch wrote:
On Sunday 12 August 2007 21:27:41 Michael Trimarchi wrote:
Implement set_mac_address() for the dm9000 driver. This allows changing
the mac address of the interface.
Implement set_mac_address() for the dm9000 driver. This allows changing
the mac address of the interface. Fix BigEndian problem.
Signed-off-by: Michael Trimarchi [EMAIL PROTECTED]
---
--- linux-2.6.22/drivers/net/dm9000.c.orig 2007-07-09 01:32:17.0
+0200
+++
(Resending old patch originally submitted at 1/7-2007 02:19, 04-Aug-2007 20:31)
In xl_freemem(), if dev_if is NULL, the line
struct xl_private *xl_priv =(struct xl_private *)dev-priv;
will cause a NULL pointer dereference. However, if we move
that assignment below the 'if' statement that tests
On Sunday 12 August 2007 23:20:09 michael trimarchi wrote:
Implement set_mac_address() for the dm9000 driver. This allows changing
the mac address of the interface. Fix BigEndian problem.
Signed-off-by: Michael Trimarchi [EMAIL PROTECTED]
---
--- linux-2.6.22/drivers/net/dm9000.c.orig
Vadim Dyadkin [EMAIL PROTECTED] :
[...]
I need help from developers, may be, because I have some troubles with
r8169 card.
Which kernel do you use ?
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sun, Aug 12, 2007 at 02:00:26PM +0200, Michael Buesch wrote:
Ok, I'll give it a try, with small modifications.
Thanks.
On Sunday 12 August 2007, Adrian Bunk wrote:
Additional changes in this patch:
- small help text changes
- B44_PCI is no longer usr visible (automatically enabled
+ return -EBUSY;
+
+ memcpy(dev-dev_addr, addr-sa_data, dev-addr_len);
+
+ for (i = 0; i 3; i++)
+ write_srom_word(db, i,
+ cpu_to_le16(((u16 *) (addr-sa_data))[i]));
Nope.
write_srom_word(db, i, le16_to_cpu(((__le16
On Monday 13 August 2007 00:45:17 Michael Trimarchi wrote:
+ return -EBUSY;
+
+ memcpy(dev-dev_addr, addr-sa_data, dev-addr_len);
+
+ for (i = 0; i 3; i++)
+ write_srom_word(db, i,
+ cpu_to_le16(((u16 *) (addr-sa_data))[i]));
set_mac_address should not write to the SROM, as Michael noted.
The proper operations are:
probe time:
read MAC address from SROM
dev open (interface up):
write dev-dev_addr[] to RX filter (or identity) registers
EEPROM update support is available separately, via an
On Tuesday 07 August 2007 13:55, Jens Axboe wrote:
I don't like structure bloat, but I do like nice design. Overloading
is a necessary evil sometimes, though. Even today, there isn't enough
room to hold bi_rw and bi_flags in the same variable on 32-bit archs,
so that concern can be scratched.
Iustin Pop wrote:
On Sun, Aug 12, 2007 at 07:03:44PM +0200, Jan Engelhardt wrote:
On Aug 12 2007 09:39, [EMAIL PROTECTED] wrote:
now, I am not an expert on either option, but three are a couple things that I
would question about the DRDB+MD option
1. when the remote machine is down, how does
per the message below MD (or DM) would need to be modified to work
reasonably well with one of the disk components being over an unreliable
link (like a network link)
are the MD/DM maintainers interested in extending their code in this
direction? or would they prefer to keep it simpler by
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp architectures, I'm concerned about interacting with interrupt
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe
([EMAIL PROTECTED]) wrote:
So, what did we decide? To bloat bio a bit (add a queue pointer) or
to use physical device limits? The latter requires to replace all
occurence of
(previous incomplete message sent accidentally)
On Wednesday 08 August 2007 02:54, Evgeniy Polyakov wrote:
On Tue, Aug 07, 2007 at 10:55:38PM +0200, Jens Axboe wrote:
So, what did we decide? To bloat bio a bit (add a queue pointer) or
to use physical device limits? The latter requires to
46 matches
Mail list logo
