* Re: Poor HVM performance with 8 vcpus
From: Juergen Gross @ 2009-10-07 11:45 UTC (permalink / raw)
To: George Dunlap
Cc: Ian Pratt, xen-devel@lists.xensource.com, Tim Deegan,
James Harper
In-Reply-To: <de76405a0910070311q6c879be0wd4f33d8108235d8b@mail.gmail.com>
George Dunlap wrote:
> Jeurgen,
>
> I think this problem is a good candidate for xentrace/xenalyze. If
> you take a 30-second trace (xentrace -D -e all -T 30
> /tmp/[traceid].trace) while the benchmark is at its heaviest, and then
> analyze it using xenalyze
> (http://xenbits.xensource.com/ext/xenalyze.hg), it should show up
> whether the shadow performance is due to brute-force search or
> something else.
>
> If you're using 3.3, you'll have to apply the back-patch to xenalyze
> to make it work properly.
Patches don't apply cleanly, build fails with error even without patches due
to incorrect format strings.
Juergen
--
Juergen Gross Principal Developer Operating Systems
TSP ES&S SWE OS6 Telephone: +49 (0) 89 636 47950
Fujitsu Technolgy Solutions e-mail: juergen.gross@ts.fujitsu.com
Otto-Hahn-Ring 6 Internet: ts.fujitsu.com
D-81739 Muenchen Company details: ts.fujitsu.com/imprint.html
^ permalink raw reply
* Kernel update to 2.6.31.1 on pxa270: udev and usb storage cause kernel Oops
From: hoefle marco @ 2009-10-07 11:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20091005225222.GB792@kroah.com>
On Mon, 2009-10-05 at 15:52 -0700, Greg KH wrote:
> On Sat, Oct 03, 2009 at 01:48:32PM +0100, Russell King - ARM Linux wrote:
> > I think you need to report this to the USB/udev people.
> >
> > On Tue, Sep 29, 2009 at 10:39:22AM +0200, hoefle marco wrote:
> > > Hello,
> > > we use Kernel 2.6.30.4 on a PXA270 platform (from Phytec). It works good
> > > with all peripherals on the Phytec board.
> > > For an old Sandisk device (diskonchip) we have a driver ported to 2.6.3x
> > > as the block device driver API has changed. We thought it will be a wise
> > > decision to do the porting already to 2.6.3x.
> > > However, when using the latest Kernel (and the previous one 2.6.30) with
> > > all the drivers we used in 2.6.30.4 udev and usb storage seem not to
> > > work any more.
> > > Does anybody have an idea why?
It looks that more things which worked with 2.6.30.4 do not work with
the latest stable 2.6.31.2 kernel. I get also a Kernel oops when
rebooting the system.
What I did to get there:
I disabled udevd and made the important device nodes static. This
allowed to boot into the system. I also disabled unnecessary things like
USB support and the tffs disk-on-chip driver.
Starting udevd manually does cause the same kernel oops as described at
the beginning of this thread.
In addition I get that oops when rebooting the system:
/ # reboot
The system is going down NOW!
Sending SIGTERM to all processes
Sending SIGKILL to all processes
Requesting system reboot
Unable to handle kernel paging request at virtual address 20726590
pgd = c39a0000
[20726590] *pgd=00000000
Internal error: Oops: f5 [#2]
Modules linked in:
CPU: 0 Tainted: G D (2.6.31.2 #3)
PC is at device_shutdown+0x34/0xbc
LR is at kernel_restart_prepare+0x2c/0x3c
pc : [<c0159314>] lr : [<c00466b0>] psr: 20000013
sp : c39c9e4c ip : c39c9e64 fp : c39c9e60
r10: 40025000 r9 : c39c8000 r8 : c0022064
r7 : 00000000 r6 : fee1dead r5 : c02f5ca0 r4 : 3d207955
r3 : 20726570 r2 : c3802c60 r1 : c001e308 r0 : c001e308
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0000397f Table: a39a0000 DAC: 00000015
Process init (pid: 456, stack limit = 0xc39c8270)
Stack: (0xc39c9e4c to 0xc39ca000)
9e40: 00000000 28121969 c39c9e70 c39c9e64
c00466b0
9e60: c01592ec c39c9e84 c39c9e74 c0046700 c0046690 01234567 c39c9fa4
c39c9e88
9e80: c0046820 c00466f8 c389a1ec 00000001 c389a0d8 c39c9eb8 c39c9ea4
c0032d38
9ea0: c0032c10 00000005 bd05720b 0087e0c1 00000000 c389a10c c389a0e0
00000000
9ec0: c389a0e0 c389a1ec 00000001 c389a0d8 c39c9f00 c39c9ee0 c0033914
c003199c
9ee0: 00000000 c383f0d4 c02cbba0 c39c9f20 c39c9efc c004f6dc c00261a4
c39d001c
9f00: c389a0e0 00000015 c389a0e0 c389a1ec c383f0a0 c39c9f34 c39c9f24
c004f7b4
9f20: c004f6b4 00000000 c39c9f68 c39c9f38 c0021e80 c004f7a0 c389a268
c39c8000
9f40: 00000011 c389a0e0 c39c9f6c c389a1ec c389a1ec 00000001 c389a0d8
c39c9f80
9f60: c39c9f6c c003ad84 c022a2b8 c39c9f6c c39c9f6c c39c9f94 c39c9f84
c003ae48
9f80: c003a800 c39c8000 00000000 00000000 00000000 00000058 00000000
c39c9fa8
9fa0: c0021ec0 c0046758 00000000 00000000 fee1dead 28121969 01234567
00000000
9fc0: 00000000 00000000 00000000 000c3c20 00000000 00000001 40025000
00000064
9fe0: 000c3418 befb3a70 00092364 4015c01c 60000010 fee1dead 00000000
00000000
Backtrace:
[<c01592e0>] (device_shutdown+0x0/0xbc) from [<c00466b0>]
(kernel_restart_prepare+0x2c/0x3c)
r5:28121969 r4:00000000
[<c0046684>] (kernel_restart_prepare+0x0/0x3c) from [<c0046700>]
(kernel_restart+0x14/0x48)
[<c00466ec>] (kernel_restart+0x0/0x48) from [<c0046820>] (sys_reboot
+0xd4/0x1ac)
r4:01234567
[<c004674c>] (sys_reboot+0x0/0x1ac) from [<c0021ec0>] (ret_fast_syscall
+0x0/0x2c)
r7:00000058 r6:00000000 r5:00000000 r4:00000000
Code: ea00000f e5913040 e3530000 0a000002 (e5933020)
---[ end trace c0e3a36da3f952db ]---
^ permalink raw reply
* [Buildroot] [PATCH 12/23] qt: respect silent mode instead non existing verbose mode
From: Thomas Petazzoni @ 2009-10-07 11:46 UTC (permalink / raw)
To: buildroot
In-Reply-To: <87ljjnmojl.fsf@macbook.be.48ers.dk>
Le Wed, 07 Oct 2009 13:27:58 +0200,
Peter Korsgaard <jacmet@uclibc.org> a ?crit :
> Maybe this would be a good subject for the dev day?
Definetely. I was anyway planning to present my proposal of a very
silent Buildroot mode (presented a few weeks ago on the list with a
prototype proposal), so this will be on the list of topics to discuss.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [v7 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Balbir Singh @ 2009-10-07 11:47 UTC (permalink / raw)
To: Vaidyanathan Srinivasan
Cc: linux-arch, Peter Zijlstra, Gautham R Shenoy, Venkatesh Pallipadi,
linux-kernel, Paul Mackerras, arun, Ingo Molnar, linuxppc-dev,
Arjan van de Ven
In-Reply-To: <20091007112648.GC7646@dirshya.in.ibm.com>
* Vaidy <svaidy@linux.vnet.ibm.com> [2009-10-07 16:56:48]:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-10-06 20:04:39]:
>
> > On Tue, 2009-10-06 at 22:05 +0530, Arun R Bharadwaj wrote:
> >
> > > Also, the per-cpu nature of registration/unregistration of cpuidle
> > > has been maintained as ACPI needs this.
> >
> > Right, so can't we ditch that and have acpi default to the lowest common
> > C-state and warn when various cpus report different C-states?
>
> Hi Peter,
>
> As Arjan mentioned previously, the per-cpu registration has to stay
> for x86 for now due to legacy ACPI compatibility. Breaking that may
> break lot of existing users and we do not have a clean fallback
> method.
>
> As far as powerpc is concerned, we can work with a single global
> registration. However we would like to have the same interface across
> different archs.
>
> With the new re-factoring (v7), Arun has killed most of the list
> traversal and linking between various cpu's cpuidle_driver structures.
> Now we have a per-cpu stack of registered devices and we lookup the
> structs using online cpumasks. The cpuidle_driver structure has list
> of idle routing pointers (struct cpuidle_state) and rest of it is
> statistics that needs to be maintained at a per-cpu level anyway. All
> that is duplicated here is the array of idle routines (struct
> cpuidle_state) on each cpu.
>
> The objective of the refactoring is to have a single common idle
> routine management framework (remove pm_idle) and we have it done
> through cpuidle registration framework. We can incrementally remove
> the per-cpu registration later easily by splitting the cpuidle_driver
> structure.
>
Yes, incremental refactoring makes the most sense from the do not
break as you refactor point of view.
--
Balbir
^ permalink raw reply
* netconf notes and materials
From: David Miller @ 2009-10-07 11:47 UTC (permalink / raw)
To: netdev
Just a note that all of the available notes and slide etc.
materials are available for netconf2009 at:
http://vger.kernel.org/netconf2009.html
Enjoy.
^ permalink raw reply
* Re: dom0 crash with unstable
From: Jan Beulich @ 2009-10-07 11:47 UTC (permalink / raw)
To: Jeremy Fitzhardinge, Bryan D. Payne; +Cc: xen-devel, Keir Fraser
In-Reply-To: <4ACB9C62.9030705@goop.org>
>>> Jeremy Fitzhardinge <jeremy@goop.org> 06.10.09 21:37 >>>
>On 10/06/09 12:02, Bryan D. Payne wrote:
>> Just Xen. Should it go to both?
>>
>
>Yeah, they need to agree what interrupt model they're using. Still
>shouldn't crash, regardless.
Not really - Xen automatically passes noapic to the kernel when it had
been passed that option (see the dom0_cmdline handling in
__start_xen()).
Jan
^ permalink raw reply
* [PATCH 2/9] collie: prepare for gpiolib use
From: Lothar Waßmann @ 2009-10-07 11:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20091007112552.GC6246@n2100.arm.linux.org.uk>
Russell King - ARM Linux writes:
> On Wed, Oct 07, 2009 at 03:08:05PM +0400, Dmitry Artamonow wrote:
> > On 23:35 Mon 05 Oct , Thomas Kunze wrote:
> > > prefix gpio definitions for direct register access with '_' so we
> > > can use the other names for gpio_request & co
> >
> > Familiar problem - numeric vs bit-shifted gpio defines.
> > I'm facing it here too while converting h3[16]00 to gpiolib,
> > and I'm thinking about dropping bit-shifted defines completely
> > and using GPIO_GPIO(SOME_NUMERIC_GPIO) instead.
>
> What we did with PXA was to decide not to use definitions for the built-in
> GPIOs - what's the point of:
>
> #define GPIO0 0
> #define GPIO1 1
> #define GPIO2 2
> ...
>
A point could be that 'grep GPIO0 ...' would find any usage of that
GPIO in the kernel source while 'grep 0 ...' would be quite
pointless.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* Re: [v7 PATCH 0/7]: cpuidle/x86/POWER: Cleanup idle power management code in x86, cleanup drivers/cpuidle/cpuidle.c and introduce cpuidle to POWER.
From: Balbir Singh @ 2009-10-07 11:47 UTC (permalink / raw)
To: Vaidyanathan Srinivasan
Cc: Peter Zijlstra, Arjan van de Ven, arun, Joel Schopp,
Benjamin Herrenschmidt, Paul Mackerras, Ingo Molnar,
Dipankar Sarma, Gautham R Shenoy, Venkatesh Pallipadi,
linux-kernel, linuxppc-dev, linux-arch
In-Reply-To: <20091007112648.GC7646@dirshya.in.ibm.com>
* Vaidy <svaidy@linux.vnet.ibm.com> [2009-10-07 16:56:48]:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2009-10-06 20:04:39]:
>
> > On Tue, 2009-10-06 at 22:05 +0530, Arun R Bharadwaj wrote:
> >
> > > Also, the per-cpu nature of registration/unregistration of cpuidle
> > > has been maintained as ACPI needs this.
> >
> > Right, so can't we ditch that and have acpi default to the lowest common
> > C-state and warn when various cpus report different C-states?
>
> Hi Peter,
>
> As Arjan mentioned previously, the per-cpu registration has to stay
> for x86 for now due to legacy ACPI compatibility. Breaking that may
> break lot of existing users and we do not have a clean fallback
> method.
>
> As far as powerpc is concerned, we can work with a single global
> registration. However we would like to have the same interface across
> different archs.
>
> With the new re-factoring (v7), Arun has killed most of the list
> traversal and linking between various cpu's cpuidle_driver structures.
> Now we have a per-cpu stack of registered devices and we lookup the
> structs using online cpumasks. The cpuidle_driver structure has list
> of idle routing pointers (struct cpuidle_state) and rest of it is
> statistics that needs to be maintained at a per-cpu level anyway. All
> that is duplicated here is the array of idle routines (struct
> cpuidle_state) on each cpu.
>
> The objective of the refactoring is to have a single common idle
> routine management framework (remove pm_idle) and we have it done
> through cpuidle registration framework. We can incrementally remove
> the per-cpu registration later easily by splitting the cpuidle_driver
> structure.
>
Yes, incremental refactoring makes the most sense from the do not
break as you refactor point of view.
--
Balbir
^ permalink raw reply
* Re: CGFreak control group visualizer
From: Balbir Singh @ 2009-10-07 11:48 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux kernel, Jonathan Corbet
In-Reply-To: <63386a3d0910070403k1d1e6d56xa46d95d2ff448b2a@mail.gmail.com>
* Linus Walleij <linus.ml.walleij@gmail.com> [2009-10-07 13:03:30]:
> 2009/10/7 Balbir Singh <balbir@linux.vnet.ibm.com>:
>
> > I looked at the screenshots and they look very interesting. Would it
> > take a lot of effort to extend it to track other controllers like
> > memory, network, etc?
>
> No I don't think that'd be a problem if you can just come up with some
> proper visualization idea.
>
> Memory can probably be a piechart as well, representing the physical memory
> (I think Matt already has some support for offline-generation of such charts in
> smem but this could be interactive, on-the-fly.)
>
Yeah.. that is a challenge, I tried running the visulation and it
seems to be quite heavy on the CPU and in my case with several
hundreds of process and several threads per process, the output
stopped making sense at some point. I'll play a bit more with it.
> Network bandwidth is harder I think because I don't know how these interfaces
> look if you want to measure throughput also (alottment would be easy to draw
> as a pie chart).
>
> Patches welcome :-)a
:)
>
> Linus Walleij
--
Balbir
^ permalink raw reply
* Problem in booting off a pxa270 board
From: Saurabh Kadekodi @ 2009-10-07 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <967093cd0910070357w2c603fefn5ea386f6c6c757e5@mail.gmail.com>
Hi All,
I have pxa270 based board, and I've just recently put an
emdebian-crush root filesystem image on it. On booting the board I get
upto the point where it starts init and then it fails for some
subsequent processes.
I would be grateful if someone could enlighten why this could be happening.
Here's the bootup log:
RedBoot> clock -L 16 -N 5
RedBoot> mount -t jffs2 -f filesystem
RedBoot> load -r -b %{FREEMEMLO} %{kernel}
Using default protocol (file)
Raw file loaded 0x00400000-0x004d0df7, assumed entry at 0x00400000
RedBoot> exec -c %{cmdline}
Using base address 0x00400000 and length 0x000d0df8
Uncompressing Linux.........................................................
done, booting the kernel.
Linux version 2.6.16.28(gcc version 3.4.4) #1 Wed Apr 25 15:39:08 BST 2007
CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
Memory policy: ECC disabled, Data cache writeback
Run Mode clock: 208.00MHz (*16)
Turbo Mode clock: 520.00MHz (*2.5, active)
Memory clock: 208.00MHz (/2)
System bus clock: 208.00MHz
CPU0: D VIVT undefined 5 cache
CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
Built 1 zonelists
Kernel command line: console=ttyS0,115200 rootfstype=jffs2
root=/dev/mtdblock1 ro
Map ISA IRQ 3 to IRQ 160
Map ISA IRQ 4 to IRQ 161
Map ISA IRQ 5 to IRQ 162
Map ISA IRQ 6 to IRQ 163
Map ISA IRQ 7 to IRQ 164
Map ISA IRQ 10 to IRQ 165
Map ISA IRQ 11 to IRQ 166
Map ISA IRQ 12 to IRQ 167
PID hash table entries: 1024 (order: 10, 16384 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 64MB 64MB = 128MB total
Memory: 127856KB available (1416K code, 301K data, 64K init)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
NetWinder Floating Point Emulator V0.97 (double precision)
JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc.
Initializing Cryptographic API
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver $Revision: 1.90 $ 64 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x10000000 (irq = 41) is a 16550A
serial8250.0: ttyS1 at MMIO 0x10800000 (irq = 42) is a 16550A
serial8250.0: ttyS2 at MMIO 0x11000000 (irq = 44) is a 16550A
serial8250.0: ttyS3 at MMIO 0x11800000 (irq = 43) is a 16550A
serial8250.0: ttyS4 at MMIO 0x40100000 (irq = 22) is a XScale
serial8250.0: ttyS5 at MMIO 0x40200000 (irq = 21) is a XScale
serial8250.0: ttyS6 at MMIO 0x40700000 (irq = 20) is a XScale
dm9000 Ethernet Driver
eth0: dm9000 at d485a000,d485c002 IRQ 46 MAC: 00:80:66:10:d2:32
eth1: dm9000 at d485e000,d4860002 IRQ 145 MAC: 00:80:66:10:d2:33
flash: Found 1 x16 devices at 0x0 in 16-bit bank
?Amd/Fujitsu Extended Query Table at 0x0040
flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
cmdlinepart partition parsing not available
Searching for RedBoot partition table in flash at offset 0x1fe0000
4 RedBoot partitions found on MTD device flash
Creating 4 MTD partitions on "flash":
0x00000000-0x00040000 : "RedBoot"
0x00040000-0x01fe0000 : "filesystem"
0x01fe0000-0x01fff000 : "FIS directory"
0x01fff000-0x02000000 : "RedBoot config"
i2c /dev entries driver
I2C: i2c-0: PXA I2C adapter
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (jffs2 filesystem) readonly.
Freeing init memory: 64K
init started: BusyBox v1.11.1 (2008-08-08 18:56:00 ART)
starting pid 223, tty '': '/etc/init.d/rcS'
process '/sbin/syslogd -n -m 0' (pid 234) exited. Scheduling for restart.
process '/usr/bin/tail -f /var/log/messages' (pid 236) exited.
Scheduling for restart.
process '/sbin/syslogd -n -m 0' (pid 247) exited. Scheduling for restart.
process '/usr/bin/tail -f /var/log/messages' (pid 248) exited.
Scheduling for restart.
process '/sbin/syslogd -n -m 0' (pid 253) exited. Scheduling for restart.
process '/usr/bin/tail -f /var/log/messages' (pid 254) exited.
Scheduling for restart.
process '/sbin/syslogd -n -m 0' (pid 259) exited. Scheduling for restart.
process '/usr/bin/tail -f /var/log/messages' (pid 260) exited.
Scheduling for restart.
process '/sbin/syslogd -n -m 0' (pid 265) exited. Scheduling for restart.
process '/usr/bin/tail -f /var/log/messages' (pid 266) exited.
Scheduling for restart.
This latter part then keeps on recurring indefinately.
Thanks in advance,
Saurabh
^ permalink raw reply
* [U-Boot] unable to configure eth0 on DM6446 using filesystem
From: rohan tabish @ 2009-10-07 11:53 UTC (permalink / raw)
To: u-boot
Hye guys
i am trying to put linux on my custom board DM6446.I am done with the UBL,U-BOOT ,uImage(kernel) and the filesystem.
Have refrred the busybox as my file system.I am using the open source code from git.Here is what i get
## Booting kernel from Legacy Image at 80000000 ...?????????????????????????????
?? Image Name:?? Linux-2.6.31-rc5-davinci1??????????????????????????????????????
?? Image Type:?? ARM Linux Kernel Image
(uncompressed)??????????????????????????
?? Data Size:??? 1542436 Bytes =? 1.5 MB????????????????????????????????????????
?? Load Address: 80008000???????????????????????????????????????????????????????
?? Entry Point:?
80008000???????????????????????????????????????????????????????
?? Verifying Checksum ... OK????????????????????????????????????????????????????
?? Loading Kernel Image ...
OK??????????????????????????????????????????????????
OK??????????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
Starting kernel ...?????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
Uncompressing Linux..............................................................
Linux version 2.6.31-rc5-davinci1 (root at localhost.localdomain) (gcc version 4.2.9
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177???????????????????
CPU: VIVT data cache, VIVT instruction
cache????????????????????????????????????
Machine: DaVinci DM644x EVM?????????????????????????????????????????????????????
Memory policy: ECC disabled, Data cache writeback???????????????????????????????
DaVinci dm6446a variant
0x1?????????????????????????????????????????????????????
Built 1 zonelists in Zone order, mobility grouping on.? Total pages: 30480??????
Kernel command line: console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x81600000,M
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: 120MB = 120MB total?????????????????????????????????????????????????????
Memory: 108116KB available (2856K code, 300K data, 124K init, 0K highmem)???????
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1?????????
NR_IRQS:229?????????????????????????????????????????????????????????????????????
Console: colour dummy device 80x30??????????????????????????????????????????????
Calibrating delay loop... 147.86 BogoMIPS (lpj=739328)??????????????????????????
Mount-cache hash table entries: 512?????????????????????????????????????????????
CPU: Testing write buffer coherency: ok?????????????????????????????????????????
DaVinci: 71 gpio
irqs???????????????????????????????????????????????????????????
NET: Registered protocol family 16??????????????????????????????????????????????
WARNING: both IDE and Flash are enabled, but they share AEMIF pins.?????????????
??????? Disable IDE for NAND/NOR
support.???????????????????????????????????????
MUX: Setting register HPIEN_DISABLE?????????????????????????????????????????????
?????????? PINMUX0 (0x00000000) = 0x80000c1f -> 0x80000c1f??????????????????????
MUX: initialized
ATAEN??????????????????????????????????????????????????????????
MUX: Setting register ATAEN?????????????????????????????????????????????????????
?????????? PINMUX0 (0x00000000) = 0x80000c1f -> 0x80020c1f??????????????????????
MUX:
initialized HDIREN?????????????????????????????????????????????????????????
MUX: Setting register HDIREN????????????????????????????????????????????????????
?????????? PINMUX0 (0x00000000) = 0x80020c1f -> 0x80030c1f??????????????????????
MUX:
initialized MCBSP??????????????????????????????????????????????????????????
MUX: Setting register MCBSP?????????????????????????????????????????????????????
?????????? PINMUX1 (0x00000004) = 0x00000081 -> 0x00000481??????????????????????
bio: create slab <bio-0> at 0???????????????????????????????????????????????????
pcf857x: probe of 1-0038 failed with error -121?????????????????????????????????
pcf857x: probe of 1-0039 failed with error -121?????????????????????????????????
pcf857x: probe of 1-003a failed with error
-121?????????????????????????????????
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 (junk in compressed archive); looks like an initrd
Freeing initrd memory:
10240K???????????????????????????????????????????????????
msgmni has been set to 231??????????????????????????????????????????????????????
io scheduler noop
registered????????????????????????????????????????????????????
io scheduler anticipatory registered (default)??????????????????????????????????
Setting Up Clocks for DM420 OSD?????????????????????????????????????????????????
Console: switching to colour frame buffer device
90x30??????????????????????????
fb0: dm_osd0_fb frame buffer device?????????????????????????????????????????????
fb1: dm_vid0_fb frame buffer device?????????????????????????????????????????????
fb2: dm_osd1_fb frame buffer
device?????????????????????????????????????????????
fb3: dm_vid1_fb frame buffer device?????????????????????????????????????????????
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled????????????????????????
Platform driver 'serial8250' needs updating - please use dev_pm_ops?????????????
serial8250.0: ttyS0
at MMIO 0x1c20000 (irq = 40) is a 16550A????????????????????
console [ttyS0] enabled?????????????????????????????????????????????????????????
serial8250 serial8250.0: unable to register port at index 1 (IO0 MEM1c20400 IRQ42
serial8250 serial8250.0: unable to register port at index 2 (IO0 MEM1c20800 IRQ42
brd: module
loaded??????????????????????????????????????????????????????????????
at24 1-0050: 32768 byte 24c256 EEPROM (writable)????????????????????????????????
davinci_emac_probe: using random MAC addr: 9a:c3:b8:e1:ad:db????????????????????
emac-mii:
probed????????????????????????????????????????????????????????????????
Fixed MDIO Bus: probed??????????????????????????????????????????????????????????
Platform driver 'smc91x' needs updating - please use dev_pm_ops?????????????????
Platform driver 'smc911x'
needs updating - please use dev_pm_ops????????????????
dm9000 Ethernet Driver, V1.31???????????????????????????????????????????????????
Platform driver 'dm9000' needs updating - please use dev_pm_ops?????????????????
console [netcon0]
enabled???????????????????????????????????????????????????????
netconsole: network logging started?????????????????????????????????????????????
i2c /dev entries
driver?????????????????????????????????????????????????????????
TCP cubic registered????????????????????????????????????????????????????????????
NET: Registered protocol family
17??????????????????????????????????????????????
RPC: Registered udp transport module.???????????????????????????????????????????
RPC: Registered tcp transport module.???????????????????????????????????????????
Clocks: disable unused
uart1????????????????????????????????????????????????????
Clocks: disable unused uart2????????????????????????????????????????????????????
Clocks: disable unused
ide??????????????????????????????????????????????????????
Clocks: disable unused asp0?????????????????????????????????????????????????????
Clocks: disable unused
mmcsd????????????????????????????????????????????????????
Clocks: disable unused spi??????????????????????????????????????????????????????
Clocks: disable unused
usb??????????????????????????????????????????????????????
Clocks: disable unused vlynq????????????????????????????????????????????????????
Clocks: disable unused
pwm0?????????????????????????????????????????????????????
Clocks: disable unused pwm1?????????????????????????????????????????????????????
Clocks: disable unused
pwm2?????????????????????????????????????????????????????
Clocks: disable unused timer1???????????????????????????????????????????????????
RAMDISK: ext2 filesystem found at block 0???????????????????????????????????????
RAMDISK: Loading
7000KiB [1 disk] into ram disk... done.????????????????????????
VFS: Mounted root (ext2 filesystem) on device 1:0.??????????????????????????????
Freeing init memory: 124K???????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
??? System initialization...????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
??? Hostname?????? : OMAP3EVM???????????????????????????????????????????????????
??? Filesystem???? :
v1.0.0?????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
??? Kernel release : Linux 2.6.31-rc5-davinci1??????????????????????????????????
??? Kernel version : #1 PREEMPT Mon Oct 5 09:45:44 PKT 2009?????????????????????
????????????????????????????????????????????????????????????????????????????????
?Mounting /proc???????????? : [SUCCESS]?????????????????????????????????????????
?Mounting /sys????????????? :
[SUCCESS]?????????????????????????????????????????
?Mounting /dev????????????? : [SUCCESS]?????????????????????????????????????????
?Mounting /dev/pts????????? : [SUCCESS]?????????????????????????????????????????
?Enabling hot-plug????????? : [SUCCESS]?????????????????????????????????????????
?Populating /dev??????????? : [SUCCESS]?????????????????????????????????????????
?Mounting other filesystems :
[SUCCESS]?????????????????????????????????????????
?Starting syslogd?????????? : [SUCCESS]?????????????????????????????????????????
?Starting telnetd?????????? : [SUCCESS]?????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
System initialization complete.?????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
Please press Enter to activate this console.
# ifconfig -a???????????????????????????????????????????????????????????????????
eth0????? Link encap:Ethernet? HWaddr 00:00:00:00:00:00?????????????????????????
????????? BROADCAST MULTICAST? MTU:1500? Metric:1???????????????????????????????
????????? RX packets:0 errors:0 dropped:0 overruns:4294967295 frame:4294967291??
????????? TX packets:0 errors:0 dropped:0 overruns:4294967295 carrier:4294967295
????????? collisions:4294967293
txqueuelen:1000?????????????????????????????????
????????? RX bytes:0 (0.0 B)? TX bytes:0 (0.0 B)????????????????????????????????
????????? Interrupt:13??????????????????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
lo??????? Link encap:Local Loopback?????????????????????????????????????????????
????????? LOOPBACK? MTU:16436?
Metric:1?????????????????????????????????????????
????????? RX packets:0 errors:0 dropped:0 overruns:0 frame:0????????????????????
????????? TX packets:0 errors:0 dropped:0 overruns:0 carrier:0??????????????????
????????? collisions:0
txqueuelen:0?????????????????????????????????????????????
????????? RX bytes:0 (0.0 B)? TX bytes:0 (0.0 B)?
# ifconfig eth0 up
eth0: no PHY found????????????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
ifconfig: SIOCSIFFLAGS: Operation not permitted
# ifconfig eth0 up
net eth0: DaVinci EMAC: request_irq() failed??????????????????
ifconfig: SIOCSIFFLAGS: Device or resource busy???
?ifconfig eth0
up??????????????????????????????????????????????????????????????
kernel BUG at include/linux/netdevice.h:439!????????????????????????????????????
????????????????????????????????????????????????????????????????????????????????
Unable to handle kernel NULL pointer dereference at virtual address 00000000????
pgd =
c1660000??????????????????????????????????????????????????????????????????
[00000000] *pgd=86668031, *pte=00000000, *ppte=00000000?????????????????????????
Internal error: Oops: 817 [#1] PREEMPT??????????????????????????????????????????
Modules linked
in:??????????????????????????????????????????????????????????????
CPU: 0??? Not tainted? (2.6.31-rc5-davinci1 #1)?????????????????????????????????
PC is at
__bug+0x20/0x2c????????????????????????????????????????????????????????
LR is at preempt_schedule+0x48/0x64?????????????????????????????????????????????
pc : [<c002b3b0>]??? lr : [<c024c9e4>]??? psr: 60000013?????????????????????????
sp : c70dbdc0? ip : c70dbd00? fp :
c70dbdcc?????????????????????????????????????
r10: c704a800? r9 : c704a800? r8 : c704aac0?????????????????????????????????????
r7 : 00000001? r6 : 00000001? r5 : 00000000? r4 : c66dda80??????????????????????
r3 : 00000000? r2 : c70da000? r1 : c706a320? r0 : 00000033??????????????????????
Flags: nZCv? IRQs on?
FIQs on? Mode SVC_32? ISA ARM? Segment user???????????????
Control: 0005317f? Table: 81660000? DAC: 00000015???????????????????????????????
Process ifconfig (pid: 857, stack limit = 0xc70da270)???????????????????????????
Stack: (0xc70dbdc0 to 0xc70dc000)???????????????????????????????????????????????
bdc0: c70dbe1c c70dbdd0
c0191e24 c002b3a0 c704a800 c704a800 c005695c c00568ac???
bde0: 00000000 00000000 c704aa08 c704aa08 c0056984 c704a800 c704a830 c0260c8c???
be00: 00001002 bee95950 c704a800 c70d630c c70dbe3c c70dbe20 c01ce43c c0191a44???
be20: c01c9c48 c704a800 00000041 00001043 c70dbe5c c70dbe40 c01cc63c c01ce388???
be40: 00000001 00000000 c70dbe78 c70d6300 c70dbec4 c70dbe60 c0210fcc c01cc5b4???
be60: 00008914 00000000 30687465 00000000 00000000 00000000 001b1043 001b46a4???
be80: 001b4708 001b4740 001b1043 001b46a4 001b4708 001b4740 001b4708 c66ddd80???
bea0: 00008914 bee95950 c66ddd80 00000003 c70da000 0019273c c70dbed4 c70dbec8???
bec0: c0211a6c c0210d18 c70dbef4 c70dbed8 c01bdab4 c02119bc c66ddd80 c66ddd80???
bee0: bee95950 00008914 c70dbf14 c70dbef8 c00a1eb4 c01bd8dc c70dbf1c
c66ddd80???
bf00: c6d9e028 bee95950 c70dbf7c c70dbf18 c00a2558 c00a1e8c c01bc0d0 c0095a68???
bf20: c0262488 c0034c18 c6d9e000 00000000 c70dbf5c c70dbf40 c0092808 c0034c18???
bf40: 00000000 00000003 c6d9e000 00000119 c70dbf84 c70dbf60 c01bc16c 00000003???
bf60: bee95950 00008914 c0027fe4 c70da000 c70dbfa4 c70dbf80 c00a25f8 c00a2018???
bf80: c01bcab0 00000000 00192574 00000004 00000000 00000036 00000000 c70dbfa8???
bfa0: c0027e60 c00a25c8 00192574 00000004 00000003 00008914 bee95950 00192574???
bfc0: 00192574 00000004 00000000 00000036 00000000 0000005c 0019273c bee95950???
bfe0: bee95ebc bee95928 0000b75c 0000903c 20000010 00000003 cf68a77a 3fd5190e???
Backtrace:??????????????????????????????????????????????????????????????????????
[<c002b390>] (__bug+0x0/0x2c) from [<c0191e24>] (emac_dev_open+0x3f0/0xc50)?????
[<c0191a34>] (emac_dev_open+0x0/0xc50) from [<c01ce43c>] (dev_open+0xc4/0x128)??
[<c01ce378>] (dev_open+0x0/0x128) from [<c01cc63c>] (dev_change_flags+0x98/0x170)
?r6:00001043 r5:00000041
r4:c704a800????????????????????????????????????????????
[<c01cc5a4>] (dev_change_flags+0x0/0x170) from [<c0210fcc>] (devinet_ioctl+0x2c4)
?r7:c70d6300 r6:c70dbe78 r5:00000000 r4:00000001????????????????????????????????
[<c0210d08>] (devinet_ioctl+0x0/0x6b0) from [<c0211a6c>] (inet_ioctl+0xc0/0xf0)?
[<c02119ac>] (inet_ioctl+0x0/0xf0) from [<c01bdab4>] (sock_ioctl+0x1e8/0x248)???
[<c01bd8cc>] (sock_ioctl+0x0/0x248) from [<c00a1eb4>] (vfs_ioctl+0x38/0x98)?????
?r6:00008914 r5:bee95950 r4:c66ddd80????????????????????????????????????????????
[<c00a1e7c>] (vfs_ioctl+0x0/0x98) from [<c00a2558>] (do_vfs_ioctl+0x550/0x5b0)??
?r6:bee95950 r5:c6d9e028 r4:c66ddd80????????????????????????????????????????????
[<c00a2008>] (do_vfs_ioctl+0x0/0x5b0) from [<c00a25f8>] (sys_ioctl+0x40/0x64)???
?r9:c70da000 r8:c0027fe4 r6:00008914 r5:bee95950
r4:00000003????????????????????
[<c00a25b8>] (sys_ioctl+0x0/0x64) from [<c0027e60>] (ret_fast_syscall+0x0/0x2c)?
?r7:00000036 r6:00000000 r5:00000004 r4:00192574????????????????????????????????
Code: e1a01000 e59f000c eb004704 e3a03000 (e5833000)????????????????????????????
---[ end trace fd18f3f6111d678d
]---????????????????????????????????????????????
Segmentation fault?
when
i do ifconfig eth0 up first tym it displays the first message.if i do
it again displays the second message device busy.if do it third time it
says bug in kernel as shown in the above log can anyone tell how to
resolve this issue.
The ethernet works well in the u-boot but it is not working in the kernel.My PHY is SMSC 8700 and i have added support for it using the make menuconfig but stilll i am unale to enable the ethernet. Can anyone tell what is the problem
with regard's
Rohan Tabish
Send instant messages to your online friends http://uk.messenger.yahoo.com
^ permalink raw reply
* Re: [PATCH] Fix hypervisor crash with unpopulated NUMA nodes
From: Jan Beulich @ 2009-10-07 11:53 UTC (permalink / raw)
To: Andre Przywara; +Cc: xen-devel
In-Reply-To: <4ACC6346.5080309@amd.com>
>>> Andre Przywara <andre.przywara@amd.com> 07.10.09 11:45 >>>
>on NUMA systems with memory-less nodes Xen crashes quite early in the
>hypervisor (while initializing the heaps). This is not an issue if this
>happens to be the last node, but "inner" nodes trigger this reliably.
>On multi-node processors it is much more likely to leave a node unequipped.
>The attached patch fixes this by enumerating the node via the
>node_online_map instead of counting from 0 to num_nodes.
While I do not see anything wrong with the patch, I still wonder why it
would be needed: It seems to indicate that node_online_map represents
only nodes with memory, but imo should be representing nodes with
memory or processors (leaving aside pure I/O nodes for the moment).
So perhaps there's rather a problem with the setup of node_online_map
somewhere?
Jan
^ permalink raw reply
* [PATCH] quickcam_messenger.c: possible buffer overflow while use strncat.
From: Alexander Strakh @ 2009-10-07 15:56 UTC (permalink / raw)
To: Jaya Kumar, Mauro Carvalho Chehab, linux-media, linux-kernel
In driver ./drivers/media/video/usbvideo/quickcam_messenger.c in line 91:
91 usb_make_path(dev, cam->input_physname, sizeof(cam-
>input_physname));
After this line we use strncat:
92 strncat(cam->input_physname, "/input0", sizeof(cam-
>input_physname));
where sizeof(cam->input_physname) returns length of cam->input_phisname
without length for null-symbol. But this parameter must be - "maximum numbers
of bytes to copy", i.e.: sizeof(cam->input_physname)-strlen(cam-
>input_physname)-1.
In this case, after call to usb_make_path the similar drivers use strlcat.
Like in: drivers/hid/usbhid/hid-core.c:
1152 usb_make_path(dev, hid->phys, sizeof(hid->phys));
1153 strlcat(hid->phys, "/input", sizeof(hid->phys));
Found by Linux Driver Verification Project.
Use strlcat instead of strncat.
Signed-off-by:Alexander Strakh <strakh@ispras.ru>
---
diff --git a/./a/drivers/media/video/usbvideo/quickcam_messenger.c
b/./b/drivers/media/video/usbvideo/quickcam_messenger.c
index 803d3e4..c4d1b96 100644
--- a/./a/drivers/media/video/usbvideo/quickcam_messenger.c
+++ b/./b/drivers/media/video/usbvideo/quickcam_messenger.c
@@ -89,7 +89,7 @@ static void qcm_register_input(struct qcm *cam, struct
usb_device *dev)
int error;
usb_make_path(dev, cam->input_physname, sizeof(cam->input_physname));
- strncat(cam->input_physname, "/input0", sizeof(cam->input_physname));
+ strlcat(cam->input_physname, "/input0", sizeof(cam->input_physname));
cam->input = input_dev = input_allocate_device();
if (!input_dev) {
^ permalink raw reply related
* [PATCH] konicawc.c: possible buffer overflow while use strncat.
From: Alexander Strakh @ 2009-10-07 15:56 UTC (permalink / raw)
To: Simon Evans, Mauro Carvalho Chehab, linux-media, linux-kernel
In driver ./drivers/media/video/usbvideo/konicawc.c in line 227:
227 usb_make_path(dev, cam->input_physname, sizeof(cam-
>input_physname));
After this line we use strncat:
228 strncat(cam->input_physname, "/input0", sizeof(cam-
>input_physname));
where sizeof(cam->input_physname) returns length of cam->input_phisname
without length for null-symbol. But this parameter must be - "maximum numbers
of bytes to copy", i.e.: sizeof(cam->input_physname)-strlen(cam-
>input_physname)-1.
In this case, after call to usb_make_path the similar drivers use strlcat.
Like in drivers/hid/usbhid/hid-core.c:
1152 usb_make_path(dev, hid->phys, sizeof(hid->phys));
1153 strlcat(hid->phys, "/input", sizeof(hid->phys));
Found by Linux Driver Verification Project.
Use strlcat instead of strncat.
Signed-off-by:Alexander Strakh <strakh@ispras.ru>
---
diff --git a/./a/drivers/media/video/usbvideo/konicawc.c
b/./b/drivers/media/video/usbvideo/konicawc.c
index 31d57f2..a0addcb 100644
--- a/./a/drivers/media/video/usbvideo/konicawc.c
+++ b/./b/drivers/media/video/usbvideo/konicawc.c
@@ -225,7 +225,7 @@ static void konicawc_register_input(struct konicawc *cam,
struct usb_device *dev
int error;
usb_make_path(dev, cam->input_physname, sizeof(cam->input_physname));
- strncat(cam->input_physname, "/input0", sizeof(cam->input_physname));
+ strlcat(cam->input_physname, "/input0", sizeof(cam->input_physname));
cam->input = input_dev = input_allocate_device();
if (!input_dev) {
^ permalink raw reply related
* [U-Boot] [PATCH 0/2] Make sure 85xx bss doesn't start at 0x0
From: Peter Tyser @ 2009-10-07 11:57 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20091007065336.9AC54E8B31E@gemini.denx.de>
> > It seems like a clean solution. Adding a bss-aware fixup routine or
> > putting the bss after the U-Boot image both seem good to me. The
> > bss-aware fixup routine has a clearer readelf output and slightly more
> > complicated code while the bss-after-uboot change has a misleading
> > readelf output and simpler code. In any case I'd give a thumbs up to
> > either of them.
>
> My vote is for the first, because otherwise we will run into
> situations again and again where users and/or the linker get confused
> about overlapping sections and/or sections wrapping around the
> physical end of address space.
Are you proposing adding this new bss fixup code to this release, or
rolling it into the next release along with Jocke's addition of
relocation code written in C-code? Logically it'd be much easier to add
this new bss fixup logic to Jocke's 1 C-code function instead of 15
assembly files, but then we'd have to have a temporary 85xx workaround
just for this release (which is fine by me).
Best,
Peter
^ permalink raw reply
* Re: sscape: general code improvements
From: Takashi Iwai @ 2009-10-07 11:57 UTC (permalink / raw)
To: krzysztof.h1; +Cc: Alsa-devel, Rene Herman
In-Reply-To: <20091007111925.560A1199B1A0@f14.poczta.interia.pl>
At 07 Oct 2009 13:19:25 +0200,
krzysztof.h1@poczta.fm wrote:
>
> > > What is a standard name for switch to select internal or external midi?
> > It is very easy to
> > > add such a functionality to the driver.
> >
> > What do you mean exactly to switch int/ext midi?
> > Usually the driver provides the interfaces for both, and let user choose.
> > If they are exclusive, it's checked in the open.
> > Or, if preferred, a control element can be used to choose the
> > interface...
> >
>
> The driver interface (MPU-401 UART) is only one and there is a
> command to switch it to the on-board synthetizer or external midi
> (joysitck port on the card).
If it can be done on the fly without any conflict, I'd implement it
as a control element. You can use iface=CARD to hide from mixer app,
for example.
Takashi
^ permalink raw reply
* Re: [PATCH 29/45] writeback: fix the shmem AOP_WRITEPAGE_ACTIVATE case
From: Hugh Dickins @ 2009-10-07 11:57 UTC (permalink / raw)
To: Wu Fengguang
Cc: Andrew Morton, Theodore Tso, Christoph Hellwig, Dave Chinner,
Chris Mason, Peter Zijlstra, Li Shaohua, Myklebust Trond,
jens.axboe@oracle.com, Jan Kara, Nick Piggin, linux-fsdevel, LKML
In-Reply-To: <20091007074904.870825579@intel.com>
On Wed, 7 Oct 2009, Wu Fengguang wrote:
> When shmem returns AOP_WRITEPAGE_ACTIVATE, the inode pages cannot be
> synced in the near future. So write_cache_pages shall stop writting this
> inode, and shmem shall increase pages_skipped to instruct VFS not to
> busy retry.
>
> CC: Hugh Dickins <hugh.dickins@tiscali.co.uk>
> Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Okay, it embarrasses me to see AOP_WRITEPAGE_ACTIVATE (and its horrid
"in this one case the page is still locked" semantic) still around -
my patch to remove it vanished from mmotm (probably caused a temporary
conflict) and I've never chased it up (partly out of guilt that I'd not
yet kept my promise to contact the openAFS people about their use of it).
But that's orthogonal to your concern here: for so long as there has
been a wbc->pages_skipped, I guess shmem_writepage() should have been
incrementing it there - thanks. But I don't believe the VFS will ever
have any interest in pages_skipped from shmem_writepage(): do you have
evidence that it does? If so, I need to investigate.
And the accompanying change to write_cache_pages() seems irrelevant
and misguided. Irrelevant because write_cache_pages() should never be
dealing with shmem_writepage() (its bdi should keep it well away), and
should never be dealing with reclaim, which is the only case in which
shmem_writepage() returns AOP_WRITEPAGE_ACTIVATE - or have your other
changes, or the bdi work, changed that?
And misguided because in your change to write_cache_pages() you're
taking AOP_WRITEPAGE_ACTIVATE to say that it should now give up, not
process more pages. We just don't know that. All it means is that
this one page couldn't be written and should be reactivated (if it
were under reclaim): it might be the case that every other page tried
after would get treated in the same way, or it might be the case that
the next page would get written successfully. That info is just not
provided.
Hugh
> ---
> mm/page-writeback.c | 23 +++++++++++------------
> mm/shmem.c | 1 +
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> --- linux.orig/mm/page-writeback.c 2009-10-06 23:39:28.000000000 +0800
> +++ linux/mm/page-writeback.c 2009-10-06 23:39:29.000000000 +0800
> @@ -851,19 +851,18 @@ continue_unlock:
> if (ret == AOP_WRITEPAGE_ACTIVATE) {
> unlock_page(page);
> ret = 0;
> - } else {
> - /*
> - * done_index is set past this page,
> - * so media errors will not choke
> - * background writeout for the entire
> - * file. This has consequences for
> - * range_cyclic semantics (ie. it may
> - * not be suitable for data integrity
> - * writeout).
> - */
> - done = 1;
> - break;
> }
> + /*
> + * done_index is set past this page,
> + * so media errors will not choke
> + * background writeout for the entire
> + * file. This has consequences for
> + * range_cyclic semantics (ie. it may
> + * not be suitable for data integrity
> + * writeout).
> + */
> + done = 1;
> + break;
> }
>
> if (nr_to_write > 0) {
> --- linux.orig/mm/shmem.c 2009-10-06 23:37:40.000000000 +0800
> +++ linux/mm/shmem.c 2009-10-06 23:39:29.000000000 +0800
> @@ -1103,6 +1103,7 @@ unlock:
> */
> swapcache_free(swap, NULL);
> redirty:
> + wbc->pages_skipped++;
> set_page_dirty(page);
> if (wbc->for_reclaim)
> return AOP_WRITEPAGE_ACTIVATE; /* Return with page locked */
^ permalink raw reply
* Bug: AR928x not working on 2.6.31.x
From: berndl81 @ 2009-10-07 11:59 UTC (permalink / raw)
To: linux-wireless
I am using Archlinux on my Acer Extensa 7630EZ and realize that my wireless-device which is an
Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
according to lspci works very well using arch-stock kernel 2.6.30 and is not working any longer when using the 2.6.31.1 or 2.6.31.2 kernel from Arch's testing repository.
When using the 2.6.30 kernel (wlan is working very well), I get the following dmesg-output:
[bernhard@wallaby ~]$ dmesg |grep ath
ath9k 0000:05:00.0: enabling device (0000 -> 0002)
ath9k 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath9k 0000:05:00.0: setting latency timer to 64
phy0: Selected rate control algorithm 'ath9k_rate_control'
Registered led device: ath9k-phy0::radio
Registered led device: ath9k-phy0::assoc
Registered led device: ath9k-phy0::tx
Registered led device: ath9k-phy0::rx
When upgrading to 2.6.31.x, i receive the following output:
[bernhard@wallaby ~]$ dmesg |grep ath
ath9k 0000:05:00.0: enabling device (0000 -> 0002)
ath9k 0000:05:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
ath9k 0000:05:00.0: setting latency timer to 64
ath9k 0000:05:00.0: PCI INT A disabled
As I see it, the device is recognized and instantly disabled again. The device cannot be brought up too using ifconfig.
I am quite clueless what do do aside from reporting the bug here as suggested in the original Arch-bugreport (http://bugs.archlinux.org/task/16413)
If any further information is helpful, I will of course happily try to provide it.
Bernhard
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
^ permalink raw reply
* Re: nocache/highmem mapping
From: David Miller @ 2009-10-07 12:01 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <4ACB63BC.90200@gaisler.com>
From: Konrad Eisele <konrad@gaisler.com>
Date: Tue, 06 Oct 2009 17:35:24 +0200
> Here is what we digged out:
> The virtual address regions with 512 MB ram and
> #define SRMMU_MAX_NOCACHE_PAGES (1280)
> are:
>
> 0xfc0000000 - 0xfc5000000 : nocache mem
> 0xfc5000000 - 0xfc9000000 : highmem
>
> however srmmu_nocache_init()->srmmu_early_allocate_ptable_skeleton()
> initializes the the page skelleton in steps of:
> ...
> while(start < end) {
> ...
> start = (start + PMD_SIZE) & PMD_MASK;
> }
> ...
>
> PMD_SIZE is 0x4000000, that means it will will initilize
>
> 0xfc0000000 - 0xfc4000000 and
> 0xfc4000000 - 0xfc8000000
> before it breaks.
I think you have found a genuine bug and maybe it explains
bugs others have run into over the past few years :-)
I'll do some more research on this tomorrow and apply some
kind of fix.
Thanks!
^ permalink raw reply
* RE: [PATCH] OMAP3: PM: Update omap3_pm_defconfig
From: Gadiyar, Anand @ 2009-10-07 12:01 UTC (permalink / raw)
To: Nayak, Rajendra, linux-omap@vger.kernel.org
In-Reply-To: <1254898768-16495-1-git-send-email-rnayak@ti.com>
> Some of the sysfs deprecated entries, if not enabled cause
> root filesystem mounts to fail at boot.
> This is seen on both the 3430SDP as well as 3430zoom platforms.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> ---
> arch/arm/configs/omap3_pm_defconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/configs/omap3_pm_defconfig
> b/arch/arm/configs/omap3_pm_defconfig
> index 9d54139..b1c42ed 100644
> --- a/arch/arm/configs/omap3_pm_defconfig
> +++ b/arch/arm/configs/omap3_pm_defconfig
> @@ -58,7 +58,8 @@ CONFIG_FAIR_GROUP_SCHED=y
> CONFIG_USER_SCHED=y
> # CONFIG_CGROUP_SCHED is not set
> # CONFIG_CGROUPS is not set
> -# CONFIG_SYSFS_DEPRECATED_V2 is not set
> +CONFIG_SYSFS_DEPRECATED=y
> +CONFIG_SYSFS_DEPRECATED_V2=y
I think these were deliberately removed on many OMAP3
defconfigs by a recent patch from Vikram
.
Having these enabled makes it hard to boot on a newer
busybox filesystem.
It's easy to fix if you just upgrade busybox to a newer
version.
- Anand
^ permalink raw reply
* Re: get request context
From: Stephen Smalley @ 2009-10-07 12:02 UTC (permalink / raw)
To: michel m; +Cc: selinux
In-Reply-To: <bb74313d0910070439s6271ebe6ib481aab3f0eca7a6@mail.gmail.com>
On Wed, 2009-10-07 at 15:09 +0330, michel m wrote:
> Hi,
>
> Is there any way that I can get context for incoming http requests
> from selinux API. that is I want to classify requests based on some
> criteria like origin`s IP address or any thing that can help me to
> know what context the request is coming from.
>
> is there such an API for this is libselinux? If not, how can I have
> this knowledge by using existing API?
If using labeled IPSEC to label the connections, you can use
getpeercon(3) in libselinux.
http://securityblog.org/brindle/2007/05/28/secure-networking-with-selinux/
Likewise with NetLabel, although there you are limited to only passing
the MLS label at present. You might be able to do something via the
fallback labeling based on IP address.
http://paulmoore.livejournal.com/
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: transparent proxy and iptables failing
From: Rakotomandimby Mihamina @ 2009-10-07 12:05 UTC (permalink / raw)
To: netfilter
In-Reply-To: <7de411230910070444u50e7c638m968350c6da1ce6e1@mail.gmail.com>
10/07/2009 02:44 PM, Robin Wood::
> br-lan
> What am I doing wrong?
IMHO, the "-" in br-lan is wrong.
escape/protect it with "br-lan" or something like that.
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34
^ permalink raw reply
* Re: [PATCH 0/3] md fixes for 2.6.32-rc
From: Holger Kiehl @ 2009-10-07 12:05 UTC (permalink / raw)
To: Dan Williams; +Cc: Neil Brown, linux-raid@vger.kernel.org
In-Reply-To: <1254875779.16798.10.camel@dwillia2-linux.ch.intel.com>
On Tue, 6 Oct 2009, Dan Williams wrote:
>> From 0496c92cf6ac1f4f7dde6d416707988991d87d41 Mon Sep 17 00:00:00 2001
> From: Dan Williams <dan.j.williams@intel.com>
> Date: Sat, 3 Oct 2009 13:47:05 -0700
> Subject: [PATCH] md/raid456: downlevel multicore operations to raid_run_ops
>
> The percpu conversion allowed a straightforward handoff of stripe
> processing to the async subsytem that initially showed some modest gains
> (+4%). However, this model is too simplistic and leads to stripes
> bouncing between raid5d and the async thread pool for every invocation
> of handle_stripe(). As reported by Holger this can fall into a
> pathological situation severely impacting throughput (6x performance
> loss).
>
> By downleveling the parallelism to raid_run_ops the pathological
> stripe_head bouncing is eliminated. This version still exhibits an
> average 11% throughput loss for:
>
> mdadm --create /dev/md0 /dev/sd[b-q] -n 16 -l 6
> echo 1024 > /sys/block/md0/md/stripe_cache_size
> dd if=/dev/zero of=/dev/md0 bs=1024k count=2048
>
> ...but the results are at least stable and can be used as a base for
> further multicore experimentation.
>
> Reported-by: Holger Kiehl <Holger.Kiehl@dwd.de>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
> On Thu, 2009-10-01 at 21:13 -0700, Neil Brown wrote:
>> On Thursday October 1, dan.j.williams@intel.com wrote:
>>> Hi Neil,
>>>
>>> A few fixes:
>>> 1/ The multicore option is not ready for prime time
>>
>> But it is already marked experimental...
>> So do we really need to revert? or is the current code broken beyond
>> repair?
>
> So we don't need a revert, this fixes up the unpredictability of the
> original implementation. It surprised me that the overhead of passing
> raid_run_ops to the async thread pool amounted to an 11% performance
> regression. In any event I think this is a better baseline for future
> multicore experimentation than the current implementation.
>
Just to add some more information, I did try this patch with
2.6.32-rc3-git1 and with the testing I am doing I get appr. 125%
performance regression. The tests I am doing is have several (appr. 60
process) sending via FTP or SFTP about 100000 small files (average size
below 4096 bytes) to localhost in a loop for 30 minutes. Here the
real numbers:
with multicore support enabled (with your patch) 3276.77 files per second
with multicore support enabled (without your patch) 1014.47 files per second
without multicore support 7549.24 files per second
Holger
^ permalink raw reply
* RE: [PATCH] OMAP3: PM: Update omap3_pm_defconfig
From: Nayak, Rajendra @ 2009-10-07 12:05 UTC (permalink / raw)
To: Gadiyar, Anand, linux-omap@vger.kernel.org
In-Reply-To: <5A47E75E594F054BAF48C5E4FC4B92AB030A332920@dbde02.ent.ti.com>
>-----Original Message-----
>From: Gadiyar, Anand
>Sent: Wednesday, October 07, 2009 5:31 PM
>To: Nayak, Rajendra; linux-omap@vger.kernel.org
>Subject: RE: [PATCH] OMAP3: PM: Update omap3_pm_defconfig
>
>> Some of the sysfs deprecated entries, if not enabled cause
>> root filesystem mounts to fail at boot.
>> This is seen on both the 3430SDP as well as 3430zoom platforms.
>>
>> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
>> ---
>> arch/arm/configs/omap3_pm_defconfig | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/configs/omap3_pm_defconfig
>> b/arch/arm/configs/omap3_pm_defconfig
>> index 9d54139..b1c42ed 100644
>> --- a/arch/arm/configs/omap3_pm_defconfig
>> +++ b/arch/arm/configs/omap3_pm_defconfig
>> @@ -58,7 +58,8 @@ CONFIG_FAIR_GROUP_SCHED=y
>> CONFIG_USER_SCHED=y
>> # CONFIG_CGROUP_SCHED is not set
>> # CONFIG_CGROUPS is not set
>> -# CONFIG_SYSFS_DEPRECATED_V2 is not set
>> +CONFIG_SYSFS_DEPRECATED=y
>> +CONFIG_SYSFS_DEPRECATED_V2=y
>
>I think these were deliberately removed on many OMAP3
>defconfigs by a recent patch from Vikram
>.
>Having these enabled makes it hard to boot on a newer
>busybox filesystem.
>
>It's easy to fix if you just upgrade busybox to a newer
>version.
Ok.. makes sense. I'll try with a newer busybox.
>
>- Anand
>
^ permalink raw reply
* Re: NULL inode->i_mapping in generic_sync_sb_inodes
From: Jeff Moyer @ 2009-10-07 12:05 UTC (permalink / raw)
To: Nick Piggin; +Cc: Christoph Hellwig, npiggin, linux-fsdevel, linux-kernel
In-Reply-To: <4ACC9E8A0200008A000439B0@novprvlin0050.provo.novell.com>
"Nick Piggin" <npiggin@novell.com> writes:
>>>> Jeff Moyer 10/07/09 12:48 AM >>>
>>Hi,
>>
>>I've come across a problem in 2.6.31 whereby the umount path on shutdown
>>Oopses like so:
>>
>>BUG: unable to handle kernel NULL pointer dereference at 00000070
>>IP: [] generic_sync_sb_inodes+0x2ca/0x34b
>>*pdpt = 00000000220b1001 *pde = 0000000099419067
>>Oops: 0000 [#1] SMP
>>last sysfs file:
>>/sys/devices/pci0000:00/0000:00:07.0/0000:0d:00.0/0000:0e:08.0/host0/target0:1:0>/0:1:0:0/block/sda/removable
>>Modules linked in: fcoe libfcoe libfc scsi_transport_fc scsi_tgt ipv6 xts lrw
>>gf128mul sha256_generic cbc dm_crypt dm_round_robin dm_multipath dm_snapshot
>>dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 raid6_pq
>>async_xor async_memcpy async_tx xor raid1 raid0 nfs lockd fscache nfs_acl
>>auth_rpcgss sunrpc radeon mptsas ttm drm_kms_helper mptscsih drm mptbase
>>i2c_algo_bit i2c_core scsi_transport_sas bnx2 iscsi_ibft pcspkr edd iscsi_tcp
>>libiscsi_tcp libiscsi scsi_transport_iscsi squashfs cramfs
>>
>>Pid: 5082, comm: grub Tainted: G W (2.6.31-27.el6.i686 #1) PowerEdge
>>1955
>>EIP: 0060:[] EFLAGS: 00010246 CPU: 0
>>EIP is at generic_sync_sb_inodes+0x2ca/0x34b
>>EAX: ec45ae14 EBX: 00000000 ECX: 00000000 EDX: c0510e4f
>>ESI: ec45ae04 EDI: ec45b1c4 EBP: f25fdf38 ESP: f25fdf10
>>DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>>Process grub (pid: 5082, ti=f25fc000 task=ef0cc6f0 task.ti=f25fc000)
>>Stack:
>>00000246 00000001 f422fa6c 000abc70 f422fa64 f422fa54 8fd7ae23 f422f970
>><0> 00000001 f25fdf68 f25fdf74 c0510f0e 00000000 00000001 00000000 7fffffff
>><0> 00000000 00000000 00000000 ffffffff 7fffffff 00000000 8fd7ae23 f422f970
>>Call Trace:
>>[] ? sync_inodes_sb+0x74/0x8c
>>[] ? __sync_filesystem+0x41/0x74
>>[] ? sync_filesystems+0x96/0xed
>>[] ? sys_sync+0x27/0x4a
>>[] ? sysenter_do_call+0x12/0x38
>>Code: 0f 85 83 00 00 00 8b b3 e4 00 00 00 81 c3 e4 00 00 00 31 ff 89 5d ec 83
>>ee 10 eb 4b f6 86 6c 02 00 00 78 75 3c 8b 9e 3c 01 00 00 <83> 7b 70 00 74 30 89
>>f0 e8 d8 61 ff ff b8 cc f4 a0 c0 e8 e0 dd
>>EIP: [] generic_sync_sb_inodes+0x2ca/0x34b SS:ESP 0068:f25fdf10
>>CR2: 0000000000000070
>>---[ end trace 8171140d16b04470 ]---
>>
>>The Oops is in fs/fs-writeback.c:568:
>>
>>list_for_each_entry(inode, &sb->s_inodes, i_sb_list) {
>>struct address_space *mapping;
>>
>>if (inode->i_state &
>>(I_FREEING|I_CLEAR|I_WILL_FREE|I_NEW))
>>continue;
>>mapping = inode->i_mapping;
>>if (mapping->nrpages == 0) <==== BUG
>>
>>Any idea how that can happen? Maybe a race in the umount path?
>
> Possibly. I can't quite see how it could happen in the core code, because
> we should always have i_state flags set if the inode is new or being
> freed. It might happen that a caller is mistakenly unlocking it too
> early or something, though.
>
> Is this repeatable?
I believe so. I'm having a hard time getting this particular system to
install, but once I have it reinstalled, I'll see if we get this problem
again. I'm pretty sure I've seen it at least twice on this machine.
hch mentioned that it would be good to instrument to what file system
the inode belonged. Anything else you'd like to look at?
Thanks a ton!
Jeff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.