• Home
  • Help
  • Search
  • Login
  • Register
  Show Posts
Pages: 1 2 [3] 4 5
31  Hardware and U-Boot firmware / Hardware / Re: Poll: Sheeva Plug Power Supply failures - does the mains voltage matter? on: August 18, 2010, 11:48:58 PM
The new one has been OK so far but whenever I plug in the power lead there is usually a small spark which is a bit worrying.

[Simple] switching power supplies draw a high amount of current when connected to mains until the capacitors have charged up and this can cause a sparc. All this assuming, of course, you connect it when the AC is not currently 0V (every 100th/120th second at 50/60Hz) but this can hardly be controlled Wink

Perfectly normal...

32  Hardware and U-Boot firmware / Hardware / Re: USB Weirdness on: August 18, 2010, 11:32:28 PM
Could be the power supply. Plugging in the USB hub will draw more power, even if its only a little as your hub has its own power supply. If this is the case, the plug should stop booting even without the hub attached pretty soon as the power supply gets worse quickly once the capacitors have lost their electrolyte. NewIT sells replacement power supplies for around 10 bucks but shipping outside of Europe is expensive. Or you could hook up an external 5V power supply with around 10-15W.

Could be something else, of course, but it seems the original power supply will always fail sooner or later.

BTW, I've seen this kind of failure on other devices as well. My NSLU2's power supply failed the same way after one year of uptime. Switching power supplies require special low-ESR capacitors with high temperature tolerance but for some reason it seems many manufacturers want to save the few cents those capacitors would cost extra...

33  Linux Stuff / General Linux questions / Re: cups 1.4.4-1 update crashes debian server on: August 10, 2010, 02:57:17 AM
That would explain why cups now hangs on the plug. If they disabled the parallel printer module in the kernel but  cups is still trying by default to load their LP_MODULE, well let the crying begin. That make perfect sense, because as part of the apt-get dist-upgrade the new 2.6.32-5-kirkwood was installed when my problem started.



Cups hanging during startup is one thing but crashing the whole system is another. I haven't really looked into this, nor do I have cups on my plug, but if a module crashes the kernel when loading, the module is seriously broken and either needs to be fixed or removed from the default configuration (which Martin just did).

Loading modules for non-existant hardware or trying to load a module that doesn't exist at all should only give you an error message, not crash anything.

34  Hardware and U-Boot firmware / U-Boot stuff / Re: serial port sends mess after kernel started on: August 03, 2010, 03:04:01 PM
This could be related to the incorrect clock rate detected by older Linux kernels on later revisions of the CPU which used by the Sheevaplugs since a couple of months. Just a guess...

35  Hardware and U-Boot firmware / U-Boot stuff / Re: serial port sends mess after kernel started on: August 02, 2010, 02:03:40 PM
You console arguments in uboot seem to be messed up. There was a similar problem in another thread -- http://plugcomputer.org/plugforum/index.php?topic=2042.msg11950#msg11950 -- where the console args were messed up and couldn't be set properly. Searching the forum for "a0000" in console boot arguments seems to yield additional theads.

36  Hardware and U-Boot firmware / U-Boot stuff / Re: uboot-envtools on: July 26, 2010, 04:09:58 AM
Looks like we got two threads in one Wink

b382f29, you're referring to configuration files for the uboot-envtools package on Debian/Ubuntu.

e-squizo is talking about the tools he wrote some time ago for Sheevaplugs, sheeva-uboot-tools, and problems with the way the Guruplug stores the configuration data.

I guess the reason why the uboot-envtools are working with Guruplugs (they don't work on Sheevaplugs) is the same reason why e-squizo's tools stopped working with the Guruplugs:

  • Sheevaplugs use 4-bit ECC for uboot and the configuration.
  • Guruplugs use 4-bit ECC for uboot but 1-bit ECC for the configuration.

37  Hardware and U-Boot firmware / Hardware / Re: SheevaPlugs with a - (dash) in the S/N from GLOBALSCALE on: July 21, 2010, 10:48:30 AM
Stupid question: could the console baud rate be incorrect? It seems unlikely that a corrupt kernel image prints this much crap before crashing...
38  Linux Stuff / Kernel / Re: Kernel SD root device with/without attached eSATA on: July 18, 2010, 02:37:25 AM
Did you connect the SD card via a USB adapter? The native SD card slot on the plug should give you device names like /dev/mmcblk0p1 for partition 1 and you shouldn't have the problems you described

If you connected the SD card via a USB adapter, you should be able to change the order in which the USB and SATA drivers are loaded by editing /etc/modules and adding the module usb_storage to the top of the file. This way, USB disks will be detected first regardless whether the eSATA disk is attached or not. Unless, of course, it takes too long for the USB stack to get up and running. In this case, you could try to add some delay after loading the USB modules in modprobe.d. Something like this:


install usb_storage /sbin/modprobe --ignore-install usb_storage; /sbin/sleep 10

If you use a kernel with an initial ramdisk, you would [also] update /etc/initramfs-tools/modules and recreate the initial ramdisk. Not sure whether the NAND kernel uses an initial ramdisk off the top of my head and whether this initial ramdisk might load SATA or USB drivers but I don't think so because the NAND kernel only needs a driver for the NAND to boot.

39  Linux Stuff / Kernel / Re: new release on: July 18, 2010, 02:18:53 AM
I couldn't see any messages around sata_mv in any of the logs. What happens when you type "rmmod sata_mv", then "modprobe sata_mv", then "dmesg"? Do you get any messages from sata_mv at all?

BTW, the new kernels have official support for eSATA plugs but they use a different acrNumber for this. The original plug uses 2097 as arcNumber, the eSATA plug uses 2678. You will have to set the arcNumber in uboot to 2678 to get eSATA working with the official kernels.

40  Hardware and U-Boot firmware / Hardware / Re: Sheeva PSU preventive maintenance on: May 31, 2010, 09:23:28 AM
Thanks, Patrick,

I can only second your warnings for everybody reading this. I once ruined a screwdriver discharging a high-voltage capacitor in an old valve radio. I thought the capacitor had already discharged and just wanted to play it safe but it must have had the full charge for such an effect and this would mean around 311V (220VAC in Germany back then). These days we have 240VAC/340V peak...

Back to the subject: so you would say only those two capacitors need replacing? I was wondering whether I should replace all of them while I'm at it... Also, do you remember the size of those two (diameter and height)?

41  Hardware and U-Boot firmware / Hardware / Sheeva PSU preventive maintenance on: May 31, 2010, 06:26:33 AM
Hi all,

my Sheevaplug is constantly powered on for a couple of months now (240VAC, although limited to around 230VAC by UPS) and the repeated stories about failing power supplies make me expect mine to fail pretty soon. Instead of hooking up an external PSU, I'm planning to replace the capacitors with better ones before they dry out completely.

However, I use this box as my central home server (email, DNS, Internet, ...) and I'm afraid that the capacitors have aready degraded to the point where it won't turn on after I opened it up to find out which capacitors I actually need...

Does anyone of you have a list of capacitors (capacity, voltage and approximate size) in the Sheevaplug PSU?

While waiting for a reply, I guess I'll try and see whether I can get a backup of the plug's root disk working on my desktop under qemu-system-arm -- I always wanted to see whether this is a viable solution for temporarily replacing the plug with a desktop while getting the plug itself fixed...

42  Hardware and U-Boot firmware / Hardware / Re: Bad erase block? on: May 04, 2010, 11:06:51 AM
No, that's perfectly normal. Flash chips almost always have bad blocks and have mechanisms to deal with it. For example, the boot load can skip over bad blocks and flash file systems such as JFFS2 and UBIFS know how to handle them. As it stands, a single bad erase block is actually pretty good Wink
43  General Category / General Discussion / Re: External Drive Spin Down? on: May 03, 2010, 12:04:30 PM
... or tell the kernel to log each block device access by doing

echo 1 >/proc/sys/vm/block_dump

The information will show up in the log files and in dmesg output; the log files will create additional I/Os, of course, but those can be identified easily in the output. Make sure you turn this off after your tests are done to prevent tons of log information being written.

BTW, you might want to stop the syslog daemon and use dmesg to get the block dump but writes to log files are one of the primary reasons for disk spinups so you may be better off leaving the syslog daemon running and discaring all information related to the log file with the block dump trace.
44  Linux Stuff / Kernel / Re: Esata Kernel problems on: April 27, 2010, 07:21:15 PM
The initrd image is created independentlly from the kernel build. It's basically a ramdisk with a bunch of modules required to boot plus some scripts and executables required to to get the system up an running. The main point is to load all modules required to access the root filesystem -- adapter driver modules, filesystem modules, etc. Once root has been mounted, the boot process continues without the initrd image and all memory associated with the ramdisk is released.

BTW, creating a kernel with all drivers required to mount the root file system compiled right into the kernel is perfectly legitimate -- initrd images are mainly used to allow distributions to adjust to different hardware environments without having to recompile the kernel.
45  Linux Stuff / Kernel / Re: Esata Kernel problems on: April 27, 2010, 03:31:21 PM
The short answer is "yes". initrd images are usually created/updated more or less automatically but if anything fails, debugging is a bit tedious.

Regarding the problem extracting the initrd image: uInitrd is an initrd image with a u-boot header. You won't be able to use gunzip and cpio to look at the contents unless you remove the u-boot header. In order to keep things simple, I would suggest to focus on the original initrd image:

$ cd /tmp
$ cat /path/to/initrd | gunzip | cpio -id

Pages: 1 2 [3] 4 5