| #
f9d1fe96 |
| 18-Jun-2005 |
Jeff Garzik <jgarzik@pretzel.yyz.us> |
Merge /spare/repo/linux-2.6/
|
| #
0107b3cf |
| 18-Jun-2005 |
David Woodhouse <dwmw2@shinybook.infradead.org> |
Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
|
| #
3afa294c |
| 17-Jun-2005 |
James Bottomley <jejb@titanic.(none)> |
merge by hand (qla_os.c mismerge)
|
|
Revision tags: v2.6.12 |
|
| #
f2cbb4f0 |
| 15-Jun-2005 |
Tony Luck <tony.luck@intel.com> |
Auto merge with /home/aegl/GIT/linus
|
| #
814d8ffd |
| 13-Jun-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Merge rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6
|
| #
77bd9196 |
| 13-Jun-2005 |
Rémi Denis-Courmont <rdenis@simphalempin.com> |
[IPv6] Don't generate temporary for TUN devices
Userland layer-2 tunneling devices allocated through the TUNTAP driver
(drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer
addres
[IPv6] Don't generate temporary for TUN devices
Userland layer-2 tunneling devices allocated through the TUNTAP driver
(drivers/net/tun.c) have a type of ARPHRD_NONE, and have no link-layer
address. The kernel complains at regular interval when IPv6 Privacy
extension are enabled because it can't find an hardware address :
Dec 29 11:02:04 auguste kernel: __ipv6_regen_rndid(idev=cb3e0c00):
cannot get EUI64 identifier; use random bytes.
IPv6 Privacy extensions should probably be disabled on that sort of
device. They won't work anyway. If userland wants a more usual
Ethernet-ish interface with usual IPv6 autoconfiguration, it will use a
TAP device with an emulated link-layer and a random hardware address
rather than a TUN device.
As far as I could fine, TUN virtual device from TUNTAP is the very only
sort of device using ARPHRD_NONE as kernel device type.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>
Acked-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
|
Revision tags: v2.6.12-rc6, v2.6.12-rc5 |
|
| #
ad34ea2c |
| 20-May-2005 |
James Bottomley <jejb@titanic.(none)> |
merge by hand - fix up rejections in Documentation/DocBook/Makefile
|
| #
325a479c |
| 17-May-2005 |
Tony Luck <tony.luck@intel.com> |
Merge with temp tree to get David's gdb inferior calls patch
|
|
Revision tags: v2.6.12-rc4 |
|
| #
bfd4bda0 |
| 05-May-2005 |
David Woodhouse <dwmw2@shinybook.infradead.org> |
Merge with master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
|
| #
8800cea6 |
| 03-May-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Merge of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git/
|
| #
db46edc6 |
| 03-May-2005 |
Thomas Graf <tgraf@suug.ch> |
[RTNETLINK] Cleanup rtnetlink_link tables
Converts remaining rtnetlink_link tables to use c99 designated
initializers to make greping a little bit easier.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
[RTNETLINK] Cleanup rtnetlink_link tables
Converts remaining rtnetlink_link tables to use c99 designated
initializers to make greping a little bit easier.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
|
Revision tags: v2.6.12-rc3 |
|
| #
fd92833a |
| 20-Apr-2005 |
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> |
[IPV6]: Fix a branch prediction
From: Tushar Gohad <tgohad@mvista.com>
Signed-off-by: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Revision tags: v2.6.12-rc2 |
|
| #
1da177e4 |
| 16-Apr-2005 |
Linus Torvalds <torvalds@ppc970.osdl.org> |
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
show more ...
|