* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Arnaldo Carvalho de Melo @ 2009-10-13 18:42 UTC (permalink / raw)
To: Ivo Calado; +Cc: Jarek Poplawski, dccp, netdev
In-Reply-To: <cb00fa210910131125m17eca24cx4a912e75f91f0fd2@mail.gmail.com>
Em Tue, Oct 13, 2009 at 03:25:48PM -0300, Ivo Calado escreveu:
> strange! I'm using the current DCCP test tree, branch dccp.
> Am I correct in use these rules?
Follow the rules in the latest Documentation/SubmittingPatches file,
that is:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches;hb=HEAD
And that states:
-------------------------------------------------------------------
8) E-mail size.
When sending patches to Linus, always follow step #7.
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.
-------------------------------------------------------------------
As Jarek pointed out.
- Arnaldo
^ permalink raw reply
* Re: [PATCH 0/5] netxen: add diagnostic tools support
From: David Miller @ 2009-10-13 18:53 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, ameen.rahman
In-Reply-To: <1255447905-29805-1-git-send-email-dhananjay@netxen.com>
From: Dhananjay Phadke <dhananjay@netxen.com>
Date: Tue, 13 Oct 2009 08:31:40 -0700
> Series of 5 patches to add diagostic and various other
> (internal) tools support.
>
> Please apply to net-next-2.6.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: Add netdev_alloc_skb_ip_align() helper
From: David Miller @ 2009-10-13 18:53 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AD49DFC.9020406@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 13 Oct 2009 17:34:20 +0200
> [PATCH net-next-2.6] net: Use netdev_alloc_skb_ip_align()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks!
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Ben Hutchings @ 2009-10-13 18:53 UTC (permalink / raw)
To: Dan Williams
Cc: Bill Nottingham, Scott James Remnant, Matt Domsch, Narendra K,
netdev, linux-hotplug, jordan_hargrave
In-Reply-To: <1255457182.2196.21.camel@localhost.localdomain>
On Tue, 2009-10-13 at 11:06 -0700, Dan Williams wrote:
> On Mon, 2009-10-12 at 13:37 -0400, Bill Nottingham wrote:
> > Scott James Remnant (scott@ubuntu.com) said:
> > > On the other hand, they *tend* to be unique for a wide range of systems.
> > > This makes them pretty comparable to LABELs on disks, and we have
> > > a /dev/disk/by-label
> > >
> > > Remember that udev already supports symlink stacking, and priorities and
> > > such.
> > >
> > > I don't think there's any danger of supporting a /dev/netdev/by-mac by
> > > default, it'll be a benefit to most and those who don't have unique MACs
> > > will just ignore it.
> >
> > At the moment, we do not appear to get the proper change uevents from things
> > like 'ip link set dev <foo> address <bar>', so we can't currently maintain
> > these symlinks.
>
> And if we really want seamless support for MAC spoofing, we want
> ETHTOOL_GPERMADDR for all drivers too, so that if your configuration
> says "rename device XX:XX:XX:XX:XX:XX to YY:YY:YY:YY:YY:YY" we can
> actually figure stuff out after the spoof.
ETHTOOL_GPERMADDR is handled in the ethtool core now. Are you thinking
of drivers that don't have ethtool ops? Maybe it's time to add default
operations.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCHv2 1/4] First Patch on TFRC-SP. Copy base files from TFRC
From: Jarek Poplawski @ 2009-10-13 18:53 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <cb00fa210910131125m17eca24cx4a912e75f91f0fd2@mail.gmail.com>
On Tue, Oct 13, 2009 at 03:25:48PM -0300, Ivo Calado wrote:
> On Tue, Oct 13, 2009 at 15:21, Jarek Poplawski <jarkao2@gmail.com> wrote:
> > On Tue, Oct 13, 2009 at 03:12:14PM -0300, Ivo Calado wrote:
> >> On Tue, Oct 13, 2009 at 15:06, Jarek Poplawski <jarkao2@gmail.com> wrote:
> >> > Ivo Calado wrote, On 10/13/2009 07:18 PM:
> >> >
> >> > ...
> >> >> Following the rule #8 in Documentation/SubmittingPatches the patch is
...
> >> 8) E-mail size.
> >>
> >> ...
> >> Large changes are not appropriate for mailing lists, and some
> >> maintainers. If your patch, uncompressed, exceeds 40 kB in size,
...
> > Large changes are not appropriate for mailing lists, and some
> > maintainers. If your patch, uncompressed, exceeds 300 kB in size,
...
> Hi Jarek,
> strange! I'm using the current DCCP test tree, branch dccp.
> Am I correct in use these rules?
Hmm... Looks like a fresh change in Linus' (and net-next) tree. So,
there is a hard legal question: which tree rules should be respected
here?
I guess you're one of a few respecting these rules ;-) Well done!
Best regards,
Jarek P.
^ permalink raw reply
* RE: PATCH: Network Device Naming mechanism and policy
From: Narendra_K @ 2009-10-13 18:53 UTC (permalink / raw)
To: dcbw, greg
Cc: shemminger, Matt_Domsch, netdev, linux-hotplug, Jordan_Hargrave
In-Reply-To: <1255456950.2196.18.camel@localhost.localdomain>
>If the BIOS support exists, it is trivial to use udev to
>create the correct naming mechanism for your machine, either
>using MAC address or BIOS-provided slot naming. No kernel
>patch is required.
>
Yes. In case, we want to rename only once. MAC address or slot names do
provide persistent naming. They help in retaining whatever names are
assigned during install time, which is the first instantiation of the
OS. But these names may not be as expected (like first on board network
interface name is expected to be "eth0" which is not always the case and
might not reflect what is written on the chassis label as "Gb1" and
"Gb2" etc) which would result in unattended installs break. Also image
based deployments will face problems by introducing state such as MAC
address.
With regards,
Narendra K
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Ben Hutchings @ 2009-10-13 18:56 UTC (permalink / raw)
To: Dan Williams
Cc: Karl O. Pinc, Greg KH, Narendra K, notting, matt_domsch, netdev,
shemminger, linux-hotplug, jordan_hargrave, charles_rose
In-Reply-To: <1255457860.2196.24.camel@localhost.localdomain>
On Tue, 2009-10-13 at 11:17 -0700, Dan Williams wrote:
> On Mon, 2009-10-12 at 14:41 -0500, Karl O. Pinc wrote:
> > On 10/12/2009 02:09:00 PM, Greg KH wrote:
> >
> > > "LOM"?
> >
> > "LAN On Motherboard" of all things.
> >
> > (I had to look this
> > one up. The expansion better suited
> > to today's economy is "Low On Manna".)
>
> Or the previous usage from Sun, Apple, and others: "Lights Out
> Management". Not sure why they needed to clash with a name already used
> in server-space, but perhaps I'm just out-of-date and there's a fancier
> name for LOM these days, and LOM got repurposed.
It's widely used with both meanings - what's more, LOM is an expected
feature of LOMs. :-)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] r8169: partial support and phy init for the 8168d
From: David Miller @ 2009-10-13 18:56 UTC (permalink / raw)
To: romieu; +Cc: netdev, simon.farnsworth, edward_hsu
In-Reply-To: <20091013174907.GA7267@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Tue, 13 Oct 2009 19:49:07 +0200
> Must I submit again or change something ?
No, I've got it, don't worry about it.
^ permalink raw reply
* Re: [PATCH 2/2] [RFC] Add c/r support for connected INET sockets
From: Oren Laadan @ 2009-10-13 19:00 UTC (permalink / raw)
To: Dan Smith
Cc: containers-qjLDD68F18O7TbgM5vRIOg, netdev-u79uwXL29TY76Z2rM5mHXA,
John Dykstra
In-Reply-To: <87ws2zcjhe.fsf-FLMGYpZoEPULwtHQx/6qkW3U47Q5hpJU@public.gmane.org>
Dan Smith wrote:
> OL> * Did you test this with UDP too ?
>
> Not sendmail of course, but I have a little test program that
> maintains a DGRAM connection to the echo service on a remote node,
> yeah.
>
> OL> * What happens if the the clock on the target machine differs from
> OL> the clock on the origin machine ? (TCP timestamps)
>
> I guess maybe we should canonicalize the timeout values to something
> like "milliseconds after checkpoint start"? This would allow the
> remote system to reset the timers to something reasonable. It would
> also cause non-migration restarts to restore the timers appropriately
> for a coordinated restart of multiple machines.
IIRC, the TCP stack takes the timestamp for each packet directly from
jiffies. So you need to teach TCP to add a per-container (or you can
make it per-socket) delta to that timestamp.
>
> OL> * How confident are we that "bad" input in one or more fields,
> OL> that you don't currently sanitize, cannot create "bad" behavior ?
> OL> (bad can be kernel crash, unauthorized behavior, DoS etc)
>
> I'm going to say 0.052.
Ah ... sure ...
To avoid confusion, can you state the units :p
>
> I haven't evaluated much of it, no :)
I guess my point is that we want to ask the networking people this
question in an explicit way.
>
> OL> * How much does TCP rely on the validity of the info in the
> OL> protocol control block, and what sorts of bads can happen if it
> OL> isn't ? Would TCP be still happy if the URG point is bogus, would
> OL> it allow the user to sent packets otherwise disallowed (to that
> OL> user?), or maybe it could crash the kernel ?
>
> Good question, I'll have to look.
Ditto.
So I'm thinking, for both, do (1) put a big fat comment in the code
saying that sanity-tests are needed, and what for, and (2) send a
separate mail to the networking people with these two scenarios and
request comments ?
>
> OL> * Can you please document (brief description) how the restart
> OL> logic works (listening parent socket etc) ?
>
> Sure.
>
> OL> * Do you intend to checkpoint (and collect) lingering sockets,
> OL> that is they are closed by the application so not references by
> OL> any task, but still sending data from their buffers ?
>
> Yeah, I expect that will be important :)
Cool. How about a TODO comment somewhere to convince everyone ( = me)
that you have it in your plans :)
>
> OL> * I'd like to also preserve the "older" behavior - so the user can
> OL> choose to restart and reset all previous connections, keep
> OL> listening sockets (e.g. RESTART_DISCONNET).
>
> Sure, sounds good to me.
>
>>> + printk("Doing post-restart hash\n");
>
> (oops, looks like I left some debug messages in place)
>
> OL> I wonder if a user can use this to convince TCP to send some nasty
> OL> packets to some arbitrary destination, with specific seq-number or
> OL> what not ?
>
> I'm not sure what you mean. The sk->num value comes from the sport
> which should have been refused during the bind() if it's in use or not
> permitted, no?
I think Serge already pointed in his review that this should not permit
a user to bind inconsistent or restricted ports.
I actually meant the contrary: suppose a malicious user on your machine
wants to attack a target machine/connection. can that user provide such
destination-address data and protocol parameters to build a connection
that locally seems valid, but is malicious ?
For example, now, if a user wants to send a TCP packet with arbitrary
protocol parameters, he needs to use raw IP sockets, which require
privilege. Would restarting a connection with the desired parameters
become a way to bypass that restriction ? (e.g. assume the user
restarts while using the host's network namespace).
Oren.
^ permalink raw reply
* Re: [PATCH] r8169: partial support and phy init for the 8168d
From: David Miller @ 2009-10-13 19:01 UTC (permalink / raw)
To: romieu; +Cc: netdev, simon.farnsworth, edward_hsu
In-Reply-To: <20091007224420.GA20170@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Thu, 8 Oct 2009 00:44:20 +0200
> Extracted from Realtek's 8.012.00 r8168 driver.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Tested-by: Simon Farnsworth <simon.farnsworth@onelan.com>
> Cc: Edward Hsu <edward_hsu@realtek.com.tw>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 0/8] gianfar: Add support for hibernation
From: David Miller @ 2009-10-13 19:09 UTC (permalink / raw)
To: afleming; +Cc: scottwood, linuxppc-dev, netdev
In-Reply-To: <64B2BB18-32DC-4B98-95D6-F203F74040D5@freescale.com>
From: Andy Fleming <afleming@freescale.com>
Date: Tue, 13 Oct 2009 12:22:38 -0500
> No, it was fine (though made unnecessary by other patches). The BD
> has a union:
>
> struct {
> u16 status; /* Status Fields */
> u16 length; /* Buffer length */
> };
> u32 lstatus;
>
> so when you write "lstatus", you need to use the BD_LFLAG() macro, but
> when you write "status", you are just setting the status bits.
Indeed I missed that, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] net: enable smsc911x on MIPS
From: David Miller @ 2009-10-13 19:09 UTC (permalink / raw)
To: manuel.lauss; +Cc: netdev, steve.glendinning, manuel.lauss
In-Reply-To: <1255454749-26895-1-git-send-email-manuel.lauss@gmail.com>
From: Manuel Lauss <manuel.lauss@googlemail.com>
Date: Tue, 13 Oct 2009 19:25:48 +0200
> Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Applied.
^ permalink raw reply
* Re: [Bugme-new] [Bug 14350] New: Network driver for mpc8313erdb board does not work
From: Andrew Morton @ 2009-10-13 19:08 UTC (permalink / raw)
To: janegu12; +Cc: bugzilla-daemon, bugme-daemon, netdev, Andy Fleming, Dai Haruki
In-Reply-To: <bug-14350-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 8 Oct 2009 22:14:38 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14350
>
> Summary: Network driver for mpc8313erdb board does not work
All right, I give up. Which net device driver does a "mpc8313erdb board" use?
I'm seeing gianfar in the dmesg. Is it that?
> Product: Drivers
> Version: 2.5
> Kernel Version: linux2.6.31.1
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: blocking
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: janegu12@gmail.com
> Regression: No
>
>
> I am working on mpc8313erdb board. I want to update current linux2.6.23 from
> freescale to latest version.there are 3 scenarios as below:
>
> 1: when I set up uboot as NFS boot, it hang on after IP-config:
>
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.31.1
> Created: 2009-10-08 21:19:37 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1987293 Bytes = 1.9 MB
> Load Address: 02000000
> Entry Point: 02000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using the fdt at 0x400000
> Using MPC831x RDB machine description
> Linux version 2.6.31.1 (root@dtl-lap-desi2.dtlab.moriseiki.co.jp) (gcc version
> 4.1.2) #15 Thu Oct 8 14:19:30 PDT 2009
> Found legacy serial port 0 for /soc8313@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=166666665, speed=0
> Found legacy serial port 1 for /soc8313@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=166666665, speed=0
> console [udbg0] enabled
> setup_arch: bootmem
> mpc831x_rdb_setup_arch()
> arch: exit
> Top of RAM: 0x8000000, Total RAM: 0x8000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00008000
> Normal 0x00008000 -> 0x00008000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00008000
> On node 0 totalpages: 32768
> free_area_init_node: node 0, pgdat c23f856c, node_mem_map c0010000
> DMA zone: 256 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 32512 pages, LIFO batch:7
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
> Kernel command line: root=/dev/nfs rw nfsroot=10.10.8.167:/tftpboot/rootfs8313
> ip=10.10.8.239:10.10.8.167:10.10.8.1:255.255.255.0:mpc8313eio:eth1:off consol0
> PID hash table entries: 512 (order: 9, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 125252k/131072k available (3896k kernel code, 5668k reserved, 180k
> data, 347k bss, 148k init)
> Kernel virtual memory layout:
> * 0xffffe000..0xfffff000 : fixmap
> * 0xfdffc000..0xfe000000 : early ioremap
> * 0xc9000000..0xfdffc000 : vmalloc & ioremap
> Hierarchical RCU implementation.
> NR_IRQS:512
> IPIC (128 IRQ sources) at c9000700
> time_init: decrementer frequency = 41.666666 MHz
> time_init: processor frequency = 333.333330 MHz
> clocksource: timebase mult[6000002] shift[22] registered
> clockevent: decrementer mult[aaaaaa7] shift[32] cpu[0]
> Mount-cache hash table entries: 512
> khelper used greatest stack depth: 7248 bytes left
> NET: Registered protocol family 16
>
> irq: irq 38 on host /soc8313@e0000000/pic@700 mapped to virtual irq 38
> khelper used greatest stack depth: 7216 bytes left
> Registering ipic with sysfs...
> khelper used greatest stack depth: 7200 bytes left
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> Generic PHY: Registered new driver
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Freescale Elo / Elo Plus DMA driver
> Switched to high resolution mode on CPU 0
> khelper used greatest stack depth: 7104 bytes left
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> NET: Registered protocol family 1
> irq: irq 9 on host /soc8313@e0000000/pic@700 mapped to virtual irq 16
> irq: irq 10 on host /soc8313@e0000000/pic@700 mapped to virtual irq 17
> khelper used greatest stack depth: 6880 bytes left
> WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (25 seconds)
> fsl-elo-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma
> controller at 0xe00082a8...
> irq: irq 71 on host /soc8313@e0000000/pic@700 mapped to virtual irq 71
> fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71
> JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
> msgmni has been set to 244
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> khelper used greatest stack depth: 6752 bytes left
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
> brd: module loaded
> loop: module loaded
> irq: irq 37 on host /soc8313@e0000000/pic@700 mapped to virtual irq 37
> irq: irq 36 on host /soc8313@e0000000/pic@700 mapped to virtual irq 36
> irq: irq 35 on host /soc8313@e0000000/pic@700 mapped to virtual irq 35
> eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:01
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> irq: irq 34 on host /soc8313@e0000000/pic@700 mapped to virtual irq 34
> irq: irq 33 on host /soc8313@e0000000/pic@700 mapped to virtual irq 33
> irq: irq 32 on host /soc8313@e0000000/pic@700 mapped to virtual irq 32
> eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:02
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> Freescale PowerQUICC MII Bus: probed
> irq: irq 20 on host /soc8313@e0000000/pic@700 mapped to virtual irq 20
> Freescale PowerQUICC MII Bus: probed
> Marvell 88E1101: Registered new driver
> Marvell 88E1112: Registered new driver
> Marvell 88E1111: Registered new driver
> Marvell 88E1118: Registered new driver
> Marvell 88E1121R: Registered new driver
> Marvell 88E1145: Registered new driver
> Marvell 88E1240: Registered new driver
> Fixed MDIO Bus: probed
> fe000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> fe000000.flash: Swapping erase regions for broken CFI table.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> RedBoot partition parsing not available
> irq: irq 16 on host /soc8313@e0000000/pic@700 mapped to virtual irq 18
> e0007000.spi: MPC8xxx SPI Controller driver at 0xc9090000 (irq = 18)
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
> fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i2c /dev entries driver
> irq: irq 14 on host /soc8313@e0000000/pic@700 mapped to virtual irq 19
> rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
> irq: irq 15 on host /soc8313@e0000000/pic@700 mapped to virtual irq 21
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> rtc-ds1307 0-0068: setting system clock to 2001-04-09 16:02:33 UTC (986832153)
> IP-Config: Complete:
> device=eth1, addr=10.10.8.239, mask=255.255.255.0, gw=10.10.8.1,
> host=mpc8313eio, domain=, nis-domain=(none),
> bootserver=10.10.8.167, rootserver=10.10.8.167, rootpath=
> VFS: Cannot open root device "nfs" or unknown-block(0,255)
> Please append a correct "root=" boot option; here are the available partitions:
> 1f00 8192 mtdblock0 (driver?)
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,255)
> Call Trace:
> [c7825ee0] [c2008768] show_stack+0x3c/0x160 (unreliable)
> [c7825f10] [c20240f4] panic+0x8c/0x164
> [c7825f60] [c23a9c5c] mount_block_root+0x124/0x2bc
> [c7825fb0] [c23a9fdc] prepare_namespace+0x180/0x210
> [c7825fd0] [c23a9210] kernel_init+0xfc/0x128
> [c7825ff0] [c2011128] kernel_thread+0x4c/0x68
> Rebooting in 180 seconds..
>
> 2:if I setup uboot as ramdisk boot and only setup eth1 interface, I can boot
> the linux. when I try to ping other PC, it hang on and get exception.
>
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.31.1
> Created: 2009-10-08 21:59:21 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1984750 Bytes = 1.9 MB
> Load Address: 02000000
> Entry Point: 02000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 01000000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Created: 2009-10-08 22:01:18 UTC
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 3811695 Bytes = 3.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Booting using the fdt at 0x400000
> Loading Ramdisk to 07ba4000, end 07f4696f ... OK
> Using MPC831x RDB machine description
> Linux version 2.6.31.1 (root@dtl-lap-desi2.dtlab.moriseiki.co.jp) (gcc version
> 4.1.2) #16 Thu Oct 8 14:59:14 PDT 2009
> Found initrd at 0xc7ba4000:0xc7f4696f
> Found legacy serial port 0 for /soc8313@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=166666665, speed=0
> Found legacy serial port 1 for /soc8313@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=166666665, speed=0
> console [udbg0] enabled
> setup_arch: bootmem
> mpc831x_rdb_setup_arch()
> arch: exit
> Top of RAM: 0x8000000, Total RAM: 0x8000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00008000
> Normal 0x00008000 -> 0x00008000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00008000
> On node 0 totalpages: 32768
> free_area_init_node: node 0, pgdat c23f756c, node_mem_map c0010000
> DMA zone: 256 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 32512 pages, LIFO batch:7
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
> Kernel command line: root=/dev/ram rw console=ttyS0,115200
> PID hash table entries: 512 (order: 9, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 121524k/131072k available (3892k kernel code, 9384k reserved, 180k
> data, 347k bss, 148k init)
> Kernel virtual memory layout:
> * 0xffffe000..0xfffff000 : fixmap
> * 0xfdffc000..0xfe000000 : early ioremap
> * 0xc9000000..0xfdffc000 : vmalloc & ioremap
> Hierarchical RCU implementation.
> NR_IRQS:512
> IPIC (128 IRQ sources) at c9000700
> time_init: decrementer frequency = 41.666666 MHz
> time_init: processor frequency = 333.333330 MHz
> clocksource: timebase mult[6000002] shift[22] registered
> clockevent: decrementer mult[aaaaaa7] shift[32] cpu[0]
> Mount-cache hash table entries: 512
> khelper used greatest stack depth: 7248 bytes left
> NET: Registered protocol family 16
>
> irq: irq 38 on host /soc8313@e0000000/pic@700 mapped to virtual irq 38
> khelper used greatest stack depth: 7216 bytes left
> Registering ipic with sysfs...
> khelper used greatest stack depth: 6736 bytes left
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> Generic PHY: Registered new driver
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Freescale Elo / Elo Plus DMA driver
> Switched to high resolution mode on CPU 0
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> NET: Registered protocol family 1
> Trying to unpack rootfs image as initramfs...
> rootfs image is not initramfs (no cpio magic); looks like an initrd
> Freeing initrd memory: 3722k freed
> irq: irq 9 on host /soc8313@e0000000/pic@700 mapped to virtual irq 16
> irq: irq 10 on host /soc8313@e0000000/pic@700 mapped to virtual irq 17
> WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (25 seconds)
> fsl-elo-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma
> controller at 0xe00082a8...
> irq: irq 71 on host /soc8313@e0000000/pic@700 mapped to virtual irq 71
> fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71
> khelper used greatest stack depth: 6624 bytes left
> JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
> msgmni has been set to 244
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
> brd: module loaded
> loop: module loaded
> irq: irq 37 on host /soc8313@e0000000/pic@700 mapped to virtual irq 37
> irq: irq 36 on host /soc8313@e0000000/pic@700 mapped to virtual irq 36
> irq: irq 35 on host /soc8313@e0000000/pic@700 mapped to virtual irq 35
> eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:01
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> irq: irq 34 on host /soc8313@e0000000/pic@700 mapped to virtual irq 34
> irq: irq 33 on host /soc8313@e0000000/pic@700 mapped to virtual irq 33
> irq: irq 32 on host /soc8313@e0000000/pic@700 mapped to virtual irq 32
> eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:02
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> Freescale PowerQUICC MII Bus: probed
> irq: irq 20 on host /soc8313@e0000000/pic@700 mapped to virtual irq 20
> Freescale PowerQUICC MII Bus: probed
> Marvell 88E1101: Registered new driver
> Marvell 88E1112: Registered new driver
> Marvell 88E1111: Registered new driver
> Marvell 88E1118: Registered new driver
> Marvell 88E1121R: Registered new driver
> Marvell 88E1145: Registered new driver
> Marvell 88E1240: Registered new driver
> Fixed MDIO Bus: probed
> fe000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> fe000000.flash: Swapping erase regions for broken CFI table.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> RedBoot partition parsing not available
> irq: irq 16 on host /soc8313@e0000000/pic@700 mapped to virtual irq 18
> e0007000.spi: MPC8xxx SPI Controller driver at 0xc9090000 (irq = 18)
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
> fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i2c /dev entries driver
> irq: irq 14 on host /soc8313@e0000000/pic@700 mapped to virtual irq 19
> rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
> irq: irq 15 on host /soc8313@e0000000/pic@700 mapped to virtual irq 21
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> rtc-ds1307 0-0068: setting system clock to 2001-04-09 16:29:22 UTC (986833762)
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing unused kernel memory: 148k init
> Setting the hostname to mpc8313erdb
> hostname used greatest stack depth: 6544 bytes left
> hostname used greatest stack depth: 6272 bytes left
> Mounting filesystems
> Running sysctl
> Setting up networking on loopback device:
>
> Warning: no IPADDR is set, please set this from the ltib
> config screen, or directly in /etc/rc.d/rc.conf.
> IP address setup bypassed
>
> Setting up networking on eth1:
> Adding static route for default gateway to 10.10.8.1:
> Setting nameserver to 10.10.1.15 in /etc/resolv.conf:
> Starting inetd:
> inetd used greatest stack depth: 6224 bytes left
>
>
> Welcome to Freescale Semiconductor Embedded Linux Environment
>
> !!!!! WARNING !!!!!!!
>
> The default password for the root account is: root
> please change this password using the 'passwd' command
> and then edit this message (/etc/issue) to remove this message
>
> mpc8313erdb login: PHY: mdio@e0024520:04 - Link is Up - 100/Full
>
>
> Welcome to Freescale Semiconductor Embedded Linux Environment
>
> !!!!! WARNING !!!!!!!
>
> The default password for the root account is: root
> please change this password using the 'passwd' command
> and then edit this message (/etc/issue) to remove this message
>
> mpc8313erdb login: root
> Password:
> login[862]: root login on `console'
>
> ~ # ping 10.10.8.167
> PING 10.10.8.167 (10.10.8.167): 56 data bytes
> NETDEV WATCHDOG: eth1 (fsl-gianfar): transmit queue 0 timed out
> ------------[ cut here ]------------
> Badness at net/sched/sch_generic.c:246
> NIP: c2254834 LR: c2254834 CTR: c21bc7f8
> REGS: c23fbcf0 TRAP: 0700 Not tainted (2.6.31.1)
> MSR: 00029032 <EE,ME,CE,IR,DR> CR: 24000022 XER: 20000000
> TASK = c23cf3e8[0] 'swapper' THREAD: c23fa000
> GPR00: c2254834 c23fbda0 c23cf3e8 00000046 00001d01 ffffffff c21b9dc0 00020000
> GPR08: 00000036 c23f97f4 00001d01 c2400ea0 44000082 00000000 07ffd000 00000001
> GPR16: c23d1ae8 c2350000 c23f8060 c23d1968 c23f8080 c2420000 c2420000 0000000a
> GPR24: c23fa000 00000000 c23d0000 c6dc11c0 c2400000 c23d0000 00000000 c6dc1000
> NIP [c2254834] dev_watchdog+0x298/0x2a8
> LR [c2254834] dev_watchdog+0x298/0x2a8
> Call Trace:
> [c23fbda0] [c2254834] dev_watchdog+0x298/0x2a8 (unreliable)
> [c23fbe00] [c20300cc] run_timer_softirq+0x158/0x1c8
> [c23fbe40] [c202ae90] __do_softirq+0xcc/0x1d4
> [c23fbe90] [c2006678] do_softirq+0x58/0x5c
> [c23fbea0] [c202acb4] irq_exit+0x48/0x58
> [c23fbeb0] [c200ea2c] timer_interrupt+0x12c/0x188
> [c23fbed0] [c201199c] ret_from_except+0x0/0x14
> --- Exception: 901 at cpu_idle+0x9c/0xe0
> LR = cpu_idle+0x9c/0xe0
> [c23fbf90] [c2009964] cpu_idle+0xd0/0xe0 (unreliable)
> [c23fbfb0] [c2003e58] rest_init+0x5c/0x84
> [c23fbfc0] [c23a883c] start_kernel+0x234/0x2bc
> [c23fbff0] [02003438] 0x2003438
> Instruction dump:
> 7c0903a6 4bfffe48 38810008 7fe3fb78 38a00040 4bfebe19 7fc6f378 7fe4fb78
> 7c651b78 3c60c238 3863101c 4bdd08f1 <0fe00000> 38000001 901c0b78 4bffff8c
>
>
>
>
>
>
> 3: if I setup uboot as ramdisk bott and setup both eth0 and eht1 interface, it
> will hang on just after login info was print out:
>
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.31.1
> Created: 2009-10-08 21:19:37 UTC
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1987293 Bytes = 1.9 MB
> Load Address: 02000000
> Entry Point: 02000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> ## Loading RAMDisk Image at 01000000 ...
> Image Name: uboot ext2 ramdisk rootfs
> Created: 2009-10-08 21:48:06 UTC
> Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
> Data Size: 3811870 Bytes = 3.6 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Booting using the fdt at 0x400000
> Loading Ramdisk to 07ba4000, end 07f46a1e ... OK
> Using MPC831x RDB machine description
> Linux version 2.6.31.1 (root@dtl-lap-desi2.dtlab.moriseiki.co.jp) (gcc version
> 4.1.2) #15 Thu Oct 8 14:19:30 PDT 2009
> Found initrd at 0xc7ba4000:0xc7f46a1e
> Found legacy serial port 0 for /soc8313@e0000000/serial@4500
> mem=e0004500, taddr=e0004500, irq=0, clk=166666665, speed=0
> Found legacy serial port 1 for /soc8313@e0000000/serial@4600
> mem=e0004600, taddr=e0004600, irq=0, clk=166666665, speed=0
> console [udbg0] enabled
> setup_arch: bootmem
> mpc831x_rdb_setup_arch()
> arch: exit
> Top of RAM: 0x8000000, Total RAM: 0x8000000
> Memory hole size: 0MB
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00008000
> Normal 0x00008000 -> 0x00008000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 0: 0x00000000 -> 0x00008000
> On node 0 totalpages: 32768
> free_area_init_node: node 0, pgdat c23f856c, node_mem_map c0010000
> DMA zone: 256 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 32512 pages, LIFO batch:7
> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
> Kernel command line: root=/dev/ram rw console=ttyS0,115200
> PID hash table entries: 512 (order: 9, 2048 bytes)
> Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
> Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
> Memory: 121524k/131072k available (3896k kernel code, 9392k reserved, 180k
> data, 347k bss, 148k init)
> Kernel virtual memory layout:
> * 0xffffe000..0xfffff000 : fixmap
> * 0xfdffc000..0xfe000000 : early ioremap
> * 0xc9000000..0xfdffc000 : vmalloc & ioremap
> Hierarchical RCU implementation.
> NR_IRQS:512
> IPIC (128 IRQ sources) at c9000700
> time_init: decrementer frequency = 41.666666 MHz
> time_init: processor frequency = 333.333330 MHz
> clocksource: timebase mult[6000002] shift[22] registered
> clockevent: decrementer mult[aaaaaa7] shift[32] cpu[0]
> Mount-cache hash table entries: 512
> khelper used greatest stack depth: 7248 bytes left
> NET: Registered protocol family 16
>
> irq: irq 38 on host /soc8313@e0000000/pic@700 mapped to virtual irq 38
> khelper used greatest stack depth: 7216 bytes left
> Registering ipic with sysfs...
> khelper used greatest stack depth: 7072 bytes left
> bio: create slab <bio-0> at 0
> SCSI subsystem initialized
> Generic PHY: Registered new driver
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Freescale Elo / Elo Plus DMA driver
> Switched to high resolution mode on CPU 0
> NET: Registered protocol family 2
> IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
> TCP established hash table entries: 4096 (order: 3, 32768 bytes)
> TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
> TCP: Hash tables configured (established 4096 bind 4096)
> TCP reno registered
> NET: Registered protocol family 1
> Trying to unpack rootfs image as initramfs...
> rootfs image is not initramfs (no cpio magic); looks like an initrd
> Freeing initrd memory: 3722k freed
> irq: irq 9 on host /soc8313@e0000000/pic@700 mapped to virtual irq 16
> irq: irq 10 on host /soc8313@e0000000/pic@700 mapped to virtual irq 17
> WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (25 seconds)
> khelper used greatest stack depth: 6752 bytes left
> khelper used greatest stack depth: 6688 bytes left
> fsl-elo-dma e00082a8.dma: Probe the Freescale DMA driver for fsl,elo-dma
> controller at 0xe00082a8...
> irq: irq 71 on host /soc8313@e0000000/pic@700 mapped to virtual irq 71
> fsl-elo-dma e00082a8.dma: #0 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #1 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #2 (fsl,elo-dma-channel), irq 71
> fsl-elo-dma e00082a8.dma: #3 (fsl,elo-dma-channel), irq 71
> JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
> msgmni has been set to 244
> alg: No test for stdrng (krng)
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> khelper used greatest stack depth: 6640 bytes left
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A
> brd: module loaded
> loop: module loaded
> irq: irq 37 on host /soc8313@e0000000/pic@700 mapped to virtual irq 37
> irq: irq 36 on host /soc8313@e0000000/pic@700 mapped to virtual irq 36
> irq: irq 35 on host /soc8313@e0000000/pic@700 mapped to virtual irq 35
> eth0: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:01
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> irq: irq 34 on host /soc8313@e0000000/pic@700 mapped to virtual irq 34
> irq: irq 33 on host /soc8313@e0000000/pic@700 mapped to virtual irq 33
> irq: irq 32 on host /soc8313@e0000000/pic@700 mapped to virtual irq 32
> eth1: Gianfar Ethernet Controller Version 1.2, 00:e0:0c:00:95:02
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> Freescale PowerQUICC MII Bus: probed
> irq: irq 20 on host /soc8313@e0000000/pic@700 mapped to virtual irq 20
> Freescale PowerQUICC MII Bus: probed
> Marvell 88E1101: Registered new driver
> Marvell 88E1112: Registered new driver
> Marvell 88E1111: Registered new driver
> Marvell 88E1118: Registered new driver
> Marvell 88E1121R: Registered new driver
> Marvell 88E1145: Registered new driver
> Marvell 88E1240: Registered new driver
> Fixed MDIO Bus: probed
> fe000000.flash: Found 1 x16 devices at 0x0 in 16-bit bank
> Amd/Fujitsu Extended Query Table at 0x0040
> fe000000.flash: Swapping erase regions for broken CFI table.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> RedBoot partition parsing not available
> irq: irq 16 on host /soc8313@e0000000/pic@700 mapped to virtual irq 18
> e0007000.spi: MPC8xxx SPI Controller driver at 0xc9090000 (irq = 18)
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
> fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
> fsl-ehci fsl-ehci.0: irq 38, io base 0xe0023000
> fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
> usb usb1: configuration #1 chosen from 1 choice
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 1 port detected
> Initializing USB Mass Storage driver...
> usbcore: registered new interface driver usb-storage
> USB Mass Storage support registered.
> i2c /dev entries driver
> irq: irq 14 on host /soc8313@e0000000/pic@700 mapped to virtual irq 19
> rtc-ds1307 0-0068: rtc core: registered ds1339 as rtc0
> irq: irq 15 on host /soc8313@e0000000/pic@700 mapped to virtual irq 21
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> rtc-ds1307 0-0068: setting system clock to 2001-04-09 16:17:27 UTC (986833047)
> RAMDISK: gzip image found at block 0
> VFS: Mounted root (ext2 filesystem) on device 1:0.
> Freeing unused kernel memory: 148k init
> Setting the hostname to mpc8313erdb
> hostname used greatest stack depth: 6544 bytes left
> [ used greatest stack depth: 6416 bytes left
> Mounting filesystems
> [ used greatest stack depth: 6304 bytes left
> Running sysctl
> Setting up networking on loopback device:
> ifconfig used greatest stack depth: 6000 bytes left
> Setting up networking on eth0:
> Adding static route for default gateway to 10.10.8.1:
> Setting nameserver to 10.10.1.15 in /etc/resolv.conf:
> Setting up networking on eth1:
> Adding static route for default gateway to 10.10.8.1:
> Setting nameserver to 10.10.1.15 in /etc/resolv.conf:
> Starting inetd:
>
>
> Welcome to Freescale Semiconductor Embedded Linux Environment
>
> !!!!! WARNING !!!!!!!
>
> The default password for the root account is: root
> please change this password using the 'passwd' command
> and then edit this message (/etc/issue) to remove this message
>
> mpc8313erdb login: PHY: 0:01 - Link is Up - 1000/Full
> PHY: mdio@e0024520:04 - Link is Up - 100/Full
> BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
> Modules linked in:
> NIP: c20551b8 LR: c2057520 CTR: c2015b20
> REGS: c23fdb50 TRAP: 0901 Not tainted (2.6.31.1)
> MSR: 00009032 <EE,ME,IR,DR> CR: 24000048 XER: 20000000
> TASK = c23d03e8[0] 'swapper' THREAD: c23fc000
> GPR00: 00009032 c23fdc00 c23d03e8 00000025 c7549520 00001032 c7401700 00000020
> GPR08: c22d4be6 c2400000 f2000087 c2428574 00000000
> NIP [c20551b8] handle_IRQ_event+0x34/0x1d0
> LR [c2057520] handle_level_irq+0x80/0x10c
> Call Trace:
> [c23fdc00] [c2055208] handle_IRQ_event+0x84/0x1d0 (unreliable)
> [c23fdc30] [c2057520] handle_level_irq+0x80/0x10c
> [c23fdc40] [c200672c] do_IRQ+0xb0/0xd8
> --- Exception: c20551b8 at gfar_schedule_cleanup+0x74/0xb0
> LR = gfar_receive+0x14/0x28
> [c23fdc60] [c201199c] ret_from_except+0x0/0x14 (unreliable)
> --- Exception: 501 at handle_IRQ_event+0x34/0x1d0
> LR = handle_level_irq+0x80/0x10c
> [c23fdd20] [c2055208] handle_IRQ_event+0x84/0x1d0 (unreliable)
> [c23fdd50] [c2057520] handle_level_irq+0x80/0x10c
> [c23fdd60] [c200672c] do_IRQ+0xb0/0xd8
> [c23fdd80] [c201199c] ret_from_except+0x0/0x14
> --- Exception: 501 at __do_softirq+0x70/0x1d4
> LR = do_softirq+0x58/0x5c
> [c23fde40] [c22410c4] __napi_schedule+0x30/0x58 (unreliable)
> [c23fde90] [c2006678] do_softirq+0x58/0x5c
> [c23fdea0] [c202acb4] irq_exit+0x48/0x58
> [c23fdeb0] [c2006730] do_IRQ+0xb4/0xd8
> [c23fded0] [c201199c] ret_from_except+0x0/0x14
> --- Exception: 501 at cpu_idle+0x9c/0xe0
> LR = cpu_idle+0x9c/0xe0
> [c23fdf90] [c2009964] cpu_idle+0xd0/0xe0 (unreliable)
> [c23fdfb0] [c2003e58] rest_init+0x5c/0x84
> [c23fdfc0] [c23a983c] start_kernel+0x234/0x2bc
> [c23fdff0] [02003438] 0x2003438
> Instruction dump:
> 7c0802a6 bf010010 7c9e2378 7c7d1b78 90010034 80040004 70090020 40820010
> 7c0000a6 60008000 7c000124 3d20c240 <3d60c240> 3b099020 3b2b9040 3b400000
> BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
>
^ permalink raw reply
* Re: [PATCH 2/2] net: smsc911x: allow platform_data to specify mac address
From: David Miller @ 2009-10-13 19:09 UTC (permalink / raw)
To: manuel.lauss; +Cc: netdev, steve.glendinning, manuel.lauss
In-Reply-To: <1255454749-26895-2-git-send-email-manuel.lauss@gmail.com>
From: Manuel Lauss <manuel.lauss@googlemail.com>
Date: Tue, 13 Oct 2009 19:25:49 +0200
> Extend the driver to accept a MAC address specified in platform_data.
>
> Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] e1000: Fix erroneous display of stats by ethtool -S
From: David Miller @ 2009-10-13 19:10 UTC (permalink / raw)
To: ajitk; +Cc: netdev, alexander.h.duyck, emil.s.tantilov, jeffrey.t.kirsher
In-Reply-To: <20091013114536.GA2276@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Tue, 13 Oct 2009 17:15:48 +0530
> Commit 23d26497 overlooked the way offsets for netdev stats were considered.
> Because of this some of the stats shown by ethtool -S were wrong.
> This patch fixes it.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] e1000e: Fix erroneous display of stats by ethtool -S
From: David Miller @ 2009-10-13 19:10 UTC (permalink / raw)
To: ajitk; +Cc: netdev, alexander.h.duyck, emil.s.tantilov, jeffrey.t.kirsher
In-Reply-To: <20091013114454.GA2246@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Tue, 13 Oct 2009 17:15:09 +0530
> Commit fd8235bb overlooked the way offsets for netdev stats were considered.
> Because of this some of the stats shown by ethtool -S were wrong.
> This patch fixes it.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] igb: Fix erroneous display of stats by ethtool -S
From: David Miller @ 2009-10-13 19:10 UTC (permalink / raw)
To: ajitk; +Cc: netdev, alexander.h.duyck, emil.s.tantilov, jeffrey.t.kirsher
In-Reply-To: <20091013114617.GA2296@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Tue, 13 Oct 2009 17:16:29 +0530
> Commit 337e067d overlooked the way offsets for netdev stats were considered.
> Because of this some of the stats shown by ethtool -S were wrong.
> This patch fixes it.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ixgb: Fix erroneous display of stats by ethtool -S
From: David Miller @ 2009-10-13 19:10 UTC (permalink / raw)
To: ajitk; +Cc: netdev, alexander.h.duyck, emil.s.tantilov, jeffrey.t.kirsher
In-Reply-To: <20091013114645.GA2453@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Tue, 13 Oct 2009 17:16:56 +0530
> Commit 5675f221 overlooked the way offsets for netdev stats were considered.
> Because of this some of the stats shown by ethtool -S were wrong.
> This patch fixes it.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next-2.6] ixgbe: Fix erroneous display of stats by ethtool -S
From: David Miller @ 2009-10-13 19:10 UTC (permalink / raw)
To: ajitk; +Cc: netdev, alexander.h.duyck, emil.s.tantilov, jeffrey.t.kirsher
In-Reply-To: <20091013114721.GA2671@serverengines.com>
From: Ajit Khaparde <ajitk@serverengines.com>
Date: Tue, 13 Oct 2009 17:17:33 +0530
> Commit 59aa3cc4 overlooked the way offsets for netdev stats were considered.
> Because of this some of the stats shown by ethtool -S were wrong.
> This patch fixes it.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] [RFC] Add c/r support for connected INET sockets
From: Dan Smith @ 2009-10-13 19:12 UTC (permalink / raw)
To: Oren Laadan
Cc: containers-qjLDD68F18O7TbgM5vRIOg, netdev-u79uwXL29TY76Z2rM5mHXA,
John Dykstra
In-Reply-To: <4AD4CE61.30503-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>
OL> IIRC, the TCP stack takes the timestamp for each packet directly
OL> from jiffies. So you need to teach TCP to add a per-container (or
OL> you can make it per-socket) delta to that timestamp.
After wondering what the heck you were talking about, I realized I
assumed you were talking about TCP timeouts and not timestamps :)
I assume you mean the following:
1. Put a absolute time stamp in the checkpoint stream
2. Calculate the delta between that and the current time on the
restoring host
3. Use that value to offset timestamps from that point on.
Correct?
Since I brought it up, do you agree that the retransmit timers should
be canonicalized to time-after checkpoint values? It occurs to me
that right now I restore a jiffies value on the receiving host which
is guaranteed to be incorrect :)
OL> So I'm thinking, for both, do (1) put a big fat comment in the
OL> code saying that sanity-tests are needed, and what for, and (2)
OL> send a separate mail to the networking people with these two
OL> scenarios and request comments ?
Yeah, although I would hope that they're seeing this conversation and
would chime in (hence the cc:netdev). Hopefully I don't have to
disguise a separate email as non-C/R related to get past their
filters! :)
OL> For example, now, if a user wants to send a TCP packet with
OL> arbitrary protocol parameters, he needs to use raw IP sockets,
OL> which require privilege. Would restarting a connection with the
OL> desired parameters become a way to bypass that restriction ?
OL> (e.g. assume the user restarts while using the host's network
OL> namespace).
Um, yeah? I don't see much way around that if we're going to trust
any of what is in the checkpoint stream. Perhaps we say CAP_NET_ADMIN
is required to restart a live TCP connection?
--
Dan Smith
IBM Linux Technology Center
email: danms-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org
^ permalink raw reply
* Re: [PATCH] cosa: Kill off the use of the old ioctl path
From: David Miller @ 2009-10-13 19:14 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20091013153045.20012.76202.stgit@localhost.localdomain>
From: Alan Cox <alan@linux.intel.com>
Date: Tue, 13 Oct 2009 16:30:46 +0100
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> ---
>
> drivers/message/i2o/i2o_config.c | 5 ++---
> drivers/net/wan/cosa.c | 18 ++++++++++++------
> 2 files changed, 14 insertions(+), 9 deletions(-)
I don't think you meant to put the I2O bits in here. :-)
Please fully resubmit this with that fixed up.
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] [RFC] Add c/r support for connected INET sockets
From: Oren Laadan @ 2009-10-13 19:35 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, netdev, John Dykstra
In-Reply-To: <87pr8rcdl0.fsf@caffeine.danplanet.com>
Dan Smith wrote:
> OL> IIRC, the TCP stack takes the timestamp for each packet directly
> OL> from jiffies. So you need to teach TCP to add a per-container (or
> OL> you can make it per-socket) delta to that timestamp.
>
> After wondering what the heck you were talking about, I realized I
> assumed you were talking about TCP timeouts and not timestamps :)
>
> I assume you mean the following:
>
> 1. Put a absolute time stamp in the checkpoint stream
> 2. Calculate the delta between that and the current time on the
> restoring host
> 3. Use that value to offset timestamps from that point on.
>
> Correct?
Sort of. Right now we already record the absolute time-of-checkpoint:
ctx->ktime_begin. The restart-blocks are saved relative to it. I'd
suggest the same for all time related data from the network - save it
in the checkpoint image as delta's compared to checkpoint time.
At restart, the restart-blocks are restored relative to restart-time,
using the saved delta. That would work for the TCP timestamps too.
>
> Since I brought it up, do you agree that the retransmit timers should
> be canonicalized to time-after checkpoint values? It occurs to me
> that right now I restore a jiffies value on the receiving host which
> is guaranteed to be incorrect :)
As for TCP timeouts - I don't think they matter that much in the case
of live migration, whether the timeout after restart happens in the
saved delta relative to original checkpoint-time, or new restart-time.
The difference is likely to be subsecond to a few seconds at most,
not important for most use-cases, I'd think.
(If we are concerned about a TCP hickup due to a migration, there are
tricks to work around it that; timeouts and retransmits are not the
best way to go, because once you get there you already slowed down
TCP significantly).
Here, too, once we have time virtualization this can be revisited, to
allow the user to choose a policy how to use the deltas.
>
> OL> So I'm thinking, for both, do (1) put a big fat comment in the
> OL> code saying that sanity-tests are needed, and what for, and (2)
> OL> send a separate mail to the networking people with these two
> OL> scenarios and request comments ?
>
> Yeah, although I would hope that they're seeing this conversation and
> would chime in (hence the cc:netdev). Hopefully I don't have to
> disguise a separate email as non-C/R related to get past their
> filters! :)
>
> OL> For example, now, if a user wants to send a TCP packet with
> OL> arbitrary protocol parameters, he needs to use raw IP sockets,
> OL> which require privilege. Would restarting a connection with the
> OL> desired parameters become a way to bypass that restriction ?
> OL> (e.g. assume the user restarts while using the host's network
> OL> namespace).
>
> Um, yeah? I don't see much way around that if we're going to trust
> any of what is in the checkpoint stream. Perhaps we say CAP_NET_ADMIN
> is required to restart a live TCP connection?
>
I don't see much way around that either. My point is to bring the issue
to everyone's attention, and see what others say about it.
CAP_NET_ADMIN is one option. CAP_NET_RAW is another option ?
Oren.
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: Greg KH @ 2009-10-13 19:51 UTC (permalink / raw)
To: Narendra_K
Cc: dannf, netdev, linux-hotplug, Matt_Domsch, Jordan_Hargrave,
Charles_Rose
In-Reply-To: <EDA0A4495861324DA2618B4C45DCB3EE58954D@blrx3m08.blr.amer.dell.com>
On Tue, Oct 13, 2009 at 10:43:49PM +0530, Narendra_K@Dell.com wrote:
>
> >> These device nodes are not functional at the moment - open() returns
> >> -ENOSYS. Their only purpose is to provide userspace with a kernel
> >> name to ifindex mapping, in a form that udev can easily manage.
> >
> >If the idea is just to provide a userspace-visible mapping
> >(and presumably take advantage of udev's infrastructure for
> >naming) does this need kernel changes? Could this be a
> >hierarchy under e.g. /etc/udev instead, using plain text
> >files? It still means we need something like libnetdevname for
> >apps to do the translation, but I'm not seeing why it matters
> >how this map is stored. Is there some special property of the
> >character devices (e.g. uevents) that we're not already
> >getting with the existing interfaces?
>
> Yes. The char device by itself doesn't help in any way. But it provides
> a flexible mechanism to provide multiple names for the same device, just
> the way it is for disks.
No, it's quite different than disks in that the symlinks, _and_ the
device nodes do absolutly nothing. And any reference to a name that is
a symlink will not work with any existing network tool, you will have to
do some kind of lookup to determine which network device you really were
referring to.
These links end up being useless, and confusing, I still don't see how
you can use them for anything.
thanks,
greg k-h
^ permalink raw reply
* Re: PATCH: Network Device Naming mechanism and policy
From: John W. Linville @ 2009-10-13 19:53 UTC (permalink / raw)
To: Ben Hutchings
Cc: Dan Williams, Bill Nottingham, Scott James Remnant, Matt Domsch,
Narendra K, netdev, linux-hotplug, jordan_hargrave
In-Reply-To: <1255459984.13438.2.camel@achroite>
On Tue, Oct 13, 2009 at 07:53:04PM +0100, Ben Hutchings wrote:
> On Tue, 2009-10-13 at 11:06 -0700, Dan Williams wrote:
> > And if we really want seamless support for MAC spoofing, we want
> > ETHTOOL_GPERMADDR for all drivers too, so that if your configuration
> > says "rename device XX:XX:XX:XX:XX:XX to YY:YY:YY:YY:YY:YY" we can
> > actually figure stuff out after the spoof.
>
> ETHTOOL_GPERMADDR is handled in the ethtool core now. Are you thinking
> of drivers that don't have ethtool ops? Maybe it's time to add default
> operations.
Not quite true -- dev->perm_addr still has to be set by the driver.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* RE: PATCH: Network Device Naming mechanism and policy
From: Jordan_Hargrave @ 2009-10-13 20:00 UTC (permalink / raw)
To: greg, Narendra_K; +Cc: dannf, netdev, linux-hotplug, Matt_Domsch, Charles_Rose
In-Reply-To: <20091013195117.GA3778@kroah.com>
We have developed a mapping library that will convert the user-friendly symlink names to the kernel names necessary for socket ioctls. All network tools that normally take ethX as argument have been modified to use this mapping library. Usually it's just a one-line addition when parsing the command line arguments.
--jordan hargrave
Dell Enterprise Linux Engineering
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Tue 10/13/2009 14:51
To: K, Narendra
Cc: dannf@hp.com; netdev@vger.kernel.org; linux-hotplug@vger.kernel.org; Domsch, Matt; Hargrave, Jordan; Rose, Charles
Subject: Re: PATCH: Network Device Naming mechanism and policy
On Tue, Oct 13, 2009 at 10:43:49PM +0530, Narendra_K@Dell.com wrote:
>
> >> These device nodes are not functional at the moment - open() returns
> >> -ENOSYS. Their only purpose is to provide userspace with a kernel
> >> name to ifindex mapping, in a form that udev can easily manage.
> >
> >If the idea is just to provide a userspace-visible mapping
> >(and presumably take advantage of udev's infrastructure for
> >naming) does this need kernel changes? Could this be a
> >hierarchy under e.g. /etc/udev instead, using plain text
> >files? It still means we need something like libnetdevname for
> >apps to do the translation, but I'm not seeing why it matters
> >how this map is stored. Is there some special property of the
> >character devices (e.g. uevents) that we're not already
> >getting with the existing interfaces?
>
> Yes. The char device by itself doesn't help in any way. But it provides
> a flexible mechanism to provide multiple names for the same device, just
> the way it is for disks.
No, it's quite different than disks in that the symlinks, _and_ the
device nodes do absolutly nothing. And any reference to a name that is
a symlink will not work with any existing network tool, you will have to
do some kind of lookup to determine which network device you really were
referring to.
These links end up being useless, and confusing, I still don't see how
you can use them for anything.
thanks,
greg k-h
^ 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