cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« on: November 10, 2009, 02:04:51 AM » |
|
2.6.31.6 is now available. Kernel and modules are available from the following location: http://sheeva.with-linux.com/sheeva/Features IPV6, CIFS, NFS4, EXT3, EXT4, JFS, XFS, FUSE(for ntfs-3g), UBIFS, usb-serial, uvcvideo, iptables, appletalk, bluetooth, v4l and ppp.
|
|
|
|
|
Logged
|
|
|
|
|
jrmt
Newbie
Karma: 0
Posts: 5
|
 |
« Reply #1 on: November 12, 2009, 04:32:52 AM » |
|
Great work. Many thanks for this. Running fine on my 2-week old SheevaPlug from NewIT.co.uk. I was just wondering about the mvsdio driver, which seems to use a lot of interrupt as it uses polling. Are there any patches out there to avoid polling, or is this a hardware issue? $ cat /proc/interrupts CPU0 1: 924575 orion_irq orion_tick 5: 2 orion_irq mv_xor.0 6: 2 orion_irq mv_xor.1 7: 2 orion_irq mv_xor.2 8: 2 orion_irq mv_xor.3 11: 70802 orion_irq eth0 19: 2832 orion_irq ehci_hcd:usb1 28: 607552 orion_irq mvsdio 33: 229 orion_irq serial 46: 24 orion_irq mv643xx_eth Err: 0
$ dmesg | grep -i mvs mmc0: mvsdio driver initialized, lacking card detect (fall back to polling) Cheers, Jon.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #2 on: November 12, 2009, 07:40:04 AM » |
|
Just plugging in my SD card reduced the interrupt rate to ~1Hz, which more-or-less fixed the problem from my point of view. B^>
Rgds
Damon
|
|
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #3 on: November 13, 2009, 12:52:08 PM » |
|
Dear cbxbiker61, i assume that you are the moderator of http://sheeva.with-linux.com/sheeva/ is there any change that you can include the 802.1q support in the future kernels? ( so i can start using your kernels instead of building my one  This is for the people that use .1q for expanding the amount of Ethernet ports by trunking to a switch like me. Thanks in advance, Regards, AMSpilot01
|
|
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #4 on: November 15, 2009, 06:33:13 AM » |
|
Can I request:
I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING)
Unless there is a reason why they might not be a good idea.
I run my Sheeva rootfs from the internal NAND, and if I have a kernel with this, I can use iotop to see where the majority of my file writing is occuring. (A good way to increase the life of my flash, and/or improve performance by relocating to faster media).
If this isn't a great idea for mainstream kernels, can I suggest a "specials" directory in sheeva-with-linux for one off testing stuff. (Clearly things are robust enough now they wouldn't have to be maintained every release).
Lastly, many thanks cxbiker, your kernel builds are awesome, and it means we don't need compiler enviroments on our plugs, or opening up to the world of hurt that is cross-compiling..
|
|
|
|
« Last Edit: November 15, 2009, 06:37:04 AM by mgillespie »
|
Logged
|
|
|
|
|
cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« Reply #5 on: November 16, 2009, 04:27:17 PM » |
|
is there any change that you can include the 802.1q support in the future kernels? ( so i can start using your kernels instead of building my one  This is for the people that use .1q for expanding the amount of Ethernet ports by trunking to a switch like me. No problem. I've just rebuild 2.6.31.6 (version 2) with 802.1q support.
|
|
|
|
|
Logged
|
|
|
|
|
cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« Reply #6 on: November 16, 2009, 04:33:48 PM » |
|
Can I request:
I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING)
Unless there is a reason why they might not be a good idea.
I run my Sheeva rootfs from the internal NAND, and if I have a kernel with this, I can use iotop to see where the majority of my file writing is occuring. (A good way to increase the life of my flash, and/or improve performance by relocating to faster media).
If this isn't a great idea for mainstream kernels, can I suggest a "specials" directory in sheeva-with-linux for one off testing stuff. (Clearly things are robust enough now they wouldn't have to be maintained every release).
Lastly, many thanks cxbiker, your kernel builds are awesome, and it means we don't need compiler enviroments on our plugs, or opening up to the world of hurt that is cross-compiling..
Well I don't think the overhead that would go along with enabling those options justifies placing it in the standard kernel. But as you suggest, I don't see a problem with creating a /testing directory for "special" testing versions. After I figure out how I want to maintain a testing tree I'll get something uploaded there for you. I'm busy working on other stuff, so it'll probably be a day or so.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #7 on: November 18, 2009, 05:18:32 AM » |
|
May I please have the map file for this build? I want to do some kernel debugging and I need to know the address of __log_buf.
|
|
|
|
|
Logged
|
|
|
|
|
cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« Reply #8 on: November 19, 2009, 02:50:44 PM » |
|
Can I request:
I/O accounting support (CONFIG_TASKSTATS, CONFIG_TASK_DELAY_ACCT, CONFIG_TASK_IO_ACCOUNTING)
OK, a taskstat enabled kernel is available under /sheeva/testing.
|
|
|
|
|
Logged
|
|
|
|
|
cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« Reply #9 on: November 19, 2009, 03:39:02 PM » |
|
May I please have the map file for this build? I want to do some kernel debugging and I need to know the address of __log_buf.
The 2.6.31.6 kernel now has a System.map in the appropriate directory.
|
|
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #10 on: November 22, 2009, 10:15:29 AM » |
|
Thanks, it is a very useful addition. To wit:
1. Booted successfully (but the idea is that this should work even if the boot is not successful).
2. Pushed the reset button on the SheevaPlug and then interrupted the uboot autoboot countdown.
3. Used the value of __log_buf from the kernel build map file to display the log messages (after subtracting the value of CONFIG_PAGE_OFFSET).
----------------------------
__ __ _ _ | \/ | __ _ _ ____ _____| | | | |\/| |/ _` | '__\ \ / / _ \ | | | | | | (_| | | \ V / __/ | | |_| |_|\__,_|_| \_/ \___|_|_| _ _ ____ _ | | | | | __ ) ___ ___ | |_ | | | |___| _ \ / _ \ / _ \| __| | |_| |___| |_) | (_) | (_) | |_ \___/ |____/ \___/ \___/ \__| ** MARVELL BOARD: SHEEVA PLUG LE
U-Boot 1.1.4 (Nov 11 2009 - 16:17:48) Marvell version: 3.4.25
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFB00
Soc: 88F6281 A0 (DDR2) CPU running @ 1200Mhz L2 running @ 400Mhz SysClock = 400Mhz , TClock = 200Mhz
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6 DRAM CS[0] base 0x00000000 size 256MB DRAM CS[1] base 0x10000000 size 256MB DRAM Total size 512MB 16bit width Addresses 8M - 0M are saved for the U-Boot usage. Mem malloc Initialization (8M - 7M): Done NAND:512 MB Flash: 0 kB
CPU : Marvell Feroceon (Rev 1)
Streaming disabled Write allocate disabled
USB 0: host mode PEX 0: interface detected no Link. Net: egiga0 [PRIME] Hit any key to stop autoboot: 0 Marvell>> md 59a0d8 0059a0d8: 4c3e353c 78756e69 72657620 6e6f6973 <5>Linux version 0059a0e8: 362e3220 2e31332e 6b282036 796c6c65 2.6.31.6 (kelly 0059a0f8: 65707340 29796465 63672820 65762063 @speedy) (gcc ve 0059a108: 6f697372 2e34206e 29312e32 20342320 rsion 4.2.1) #4 0059a118: 45455250 2054504d 20756854 20766f4e PREEMPT Thu Nov 0059a128: 31203931 32303a35 2030353a 2054534d 19 15:02:50 MST 0059a138: 39303032 3e343c0a 3a555043 72654620 2009.<4>CPU: Fer 0059a148: 6f65636f 3838206e 33315246 355b2031 oceon 88FR131 [5 0059a158: 31353236 5d313133 76657220 6f697369 6251311] revisio 0059a168: 2031206e 4d524128 45543576 63202c29 n 1 (ARMv5TE), c 0059a178: 30303d72 39333530 3c0a3737 50433e34 r=00053977.<4>CP 0059a188: 56203a55 20545649 61746164 63616320 U: VIVT data cac 0059a198: 202c6568 54564956 736e6920 63757274 he, VIVT instruc 0059a1a8: 6e6f6974 63616320 3c0a6568 614d3e34 tion cache.<4>Ma 0059a1b8: 6e696863 4d203a65 65767261 53206c6c chine: Marvell S 0059a1c8: 76656568 756c5061 65522067 65726566 heevaPlug Refere Marvell>> md 59a1c8 0059a1c8: 76656568 756c5061 65522067 65726566 heevaPlug Refere 0059a1d8: 2065636e 72616f42 343c0a64 6d654d3e nce Board.<4>Mem 0059a1e8: 2079726f 696c6f70 203a7963 20434345 ory policy: ECC 0059a1f8: 61736964 64656c62 6144202c 63206174 disabled, Data c 0059a208: 65686361 69727720 61626574 3c0a6b63 ache writeback.< 0059a218: 6e4f3e37 646f6e20 20302065 61746f74 7>On node 0 tota 0059a228: 6761706c 203a7365 30313331 3c0a3237 lpages: 131072.< 0059a238: 72663e37 615f6565 5f616572 74696e69 7>free_area_init 0059a248: 646f6e5f 6e203a65 2065646f 70202c30 _node: node 0, p 0059a258: 74616467 35306320 38343539 6e202c30 gdat c0595480, n 0059a268: 5f65646f 5f6d656d 2070616d 36363063 ode_mem_map c066 0059a278: 30303062 3e373c0a 6f4e2020 6c616d72 b000.<7> Normal 0059a288: 6e6f7a20 31203a65 20343230 65676170 zone: 1024 page 0059a298: 73752073 66206465 6d20726f 616d6d65 s used for memma 0059a2a8: 373c0a70 4e20203e 616d726f 6f7a206c p.<7> Normal zo 0059a2b8: 203a656e 61702030 20736567 65736572 ne: 0 pages rese Marvell>> md 59a2b8 0059a2b8: 203a656e 61702030 20736567 65736572 ne: 0 pages rese 0059a2c8: 64657672 3e373c0a 6f4e2020 6c616d72 rved.<7> Normal 0059a2d8: 6e6f7a20 31203a65 34303033 61702038 zone: 130048 pa 0059a2e8: 2c736567 46494c20 6162204f 3a686374 ges, LIFO batch: 0059a2f8: 3c0a3133 75423e34 20746c69 6f7a2031 31.<4>Built 1 zo 0059a308: 696c656e 20737473 5a206e69 20656e6f nelists in Zone 0059a318: 6564726f 6d202c72 6c69626f 20797469 order, mobility 0059a328: 756f7267 676e6970 2e6e6f20 6f542020 grouping on. To 0059a338: 206c6174 65676170 31203a73 34303033 tal pages: 13004 0059a348: 353c0a38 72654b3e 206c656e 6d6d6f63 8.<5>Kernel comm 0059a358: 20646e61 656e696c 6f63203a 6c6f736e and line: consol 0059a368: 74743d65 2c305379 32353131 72203030 e=ttyS0,115200 r 0059a378: 3d746f6f 7665642f 636d6d2f 306b6c62 oot=/dev/mmcblk0 0059a388: 72203170 343c0a77 4449503e 73616820 p1 rw.<4>PID has 0059a398: 61742068 20656c62 72746e65 3a736569 h table entries: 0059a3a8: 34303220 6f282038 72656472 3131203a 2048 (order: 11 Marvell>> md 59a3a8 0059a3a8: 34303220 6f282038 72656472 3131203a 2048 (order: 11 0059a3b8: 3138202c 62203239 73657479 363c0a29 , 8192 bytes).<6 0059a3c8: 6e65443e 20797274 68636163 61682065 >Dentry cache ha 0059a3d8: 74206873 656c6261 746e6520 73656972 sh table entries 0059a3e8: 3536203a 20363335 64726f28 203a7265 : 65536 (order: 0059a3f8: 32202c36 34313236 79622034 29736574 6, 262144 bytes) 0059a408: 3e363c0a 646f6e49 61632d65 20656863 .<6>Inode-cache 0059a418: 68736168 62617420 6520656c 6972746e hash table entri 0059a428: 203a7365 36373233 6f282038 72656472 es: 32768 (order 0059a438: 2c35203a 31333120 20323730 65747962 : 5, 131072 byte 0059a448: 3c0a2973 654d3e36 79726f6d 3532203a s).<6>Memory: 25 0059a458: 20424d36 4d363532 203d2042 4d323135 6MB 256MB = 512M 0059a468: 6f742042 0a6c6174 4d3e353c 726f6d65 B total.<5>Memor 0059a478: 35203a79 32303331 20424b34 69617661 y: 513024KB avai 0059a488: 6c62616c 35282065 4b363530 646f6320 lable (5056K cod 0059a498: 31202c65 4b343230 74616420 31202c61 e, 1024K data, 1 Marvell>> md 59a498 0059a498: 31202c65 4b343230 74616420 31202c61 e, 1024K data, 1 0059a4a8: 204b3434 74696e69 4b30202c 67696820 44K init, 0K hig 0059a4b8: 6d656d68 363c0a29 554c533e 47203a42 hmem).<6>SLUB: G 0059a4c8: 6c736e65 3d736261 202c3131 6c615748 enslabs=11, HWal 0059a4d8: 3d6e6769 202c3233 6564724f 2d303d72 ign=32, Order=0- 0059a4e8: 4d202c33 624f6e69 7463656a 2c303d73 3, MinObjects=0, 0059a4f8: 55504320 2c313d73 646f4e20 313d7365 CPUs=1, Nodes=1 0059a508: 3e363c0a 495f524e 3a535152 0a343131 .<6>NR_IRQS:114. 0059a518: 433e343c 6f736e6f 203a656c 6f6c6f63 <4>Console: colo 0059a528: 64207275 796d6d75 76656420 20656369 ur dummy device 0059a538: 33783038 363c0a30 6c61433e 61726269 80x30.<6>Calibra 0059a548: 676e6974 6c656420 6c207961 2e706f6f ting delay loop. 0059a558: 31202e2e 2e323931 42203537 4d6f676f .. 1192.75 BogoM 0059a568: 20535049 6a706c28 3639353d 36373733 IPS (lpj=5963776 0059a578: 343c0a29 756f4d3e 632d746e 65686361 ).<4>Mount-cache 0059a588: 73616820 61742068 20656c62 72746e65 hash table entr Marvell>>
|
|
|
|
|
Logged
|
|
|
|
|
gra
Newbie
Karma: 0
Posts: 2
|
 |
« Reply #11 on: November 26, 2009, 01:59:50 AM » |
|
may I request the inclusion of gspca driver for my Logitech QuickCam Communicate STX webcam in next releases?
Thanks for all your work!!
|
|
|
|
|
Logged
|
|
|
|
|
|
|
 |
« Reply #12 on: December 06, 2009, 03:42:37 AM » |
|
cbxbikier:
can you please set the ramdisk size to be 8192 (instead of default 4096)?
this will solve the sheevaplug installer issue when using your kernels (since it seems initrd grew to be too big) !
< CONFIG_BLK_DEV_RAM_SIZE=4096 --- > CONFIG_BLK_DEV_RAM_SIZE=8192
Thanks, Rabeeh
|
|
|
|
|
Logged
|
|
|
|
|
cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« Reply #13 on: December 06, 2009, 07:11:47 PM » |
|
may I request the inclusion of gspca driver for my Logitech QuickCam Communicate STX webcam in next releases?
Thanks for all your work!!
The cspca drivers have been added to the 2.6.32 kernel.
|
|
|
|
|
Logged
|
|
|
|
|
cbxbiker61
Global Moderator
Sr. Member
   
Karma: 37
Posts: 488
|
 |
« Reply #14 on: December 06, 2009, 07:13:13 PM » |
|
can you please set the ramdisk size to be 8192 (instead of default 4096)?
this will solve the sheevaplug installer issue when using your kernels (since it seems initrd grew to be too big) !
< CONFIG_BLK_DEV_RAM_SIZE=4096 --- > CONFIG_BLK_DEV_RAM_SIZE=8192
Thanks, Rabeeh
Updated to 8192 in the 2.6.32 kernel.
|
|
|
|
|
Logged
|
|
|
|
|
|